User Roles & permissions

Access in the system is role × module × level. There are 9 standard roles (Super Admin, Hotel Manager, Receptionist, Accountant, Housekeeping Mgr, Maintenance, Restaurant Mgr, HR Manager, Security) and 8 permission modules (Dashboard, Bookings, Rooms, Guests, Payments, Staff, Reports, Settings). Each role holds a level from 0 to 3 for each module. The same table drives the sidebar, the buttons on every screen and the API guard behind them, there is no separate list of "who can click what".

User Roles & Access is the screen where an administrator reads and changes that table. It is deliberately narrow: it does not create roles, rename them or assign people to them. People are given a role in Staff → Accounts; this screen only sets what a role may do.

Only a user whose Settings level is Full can open it, by default that is Super Admin alone (Hotel Manager holds Settings at "Can edit").

• Each cell is a small dropdown with the values 0–3, coloured by level.
• The Super Admin row shows a lock icon and eight fixed green 3 badges, it has no dropdowns.
• There are no filters, tabs or search; the whole matrix fits on one screen (scroll sideways on a narrow window).

The server never stores a list of actions per role. It stores one number per module and derives the actions: View at 1, Create and Edit at 2, Delete, Approve and Export at 3. Every screen and every API route is annotated with the module and the minimum level it needs, so the derivation is the same in the sidebar, on the buttons and in the guard.

Two practical consequences. A role with View only on a module sees a small lock icon next to it in the sidebar and gets read-only screens. A role with No access does not see the entry at all, and if someone types the address by hand, the page shows a module gate and the API answers 403.

The permission modules are coarser than the sidebar. When you set a level for Rooms you are also setting it for Housekeeping and Maintenance; a level for Payments covers the POS terminal, Restaurant and Inventory as well.

So a Housekeeping Manager with Rooms = Full can also close maintenance tickets, and a Restaurant Manager with Payments = Can edit can record a payment on a guest folio. If that is not what you want, lower the level, there is no finer split.

• Super Admin: Full on everything, and fixed: the server refuses to change it.
• Hotel Manager: Full on everything except Settings (Can edit), so it runs the hotel but cannot rewrite this matrix.
• Receptionist: Full on Bookings, Can edit on Rooms and Guests, View only on Payments: can see a folio but not record money.
• Accountant: Full on Payments (record, refund, settle-later at checkout), Can edit on Reports.
• Housekeeping Mgr: Full on Rooms (housekeeping and maintenance included), Can edit on Staff for the rota.
• Maintenance, Restaurant Mgr, HR Manager, Security: narrow by design; Security has View on most operational modules plus the Audit log.

1. 1
   Open User Roles

   Sidebar → User Roles. If you cannot see the entry, your Settings level is below Full.
2. 2
   Change the cells you need

   Use the dropdown in each cell (0–3). You can change several cells in one row before saving; each row saves separately.
3. 3
   Click Save on that row

   The button appears only on rows with unsaved changes. The toast reads “<role> permissions saved. Applies to signed-in users within about 15 seconds”.
4. 4
   Verify

   Ask the affected person to reload, the sidebar re-reads the levels from their session. The change is recorded in the Audit log as role.permissions.updated with the before and after levels.

"Admin tier" is what the system calls the roles that can manage roles, user accounts and the shared front-desk PIN. It is decided in two ways, and either is enough:

• By name: Super Admin and Hotel Manager, whatever their matrix says.
• By capability: any role whose Settings level is Full, whatever it is called.

Being admin-tier has three effects:

• The shared staff PIN can never sign in as an admin-tier user, those accounts always use email and password, and they are hidden from the PIN name list.
• Creating an account with an admin-tier role, or changing one, needs Settings = Full. Staff → Accounts refuses otherwise with “Only a Super Admin can manage <role> accounts”.
• The Audit log is readable (admin tier plus Security).

This is why the matrix editor refuses Settings = Full for non-admin roles: promoting, say, Receptionist to Settings = Full would make it admin-tier by capability while still being reachable through the desk PIN.

• Open User Roles, read the matrix: Settings · Full access. (View or Can edit is not enough; the sidebar entry is hidden below Full.)
• Save a row: Settings · Full access.
• Assign a role to a person: done in Staff → Accounts under the Staff module; admin-tier roles additionally need Settings · Full.

Permission module

One of the 8 areas a level is set for. Several sidebar screens can share a module.

Level

0 No access · 1 View only · 2 Can edit · 3 Full access. Stored per role per module.

Admin tier

Super Admin, Hotel Manager, or any role with Settings = Full. Excluded from PIN sign-in; may manage accounts and roles.

Module gate

The read-only or blocked state a screen shows when your level is too low for it.