Bỏ qua để đến nội dung

Stores (Admin)

Nội dung này hiện chưa có sẵn bằng ngôn ngữ của bạn.

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.


GoalsNon-goals
CRUD stores within correct vendor / tenancyManage vendor POS terminal keys (see technical POS docs)
Link to tenancy modelDocument 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).

  1. Open Stores → search/filter → select store.
  2. Create → bind vendor/address (and any legacy zone fields the form still exposes) → save.
  3. 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.

IDScenarioExpected
S1Admin lists storesRows allowed by role and filters
S2Create storePersists; visible to vendor if linked
S3Cross-tenant ID tamperingAPI 403 / not found

PathPurpose
/dashboard/storesStore list
/dashboard/stores/createCreate store
/dashboard/stores/:idStore detail
/dashboard/stores/:id/editEdit store
  • Search — debounced (400ms).
  • Pagination10 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).