The permission grid in a member's editor shows the effective value: the role default unless an override exists. Changing a box stores an override; setting it back to the role default deletes the override rather than keeping a redundant one. Changing someone's role clears their overrides.
Also called: custom permissions · exception for one person · give this guy extra access
- 1Effective value = custom override if present, otherwise the role's value; differences render in accent colour and bold.
- 2Setting a box back to the role's value removes the key, and an empty override object is stored as none at all.
- 3Overrides are saved to the person's account via /api/users/[id]/role, and an explicit clear is sent as null so the server does not keep a stale override.
Real crews do not fit five templates — a trusted lead may need to approve labour, a PM may not be allowed to delete. The clear-on-null behaviour has its own comment: without it 'the server keeps the old override even after the admin removed it'. Overrides live on the server account precisely because the previous localStorage version could be self-granted from DevTools.
- Role templates could not express one-off exceptions.
- Removing an override left the old value in place server-side.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →