What problem does it solve? Nested relational writes (M2M, O2M, M2A) sent to a parent collection normally bypass permission checks on the underlying junction and child tables, letting any user with parent update access freely create or delete related rows. This Skill closes that gap by enforcing a two-layer permission model at every relational level. ## Core Features & Use Cases - Two-Layer Enforcement: Applies a gate check (does the user have any permission for this action on the child collection?) followed by an item-level filter that scopes UPDATE/DELETE via WHERE clauses and INSERT via fields, validation, and presets. - Guided Setup Workflow: Identifies junction/child collections from daas_relations, seeds daas_permissions rows per action, verifies coverage with the audit-relational-permissions endpoint, and enables enforcement via ENFORCE_RELATIONAL_PERMISSIONS. - Filter Rule Guardrails: Documents which JSONB filter patterns are supported on child mutations (scalar operators, _in, _and/_or, $CURRENT_USER) and which silently fail (_has, dot-notation, _some/_none), preventing accidental over-permissive access. - Use Case: A PATCH to cmp_catalogues with nested catalogue_services create/delete blocks is rejected with 403 unless the user's policy grants create/delete on cmp_catalogue_services, scoped to rows they own. ## Quick Start Set up relational permissions so that nested writes to the catalogue_services junction table require explicit create and delete permissions scoped to the current user.
