Authorizations – cavaliba.com
Description: Data Reference

`CTRL K`

Documentation
Data
Authorizations

# Authorizations

## Data Authorization model

Access to Data instances is controlled by a three-tier permission hierarchy:

1. Global permissions — apply to all schemas and all instances.
2. Schema-level permissions — override globals for a specific schema.
3. Instance-level permissions — override schema permissions for a single instance (strict: if defined, no fallback).

Resolution order (highest to lowest):

1. `p_data_admin` → grants all operations on all schemas and instances (non-blockable)
2. Schema `p_admin` → grants all operations on instances of that schema
3. Instance `p_use / p_read / p_update / p_delete` → strict override for the individual instance
4. Schema `p_use / p_read / p_create / p_update / p_delete` → applies to all instances of that schema
5. Global `p_data_use / p_data_read / p_data_create / p_data_update / p_data_delete` → default fallback

## Global permissions

Permission | Description
--- | ---
`p_data_admin` | All operations on all data. Non-blockable.
`p_data_read` | Read all instances. Blockable at schema or instance level.
`p_data_create` | Create instances in all schemas. Blockable at schema level.
`p_data_update` | Update all instances. Blockable at schema or instance level.
`p_data_delete` | Delete all instances. Blockable at schema or instance level.
`p_data_use` | Operate/execute all actionable instances. Blockable at schema or instance level.
`p_data_import` | Access the import tool.
`p_data_export` | Access the export tool.
`p_data_security_view` | View instance-level permission fields in the UI.
`p_data_security_edit` | Edit instance-level permission fields in the UI and via import.

## Schema-level permissions

Set in `_options` of the schema definition. Override global defaults for all instances of that schema.

    - classname: _schema
      keyname: my_schema

      _options:
          p_admin:  PERMISSION_NAME   # all ops on this schema, non-blockable
          p_create: PERMISSION_NAME   # create instances
          p_read:   PERMISSION_NAME   # read instances
          p_update: PERMISSION_NAME   # update instances
          p_delete: PERMISSION_NAME   # delete instances
          p_use:    PERMISSION_NAME   # operate/execute actionable instances

If a schema permission is defined and the user does not have it, access is denied even if the user holds the global permission (strict override).

## Instance-level permissions

Set per instance via the UI (requires `p_data_security_edit`) or via YAML import.

    - classname: my_schema
      keyname: my_instance
      p_read:   PERMISSION_NAME
      p_update: PERMISSION_NAME
      p_delete: PERMISSION_NAME
      p_use:    PERMISSION_NAME

Instance permissions take precedence over schema permissions. If defined and the user does not hold the required permission, access is denied (strict: no fallback to schema or global).

## p_use — Actionable instances

`p_use` controls the right to operate or execute an instance that represents something actionable, such as triggering a pipeline, running a job, or activating a process. It is distinct from `p_read` (viewing) and `p_update` (editing data).

Example: restrict who can trigger a pipeline instance without restricting who can read or edit its configuration.

    - classname: _schema
      keyname: _pipeline
      _options:
          p_use: p_pipeline_operator

    - classname: _pipeline
      keyname: my_pipeline
      p_use: p_my_pipeline_operator   # instance-level override

## Per Field Authorization

Not implemented.

Enumerate Search & Filters