Discussion: scanned table QR ordering page should not show table-bound order history; order history should be tied to the consumer, not the table

[firefoxwang]

Type

Design discussion — not a bug fix; requires human engineers to discuss and decide before development. Without a decision reached, Agents must not start development (Human in the loop).

Origin

This discussion mirrors GitHub issue #350 (#350). GitHub removed the "Convert to discussion" feature, so we re-created it here. Original issue stays as the source of truth for agent task tracking.

Background

The scanned ordering page (/menu/{table_token}) currently loads and displays the order history of that specific table:

• Backend public endpoint GET /menu/{table_token}/order-history (back/app/main.py): no login required, returns the most recent paid/completed orders for that table (default 10, max 50).
• The frontend ordering page calls this endpoint automatically and renders an "Order history" section (front/src/app/menu/menu.component.ts / menu.component.html).

Problems

1. UX problem: Consumers scan the QR code to order, not to browse past orders. If a table has been used for a long time, its history accumulates (potentially 100+ orders), and rendering all of it on the page distracts from the core ordering flow and hurts the experience.
2. Privacy problem: Table-bound history is exposed to anyone who scans the same code. These orders belong to different groups of consumers and include line-item details, which may contain personal preferences, allergies/intolerances, and other sensitive information. This is consumer privacy and should not be exposed indiscriminately per table.
3. Wrong ownership model: Order history fundamentally belongs to the consumer, not the table. Binding orders to tables both leaks privacy and prevents consumers from viewing their own history across tables and venues.

Proposed direction (open for discussion)

Core principle: order history on the ordering page must be bound to the consumer (logged-in account), not to the table.

Scenario 1: Logged-in consumer placing an order

• May display "my own order history" (suggested: most recent 3 orders), not necessarily restricted to the current table.
• Data source should be based on the consumer login identity (account), not the table token.

Scenario 2: Anonymous (not logged in) table ordering

• By default, do not show the table order history, avoiding privacy leaks and UX distraction.

Questions that need discussion/decision

1. Should table-bound order history be fully hidden from ordinary consumers, or only limited to "the current session at this table today"?
2. Should we keep showing "orders placed at this table in the current session that are not yet settled" (e.g. the multi-person-add-orders scenario at the same table)? How should this be distinguished from "historical orders"?
3. For logged-in consumers ordering at the table, do we need to integrate account login/linking into the table ordering flow so orders are written with Order.customer_id? (A starting point already exists in GET /customer/orders in customer_routes.py, but the public flow currently does not attach an account.)
4. Should "hidden before login, show most recent 3 after login" be the default history-display policy?
5. Should we keep an operations/table-level view (e.g. in the back-office) for viewing table orders, only removing it from the consumer-facing page?

Constraints

• This discussion is for decision only and produces no code changes; development tasks should be split off only after human engineers reach a decision on the questions above.
• Agents must not start development bypassing this discussion (Human in the loop).

[raro42]

Table token was ment to be unique per scan.

Need to review

[raro42]

1. Should table-bound order history be fully hidden from ordinary consumers, or only limited to "the current session at this table today"?

Table history should be bound to current token.

2. Should we keep showing "orders placed at this table in the current session that are not yet settled" (e.g. the multi-person-add-orders scenario at the same table)? How should this be distinguished from "historical orders"?

Yes show them. As always bound to the token.

3. For logged-in consumers ordering at the table, do we need to integrate account login/linking into the table ordering flow so orders are written with Order.customer_id? (A starting point already exists in GET /customer/orders in customer_routes.py, but the public flow currently does not attach an account.)

Yes, add customer account. I thought this was already working.

4. Should "hidden before login, show most recent 3 after login" be the default history-display policy?
   Only show relevant customer orders. Always bind them to either the login or the token.

5. Should we keep an operations/table-level view (e.g. in the back-office) for viewing table orders, only removing it from the consumer-facing page?

Back Office should always be able to see any order from any table at any time. Also historical order per table, per customer.

[raro42]

re-opened #350