Settings — Políticas CASL (Roles y Permisos)

The Roles y Permisos tab under Ajustes (?section=roles) uses a segmented control (Políticas | Roles). Políticas: left column lists policies (search by name, Crear política o permiso at the bottom); right column is the create/edit form (action, subject, conditions JSON, inverted). Roles: same two-column pattern — list roles, Crear rol, form with nombre/descripción and checkboxes to assign policies (create and edit; attach/detach via Identity role policy endpoints). System roles and policies remain read-only where the API enforces isSystem.

UI behaviour

• Org context: Requests require a selected organization (x-org-id). If none is selected, the tab shows an alert.
• List & search: Policies load from GET /api/identity/policies. Search filters client-side by name, description, action, and subject.
• Create: Form on the right collects name, description, acción and sujeto via selects whose options are the distinct action / subject values already returned for the org (existing policies in the DB), plus invertir and condiciones edited with Monaco (@monaco-editor/react, language JSON, vs-dark) when creating; read-only Monaco when viewing an existing policy. Empty conditions send null. The JSON must be an object (not an array); see CASL authorization.
• Edit: Only name and description are writable. Action and subject selects are disabled (immutable after create). Same for invertir and conditions (read-only); API UpdatePolicy only accepts name/description.
• System policies: No editing or deletion; the panel shows an alert and disables saves.

Panel routes

• Settings → Roles y Permisos (section=roles via nuqs on the settings view).

API reference

• RBAC and Custom Roles — policy model, actions, and subjects.
• Identity PolicyController: GET/POST /api/identity/policies, GET/PUT/DELETE /api/identity/policies/:id.

Follow-up

• Roles tab: Assigning policies to roles will use POST/DELETE /api/identity/roles/:id/policies in a later iteration.