frontend(desktop): hide the desktop entry from users the socket will refuse, with i18n in all 11 locales #17370

Activity

1. mrveiss

   added

   bugSomething isn't workingSomething isn't working

   priority: medium

   frontend

   on Sep 24, 2026
2. mrveiss commented on Sep 28, 2026

   

   mrveiss

   on Sep 28, 2026

   OwnerAuthor

   More actions

   Taking this. Two amendments first, one of which makes the second criterion produce the exact disagreement it forbids.

   AC2 cannot be met with hasPermission, because that function has the short-circuit #13854 removed

   This issue says:

   if the frontend gates on the same permission it will agree with the socket automatically, including on that [superadmin]

   It will not. autobot-frontend/src/composables/usePermissions.ts:88-92:

   const hasPermission = (permission: Permission | string): boolean => {
     // Admin always has all permissions
     if (userStore.isAdmin) return true
     return permissions.value.includes(permission as Permission)
   }

   And useUserStore.isAdmin is isAdminRole(currentUser.role), which admits superadmin — its own test says so in as many words (useUserStore.isAdmin.test.ts:46: "admits superadmin — a hand-rolled === 'admin' check previously rejected this").

   So, from the generated table:

   Role	ROLE_PERMISSIONS holds mcp.desktop.control	socket (asks the table)	hasPermission(...)
   admin	yes (63 perms)	admits	true
   operator	yes (34 perms)	admits	true
   superadmin	no — 0 perms	refuses	true

   A superadmin would be shown the desktop entry and then closed with 1008 on the handshake. That is the disagreement AC2 exists to prevent, and gating on hasPermission is what would create it.

   This is #13854's ruling reappearing one layer up. PR #17369 refused to write is_admin_role(role) or role_has_permission(...) in the backend gate precisely because #13854 removed the administrative short-circuit from the permission predicate. hasPermission is that short-circuit, alive in the frontend composable. Gating on it would reinstate in the UI the thing the backend was careful not to reinstate.

   The codebase already knows this hazard, three lines away from the same store — useUserStore.ts:107-109, for service.management:

   superadmin deliberately excluded: its ROLE_PERMISSIONS entry is empty by …

   AC2 is amended to: the gate reads the role permission table — the same source role_has_permission reads — with no administrative override, so the frontend and the socket agree on every role including superadmin. usePermissions already exposes permissions (table-derived, no short-circuit); I am adding a named, documented holdsPermission alongside hasPermission so the next call site that needs to match a backend gate has one to reach for instead of rediscovering this.

   hasPermission is not being changed. It has 60-odd call sites whose expectations I have not audited, and changing an administrative override's semantics across the app is not this issue's risk envelope. That is worth its own issue and I will file it.

   AC4 understates itself: all five tab labels are hardcoded, not one

   ChatTabs.vue:36-43 — the whole withDefaults default:

   { key: 'chat',     label: 'Chat',     icon: 'comments' },
   { key: 'files',    label: 'Files',    icon: 'folder' },
   { key: 'terminal', label: 'Terminal', icon: 'terminal' },
   { key: 'browser',  label: 'Browser',  icon: 'globe' },
   { key: 'novnc',    label: 'noVNC',    icon: 'desktop' }

   The issue names 'noVNC'. The other four are the same violation in the same expression, and fixing one of five while editing the line would be the "patched again in every PR that finds it" shape. All five go to i18n.

   The two unassessed entry points, checked rather than assumed

   Entry point	Verdict
   views/AdvancedControlView.vue	not an entry point. Its only noVNC references are capability readouts — novnc_available ? t('common.yes') : t('common.no') at :201-206 and :330-331. It reports whether the feature exists; it does not open it. No gate needed, and gating it would hide diagnostics from the people who need them
   views/DesktopView.vue	is an entry point — 411 bytes, mounts DesktopInterface.vue. But /desktop redirects to /chat (router/index.ts:905), so the view is unreachable by URL. Unreachable-but-mounted is unfinished work rather than litter, so it is in scope for the gate rather than ignored

   Third entry point, reachable and needing the explanation rather than a hidden control: /slm/tools/novnc → SlmNoVncView.vue (router/index.ts:908-915, requiresAuth: true and nothing else). A bookmarked URL is activation, so hiding a tab does not cover it.
3. mrveiss

   closed this as completedin #17691on Sep 28, 2026
4. mrveiss

   added a commit that references this issue on Sep 28, 2026

   fix(frontend): hide the desktop entry from roles the socket refuses (#…

   ...

   41edb79