Skip to content

Draft: Add User Role and Allow/Disallow Roles to control Element Visibility

Tsering Paljor requested to merge 2498-hide-element-depending-on-role into develop

What is in this MR

This MR adds the ability to show or hide Elements based on a user's role.

It makes the following changes:

  • Allow specifying a new Role attribute to the User Source
  • Adds Allow Roles and Disallow Roles attributes to Element
  • Allow adding/removing Roles from Allow Roles and Disallow Roles via the Visibility tab in the Editor View

With the above new changes, a builder can specify which roles are allowed to view a particular Element.

How to test this MR

To test this MR, you'll need the following:

  • A Database table containing one or more users.
  • An App Builder app that is configured like so:
    • It should define a User Source that points to your Database table of users.
    • A Welcome page that contains some basic elements.
    • A Login Page that uses the User Source and redirects to the Welcome page upon logging in.

1. Create a Database of Users

In the Database module, create a table for your users. You can use an existing users table if you want.

In addition to the usual Name, Email, and Password fields, add a new column named Role which is of the type Single Line Text.

image

2. Create an AB App

In the AB module, create a new app.

2.1. Add a User Source

In the app's Settings -> Users -> Add a new User Source that points to your local Baserow users table. There is now a new "Select role field" section, where you should select the Role column in your users table.

Screenshot_2024-04-29_at_2.38.50_PM

2.2. Add Pages

The app should have at least two pages.

  1. The Welcome page (or the default Homepage) should have a few elements that we will need to test the visibility.
  2. The Login page should have a Login Form that uses the user source defined earlier. Upon login it should redirect to the Welcome page.

Screenshot_2024-04-29_at_2.49.48_PM

3. Set Role(s) for Elements

In the Welcome page, select any Element and go to its Visibility tab. Select "Logged-in visitors" and from the Allow Roles drop down select one of your roles.

Select the Logic page, then click the Preview button. Log in as your user.

You should observe that some elements are visible while others are not. Specifically, if your logged-in user's role is in the Allow Roles list of an Element, that Element will be visible. If not, or if the user's role is in the Disallow Roles list of an Element, that Element will not be visible.

This is the general testing flow:

  1. In the Database table, assign a Role to a User (by updating the Role column in the users table)
  2. In the AB editor, set the Allow Roles and/or Disallow Roles value for particular Elements
  3. In the AB editor, click the "View as" dropdown in the top left corner. Select your user, and ensure the element is correctly hidden or shown.
  4. Preview the page
    4.1. Log in as the user, and verify that Elements are visible only if the user role allows it
  5. Publish the page and do step 4.1. above

Merge Request Checklist

  • changelog.md has been updated if required.
  • New/updated Premium/Enterprise features are separated correctly in the premium or enterprise folder
  • The latest Chrome and Firefox have been used to test any new frontend features
  • Documentation has been updated
  • Quality Standards are met
  • Performance: tables are still fast with 100k+ rows, 100+ field tables
  • The redoc API pages have been updated for any REST API changes
  • Our custom API docs are updated for changes to endpoints accessed via api tokens
  • The UI/UX has been updated following UI Style Guide

Closes #2498

Edited by Tsering Paljor

Merge request reports