Every role comes with default permissions. When you want to grant one extra capability to a specific person — or revoke one — use the per-staff override editor. Only the owner can set overrides.
Where to find the editor
Two ways to reach it — same editor, same effect:
- Sidebar: Settings → Permissions — the pharmacy-wide matrix showing every staff member's overrides in one grid. Good for cross-team decisions.
- Sidebar: Staff → click the staff member — that member's own overrides on their detail page. Good when you're focused on one person.
Both are owner-only. Managers see the staff directory but not the permission editor.
How the tri-state works
Every permission shows one of three states per staff member:
| State | Meaning |
|---|---|
| Default | Follow the role default. Whatever manager / dispenser / accountant gets by default, this person gets. |
| Allow | Grant this permission to this specific person, overriding the role default. |
| Deny | Revoke this permission from this specific person, overriding the role default. |
Click a state to switch. Changes save immediately.
Example — Let a dispenser refund sales
By default, dispensers can't refund sales. To grant refund permission to one trusted dispenser:
- Sidebar: Staff → click the dispenser.
- Find manage_refunds in the permission list.
- Click Allow.
Their next login will pick up the change.
Making a change take effect immediately
Permission changes usually reach a staff member within about 30 minutes — whenever their session next refreshes. To make it apply right away (say, before they process a refund), open their staff detail page and click Sign out everywhere. They'll be signed out of every device; on next login they pick up the fresh permissions.
What accountants can NEVER do
Certain actions are always blocked for accountants, no matter what:
- Recording a sale
- Processing a refund
Granting sales permission to an accountant does nothing — the action still refuses to run. This is by design: accountants are for reporting and financials, not till operation.
Two layers, always in sync
RxShelf checks permissions in two places, always in sync:
- The app — buttons hide, pages redirect, actions refuse.
- The server — every action is re-checked when it runs.
Both layers use the same source, so an override propagates cleanly: grant a permission → the button appears in the UI and the action succeeds when clicked.
Next steps
- Refund a sale — a common override use case.
- Invite your first staff member.