How to set button or block visibility based on user role

English Forum Questions
1

Hi all —

I’m trying to configure button visibility and block access in NocoBase based on the current user’s role or group membership, and I’m running into a few limitations. Hopefully someone has ideas or can confirm if this is currently possible.

:white_check_mark: What I’m Trying To Do

I want to hide or disable UI elements like:

  • “Add” buttons
  • “Edit” buttons
  • “Delete” buttons
  • Whole blocks, like tables or detail views

…based on the user’s role, such as:

  • Admins can do everything
  • Staff can view but not edit
  • Guests can’t see certain elements at all

:brick: What I’ve Tried

NocoBase has a system called Linkage Rules, which works great for data-based logic (like filtering rows in a table based on another field’s value).

But: Linkage Rules don’t seem to have access to variables like the user’s role, group membership, or permissions.

There are variables exposed in some blocks (like currentUser.role), but I haven’t found a way to actually use those to hide buttons or blocks.

:firecracker: What’s Not Working

  1. No visibility controls tied to role or group
    I can’t hide UI elements based on roles — every user sees every button.

  2. No conditional logic for blocks or buttons
    There’s no UI-level condition builder that can check user roles or permissions like:

    if currentUser.role == "admin"

  3. Access control at the UI level is missing
    Even if I lock down the API side with permission rules, users can still see the interface elements, which is confusing and potentially insecure.

  4. No protection against direct access
    For example, a user can visit /app/building?building=123 directly, and I can’t find a way to enforce a permission check to hide or redirect them if they don’t have access to that building. Role rules apply at the collection level, but there’s no way (yet?) to do record-level access control for views.

:closed_lock_with_key: Why This Matters

  • We’re building real workflows with different kinds of users (managers, designers, etc)
  • UI clutter becomes an issue when everyone sees controls they can’t use
  • Direct access to data pages without access checks is a security risk
  • We want to use NocoBase for serious apps, and that needs stronger access controls both at the data layer and the UI layer

:pray: What I’m Asking

  • Is there a way to control visibility of buttons or blocks based on the current user’s role or groups?
  • Can we use currentUser or similar variables in a “visibility condition” anywhere?
  • How are others working around this?
  • Is there a roadmap for record-level access control or UI-level permission hooks?

Thanks in advance — really hoping someone has a clever trick for this, or that it’s something on the roadmap!

1 Like
2

Hi @troykelly , this feature will be relased to v1.7(Beta branch) in about one weeek.

1 Like