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

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:

• Allows specifying a new Role Field in the User Source settings. The Role Field can be one of:
  • Use Default Role
  • An existing Database field
• Adds a Role Type dropdown in the Element Visibility tab.
  • Valid options are: Allow all roles, Allow all roles except, and Disallow all roles except.
  • If the builder selects "Allow all roles", the Element will be visible to all logged-in users.
  • If the builder selects "Allow all roles except" or "Disallow all roles except", a list of Roles are presented to the builder. More on this in the next point.
• Adds a Roles checkbox list in the Element Visibility tab.
  • When "Allow all roles except" or "Disallow all roles except" is selected, a list of Roles in the form of checkboxes are shown.
  • The builder can check all or some of the checkboxes for more granular control over Element visibility.
• Supports multiple User Sources
  • The "Roles" are a unique set of all roles across all User Sources
• Adds the User Source name and the Role name next to the User's name, in the User context menu (top-left corner of the builder page).

With this new change, a builder can specify how users are able 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 page that contains some elements, e.g. a Heading Element (any Element type will do).

[Prep] 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.

[Prep] 2. Create an AB App

In the AB module, create a new app.

[Prep] 2.1. Add User Sources

You should create at least two User Sources.

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" dropdown where you should select the Role column in your users table.

[Prep] 2.2. Add a Page

The app should have at least one page.

1. The page (or the default Homepage) should have a few elements that we will need to test element visibility.

E.g. in the screenshot above, I've created:

• A few Heading elements:
  • Yellow heading indicates it should only be visible to the first User Source
  • Blue heading indicates it should only be visible to the second User Source
  • Black heading indicates it should be visible to all users
  • Ping heading indicates it should be visible to both User Sources
• A Column element containing two Login elements; one per User Source
• A Logout button; this is optional

[Test] 3. Set Role(s) for Elements

The general testing flow is as follows:

1. In the AB editor, select an Element and go to the Visibility tab.
2. Select "Logged-in visitors", then from the drop down, select one of the options.
   2.1. If you selected anything other than "Allow all roles", you should see a list of checkboxes that represent all valid Roles that you defined earlier (in your Database user tables). Check one or more roles.
3. In the AB editor, click the "View as" dropdown in the top left corner. Select your user, then..
   3.1. Ensure that the User Source name and Role name appears next to the User's name in the context menu
   3.2. Ensure the Element is correctly hidden or shown in the preview.
4. Publish the page
   4.1. Ensure that only Elements that have a Visibility setting of "Allow all roles" are visible by default.
   4.2. Login as a user. Ensure that the user can only view Elements which allow the user's role.

In general, you should observe that some elements are visible while others are not. Specifically, the element should only be visible to your user if:

• The user is logged-in
• The user's role is in the Roles list of an Element and and the Role Type allows it

Additional scenarios to test:

• In the User Source settings, instead of a specific Role Field, select "Use Default Role".
• In the User Source settings, set one User Source to use "Use Default Role", while the other one uses a specific Role Field
• In the element's Visibility tab, play around with different combinations of Roles and Default Roles
  • Note that when you select "Use Default Role", that is represented in the list of checkboxes as "All members of ".
• For the Role field, try setting it to one of the other support Field Types:
  • Single Select
  • Formula

[Test] 4. Change User Source

This test is to ensure that the list of Roles and the Dropdown itself is automatically updated when the user source changes.

First, ensure that an element is selected and that its Visibility tab is open. Then, open the application's Settings -> Users -> User Sources -> Edit.

You should be able to edit the User Source, such as changing the name of the Role field, and see that the Visibility tab's roles settings has also been updated.

[Test] 5. Duplicate Element

Set some roles on an element, then duplicate that element. Hint: you can select the element, then use the d key to duplicate it.

Ensure that the newly duplicated element's Visibility tab has the same role configuration. Ensure that the element is correctly hidden or displayed in the Preview/Published views.

[Test] 5. Update Roles

Go to the Database section and view your users table. Add or remove some roles from the users table.

Then in AB, go back to the element's Visibility tab. Ensure that the list of roles has been updated as well.

• If the role was deleted or renamed from the users table, and if the role was previously used by the Element, the role should have been removed from the roles list.
• If a role was added to the users table, that role should now be available to select as an option in the roles dropdowns.

[Test] 6. Zero Downtime Migration

This MR introduces two new columns: role_type and roles. See the Test 0 migration downtime and Test migration sections in the AB Team guidelines notion doc.

6.1. Test 0 migration downtime

• Checkout the develop branch, clean your local environment (clear containers + volumes), and reinitialize it with ./dev.sh.
• Create an AB app.
• Checkout the 2498-hide-element-depending-on-role branch (this MR's branch) and apply the migrations.
• Checkout develop again.
• Create an element.

You should observe that the AB app is working normally without errors in the develop branch.

You should also observe that creating an Element does not cause any error (check Chrome console).

6.2. Test migration

• Checkout the develop branch, clean your local environment (clear containers + volumes), and reinitialize it with ./dev.sh.
• Create an AB app and create some elements.
• Checkout the 2498-hide-element-depending-on-role branch and apply the migrations.
• Ensure that the previously created elements (while you were in develop) are still working.

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 (closed)