Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt

Use this file to discover all available pages before exploring further.

Roles define sets of permissions that can be assigned to users, controlling their access to various features and resources within Metabind. Users follow a pure Role-Based Access Control (RBAC) model where permissions are never stored directly on user objects.

​
The Role Object

​
id
string
Unique identifier (UUID)
​
name
string
Role name (e.g., “editor”, “developer”)
​
description
string
Role description
​
permissions
object
Permission settings for each resource type
​
createdAt
string
Creation timestamp (ISO 8601 format)
​
updatedAt
string
Last update timestamp (ISO 8601 format)

​
Permission Categories

Roles control access to 10 resource types, each with specific actions:

​
Administrative Resources

ResourceActionsDescription
organizationsread, update, deleteOrganization settings access
projectscreate, read, update, deleteProject management
userscreate, read, update, deleteUser management
rolescreate, read, update, deleteRole management
apiKeyscreate, read, update, deleteAPI key management

​
Development Resources

ResourceActionsDescription
componentscreate, read, update, deleteComponent development
packagescreate, read, update, deletePackage publishing
contentTypescreate, read, update, publish, deleteContent type management

​
Content Resources

ResourceActionsDescription
contentcreate, read, update, publish, deleteContent management
assetscreate, read, update, deleteAsset management
Content and content types have a separate publish permission, allowing editorial workflows where users can create and update drafts but not publish.

​
Inherited Permissions

Certain organizational features inherit permissions from related core resources:
  • Collections: Inherit from components permissions
  • Folders: Inherit from the resources they organize
  • Saved Searches: Inherit from content and assets permissions
  • Tags: Inherit from content and assets permissions
  • Preview Links: Inherit from source resource permissions

​
Example Role Object

{
  "id": "role123",
  "name": "editor",
  "description": "Content management with publishing rights",
  "permissions": {
    "organizations": {
      "read": true,
      "update": false,
      "delete": false
    },
    "projects": {
      "create": false,
      "read": true,
      "update": false,
      "delete": false
    },
    "users": {
      "create": false,
      "read": false,
      "update": false,
      "delete": false
    },
    "roles": {
      "create": false,
      "read": false,
      "update": false,
      "delete": false
    },
    "apiKeys": {
      "create": false,
      "read": false,
      "update": false,
      "delete": false
    },
    "components": {
      "create": false,
      "read": true,
      "update": false,
      "delete": false
    },
    "packages": {
      "create": false,
      "read": true,
      "update": false,
      "delete": false
    },
    "contentTypes": {
      "create": false,
      "read": true,
      "update": false,
      "publish": false,
      "delete": false
    },
    "content": {
      "create": true,
      "read": true,
      "update": true,
      "publish": true,
      "delete": true
    },
    "assets": {
      "create": true,
      "read": true,
      "update": true,
      "delete": true
    }
  },
  "createdAt": "2024-03-20T10:00:00Z",
  "updatedAt": "2024-03-20T10:00:00Z"
}

​
Permission Computation

When checking a user’s permissions:
  1. All roles assigned to the user are retrieved
  2. Permissions from all roles are merged using OR logic
  3. If any role grants a permission, the user has that permission
This allows flexible role composition where users can have multiple specialized roles.