Role-Based Access Control for Restaurant POS: Model Actions, Not Job Titles

A cashier, kitchen worker, manager, and owner need different access. But a role name by itself is not a security rule.

In OrderRestro, permissions represent capabilities such as creating orders, managing tables, viewing reports, or processing refunds. Seeded roles are bundles of permissions, and the individual permissions can be adjusted. The backend checks those capabilities when protected actions are requested; the interface can hide controls, but hiding a button is not enforcement.

This model is more flexible than hardcoding checks like “if role equals manager.” Real teams often have exceptions: a supervisor who can issue refunds but cannot export payroll, or an inventory lead who can receive stock but cannot change user access.

Granularity has a cost. A list of dozens of permission keys can become impossible to understand. Permission names should map to tasks people recognize, and an admin screen should show the effective access clearly. Defaults need to be sensible, and changes should be auditable.

When reviewing a POS access model, test both directions: can each person do the work they need, and can they reach actions outside their responsibility by calling the API directly? A role matrix is a starting point; an authorization check on every sensitive operation is what makes it real.

The current permission model and project scope are documented in the OrderRestro repository. I write about the engineering behind business software at RaktimRanjit.com.