[UI] Integrate Sistent PermissionProvider and migrate Navigator permissions - #20590

@banana-three-join

There's actually no switch from sessionStorage to JS heap for the org itself; useGetSelectedOrganization() derives from RTK Query hooks (useGetUserPrefQuery + useGetOrgsQuery), which fetch from the server and live in the Redux store cache. The org selection was already server-backed.

The userContext here is only used for display inside the PermissionShield tooltip (shows "User: X, Org: Y, Roles: Z" when a user lacks permission). It's purely cosmetic; no authorization logic depends on it.

On SSR: _app.tsx runs client-side only (Next.js custom App), and both RTK Query hooks skip on the server (no window/sessionStorage access). The useMemo will just produce undefined/empty values during SSR, and the PermissionProvider handles that gracefully; sistent's usePermissionUserContext() returns undefined when no context is available, and the tooltip section is conditionally rendered (userContext && (userContext.userName || userContext.orgName)). So no SSR gotchas.

Reviewed and tested locally on branch pr-20590:

• Full unit suite: 375 files / 2509 tests passing, 0 regressions
• navigatorComponents.test.tsx: 7/7 passing
• tsc --noEmit: clean
• eslint: 0 errors (1 pre-existing unused eslint-disable warning in _app.tsx line 153, unrelated/trivial — could be cleaned up in a follow-up)

Walked the diff in all 3 changed files:

• _app.tsx: the userHasPermission adapter (ability.can(key.id, _.lowerCase(key.function))) exactly replicates the old CAN() helper's logic (confirmed in utils/can.ts), so this is behavior-preserving, not a functional change.
• navigatorComponents.tsx: clean 1:1 mechanical migration from permission: {action, subject} to permissionKey: Keys.X across all 9 nav items — nothing missed or mismatched.
• Navigator.tsx: confirmed via Sistent's type declarations that ListItemButton natively supports permissionKey/permissionAction="showShield" and handles disabling internally, so dropping the manual disabled={!CAN(...)} prop is safe, not a regression.

Ran the app locally against a dev backend — nav renders correctly with no permission-related console errors.

Overall: solid, well-scoped refactor.

Reviewed and tested locally on branch pr-20590:

• Full unit suite: 375 files / 2509 tests passing, 0 regressions
• navigatorComponents.test.tsx: 7/7 passing
• tsc --noEmit: clean
• eslint: 0 errors (1 pre-existing unused eslint-disable warning in _app.tsx line 153, unrelated/trivial — could be cleaned up in a follow-up)

Walked the diff in all 3 changed files:

• _app.tsx: the userHasPermission adapter (ability.can(key.id, _.lowerCase(key.function))) exactly replicates the old CAN() helper's logic (confirmed in utils/can.ts), so this is behavior-preserving, not a functional change.
• navigatorComponents.tsx: clean 1:1 mechanical migration from permission: {action, subject} to permissionKey: Keys.X across all 9 nav items — nothing missed or mismatched.
• Navigator.tsx: confirmed via Sistent's type declarations that ListItemButton natively supports permissionKey/permissionAction="showShield" and handles disabling internally, so dropping the manual disabled={!CAN(...)} prop is safe, not a regression.

Ran the app locally against a dev backend — nav renders correctly with no permission-related console errors.

Overall: solid, well-scoped refactor.

Thanks @Maanvi212006 !!!

Commit SHA: 0d8273fcc7fb44b46ffd89f19dbcefef24a3c55e

END-TO-END TESTS

• Testing started at: July 15th 2026, 6:37:20 pm

📦 Test Result Summary

• ✅ 63 passed
• ❌ 0 failed
• ⚠️ 0 flaked
• ⏩ 7 skipped

⌛ Duration: 4 minutes and 9 seconds

Overall Result: 👍 All tests passed.

🔗 Relationship Tests