12 Commits

Author SHA1 Message Date
b5ad61eca6 chore/any-pragmatism (#1)
Some checks failed
Deploy / deploy (push) Has been cancelled
Reviewed-on: http://gitea/marcusDenslow/terminalShop/pulls/1
2026-06-06 13:02:02 +00:00
9515603b32 feat(tui): split account orders into active and history tabls
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-05-19 19:50:21 +02:00
e43040f702 feat(notify): post order vents into per-order slack threads - made by claude
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-05-15 12:25:45 +02:00
0e4d267adb fix(orders): write NULL instead of empty string for unpopulated shipp_transaction_id
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-05-15 11:27:00 +02:00
c22b64d6fa feat(shipping): shippo label purchase endpoint
Some checks failed
Deploy / deploy (push) Has been cancelled
Adds POST /api/v1/orders/{id}/label (admin-only) that buys a shipping
  label through Shippo and writes carrier + tracking + label fields back
  onto the order, transitioning paid -> shipped.
2026-05-12 20:57:11 +02:00
c5f4e492c0 refactor(orders): embed tracking on orders, drop shipments table
Some checks failed
Deploy / deploy (push) Has been cancelled
realized per-shipment table is kinda bad, switched to single embedded tracking blob. since im only
shipping from my house  no split is needed. adds tracking_status, tracking_status_details,
tracking_status_updated_at columns. reverse-backfills any historical shipments rows back onto orders
(idempotent, table-guarded). UpdateTracking rewritten to write to otder columns direcly
2026-05-09 10:08:32 +02:00
add6e573b3 feat: extract shipments to dedicated table 2026-05-08 14:54:17 +02:00
9b45fb5138 updating
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-05-08 13:43:03 +02:00
1849e324fc feat: add admin tracking updates
Some checks failed
Deploy / deploy (push) Has been cancelled
2026-05-08 10:47:57 +02:00
d5cb4259f5 fix: prevent charge-without-order by creating order before charging
When paying the application charges the card and then sends a payment
record to the database after, in a situation where something goes wrong
between those two steps, we could potentially end up where a users card
was charged but no record on what is was charged for. The fix is to
re-order ConvertCart to write a pending order record before calling
Stripe, this way a DB record always exists if anything fails
mid-operation. This implementation uses an idempotency key keyed to the
order ID to prevent double-charges on retry. Wraps the post-charge DB
updates in a transaction so marking paid andd clearing the cart are
atomic. Adds OrderStatusFailed and a CRITICAL log for the unrecoverable
case. Includes a checkout flow doc with test cards and reconcilation
steps.
2026-03-25 20:13:51 +01:00
7f07394537 something 2026-02-24 15:35:32 +01:00
59cd90b6a9 something 2026-02-23 19:51:13 +01:00