Roles & Permissions
Permissions in MahirRMS are granted to roles, and people get roles — never one-off permission grants that nobody remembers a year later. The permission list is organized by module and screen, so a role reads like a job description.
The default roles
A new business opens with working roles so day one doesn't start with permission archaeology:
| Role | What it's for |
|---|---|
| Cashier | The POS: sell, take payments, open and close their own register. No reports beyond their own day, no settings. |
| Manager | The floor: everything the cashier has, plus running-order oversight, day close, register visibility and the operational reports. |
| Menu Manager | The menu and nothing else: items, variants, add-ons, deals, recipes. Lets the menu owner work without broader access. |
| System Setup | Configuration: settings, users, printers, branches — for the person who administers rather than operates. |
Adjust these rather than starting from zero: rename them, trim them, clone one as a starting point for a custom role.
How permissions compose
- A permission not in your role → the screen or button simply isn't there.
- A module disabled for the business → off for everyone, whatever their role says.
- An action guarded by authorization → visible and permitted, but requires a signature to complete.
Designing custom roles
Start from the job, not the screens: list what the person must accomplish daily, grant the screens those tasks need, and stop. Two habits keep roles healthy:
- Review quarterly. Roles accrete permissions during busy weeks; a quarterly read-through of each role against real duties keeps them honest.
- Prefer a new role over a bloated one. If "cashier but also does purchasing at the small branch" keeps coming up, make that its own role instead of widening Cashier for everyone.
Permission changes take effect on the user's next sign-in. When you tighten a role, have affected users sign out and back in — and test with a real account from that role, not your administrator login.