Statamic Delegated Laravel Package

Technical Evaluation

Package summary. Delegated is a Laravel/PHP addon for Statamic (the Laravel-based CMS) that governs who may edit what: it narrows authoring rights by territory, layers assignments onto users, and records changes in an audit log. It is a governance/permissions addon, not a content-rendering or delivery component — it sits on the control-panel and authoring path rather than the public request path.

Architecture fit. The addon's responsibility is orthogonal to content modelling and site delivery, which is the right shape: it constrains the authoring surface and observes writes, so it should not entangle itself with Antlers templates, routing, or the publish pipeline. The existence of a persistent audit log means there is a storage and retention concern that lives alongside the app database, and permissions semantics that need to be understood as additive restrictions on top of Statamic's native roles rather than a replacement for them. That is a sound design for a governance layer, but it means the mental model is "Statamic permissions, then Delegated narrows further" — important for both admins and for whoever debugs an access complaint.

Integration feasibility. Low-friction on the mechanical side. It is a Composer package installed with composer require, with no migration in this release and, per the notes, no change to territories, assignments, or audit-log data. Control-panel assets are prebuilt and shipped, so there is no Node/build-toolchain dependency imposed on the host project. The practical integration work is therefore configuration and policy design (defining territories, mapping users to assignments, deciding audit retention), not engineering plumbing.

Technical risk. The dominant risk in this class of package is version coupling: it patches Statamic's control panel, so it is sensitive to minor-version churn in the CMS. v1.0.2 directly addresses that, and does so in the least risky way available — it widens the constraint (>=6.31.0 <6.39.0) and states it was verified against 6.34 through 6.38. Widening without a behavioural change is a compatibility claim, not a functional change; the blast radius is limited to the control-panel bundle. The one cosmetic discrepancy called out — a name added to Statamic's UI kit in 6.36 that Delegated does not consume — is a good signal that the vendor is tracking the UI kit deliberately rather than incidentally.

Secondary risks worth naming: the audit log is a growing, append-mostly dataset with compliance overtones, so its retention, immutability, and export story matter more than its size; and permission layers that subtract from native roles can produce "I have the role but still can't edit" support tickets if the interaction isn't documented for admins.

Key questions.

• Does Delegated's audit log capture who/when/what-before/what-after, and is it queryable/exportable for an auditor without direct DB access?
• How are territory and assignment definitions stored — config files (deploy-time, reviewable) or database/CP (runtime, auditable but mutable)? This determines whether permission changes go through change control.
• Is there a documented precedence rule between Statamic's native roles and Delegated's restrictions, with a test or matrix we can cite?
• What is the supported upgrade cadence when Statamic ships 6.39? Is there a stated policy for how quickly the constraint is widened, and does the constraint's upper bound mean installations will hard-fail on a new Statamic minor?
• Does the addon have automated tests against the full supported matrix, or is verification manual per release?

Integration Approach

Stack fit. Requires a Laravel application running Statamic 6.x in the 6.31–6.38 window, PHP at whatever floor Statamic 6 itself imposes, and Composer as the delivery mechanism. It is a natural fit for a standard Statamic site — no separate service, no queue worker, no external dependency introduced. Teams running Statamic for marketing sites with a small editors group will find the value proposition thin; teams with regional editors, franchise/location content, or regulated content ownership will find it material.

Migration path. This release is explicitly migration-free: upgrading leaves territories, assignments, and the audit log intact. For our purposes the migration question is really the initial adoption, not the v1.0.2 bump. Adopting Delegated onto an existing site is a policy migration: existing users have implicit broad access, and turning on territory restrictions will remove access they currently have. That is the change that needs a communication and validation plan — not the patch upgrade.

Compatibility. The constraint widening is the headline and it is genuinely useful: a greenfield site installing the newest Statamic no longer has to downgrade the CMS to install Delegated, which removes an awkward pin-and-hold step from any new build. The upper bound at <6.39.0 is a deliberate guardrail — it will block installation on the next Statamic minor until the vendor re-verifies. That is the right default for a CP-patching addon, but it must be planned for, not discovered.

