What are model permissions?

Using permissions, you can provide or restrict access to information in your application for specific roles.

Model permissions determine what actions a user can perform based on their assigned role within your application. These permissions establish the level of access users have to data and remote models, ensuring that sensitive information is only accessible to those with the appropriate authorization.

By defining model permissions, you can control who can view the data within a chosen data model. This article aims to explain how to work with Read model permissions, apply filter rules to model properties, and enable one to edit, delete, create and manipulate data in other possible ways via permissions in Actions.

Read permissions for data models

Managing the Read access to data models is one of the main aspects of role-based access control. With this enabled, users with proper access can view specific data from an application.

Within the Roles and permissions section of your application, you can toggle the Read access for different data models that are stored in your application.

Open Roles and permissions by heading to Tools > Roles and permissions.

Application roles (1) are displayed on the left, while the table on the right shows all application's data models. Toggle a desired data model box to open a dropdown with Read permission settings (2):

• Allowed grants access to read (view) data from a specific data model

• Not allowed restricts the access to a data model

• Use filter option enables selecting a rule for a particular property within the selected model

For example, let’s consider a data model Author. Suppose you apply a filter rule that sets the Read access for the Author model to Use filter with the filter condition:

Author.Created At - is after - 01/01/2020

This configuration means that users assigned to this role can only view authors whose records were created after January 1, 2020. As a result, users will not have access to records of authors created before this date.

Using permissions via Actions

Permissions for operations with data such as Delete, Create, Update and others are managed through individual action settings (1).

For example, this Create author action is aimed at creating a new book author record in a database. Create record step (2) is used for this operation, and the Author model with Name property is added to the action step options.

In the same way, you can add a remote model with its properties, which gives access to control access to data retrieved from an external data source.

When setting up the permissions, the roles you have created will be displayed in action settings, Permissions tab:

• Private action (1): When toggled on, a webuser needs to be authorized and have permission for their role. If the toggle is off, an action becomes public

• Authentication profile (2): Defines how users are authenticated when performing actions. Only users with the correct credentials and roles can execute certain actions

• Permissions (3) control who can perform specific actions within your application

This example demonstrates that the action is private, and can be executed by an authenticated user (with a Betty Blocks account) with an admin role. In simple words: Only an application admin can create new book authors in the application's database.

Users with multiple roles assigned

When a user is assigned to two separate roles, the permissions of the more restrictive role will take precedence. This means that if one role restricts a particular action, the user will be unable to perform that action, even if the other role allows it.

Example:

• Role A CAN create model X.

• Role B CANNOT create model X.

If a user has both Role A and Role B, then this user CANNOT create model X.

Keep an eye on the use of multiple roles when they have different permission settings.