Understand school order context
Customer App can conditionally present a school-oriented business, student selection, filtered menu, cart warnings, and Checkout student section. These surfaces handle private minor and school context. Visibility does not prove that the selected student is authorized, that every product was filtered consistently, or that the cart, payment, and order carry the same student.
This is a state and safety overview. It does not provide student, product, cart, payment, or order procedures.
Authorized student context
One school-order journey needs one current, authorized student context bound to the exact account, project, school/business, session, cart, and revision.
| State | Safe interpretation |
|---|---|
| Student selector absent | Current business/config/account state does not present the control; student existence is not disclosed |
| Students loading | Authorized student inventory is unresolved; no automatic selection or cart assignment is established |
| No eligible student | No current student matches the school context; do not reuse a student from another business or account |
| One student auto-selected | Local selected context changed; cart assignment and later order propagation remain separate |
| Student selected-looking | Local business-scoped selection references one student; authorization and cart settlement still require proof |
| Student becomes invalid | Clear the stale selection and block product/cart/Checkout continuation without revealing minor data |
Student identity must be partitioned by current account, project, and school. Account, project, business, or session changes must clear stale student context and reject late results.
Filtering must be consistent
Student-aware filtering can occur at different layers:
| Layer | Required boundary |
|---|---|
| Business read | The authorized student can constrain the returned school business/menu projection |
| Category and product list | Every visible category, product, search result, featured item, and lazy-loaded page must use the same student generation |
| Deep product | A directly opened product must be reauthorized and filtered with the same current student, not trusted from navigation parameters |
| Product customization | Options, ingredients, allergens, dietary tags, availability, and price must remain consistent with the authorized product projection |
| Cart | Added historical product data does not prove current compatibility or student assignment |
The pinned source applies student context inconsistently across these layers and can retry a business read without the student after certain errors. A visible product is therefore not a dietary, school-policy, availability, or safety guarantee.
Dietary and allergy information is advisory
Customer App can compare returned product tags with student allergy or dietary tags and present a conflict warning. The customer can keep or remove warned items. That comparison is advisory only.
Do not describe it as medical screening, allergen-free certification, dietary compliance, cross-contact protection, ingredient completeness, or professional advice. Data can be missing, stale, differently named, incomplete, or supplied by separate parties. The business and responsible adult retain the applicable real-world safety process outside this documentation.
No student name, school, classroom, grade, allergy, dietary, health-adjacent, or product-conflict value belongs in screenshots, logs, diagnostics, or support notes.
Cart warning and assignment settlement
| Visible event | Safe interpretation |
|---|---|
| Student selection changes | Local business-scoped selection changed; cart assignment can start automatically |
| Cart warning opens | A local comparison found advisory conflicts for the current visible cart/student state |
| Keep items | The warning was dismissed; product suitability or order authorization is not certified |
| Remove items | One or more product-removal operations can start and settle independently |
| Warning closes | Local modal state changed; removals, cart refresh, assignment, and totals can remain pending |
| Cart displays a student | Returned cart state contains a student relation; ownership and current selection still require reconciliation |
Student selection and Checkout student UI can automatically request cart assignment or clearing. Those are mutation effects, not a read-only selector. An optimistic selection, warning, or refreshed cart is not a versioned assignment receipt.
Checkout requires authoritative context
School Checkout can block Place when no selected student is visible. That client gate is necessary but not sufficient. Before placement, the server must confirm:
- the current account is authorized for the student and school;
- the cart is assigned to that same student and current revision;
- every cart item belongs to the authorized business/product projection;
- address, fulfillment, schedule, customer, amount, and payment state are current;
- advisory dietary data is not converted into an unsupported safety decision; and
- the resulting order stores only a purpose-minimal student relation.
A selected student, enabled Place control, provider result, navigation, or order card does not prove those conditions settled.
Product, payment, and order handoffs
Product selection/customization, cart add/update/remove, Checkout, payment, provider confirmation, Place, order creation, and Order Details are separate owners. A failure or stale student context at any boundary must stop or preserve an unknown outcome; it must not silently fall back to an unfiltered product or a different student.
Order Details must use a minimal student projection and must not expose school, dietary, allergy, or health-adjacent data merely because the order exists.
Unknown and partial outcomes
| Situation | Safe interpretation |
|---|---|
| Student clears after a business error | Prior filter/authorization failed or became stale; do not continue with fallback menu as student-safe |
| Category/product/deep-product results disagree | Filtering generations differ; product eligibility is unknown |
| Warning appears after product add | Cart accepted data before advisory comparison; no suitability or rollback follows |
| Some conflicting items are removed and others remain | Exact per-item/cart outcome is partial; do not infer cleanup |
| Cart student differs from current selection | Assignment and local context disagree; block Checkout/Place |
| Checkout section appears or disappears | Config/account/cart/student generation changed; no minor-data inference follows |
| Place response is lost | Student assignment, payment, order, provider, and cart outcomes are unknown; do not repeat automatically |
| Account/project/school changes | Discard prior student/menu/cart/order state and reject late callbacks |
Troubleshoot safely
- Confirm only the state class: no student, selected-looking, filter mismatch, advisory warning, assignment mismatch, or unknown placement.
- Do not switch students repeatedly to test filtering or cart assignment.
- Do not add/remove products, dismiss warnings, change cart/payment state, or use Place as a diagnostic.
- Do not rely on a product page, tag, warning, or missing warning for allergy or dietary safety.
- If category, product, deep-product, cart, and Checkout disagree, stop and preserve the mismatch without copying private data.
- Never use a real student's information in documentation, fixtures, support notes, screenshots, or testing.
Accessibility and privacy
School/business scope, selector, loading, no-student, selected, stale, invalid, filter mismatch, advisory warning, Keep/Remove, assignment, Checkout required, Place blocked, partial, and unknown states need explicit semantic text. Controls need names, roles, selected/disabled/busy state, consequences, focus order, and announcements without reading private student or health-adjacent values.
Large text, keyboard, screen reader, modal focus, safe area, reduced motion, and Back behavior must not hide warnings or trigger automatic student/cart actions. These are verification requirements, not current privacy, accessibility, dietary, allergy, school, payment, or order certification.
Recertification triggers
Revalidate after changes to student authorization/partitioning, onboarding or selector auto-selection, business/category/product/search/lazy/deep-product filtering, advisory tag matching, Keep/Remove behavior, cart assignment/clearing, Checkout student gate, product/cart/payment/Place/order handoffs, minimal order projection, account/project/school/session cleanup, privacy, or accessibility.
Related guides: Review school ordering options · Browse a business menu · Customize a product · Review your cart before checkout · Review customer and delivery details · Understand order details and status