# Administrator Account and Deployment Setup

> **Security warning:** Do not put real production passwords in this file, source code, screenshots, or a public repository. Keep actual credentials in a password manager or configure them privately in the deployment environment.

## Active roles

The application supports three roles:

| Role | Access |
|---|---|
| Administrator | Manage users and menu, view reports and orders, and verify or reject manual customer payments. |
| Cashier | Review pending customer-submitted GCash receipts only. Approval requires the existing receipt, exact merchant reference, and amount checks. Cashiers cannot create walk-in orders, change order status, record counter payments, or use administration pages. |
| Customer | Place orders, submit payment receipts, and view only their own account, order, and payment information. |

Staff is an obsolete role. Existing staff accounts are not automatically converted to another role. Migration 14 disabled legacy Cashier/Staff accounts; migration 15 restores Cashier as a restricted receipt-review role. Legacy accounts are not silently reactivated or converted. Existing user, order, receipt, and payment history is preserved.

## Secure account setup

1. Create the first Administrator using the existing one-time setup process or private environment variables. Disable/remove the setup mechanism after provisioning.
2. Create Administrator, Cashier, or Customer accounts through the protected Users page. Use a separate account and unique password for each person. Cashier permissions are enforced by the order and receipt endpoints.
3. Use a unique password of at least 8 characters. Passwords are hashed on the server and are not displayed again after creation.
4. If migrating an existing database, back it up and restore-test a separate copy before applying `database/14_two_role_admin_payment_verification.sql` and `database/15_cashier_demo_accounts.sql` after all required payment-review migrations. Verify that legacy accounts remain disabled unless an Administrator deliberately reassigns an account.
5. Test permissions by directly requesting protected routes and posting to payment verification endpoints as each role. Customers must not access Administrator actions or another customer's receipt/order; Cashiers must not access non-pending receipts, general order details, or Administrator routes.
6. Store database, email, SMS, and payment-provider credentials only in the deployment environment or secret manager. Remove bootstrap secrets after setup.

## Deployment checklist

- [ ] Demo credentials remain disabled by default. If publicly enabled, use a separate demo deployment and database with no real customer or payment data; public demo administrators can change application data.
- [ ] Only intentionally provisioned Administrator, Cashier, and Customer accounts are active.
- [ ] Legacy staff accounts are disabled, not converted; historical data remains intact.
- [ ] Cashiers can review only pending customer GCash receipts and cannot access walk-in, payment collection, user, product, report, or audit functions.
- [ ] Administrator-only endpoints enforce authorization on the server.
- [ ] Customers cannot read or change another customer's profile, address, order, or payment record.
- [ ] Manual GCash stays pending until an Administrator or authorized Cashier verifies it in the merchant account.
- [ ] HTTPS, backups, restore procedures, migration review, logging, and monitoring are configured.
- [ ] End-to-end authentication, checkout, payment verification, and order tests pass in staging.