Statamic Activity Laravel Package

Product Decisions This Supports

• Data lifecycle and retention policy: The new 365-day default for retention.days forces an explicit decision on how long activity/audit data is kept—supporting GDPR/data-minimization, storage cost control, and audit-history requirements.
• Upgrade risk and release sequencing: This is a behavior change on update, not a routine maintenance release. PMs should plan a dry-run and config review, and communicate that older activity may be pruned after upgrade.
• Configuration ownership: Retention now lives in config/activity.php / ACTIVITY_RETENTION_DAYS rather than per-brand Settings. PMs decide whether a central installation-wide policy is acceptable or whether per-tenant customization is needed.
• Multi-brand policy simplification: Removing the unused per-brand retention.days field clarifies that pruning is one installation-wide window. PMs should confirm this matches brand/tenant contracts.
• Safety and reliability: activity:prune now refuses windows below 1 or non-numeric values, preventing accidental deletion of the entire activity store. This supports operational trust and safer automation.
• Build vs. buy/configure: Built-in pruning with guardrails reduces the need for custom retention jobs, provided a global retention policy is acceptable.
• Known gap management: anonymize_after_days remains stored per brand while anonymization runs globally. PMs should scope or defer per-brand anonymization work separately.
• Control Panel information architecture: The addon still supports settings navigation grouping via settingsNavParent() under brand-context 1.16+, but retention controls have moved out of the Settings page.

When to Consider This Package

• You need automated activity-log pruning with a configurable, installation-wide retention window.
• You can adopt the 365-day default or explicitly set ACTIVITY_RETENTION_DAYS or 'days' => null in the published config.
• You want guardrails against zero-day, negative, or invalid retention settings.
• You accept that retention is global rather than per brand.
• You are willing to run php artisan activity:prune --dry-run before upgrading and re-publish config if it was previously published.
• Look elsewhere if: you require per-brand retention or per-brand anonymization now; you cannot change environment/config values; you need to preserve all history indefinitely and cannot set 'days' => null; or you are pinned to an older version and cannot take a behavior-changing upgrade.

How to Pitch It (Stakeholders)

• Executives: This release changes default data retention: activity older than 365 days will be pruned unless configured otherwise. It is a small code change but a policy decision—no migration is required, but explicit sign-off on retention is recommended. It also adds safety checks that prevent accidental full deletion.
• Engineering: retention.days now defaults to 365 and is installation-wide; the per-brand Settings field is removed. activity:prune validates windows (>= 1) and refuses invalid values. Run --dry-run first; re-publish config or set 'days' => null to keep everything. Known gap: anonymize_after_days remains per brand while anonymization runs globally.