docyrus-acl-design

Sterne13

Forks0

Aktualisiert23. Juni 2026 um 21:22

Design, configure, and validate a Docyrus tenant ACL (Access Control Layer) end-to-end using the `docyrus acl` CLI commands. Use when the user wants to define permission roles, assign operation-level permissions to roles for data sources / apps / AI tools / settings / devtools, set up row-level record filters (role queries), build an organizational hierarchy (hierarchy units), or look up available system operations. Triggers on "create a role", "set permissions for a role", "grant access to a data source", "role query", "row-level filter", "hierarchy unit", "org-chart access", "acl rules", "what operations", `docyrus acl roles`, `docyrus acl rules`, `docyrus acl role-queries`, `docyrus acl hierarchy-units`, `docyrus acl operations`, or any ACL role/permission design + configuration task in Docyrus.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

Docyrus

Docyrus/agent-skills

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

Datei-Explorer

3 Dateien

SKILL.md

readonly

Mehr aus diesem Repository

gleiches Repository

docyrus-automation-design

Docyrus/agent-skills

Design, build, validate, and test a Docyrus automation (workflow) end-to-end using the `docyrus automation` CLI commands. Use when the user wants to automate a process — fire actions when records are created/modified/deleted, on a schedule, from a webhook/email/webform, or on a button click — and chain action nodes (send email/notification, create/update records, request approval/input, HTTP request, query a data source, generate a document, run an AI prompt/agent, execute a script, wait). Covers picking the right trigger, composing the action-node graph (conditions, field mappings, parent/child sequencing), and proving it runs. Triggers on "create an automation", "when a record is created/updated do X", "send an email/notification automatically", "schedule a recurring job", "webhook/email trigger", "approval workflow", "build a workflow", "automation trigger", "action node", `docyrus automation create`, `docyrus automation create-trigger`, `docyrus automation create-node`, or any Docyrus automation/workflow

2026-07-1513

docyrus-app-dev-react

Docyrus/agent-skills

Build Docyrus React TypeScript web applications end-to-end, combining authentication, API access, @docyrus/app-utils runtime helpers, @docyrus/devtools in-app debugging, generated collections, TanStack Query/Form patterns, and production-grade UI implementation with preferred component libraries. Use when creating or modifying Docyrus-backed apps that use @docyrus/api-client, @docyrus/signin, @docyrus/app-utils, @docyrus/devtools, Docyrus collections, queries, dashboards, forms, tables, layouts, or Docyrus UI components.

2026-07-1313

docyrus-cli-app

Docyrus/agent-skills

Use the Docyrus CLI (`docyrus`) to interact with the Docyrus platform from the terminal. Use when the user asks to authenticate, list apps, query or manage data records (`ds`), manage dev app data source schema objects (`studio`) including data sources, fields, enums, data views, forms, webforms, HTML/PDF export templates, and email templates, manage automations and their triggers/action nodes (`automation`), build or edit custom AI agents and their sub-resources (`agent`), set an app's AI agent context or manage app-scoped AI tools (`apps`), list tenant email accounts and send emails (`messaging`), manage tenant account settings — brands, the current user's profile, and tenant regional/formatting preferences (`account`), discover and call connectors (`connect`), send API requests, switch tenants/accounts, discover tenant OpenAPI specs, drive browser automation (`browser`), chat with platform agents (`docy`), launch the pi cowork/coding agents (`opsy`/`cody`/`coder`), run the agent bridge server (`server`), m

2026-07-0813

docyrus-create-app

Docyrus/agent-skills

Create a new Docyrus app from the terminal with `docyrus apps create` and bootstrap a local dev workspace. Use when the user wants to scaffold a new app (web app / `external-app`, React techstack), create an app with an empty git repo, remix an existing template app, list remixable template apps, clone an existing app's repo locally, or generate the `.env` for local development against Docyrus. Triggers on "create an app", "new web app", "scaffold a Docyrus app", "start a new Docyrus frontend/project", "empty app repo", "remix a template app", "clone my app locally", "set up local development for an app", `docyrus apps create`, `docyrus apps clone`, `docyrus apps templates`, or any Docyrus app-creation + local-dev-bootstrap task via the CLI. For the full CLI command index see docyrus-cli-app; for building the app's code after cloning see docyrus-app-dev-react.

