157 permissions, grouped into roles you decide
Each permission covers one action in one part of the product — creating an invoice, applying a discount, deleting a bill. A role is a bundle of them, and most shops need only a few roles, decided once.
- Roles are bundles, not presets
- You name the roles — owner, manager, counter staff — and pick which of the 157 permissions each one carries. Permissions are easier to loosen later than to claw back, so start narrow; we configure the bundles with you during onboarding.
- Owner holds every key by name
- The owner role carries all 157 permission keys explicitly rather than an admin flag that waves every check through. That is the difference between a role you can trim and one you cannot: revoke a permission from the owner and it is actually revoked.
- A new cashier starts switched off
- The capabilities that cost money when they are misused — refunds, void, price override and ledger access — are off the day a cashier account is created, and the owner turns each one on deliberately. A further 9 capabilities are manager-only and cannot be granted to a cashier at all, however the roles are edited.
- Enforced at the screen and at the API
- Menus a role cannot use never appear, and the server checks the same permission again on every request. An endpoint that forgets to declare which permission it needs returns 403 rather than running — the check fails closed, so a missing rule blocks the action instead of allowing it.
- One account per person
- Staff sign in with their own accounts, so every invoice, discount, and correction attaches to a named person. That is what makes the audit trail worth reading.