Preorder requests
Route: /org/ecom/preorder-requests · Permission: Open the page; read the queue of Preorder request
To decide: Approve / reject a preorder request · Module: org_ecom_preorder_request
1. What a preorder request is
"Visitor-submitted requests for pre-order items." A customer asks for something on a future date; the store says yes or no. It is not an order — no money, no fulfilment, nothing in the orders workbench — until it is approved.
| Preorder request | Order | |
|---|---|---|
| Created by | A visitor asking | Checkout, or staff |
| Money | None | Yes |
| Needs a decision | Yes | No |
| States | pending · approved · rejected · cancelled | Six order statuses |
2. How a request is decided
The backend allows moves between all three of pending, approved and rejected — so an accidental approve or reject is undone by dragging the card back. There is no one-way door here.
3. Two views over one queue
| View | Shape |
|---|---|
| List | A flat vertical list with status tabs and pagination |
| Kanban | Three columns with real drag-and-drop |
Both read the same data and commit through the same review mutation — "Drag a card between columns to change its status." The empty Rejected column invites it: "Drop a card here to mark it rejected."
The filter presets
| Preset | Shows |
|---|---|
All requests | Everything |
Pending only | Awaiting a decision |
Pending + last N days reviewed | The worklist plus recent history |
Pending + upcoming approved | What is outstanding and what is coming |
Upcoming dates only | Future requests |
Approved only / Rejected only | History |
A Group by date toggle and a request count sit beside them.
4. Field reference — a request card
| Element | Holds |
|---|---|
| Item | Image, name, and a PRODUCT or PACKAGE chip |
| Quantity | ×n |
| Requested date | The date the customer wants |
| Requester | Name, email, phone — masked in these figures |
| Requested section | e.g. Lunch, Dinner |
| Submitted | When the request arrived |
| ADMIN RESPONSE | The response note, once reviewed |
| Approve / Reject | Present with review |
The scheduling conflict warning
A card can carry an amber notice:
⚠ This item is already scheduled in Dinner on this date · VIEW ›
It tells you the same item already appears on a showcasing schedule for that date and section, with a link to look. Approving anyway is allowed — the queue trusts the reviewer.
It is the one signal that a request duplicates existing capacity, so it is worth reading before approving in bulk.
5. The admin contract
| Prerequisite | Without it |
|---|---|
| Open the page; read the queue of Preorder request | No access |
| menu Listing of Preorder requests | No sidebar entry |
| Approve / reject a preorder request | The queue is read-only — no Approve, no Reject, no drag |
| Preorder-able items | Nothing to request |
| Preorder timing | No constraint on how far ahead |
| Showcasing schedules | Approvals have nothing to attach to |
6. Downstream
| Effect | Where |
|---|---|
| Approved request | May be auto-attached to a schedule by Operation Automation |
| Response note | Shown on the card as ADMIN RESPONSE |
| The customer's view | Preorders and support |
7. Don't confuse this with…
| Thing | Why it differs |
|---|---|
| Preorder request (this page) | A request awaiting a decision |
| Order | Real, with money |
| Showcasing schedule | When items are offered |
| Preorder timing | How far ahead a request may be made |
8. Troubleshooting
| Symptom | Cause |
|---|---|
| No Approve / Reject and no dragging | Missing Approve / reject a preorder request |
| An approved request is not in Orders | Approval does not create an order |
| The conflict warning appeared | The item is already scheduled for that date and section |
| A card was approved by mistake | Drag it back — every transition is allowed |
| Counts differ from the list | A filter preset is applied |