Record Rules

Record Rules in SOLID provide fine-grained access control at the data level, allowing you to define who can access specific records based on various conditions.

Overview

Record Rules enable:

Row-level security
Dynamic access control
User-specific data visibility
Role-based data access

Rule Types

User-Based Rules

Rules based on the current user:

{
  "name": "own_records",
  "resource": "projects",
  "condition": {
    "field": "created_by",
    "operator": "equals",
    "value": "${currentUser.id}"
  }
}

Role-Based Rules

Rules based on user roles:

{
  "name": "department_records",
  "resource": "employees",
  "condition": {
    "field": "department",
    "operator": "equals",
    "value": "${currentUser.department}",
    "roles": ["department_manager"]
  }
}

Complex Rules

Combining multiple conditions:

{
  "name": "regional_sales",
  "resource": "sales_orders",
  "condition": {
    "operator": "and",
    "conditions": [
      {
        "field": "region",
        "operator": "equals",
        "value": "${currentUser.region}"
      },
      {
        "field": "status",
        "operator": "in",
        "value": ["active", "pending"]
      }
    ]
  }
}

Rule Configuration

Available Operators

Operator	Description	Example
equals	Exact match	`field = value`
not_equals	Negative match	`field != value`
in	In array	`field IN (values)`
not_in	Not in array	`field NOT IN (values)`
greater_than	Greater than	`field > value`
less_than	Less than	`field < value`
contains	String contains	`field LIKE %value%`
starts_with	String starts with	`field LIKE value%`

Dynamic Values

Available context variables:

${currentUser} - Current user object
${currentRole} - Current user's role
${timestamp} - Current timestamp
${custom} - Custom context variables

Implementation

Creating a Rule

{
  "name": "active_projects",
  "description": "Access to active projects in user's department",
  "resource": "projects",
  "condition": {
    "operator": "and",
    "conditions": [
      {
        "field": "status",
        "operator": "equals",
        "value": "active"
      },
      {
        "field": "department",
        "operator": "equals",
        "value": "${currentUser.department}"
      }
    ]
  },
  "actions": ["read", "update"],
  "priority": 1
}

Rule Priority

Rules are evaluated in priority order:

Higher priority rules override lower priority
More specific rules take precedence
Deny rules override allow rules

Common Scenarios

Team-Based Access

{
  "name": "team_access",
  "resource": "tasks",
  "condition": {
    "operator": "or",
    "conditions": [
      {
        "field": "assigned_team",
        "operator": "equals",
        "value": "${currentUser.team}"
      },
      {
        "field": "created_by",
        "operator": "equals",
        "value": "${currentUser.id}"
      }
    ]
  }
}

Hierarchical Access

{
  "name": "hierarchical_access",
  "resource": "employees",
  "condition": {
    "field": "department_path",
    "operator": "starts_with",
    "value": "${currentUser.department_path}"
  }
}

Time-Based Access

{
  "name": "time_restricted_access",
  "resource": "documents",
  "condition": {
    "operator": "and",
    "conditions": [
      {
        "field": "valid_from",
        "operator": "less_than",
        "value": "${timestamp}"
      },
      {
        "field": "valid_to",
        "operator": "greater_than",
        "value": "${timestamp}"
      }
    ]
  }
}

Best Practices

Rule Design

Keep rules simple and focused
Use meaningful names
Document rule purpose
Consider performance impact

Security

Test rule combinations
Validate rule logic
Monitor rule effectiveness
Regular security audits

Maintenance

Regular rule review
Update documentation
Clean up unused rules
Monitor performance

Testing

Test edge cases
Verify rule combinations
Check rule priorities
Validate performance

Record Rules

Rule Design

Security

Maintenance

Testing

On this page