3.1 KiB
ADDED Requirements
Requirement: Storefront content management
The platform console SHALL manage the four home-content kinds — banners, promos, quick links and floor adverts — on a content page reachable from the console navigation, loading every entry including inactive ones through the shared API adapter. Each kind SHALL be edited as its ordered list of rows with add, remove and reorder controls (no drag and drop), the per-entry fields the API accepts, an active flag per entry, and a preview of how the storefront renders each entry. Saving a kind SHALL submit the whole edited list in its displayed order as one replacement with the semantics of PUT /api/admin/content/{kind}, so positions follow the submitted order and the other three kinds are untouched. Rows SHALL be validated before any request with the rules the API enforces — non-empty image and destination URLs, non-empty glyph, and non-empty en and zh quick-link labels in { en, zh } JSONB text — with inline field errors on failing rows. Saves SHALL give clear success feedback; a rejected save SHALL keep the edited rows and show a visible failure message.
Scenario: save replaces one kind only
- WHEN an admin reorders banners, saves that kind, and the mall reloads its home content
- THEN banners appear in the new order while promos, quick links and floor adverts are unchanged
Scenario: invalid row is blocked before submit
- WHEN an admin leaves a banner image URL empty and saves
- THEN the row shows an inline field error and no replacement request is sent
Scenario: rejected save keeps the editor state
- WHEN the API rejects a replacement
- THEN the page shows a failure message and keeps the edited rows for correction
Requirement: Brand management
Platform admins SHALL manage the ordered brand registry on a brands page reachable from the console navigation, through the shared API adapter. The page SHALL edit the whole list — slug, non-empty { en, zh } names and an active flag per row — with add, remove and reorder controls and a preview of each brand as the public list serves it. Saving SHALL replace the whole list in its displayed order so positions follow the submitted order. Slugs SHALL be validated against the ascii a-z, 0-9, - pattern and duplicate slugs and incomplete bilingual names SHALL be rejected with inline errors before any request is sent. Saves SHALL give clear success feedback; a rejected save SHALL keep the edited rows and show a visible failure message.
Scenario: replace round-trips to the public list
- WHEN an admin reorders brands, renames one, and saves
- THEN the public brand list returns the same entries in the submitted order
Scenario: duplicate slug is blocked before submit
- WHEN an admin saves with two rows carrying the same slug
- THEN the duplicate rows show inline errors and no replacement request is sent
Scenario: save feedback distinguishes success and failure
- WHEN a save succeeds or the API refuses the list
- THEN the page shows a success confirmation or keeps the edited rows with a failure message, respectively