Stores tie vendors to physical locations and are the main anchor for outlet-scoped data. Admins manage list/create/edit/detail under /dashboard/stores with module- and store-aware APIs.
| Goals | Non-goals |
|---|
| CRUD stores within correct vendor / tenancy | Manage vendor POS terminal keys (see technical POS docs) |
| Link to tenancy model | Document legacy stores table columns exhaustively |
- Routes include list, create, detail, edit (see table).
- Which stores appear depends on admin role
modules, explicit store_id filters, and backend checks—not a zone_id claim on the JWT (Tenancy — stores and outlets).
- Open Stores → search/filter → select store.
- Create → bind vendor/address (and any legacy zone fields the form still exposes) → save.
- Edit → update hours/contact → save.
- Validate address and contacts for PCI-adjacent workflows (delivery, BOPIS).
- Store IDs appear in vendor/POS flows—avoid leaking across tenants in screenshots.
| ID | Scenario | Expected |
|---|
| S1 | Admin lists stores | Rows allowed by role and filters |
| S2 | Create store | Persists; visible to vendor if linked |
| S3 | Cross-tenant ID tampering | API 403 / not found |
| Path | Purpose |
|---|
/dashboard/stores | Store list |
/dashboard/stores/create | Create store |
/dashboard/stores/:id | Store detail |
/dashboard/stores/:id/edit | Edit store |
- Search — debounced (400ms).
- Pagination — 10 stores per page; data from
fetchAdminStoresList (admin-user-management.api).
- New Store — button to
/dashboard/stores/create.
- Summary tiles at the top show placeholder values (—) in the current UI; they are layout placeholders until wired to overview metrics.
Each store belongs to the tenancy model (vendor, optional legacy zone columns in DB); backend rules determine which stores an admin may see or edit (see Tenancy — stores and outlets and Admin panel overview).