Role-Based Editing [DONE] `PL-F1810`
En resumen
RBAC for the CMS — federation, region and club editor roles enforced at the API layer with org-node scope checks, a draft → review → publish approval workflow with state-machine transitions, a full audit trail on every create/update/delete/publish/schedule/approve/reject including denied attempts, and split publish-immediate vs. publish-scheduled permissions so larger federations can run a real editorial queue while small clubs keep one-click publishing.
Cómo funciona
Every CMS mutation route runs through `enforce_site_edit_scope`, which maps the target CmsSite's SiteTemplate (federation/region/club) to a required capability — `cms:edit:federation`, `cms:edit:region`, `cms:edit:club`. For region and club editors the enforcement also checks org_node scope: an editor with `cms:edit:club` for OrgNode `Bk Hagaberg` cannot mutate any other club's site, even within the same tenant. Federation admins get a blanket override across the federation.
The approval workflow is a state machine — `APPROVAL_WORKFLOW_TRANSITIONS` defines legal moves: editors with `cms:edit:*` push draft → review; approvers with `cms:approve` push review → published or back to draft with a rejection reason; users with `cms:publish:immediate` bypass the queue and go draft → published in one step; users with both `cms:approve` and `cms:publish:schedule` can approve from review and schedule for a future date. Role templates ship preconfigured: `federation-content-editor` (edit + approve + schedule), `club-content-editor` (edit + immediate publish), `region-content-editor` (edit + immediate). The audit trail (`audit_cms_mutation`) writes to AuditLogDomain.CMS for every create, update, delete, publish, schedule, approve and reject event, capturing actor, timestamp, before/after diff and reason.
Denied attempts are also logged via `_audit_cms_denied` so security incidents are reviewable. Enforcement is integrated across every CMS router (cms, cms_media, cms_blog, cms_forms, cms_seo, cms_widget) so no surface bypasses RBAC. The result: a small club uses immediate publish with one editor, a large federation uses a full editorial workflow with separate approvers and translators, and both share the same engine.
Capacidades clave
- Scoped editor roles: federation, region, club with org-node enforcement
- Draft → review → published state machine with rejection reasons
- Immediate publish vs. scheduled publish split as separate capabilities
- Pre-configured role templates for common workflows
- Audit trail on every mutation including denied attempts
- Federation-admin blanket override across all sites in a tenant
- Enforcement integrated across all CMS routers — no bypass surface
En la práctica
Marie, a content editor at a French ligue, drafts a press release. She has `cms:edit:federation` and `cms:approve` but only `cms:publish:schedule`, not `cms:publish:immediate`. She moves the article to review, then approves her own work — but the system requires a different approver, so she pings her colleague Henri who has `cms:approve`.
Henri reviews, approves, and Marie schedules publish for tomorrow at 09:00 since she has `cms:publish:schedule`. The audit trail records every step: Marie's draft creation, Henri's approval with timestamp, Marie's schedule action with target time. Tomorrow at 09:00 the publisher job flips state to published; the audit log captures the automatic transition with `actor=system`.
A month later an internal review pulls the full history in seconds.
Funcionalidades de este subsistema
6| ID | Status | Funcionalidades |
|---|---|---|
| F18.10.01 | Entregado | Federation editor role (manages federation site) — PL-F1810 ✅ PL-F1810 |
| F18.10.02 | Entregado | Club editor role (manages club site only) — PL-F1810 ✅ PL-F1810 |
| F18.10.03 | Entregado | Region editor role (manages region landing page) — PL-F1810 ✅ PL-F1810 |
| F18.10.04 | Entregado | Content approval workflow (draft > review > publish) for larger federations — PL-F1810 ✅ PL-F1810 |
| F18.10.05 | Entregado | Audit trail on all content changes — PL-F1810 ✅ PL-F1810 |
| F18.10.06 | Entregado | Content scheduling permissions (who can publish immediately vs. schedule) — PL-F1810 ✅ PL-F1810 |