Permissions
When a user cannot do something, the worst answer is a feature that silently disappears — it reads as a bug and generates support tickets. Prism's permission components make limits legible: they show that something exists, why it is restricted, and what to do about it.
The components
- LockedOverlay — a premium or gated surface. It shows the real content, blurred behind a veil, with a lock and a single path to unlock. The user sees the value before the wall.
- ReadOnlyBanner — a clear, persistent strip stating that this view cannot be edited and why (role, lifecycle stage, lock).
- RestrictedState — a full state for "you don't have access", with the route to request it.
- RoleBadge — a compact label showing the acting role, so the current permissions context is never a mystery.
Rules
- Prefer disabled-with-reason over hidden. If you must hide, hide whole sections, not individual controls, so the layout doesn't look broken.
- Always give the next step: request access, switch role, upgrade. A dead end is a failure.
- State the reason in plain terms. "Read-only while this record is in review" beats "permission denied".
- Keep restricted content reachable to assistive technology where it is shown — a blurred overlay is visual; the lock and its explanation must still be announced.