Record Level Security (RLS)

The concept and principles of Record Level Security

Record Level Security in Undb is a feature that allows users to control access to data records based on the condition of table. With record level security, users can define who can view, edit, or delete specific data records, ensuring data security and privacy.

The document will explain the fundamental concept and principles of Record Level Security, including how it helps you control access to data records.

The principle of Record Level Security (RLS) is similar to configuring data filtering conditions while RLS is apply to the whole table scope. Users need to configure corresponding rules in a pop-up window, and the system will control the display of table data and permissions for operations such as adding, deleting, and modifying records based on these rules. Please refer to the image below for a visual representation.

Configure RLS rules

Next, we will guide you on how to create user-based record-level permission management, allowing you to assign specific record editing permissions based on the needs of different users.

1. In the initial setup of each rule, you can choose the category of personnel to which the rule applies, with options of “anyone” and “users”. If you choose “users”, you can further specify a specific user from the system. Once the rule is created, it will apply to the specified user. Conversely, if “anyone” is selected, the rule will apply to all users. Within a table, you can create multiple rules for different users.

2. When creating a rule, you can set rule conditions. You can select a field in the table and set conditions for that field, then fill in the condition value. For example, selecting the “Deal” field and setting the condition as data starting with “Deal Name”.

Select the field

Choice of conditions

Input data

3. A rule can have multiple conditions, and the system will calculate the intersection between these conditions. For example, Condition 1: Selecting the “Deal” field and setting the condition as data starting with “Deal Name”; Condition 2: Selecting the “Stage” field and setting the condition as not equal to “Discovery” status. This rule will be the intersection of meeting Condition 1 and Condition 2.

The conditions in a rule take effect in the order they are listed, with each condition being evaluated based on its position in the rule and the matching criteria.

4. After filling in the setup information, you must click the “Create New Record-Level Security” button to complete the creation.

5. When modifying the information of an already created rule, you need to click the adjacent “Update Rule” button for the changes to take effect.

Use Case

UseCase 1: filtering data

The following GIF demonstrates how to set the visibility of data so that it is only accessible to everyone when the field “Deal” contains the data “Deal Name 1”.

1. Open the table for which you want to set the data visibility.
2. Identify a suitable field in the table that represents the record creator and updater. For example, you can use the “Create by” field and “Update by”.
3. Locate and click on the “Data Visibility” or similar option to set the data visibility rules.
4. In the data visibility settings, select the “Creator” field and choose the “Equals” operator.
5. In the value field, select “Jason” (without quotes).
6. Save the settings and close the data visibility settings.

The diagram illustrates the records that Jason user can access. These records are filtered based on the application’s record level security rules to ensure that only the records relevant to the Jason user are visible to them.

UseCase 2: Only creator can update their own records

The following RLS rule indicates that only creator of the record can update the record.

If you are not the creator of the record, you can still view or list the record(s), but the record is readonly for you.

Since the record is created by Jason, so I cannot update the record.

UseCase 3: Users can not create a record with Done status

The following RLS rule indicates user can not create a record with Permits field with value Done

Record operation authority

Undb provides record-level permissions for the following operations: List, View, Create, Update, and Delete. Let’s explore each of these operation types in detail:

List

The List operation controls the display of records in a data table. It functions similarly to the filtering feature in a grid view, allowing you to specify that only records that comply with the RLS (Row-Level Security) should be shown to a particular user.

View

The List operation controls whether a user have access to view a single record.

Create

The Create operation defines rules for data creation permissions. It enables you to specify what kind of data a user can create based on the defined rules. For example, you can set a creation rule where users can only create records with a specific status field, such as “New” “In Progress” or “Completed”.

Note that duplicate or restore a record also respect create rule.

Update

The Update operation, similar to Create and Delete, controls the user’s permission to modify each individual record. It uses RLS rules to determine which rows a user can modify.

Delete

The Delete operation sets the permission for users to delete specific rows of records. It ensures that users can only delete the rows they are authorized to delete based on the RLS rules.

Subscriptions

When you subscribe to a table, the listed records will be filtered automatically to respect your RLS configuration.

Difference with view filter

1. RLS is applied to the whole table, and has higher priority over view filter
2. RLS can be set by owner or admin while view filter can be set by onwer, admin or editor