Repository navigation
tech-debt(frontend): router meta.minRole is declared and read by no guard #16244
Description
Activity
Design, starting once PR #16265 merges (it adds
Roleto the codegen manifest):- The codegen emits
ROLE_PRIORITY: Readonly<Record<Role, number>>from the publicSYSTEM_ROLES[*].priority. That is the backend's_ROLE_METAranking, not a second hand-written order. It is validated againstRole's members, so a missing or extra role fails generation. - A pure
minRoleAllows(role, minRole)lives inrouter/roleGuard.ts, andbeforeEachenforces every matched record'sminRole. - It does not depend on auth: extend Permission to cover chat, teams and webhooks, define key scopes as permission bundles, and return effective permissions from /me #16270's
/mefields; it needs only the role/mealready returns.
- The codegen emits
- added a commit that references this issue
on Sep 12, 2026 - linked a pull request that will close this issuefeat(frontend): wire router meta.minRole into a real guard, ranked against the backend's role order (#16244) #16489
on Sep 12, 2026 Post-merge audit: no acceptance criteria in the body, so here is the problem mapped to the fix
Merged in PR #16489, merge commit
23d9e2b2e, verified onorigin/main.Problem stated here Fix on mainmeta.minRoleis declared and no guard reads itautobot-frontend/src/router/index.ts:1337resolveMinRoleRedirecttakes the strictestminRoleacross the matched records. ThebeforeEachat:1420-1423redirects home when the user doesn't meet it.Compare the user's role to minRoleby rankautobot-frontend/src/constants/roles.ts:70meetsMinRole:ROLE_RANK[role] >= ROLE_RANK[minRole]. An unknown or missing role never meets any floor (:71).Ranks as in _ROLE_META(superadmin 110 … readonly 10)roles.ts:59ROLE_RANKhas the same seven values.Tests autobot-frontend/src/router/__tests__/resolveMinRoleRedirect.test.ts(6 cases);autobot-frontend/src/constants/__tests__/roles.test.ts:40,44What's still missing. The issue asked that the guard "take its ranking from there rather than from a second hand-written order".
ROLE_RANKis a second hand-written order.roles.test.ts:44("matches the backend _ROLE_META ordering exactly") compares it to literal values, not to_ROLE_META. No repo test reads both files:git grepforROLE_RANKin*.pyonorigin/mainfinds nothing. So a change to_ROLE_METAinautobot_shared/auth/permissions.pywouldn't fail any check. I'm not reopening, because this issue lists no acceptance criteria. A parity guard between the two needs its own issue.The drift gap from the closure audit above (the frontend
ROLE_RANKis a hand-typed copy of the backend ranking, androles.test.tschecks literals only, so a backend re-rank fails nothing) is already tracked in #16491, which foldsROLE_RANKintogen_frontend_types.pythe same way Permission and Role are generated. No separate issue is needed.
Found while fixing #14937, which retyped this field to the canonical
Role.autobot-frontend/src/types/router.d.tsdeclaresmeta.minRole("Minimum role required"), but nothing uses it: no route sets it and no guard reads it. I searched both GUIs'src/. The only role gate ismeta.admincombined withuserStore.isAdmininrouter/index.ts. SominRolelooks like a working access control but isn't one.Ask
Wire it in: add a route guard that compares the user's role to
minRoleby rank.The backend already ranks roles, in
_ROLE_METAinautobot_shared/auth/permissions.py:The guard should take its ranking from there rather than from a second hand-written order. Until that guard exists, nothing should rely on
minRolefor access control.Refs #14937.