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:

1. Higher priority rules override lower priority
2. More specific rules take precedence
3. 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