# Staff access deployment

1. Apply `migrations/2026-09-12-add-admin-audit-log.sql` before deploying the backend. The earlier admins/staff schema must already exist. Mutating admin requests require the audit table; missing audit storage blocks writes instead of allowing unrecorded changes.
2. Deploy backend and frontend together.
3. Sign in as Super Admin, open **Staff & Permissions**, select tabs and actions, then **Save permissions**. New staff accounts start with no permissions. Adding an action also adds its View permission.
4. Staff authorization uses the current database record on every request. Revocations and disabled accounts therefore take effect on the next API request, even with an old JWT. The open panel refreshes its profile every 15 seconds and on access-denied responses, and discards cached admin data on changes.
5. Open **Staff & Permissions → Activity history** to review attempted authorized mutations and their result. No passwords, tokens or full request bodies are stored. Logs contain actor, method, resource path, selected changed values and response status. An interrupted request can leave a pending record; this is an operational action log, not a complete before/after database audit.

## Access boundaries

- View, Add, Edit/Update, Delete, order cancellation and notification sending are separate permissions. Unknown permissions and staff wildcards are rejected. Unknown admin API routes default to Super Admin-only until mapped.
- Staff management, audit history, Settings and Profit & Loss remain Super Admin-only. Existing `admin` accounts keep their operational access, but are not granted those Super Admin capabilities.
- Online Pending viewing no longer authorizes contact updates. Grant **Update Online Pending** explicitly. Converting an online-pending customer to premium also requires **Premium Customers → Add**.
- Product, Stock, Master Products and offer screens share read-only catalog/vendor/category lookups. These lookup allowances do not grant edit actions or access to unrelated pages. Stock updates are separate from editing a product. Master Products updates control the master flag; full product editing requires Products → Edit.
- Viewing order details from COD/feedback or customer details from offers requires the corresponding Orders/User Info permission. Selecting one report does not implicitly grant unrestricted customer/order access.
- Some existing screens are placeholders (Customers, Wholesale, Offline Purchase, Settings); permissioning does not add functionality to those screens.

## Maintenance and validation

The backend source of the catalog and HTTP policy is `config/adminAccess.js`. Keep `yumistry-app/src/utils/adminAccess.js` identical apart from the final CommonJS/ES-module export. `test/adminAccess.test.js` checks parity when both repositories are present and verifies that every mounted admin-authenticated endpoint has an explicit policy.

Run `npm test` in the backend and `npm run build` in the frontend. Browser smoke checks should cover a no-access staff account, premium view-only, premium Add/Edit, revoked access in an already-open session, and Super Admin staff/audit screens. Apply migration and use test accounts on staging before rollout.