2026-07-0813

docyrus-platform

Docyrus/agent-skills

Architecture and building-blocks reference for the Docyrus platform — what the platform is made of (apps, data sources, fields, enumerations, custom queries, automations) and how the pieces fit together. Use when you need conceptual context about how Docyrus works, what its building blocks and capabilities are, or to decide which dedicated skill to use for a task. This is the conceptual map and router; hands-on how-to lives in the dedicated design / CLI / API skills it points to (data sources, automations, agents, AI tools, templates, webforms, ACL, querying, the CLI, and the REST API).

2026-07-0713

docyrus-custom-query

Docyrus/agent-skills

Create, read, update, delete, run, and consume saved Docyrus custom query records (tenant_custom_query) — reusable, parameterized SQL query templates whose body is DSQL — using the `docyrus dsql *-custom-query` CLI commands, and call them from a frontend via `@docyrus/api-client`'s `RestApiClient.runCustomQuery`. Use when the user wants to save a DSQL query as a reusable named report/template, parameterize it with runtime filters (Handlebars `{{filter}}` binding), test/run a saved query (`--debug` compiled SQL, `--simulate` EXPLAIN ANALYZE), manage the lifecycle of custom query records, or run a saved custom query from a React/frontend app. Triggers on "custom query", "saved query", "query template", "reusable report", "parameterized query", "run a saved query", "runCustomQuery", `docyrus dsql create-custom-query`, `docyrus dsql run-custom-query`, `list/get/update/delete-custom-query`, or wiring a saved query into an app. For authoring the DSQL body itself and ad-hoc one-off queries, see docyrus-dsql-query-de

2026-07-0513

name

docyrus-acl-design

description

Docyrus ACL Design

Configure tenant access control with docyrus acl, then validate the setup before handing it off. The Docyrus ACL system has five concepts:

