Permissions by area and by location: how they combine in Klyra

Role and single permission are not the same thing

The role (Admin, Manager, Base or a custom role) sets the baseline package of permissions a person has. A single permission is instead a precise rule on one specific function, for example "manage goods receiving" or "approve clock-in corrections", which you can grant or revoke without changing the assigned role.

Working with single permissions is useful when a person needs an exception to their role, without having to create or edit a role for the whole organization.

Location scoping: where permissions apply

Roles and permissions never apply generically: they are always tied to the locations a person is assigned to. The same person can have the Manager role at location A and no access to location B, simply because they were never assigned to it.

This scoping is what makes it safe for multiple venues to coexist in the same organization: adding a location to a person expands what they see, removing it excludes them from that data immediately, regardless of the role they keep elsewhere.

• A role without an assigned location grants no access to operational data
• The same person can have different permissions at different locations
• Removing a location does not delete history, it only removes access from that point on

Single-site managers and multi-site managers

A single-site manager sees and manages only the venue they are assigned to: shifts, inventory, HACCP and till of that location alone. A multi-site manager instead has several locations assigned at once and, if their role allows it, can also see aggregated summaries comparing the locations.

The type of manager doesn’t depend on the role name but on the number of locations actually assigned on their user record: two people with the same Manager role can have very different scopes.

Overrides with an expiry date

For temporary needs, for example covering an absence or a time-limited project, you can grant an override: an extra permission valid only until a date you choose. Once it expires, the permission is withdrawn automatically, with no need to remember it or touch the user record again.

Expiring overrides are preferable to permanent exceptions when you already know the need is time-limited: they avoid leaving widened permissions forgotten once the need is gone.

Checking the real effect in /admin/roles/audit

Before assuming a combination of role, single permissions and locations works as intended, open the permission audit page in Users and permissions (/admin/roles/audit). There you can check, for every person, which permissions are actually active per location, including exceptions and overrides still in effect.

This check is especially useful after creating a custom role, adding an expiring override or changing someone’s assigned locations: the audit page shows the final outcome, not just the individual rules applied.