After a permission change, navigation must update rather than cache the old structure

What it is

After a role is granted or taken back, a navigation still drawn from the permissions of app-open is showing an expired map. When permission changes, navigation must change, not wait for the user to sign out and in. A cached old state leaves a just-enabled entry still missing, or a revoked entry still looking enterable.

Why it happens

Navigation is often treated as a shell computed once at launch: fetch roles, filter items, pin in memory until the next cold start. Permission, though, changes in a session — an admin enables on the spot, a trial expires, someone is removed from a project. If the shell does not recompute, the choice field and the real capability window misalign. After enablement, people follow a prompt to find the new item, it is not on the map, and they fall back to “did it even turn on”. After revocation the old item remains, fails only on tap, or worse, the client still shows a write until the server refuses. Pins and the command-palette index, if also built at launch, expire together, and a short-cut points at a door that has been taken away.

“Immediately” need not mean a millisecond push, but it must finish before the next time the navigation is drawn after the change. Waiting for a coincidental pull-to-refresh or a restart days later leaves a window where the map is wrong. When the change comes from another device or another admin, the current session has no local action to use as a refresh trigger, and needs an active invalidation even more.

Where it stops holding

A fully offline client cannot learn the change until it reconnects; it should mark the navigation as possibly stale and refetch on connect, not keep pretending the offline copy is authority. A huge tree is expensive to recompute every time; invalidate the affected branch rather than the whole tree — but the affected items must update before the next draw. Demo mode and simulated role-switch are deliberate requests to see another map; replace it in full immediately, and mark clearly that this is a simulation.

Applying it

• Permission-change events (enablement, expiry, removal from a project) must invalidate the current session’s navigation and refetch; do not wait for the next cold start.
• Pins and the command index invalidate at the same moment as the navigation, so a short-cut does not keep pointing at an old door.
• A long-lived foreground session must still be able to receive invalidation; fetching only at launch is not enough.
• How to check: grant an account a permission mid-session, without signing out, and watch the item appear on the navigation. Revoke it and watch it vanish or become disabled. If it only changes after a restart, the old state was cached. Change permission from another device; the next draw of navigation on this device should follow.

Related

• Within the group: E5.18.1 Unauthorized items may be hidden, or shown disabled with a reason · E5.18.2 Hiding entirely makes people think the function does not exist · E5.18.4 Permission must be checked on the server; hiding nav is not authorization
• Adjacent: E5.16 Shortcuts and Pinned Items · E5.17 Navigation Badges and Hints
• Search terms: stale navigation · permission change · session cache