Concept	What it is
Role	Named permission group assigned to users
Hierarchy Unit	Org-tree node for org-chart-aware row-level security (RLS)
Role Query	Row-level filter attached to one or more roles for a data source
Operation	System-defined permission slug (read-only — you can't create these)
Rule	Binds a role to a target (data source / app / AI tool / settings) with a list of allowed operation slugs

For platform concepts see the docyrus-platform skill. For CLI flag tables see the docyrus-cli-app skill. This skill is the ACL-specific workflow.

Workflow

Follow in order. A role without rules grants nothing useful.

Confirm auth.
```
docyrus auth who --json          # confirm session + tenant
```
No session → stop and ask the user to run docyrus auth login.

Survey available operations. Before creating rules, know which operations exist per target type:

docyrus acl operations list --targetType data_source --json
docyrus acl operations list --targetType settings --json
docyrus acl operations list --targetType devtools --json

The full catalog is in references/operation-catalog.md.

Create roles. See Roles. One role per logical access level (e.g. "Viewer", "Editor", "Admin"). If the role is app-scoped pass --tenantAppId.
Create hierarchy units (skip if org-chart RLS is not needed). See Hierarchy Units. Build parent units before children.
Create role queries (skip if row-level record filtering is not needed). See Role Queries. Each role query narrows which records a role can see in a specific data source.
Create rules. Each rule grants a role a set of operations on one specific target. See Rules. Start with data_source rules, then settings, devtools, app, ai_tool as needed.
Validate. Re-read each object to confirm it landed with the right values. See Validate.

A full worked example (two-role CRM setup with data-source rules, a settings rule, and a role query) is in references/workflow-examples.md.

Roles

# List roles (optionally filter by name/slug)
docyrus acl roles list --json
docyrus acl roles list --search "editor" --json

# Get one role
docyrus acl roles get --roleId <uuid> --json

# Create a role
docyrus acl roles create --slug "crm-viewer" --name "CRM Viewer" --json
docyrus acl roles create --slug "crm-editor" --name "CRM Editor" \
  --tenantAppId <app-uuid> --ownership CUSTOM --json

# Update a role (PATCH — any subset of fields)
docyrus acl roles update --roleId <uuid> --name "CRM Viewer (Read-Only)" --json

# Delete a role and all its assignments
docyrus acl roles delete --roleId <uuid> --json

Key fields:

--slug and --name are required on create.
--ownership ∈ SYSTEM | CUSTOM | APP | USER | PRODUCT (default CUSTOM).
--tenantAppId scopes the role to a specific app.
--disableLogin (int 0/1) prevents login when the user only holds this role.
--activitySummaryReportQueryId points to a custom query UUID for the role's activity summary dashboard.
--data '<json>' / --from-file ./payload.json override individual flags.

Hierarchy Units

Hierarchy units form an org-chart tree. Users are then assigned to units, and data-source data_access/unit_peer_access rules use that tree for RLS.

# List units (optionally filter by parent or name)
docyrus acl hierarchy-units list --json
docyrus acl hierarchy-units list --parentId <uuid> --json
docyrus acl hierarchy-units list --search "sales" --json

# Get one unit
docyrus acl hierarchy-units get --unitId <uuid> --json

# Create (build parents before children)
docyrus acl hierarchy-units create --name "Sales" --json
docyrus acl hierarchy-units create --name "Sales East" --parentId <sales-unit-uuid> --json

# Update
docyrus acl hierarchy-units update --unitId <uuid> --name "Sales West" --json

# Delete (fails if the unit has children — delete children first)
docyrus acl hierarchy-units delete --unitId <uuid> --json

--name is required on create.
--parentId is optional; omit for a root unit.

Role Queries

A role query is a DSQL-style filter object attached to one or more roles for a specific data source. Users whose active role matches are restricted to only the rows that match the query.

# List role queries
docyrus acl role-queries list --json
docyrus acl role-queries list --dataSourceId <uuid> --json
docyrus acl role-queries list --roleId <uuid> --json
docyrus acl role-queries list --restrictionLevel hidden --json

# Get one
docyrus acl role-queries get --roleQueryId <uuid> --json

# Create
docyrus acl role-queries create \
  --roleIds "<role-uuid-1>,<role-uuid-2>" \
  --dataSourceId <ds-uuid> \
  --query '{"field":"status","operator":"eq","value":"active"}' \
  --restrictionLevel "read-only" \
  --json

# Update
docyrus acl role-queries update --roleQueryId <uuid> \
  --query '{"field":"status","operator":"in","value":["active","pending"]}' --json

# Delete
docyrus acl role-queries delete --roleQueryId <uuid> --json

Key fields:

--roleIds comma-separated UUIDs — required on create.
--query JSON string of the filter object — required on create.
--dataSourceId scopes the query to one data source (optional — omit for a global filter).
--restrictionLevel ∈ hidden | read-only | not-deletable.
--filterChildRelations boolean — also apply the filter to child-relation queries.

Operations

Operations are system-defined and read-only — you can list them but cannot create, modify, or delete them.

# List all operations
docyrus acl operations list --json

# Filter by target type
docyrus acl operations list --targetType data_source --json
docyrus acl operations list --targetType settings --json
docyrus acl operations list --targetType devtools --json
docyrus acl operations list --targetType ai --json
docyrus acl operations list --targetType ai_tool --json
docyrus acl operations list --targetType field --json

# Search by name or slug
docyrus acl operations list --search "delete" --json
docyrus acl operations list --search "manage" --targetType settings --json

--targetType values: data_source, field, ai, settings, devtools, app, ai_tool. The full operation catalog (slugs + names per target type) is in references/operation-catalog.md.

Rules

A rule grants a role a set of operations on exactly one target. One rule = one (role × target) binding.

# List rules
docyrus acl rules list --json
docyrus acl rules list --roleId <uuid> --json
docyrus acl rules list --targetType settings --json
docyrus acl rules list --dataSourceId <uuid> --json
docyrus acl rules list --appId <uuid> --json
docyrus acl rules list --aiToolId <uuid> --json
docyrus acl rules list --includeArchived --json     # default: archived rules are hidden

# Get one rule
docyrus acl rules get --ruleId <uuid> --json

# Create a rule
# data_source target (default)
docyrus acl rules create \
  --roleId <role-uuid> --dataSourceId <ds-uuid> \
  --allowedOperations "view,create,edit,delete" --json

# settings target (no FK — omit dataSourceId/appId/aiToolId)
docyrus acl rules create \
  --roleId <role-uuid> --targetType settings \
  --allowedOperations "manage_users,manage_teams" --json

# devtools target
docyrus acl rules create \
  --roleId <role-uuid> --targetType devtools \
  --allowedOperations "cody,studio" --json

# ai_tool target
docyrus acl rules create \
  --roleId <role-uuid> --targetType ai_tool --aiToolId <tool-uuid> \
  --allowedOperations "allow" --json

# Update a rule (PATCH — supply only what changes)
docyrus acl rules update --ruleId <uuid> \
  --allowedOperations "view,create,edit,delete,export" --json

# Archive a rule (soft disable — still visible with --includeArchived)
docyrus acl rules update --ruleId <uuid> --archived true --json

# Restore an archived rule
docyrus acl rules update --ruleId <uuid> --archived false --json

# Hard-delete a rule
docyrus acl rules delete --ruleId <uuid> --json

Key fields:

--roleId is required on create.
--targetType defaults to data_source; valid values: data_source, field, ai, settings, devtools, app, ai_tool.
--allowedOperations comma-separated list of operation slugs; must match real slugs for the target type.
FK fields are mutually exclusive per rule row: set --dataSourceId for data_source targets, --appId for app targets, --aiToolId for ai_tool targets. Leave all three null for settings, devtools, ai, field targets.

Critical rules

All payload keys are camelCase. --roleId, --dataSourceId, --allowedOperations, --roleIds, --targetType — never snake_case. The backend ACL DTOs are camelCase and GlobalValidationPipe does NOT transform snake_case → camelCase.
One rule per (role × target FK). A unique database constraint prevents two rules for the same (tenant, role, dataSource), (tenant, role, app), or (tenant, role, aiTool). Attempting to create a duplicate returns a 500 constraint error. Check with rules list --roleId <id> first.
targetType defaults to data_source on rules create — always pass it explicitly when creating non-data-source rules to avoid accidentally creating a data_source rule with null FK.
--allowedOperations is comma-separated on the CLI — it becomes a string[] in the request. Spaces around commas are stripped.
--roleIds is comma-separated for role queries (same pattern).
--query must be a JSON string for role queries — wrap in single quotes: --query '{"field":"owner","operator":"eq","value":"{{userId}}"}'.
Operations are read-only. You cannot create or modify core_acl_operation rows — only a superadmin can. Use acl operations list to discover slugs; pass them into --allowedOperations.
Hierarchy unit delete rejects units with children. Delete leaves first, then parents.
Archive ≠ delete. rules update --archived true soft-disables a rule (the row stays and is hidden from normal list results). rules delete hard-removes it. Prefer archive when you may want to restore later.
--targetType uses underscores (data_source, ai_tool), not hyphens.
--restrictionLevel for role queries uses hyphens (read-only, not-deletable), not underscores.
Validate then test. After configuring roles + rules, log in as a user with that role and confirm the access behaves as expected.

Validate

After authoring, confirm each object landed correctly:

Roles:

docyrus acl roles list --json            # count matches
docyrus acl roles get --roleId <id> --json   # slug, name, ownership, tenantAppId

Hierarchy units:

docyrus acl hierarchy-units list --json          # tree structure
docyrus acl hierarchy-units list --parentId <id> --json  # children of a node

Role queries:

docyrus acl role-queries list --roleId <id> --json   # confirm query + restrictionLevel

Rules:
```
docyrus acl rules list --roleId <id> --json       # all rules for the role
docyrus acl rules get --ruleId <id> --json         # confirm allowedOperations, targetType, FK
```
Confirm allowed_operations matches the slugs you passed. Check target_type is correct and exactly one of tenant_data_source_id, tenant_app_id, tenant_ai_tool_id is set (rest null) for FK-targeted types.

References

references/operation-catalog.md — All operation slugs grouped by target type, with display names and intended use.
references/workflow-examples.md — End-to-end worked example: create two roles with data-source and settings rules, add a role query, validate, and test.