#195 and #203 made the cart say a demo order is a demo order. The durable record still does not.
A minute after checking out, the customer opens /orders and sees a row: item name, $80.00, status completed, processor demo, date. frontend/src/customer/Orders.tsx:22-42 renders processor as a raw column value under a heading of "Processor" — it is not an explanation, and a customer has no reason to read demo as "this did not happen". STATUS_COLORS at :22-26 has no completed key, so <Tag color={undefined}>completed</Tag> renders neutral, visually identical to a real fulfilled order.
So the fix covers the three seconds after the click and leaves the permanent record unqualified — which is the record the customer will actually go back to when they wonder where their item is.
The backend already carries everything needed: orders.processor = 'demo' is written at backend/src/routes/cartCheckout.ts:192 and selected at backend/src/routes/customers.ts:562. This is presentation only.
Fix
Render processor === 'demo' explicitly — a "Demo (not charged)" tag, or a row-level note. Whatever the wording, it has to be legible to someone who does not know what "processor" means.
Worth deciding at the same time whether a demo order should appear in order history at all, or appear in a separated group. It is a real row in a real table, so hiding it would be its own kind of lie; labelling is probably right.
Found by
Code review of #195 (456e1aa), raised as Important 3 — out of that issue's letter but inside its stated standard, "whatever the storefront tells the customer after the click".
#195 and #203 made the cart say a demo order is a demo order. The durable record still does not.
A minute after checking out, the customer opens `/orders` and sees a row: item name, `$80.00`, status `completed`, processor `demo`, date. `frontend/src/customer/Orders.tsx:22-42` renders `processor` as a raw column value under a heading of "Processor" — it is not an explanation, and a customer has no reason to read `demo` as "this did not happen". `STATUS_COLORS` at `:22-26` has no `completed` key, so `<Tag color={undefined}>completed</Tag>` renders neutral, visually identical to a real fulfilled order.
So the fix covers the three seconds after the click and leaves the permanent record unqualified — which is the record the customer will actually go back to when they wonder where their item is.
The backend already carries everything needed: `orders.processor = 'demo'` is written at `backend/src/routes/cartCheckout.ts:192` and selected at `backend/src/routes/customers.ts:562`. This is presentation only.
## Fix
Render `processor === 'demo'` explicitly — a "Demo (not charged)" tag, or a row-level note. Whatever the wording, it has to be legible to someone who does not know what "processor" means.
Worth deciding at the same time whether a demo order should appear in order history at all, or appear in a separated group. It is a real row in a real table, so hiding it would be its own kind of lie; labelling is probably right.
## Found by
Code review of #195 (`456e1aa`), raised as Important 3 — out of that issue's letter but inside its stated standard, "whatever the storefront tells the customer after the click".
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
#195 and #203 made the cart say a demo order is a demo order. The durable record still does not.
A minute after checking out, the customer opens
/ordersand sees a row: item name,$80.00, statuscompleted, processordemo, date.frontend/src/customer/Orders.tsx:22-42rendersprocessoras a raw column value under a heading of "Processor" — it is not an explanation, and a customer has no reason to readdemoas "this did not happen".STATUS_COLORSat:22-26has nocompletedkey, so<Tag color={undefined}>completed</Tag>renders neutral, visually identical to a real fulfilled order.So the fix covers the three seconds after the click and leaves the permanent record unqualified — which is the record the customer will actually go back to when they wonder where their item is.
The backend already carries everything needed:
orders.processor = 'demo'is written atbackend/src/routes/cartCheckout.ts:192and selected atbackend/src/routes/customers.ts:562. This is presentation only.Fix
Render
processor === 'demo'explicitly — a "Demo (not charged)" tag, or a row-level note. Whatever the wording, it has to be legible to someone who does not know what "processor" means.Worth deciding at the same time whether a demo order should appear in order history at all, or appear in a separated group. It is a real row in a real table, so hiding it would be its own kind of lie; labelling is probably right.
Found by
Code review of #195 (
456e1aa), raised as Important 3 — out of that issue's letter but inside its stated standard, "whatever the storefront tells the customer after the click".