github →

New request

#20141: Object and view navigation items still visible inside folders despite canRead permission being disabled

We'll provision a sandbox, run an agent against the issue, and open a draft PR. You can pull the branch and iterate from there.

Issue
prio: medium

Bug Description

When an object is placed inside a folder in the left navigation sidebar, role-based object permissions (canRead = false) are not fully enforced — the object's navigation item remains visible in the sidebar for users whose role should prevent them from seeing it.

The actual object content (records/data) is still correctly restricted — clicking the visible navigation item does not expose any data. So this is a UI-level leak, not a data leak. However, the object should not appear in the navigation at all for restricted users, as it does when placed at root level.

Moving the same object back to the root level of the navigation immediately applies the permission correctly and hides the navigation item as expected.

The same applies to views on the affected objects: if a view for a restricted object is placed inside a folder, it also remains visible in the navigation for users who should not have access. Again, the underlying data is not exposed, but the view entry itself should be hidden.

This means the navigation folder rendering bypasses the visibility filtering for object-level read permissions — both for objects and their associated views.

This behaviour is specifically annoying when it comes to manually triggered workflows as they become also visible on the views/objects even though the data itself is not exposed.

Example:

  1. Go to Settings → Roles and create (or edit) a role.
  2. For a specific object, set the "See" (canRead) permission to disabled/off.
  3. Assign this role to a non-admin user.
  4. In the left navigation sidebar (as admin), drag the object into a folder.
  5. Log in as the restricted user.
  6. Issue: The object's navigation item is still visible inside the "Finance" folder. Clicking it does not show any records (the content/data is correctly restricted), but the nav entry itself should not be shown at all.
  7. Additionally, create or move a view for the same restricted object into the folder.
  8. Issue: The view entry is also still visible in the folder for the restricted user, even though the underlying object has canRead = false.
  9. Now (as admin) move the object and its views back to root level (outside any folder).
  10. Log in again as the restricted user or reload.
  11. Tadaa: Both the object and its views are now correctly hidden from the navigation.

Expected behavior

Objects and their associated views for which a user's role has canRead = false should not be visible in the navigation sidebar, regardless of whether they are placed at root level or nested inside a folder. The permission check should be applied recursively to all navigation items, including folder children. Additionally, if all children of a folder are hidden due to permissions, the folder itself should also be hidden (empty folders should not be rendered).

Environment

Twenty version: v2.1.0 Hosting: Self-Hosted (Ubuntu via Docker) Browser: Chrome (latest)

Potentially Related?

  • #15612 — Cannot see all objects in navigation bar (objects with permissions not appearing — the inverse symptom, now resolved)
  • #10421 — User Role Based Controls (general RBAC request)
  • #19620 — Filter out deactivated objects from navigation sidebar
Assessmentadvisory
bug●● medium90% confidence

Navigation folder component fails to apply role-based visibility filtering that works at root level, requiring aligned permission guards in folder rendering logic.

Likely files
  • packages/twenty-front/src/modules/navigation/components/NavigationFolder.tsx
  • packages/twenty-front/src/modules/navigation/components/MainNavigation.tsx
  • packages/twenty-front/src/modules/object-metadata/hooks/useFilteredObjectMetadataItems.ts
  • packages/twenty-front/src/modules/views/hooks/useGetCurrentView.ts
  • packages/twenty-front/src/modules/permissions/hooks/useCanReadObject.ts
Create the request

This opens a fresh agent run and a draft PR for issue #20141.

Cancel