Permissions reference

The grid below is the five built-in roles against every module, verified against the server's own rules. Columns: SA Store Admin · Ca Cashier · IM Inventory Manager · RV Reports Viewer. The Administrator and the Admin role can do everything, so they are omitted; ✓ = allowed, — = not.

Before reading the grid: three rules that trump it#

• Four actions are the Administrator's alone, whatever a role says: inviting staff, enabling/disabling a staff account, creating a store, and editing or re-enabling a store. These spend the seats the business pays for, so no role unlocks them — even where the grid shows a ✓ on the underlying module.
• Reports Viewer is derived: it holds every module's view action automatically — including new features as they ship — plus all of analytics.
• A store-scoped role acts only inside its stores, and under "All Stores" holds nothing.

Selling#

The Cashier is deliberately strong here: a till that can take an order but not refund it sends the customer to find a manager.

Catalogue and stock#

The catalogue is business-wide, which is why a store-scoped Store Admin only views it — editing a product from inside one store would change every store.

Customers and discounts#

Applying a discount at checkout rides order permissions — a Cashier applies promotions without being able to author them.

Team, analytics and admin#

How a yes or no is decided#

A staff member's abilities are the union of their roles (global roles plus the selected store's), a disabled role grants nothing, and someone with no roles at all is silently view-only. Nobody can grant a permission they don't hold themselves. And the server checks every call regardless of what the screen shows — a hidden button and a refused API are two layers of the same answer.

Related pages#

Roles & permissions · Custom roles · The Administrator