Draft: Implement new Design for Visibility Roles

What is in this MR

This MR implements the updated design for the Visibility Roles.

Currently, the user roles are controlled via two dropdown lists: allow_roles and disallow_roles. This MR greatly simplifies that to a single list of user roles, named roles along with a default policy named role_type.

The role_type can be one of "allow" or "disallow". The permissions system takes this role_type along with the list of roles and ensures that an element's visibility is appropriately allowed or disallowed.

E.g. if role_type is "allow", by default the element is visible. However, if the user has a role and that role is in the element's roles list, the element will not be visible to the user. In other words, the roles list will exclude the element from the user's view.

Conversely, if role_type is "disallow", by default the element is not visible. However, if the user has a role and that role is in the element's roles list, the element will be visible to the user. In other words, the roles list will include the element in the user's view.

How to test this MR

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

• A Database table containing two 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.

[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. The value for the Role can be any string, such as user_role, admin_role, foo_role`, etc.

[Prep] 2. Create an AB App

In the AB module, create a new app.

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

[Prep] 2.2. Add 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 visibility roles.
2. The page should also have a Login Form that uses the user source defined earlier.

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

In the page, select any Element and go to its Visibility tab. Select "Logged-in visitors". You should see a switch that controls the default policy, which is either Allow or Disallow. You should also see a list of checkboxes, one per role.

You should select an element, then:

• Use the switch to select either Allow or Disallow
• Check one or more roles from the list of checkboxes

Repeat the above steps such that you end up with a few elements, each with slightly different combinations of roles. Finally, click the Preview button and 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 allowed by the Visibility Roles, that element will be visible. If not, or if the user's role is explicitly disallowed in the Visibility Roles, that element will not be visible.

In general, this is the 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, select an element, and apply a role to it.
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 according to the role.
4. Preview the page and
   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

[Test] 4. Change User Source

This test is to ensure that the list of roles in the Visibility tab is 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 edit the User Source, e.g. change the name of the Role field. After having updated the User Source, you should see that the Visibility tab's list of roles 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 has the same set of user roles. Ensure that the roles have been correctly replicated to the new element.

Also ensure that the duplicated 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 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 list

[Test] 6. Add Lots of Roles

Add lots of roles. You should notice that an overflow vertical scrollbar in the Visibility tab.

[Test] 7. Add a Long Role Name

Add a really long role name. In the Visibility tab, you should see an overflow horizontal scrollbar.

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