RLS is a feature that allows you to control user access to every entity in your database.

​
How to use RLS?

You can set RLS for each entity by going to the “Entity” section, and clicking on the “Security” button.

​
Adding Security Rules

When you want to control access to an entity, you can add a security rule using the “Security” button in the Entity section. This opens the Add Security Rule dialog:

Here’s what each option means:

  • Rule Name:
    Enter a descriptive name for your rule (e.g., “Admins Only Read”, “User Can Edit Own Posts”).

  • Access Type:

    • Read Access: Controls who can view records.
    • Write/Delete Access: Controls who can create, update, or delete records.

  • Rule Type:

    • No Restrictions:
      All users can access records (default, open access).
    • Creator Only:
      Users can only access records they created.
    • Entity-User Field Comparison:
      Compares a field in the entity with a user property (e.g., only users whose department matches the record’s department can access).
    • User Property Check:
      Checks if a user property matches a specific value (e.g., only users with the role “admin” can access).

  • Description (optional):
    Add any notes or context for this rule.

Once you’ve configured your rule, click Add Rule to apply it.

​
Examples

​
Example 1: Blog Posts (Admin Create + Creator Edit)

Scenario: Users can view all blog posts, only administrators can create new posts, and users can edit/delete their own posts.

Setup:

  1. Read Access Rule:

    • Rule Name: “Public Read Access”
    • Access Type: Read Access
    • Rule Type: No Restrictions

  2. Create Access Rule:

    • Rule Name: “Admin Can Create”
    • Access Type: Write/Delete Access
    • Rule Type: User Property Check
    • User Property: role
    • Expected Value: admin

  3. Edit Access Rule:

    • Rule Name: “Creator Can Edit”
    • Access Type: Write/Delete Access
    • Rule Type: Creator Only

Result: All users can see all blog posts, only administrators can create new posts, and users can edit/delete posts they created.

​
Example 2: Company Documents (Department-Based)

Scenario: Employees can only access documents from their own department.

Setup:

  • Rule Name: “Department Access Only”
  • Access Type: Read Access
  • Rule Type: Entity-User Field Comparison
  • Entity Field: department (field in the documents table)
  • User Property: department (user’s department from their profile)

Result: A user with department: "Engineering" can only see documents where the document’s department field equals “Engineering”.

​
Example 3: Admin Panel (Role-Based)

Scenario: Only administrators can access sensitive user management data.

Setup:

  • Rule Name: “Admin Only Access”
  • Access Type: Read Access
  • Rule Type: User Property Check
  • User Property: role
  • Expected Value: admin

Result: Only users with role: "admin" can view the user management entity.

​
Example 4: Project Management (Combined Rules)

Scenario: Project team members can view projects, but only project managers can edit them.

Setup:

  1. Read Access Rule:

    • Rule Name: “Team Member Read”
    • Access Type: Read Access
    • Rule Type: Entity-User Field Comparison
    • Entity Field: team_id
    • User Property: team_id

  2. Write Access Rule:

    • Rule Name: “Manager Edit Only”
    • Access Type: Write/Delete Access
    • Rule Type: User Property Check
    • User Property: role
    • Expected Value: project_manager

Result: Team members can see projects from their team, but only users with the “project_manager” role can edit or delete them.

Tip: You can combine multiple rules for fine-grained access control. For example, allow all users to read, but only creators or admins to edit or delete.