Sequencing.

1. Pin the target Statamic minor, confirm it falls in 6.31–6.38, and record the constraint's upper bound as a known operational tripwire.
2. Install Delegated in a staging environment against a production-like content export; do not touch production first.
3. Model territories and assignments on staging, then diff resulting access against current access per user — this is the step that surfaces unintended lockouts.
4. Validate the audit log against a real editorial session: create, edit, move, delete, publish/unpublish, and confirm each is captured as expected.
5. Agree audit retention/export with whoever owns compliance before go-live, so the log isn't a discovery later.
6. Roll out to a single territory or team first, with a documented fallback (disable the addon / restore broad roles).
7. Schedule the Statamic 6.39 upgrade as a joint task with a Delegated constraint bump, not as two independent updates.

Operational Impact

Maintenance. Low steady-state maintenance. No migration in this release, no data-shape change, no new runtime service. The recurring cost is upgrade coupling: each Statamic minor potentially requires a Delegated release to widen the constraint, and because the upper bound is hard, a Statamic upgrade can be blocked by Delegated's verification lag. Budget for that as a recurring coordination task rather than an occasional surprise.

Support. Support load will concentrate in two places. First, access disputes — "I should be able to edit this page." Because Delegated subtracts from native roles, editors will see their Statamic role and reasonably conclude they have access. Admin-facing documentation of the precedence rule and a way to answer "why can't this user edit this page?" quickly is the single highest-value operational artifact. Second, audit questions from compliance or legal, which require someone who knows the log's schema and retention policy.

Scaling. Two dimensions. Content and user scale: territory/assignment evaluation on the authoring path is per-request for editors only, not the public site, so it should not affect visitor-facing latency; the population that matters is concurrent CP users, which is typically small. Data scale: the audit log grows monotonically with editorial activity. It needs a retention window or archival plan from day one — this is the component most likely to become an unbounded table if no one owns it. Neither scaling concern is acute at typical editorial volumes.

Failure modes.

• Constraint block on Statamic upgrade. Statamic 6.39 ships, Delegated still caps at <6.39.0, and the upgrade stalls or someone force-installs with --ignore-platform-reqs and gets an unverified CP bundle. Mitigation: treat CMS upgrades and addon bumps as one ticket.
• Over-restriction at rollout. Misconfigured territories silently remove editing rights; users work around it by sharing accounts or asking an admin to broaden a role, quietly defeating the governance model. Mitigation: staged rollout with an access diff.
• Silent audit gaps. If a content mutation path bypasses what Delegated observes (bulk operations, programmatic imports, API writes), the audit log looks complete but isn't — the worst failure for a compliance control. Mitigation: explicitly test non-CP write paths before relying on the log.
• CP bundle drift. A Statamic UI-kit change breaks the Delegated panel. Low severity (authoring UI, not public site), recoverable by pinning, but disruptive mid-day.
• Orphaned assignments. Users leave; assignments and territories linger and grant access to successors. Mitigation: periodic access review, ideally generated from the same data Delegated holds.

Ramp-up. For developers, near-zero: composer require and configuration. For editors, minimal and one-directional — they will simply find some content no longer editable, which needs a short explainer rather than training. The real ramp-up is on the admin/ops side: whoever owns permissions must internalize the territory/assignment model and the precedence rule, and whoever owns compliance must own the audit log's retention and export. Plan for roughly a half-day of admin enablement plus a documented runbook covering the access-dispute question, the audit-export procedure, and the Statamic-upgrade-plus-Delegated-bump checklist. Do not treat this as a zero-onboarding package just because the install is one command.

Assessment of v1.0.2. No breaking changes, no behavioural change, no migration. The release is a compatibility widening plus a re-verified CP asset build. It removes a real onboarding friction (greenfield sites no longer need to downgrade Statamic) and confirms active maintenance across five Statamic minors. Net: a positive maintenance signal for an addon we would otherwise watch for abandonment risk, and a reason to proceed with a staging evaluation rather than wait.