1.6.0

Changed

• Behaviour change on update: retention.days now defaults to 365. Without ACTIVITY_RETENTION_DAYS set, activity:prune deletes every entry older than 365 days at its next run (before, an unset value pruned nothing by age). Check with php artisan activity:prune --dry-run first. If you published config/activity.php earlier, it still reads env('ACTIVITY_RETENTION_DAYS') without a default and keeps everything until you change it to env('ACTIVITY_RETENTION_DAYS', 365) (or re-publish). To keep everything on a fresh install, set 'days' => null in the published config/activity.php.

• A window of 0 or less is refused. activity:prune exits with an error and deletes nothing when the global window, --days, or any per-event-type window is below 1 or not a number, whatever it came from. subDays(0) is "now", which would delete the whole store.

• Known gap, not changed here: retention.anonymize_after_days is still stored per brand while activity:anonymize works across the whole store.

• Retention: retention.days is one value for the whole installation, not per brand. activity:prune already deleted across every brand by that single number, while the Settings page stored a separate value per brand that nothing read. The field is removed from the Settings page; the page now says where the value lives (config/activity.php). Set it there with ACTIVITY_RETENTION_DAYS or by editing the published config.

• Retention, upgrading: no migration. Rows that an earlier release stored for retention.days in brand_settings are no longer read and can be deleted by hand.

Fixed

• activity:prune no longer shortens or lengthens its window depending on which brand the run starts under.

1.5.0

Changed

• Settings: the addon now declares settingsNavParent() ([section, name] of its own Control Panel navigation entry). With statamic-brand-context 1.16 or newer its settings show as the sub-item "Einstellungen" under that entry; addons without a navigation of their own share one "Addon-Suite" page under Settings. Older brand-context versions ignore the method and keep the previous layout.

Upgrading

• No migration, no new config key.

1.4.3

Fixed

• [fix] The settings entry names itself with settingsTitle() (brand-context 1.15), in German "Aktivität". It read so only because other addons translated the name "Activity" globally, which they no longer do.

1.4.2

Fixed

• [fix] The German intro of the ledger no longer uses a dash ("Rohe, unveränderliche Fakten, nur zum Lesen. …"). A test keeps the German texts free of them.

1.4.1

Fixed: the test bed carried one test's saved settings into the next one on MySQL

Nothing in the shipped addon changed. The suite's own bed did: the shared settings layer writes
the stored overrides onto the live config from an app->booted() callback, and that callback runs
before RefreshDatabase resets the database for the test about to start. On SQLite that is
invisible, because an in-memory database is new with every connection and the boot never finds a
row. On MySQL the table still holds what the previous test left there, so the boot read those rows
and pinned them onto the config, where they stayed after the table was emptied a moment later — a
test that saves enabled => false silenced the recorder in the test after it. The bed now drops
the cached overrides and re-applies the layer once the database stands.

1.4.0

Changed: a Control Panel page whose table is missing shows an empty state instead of HTTP 500

The addon can be installed without its migrations having run — composer pulls the package in, the
nav entry appears, and activities still does not exist. Both the activity listing and an
activity's detail screen reached for that table while the page was being built and answered
HTTP 500. They now check before the first query and render a setup screen that names the missing
table and says to run php artisan migrate. The listing fetches its own rows from the same route;
that request gets an empty result set, so a tab that was already open shows an honest "nothing
here" rather than a broken table.

The reason does not disappear with the 500: every guarded page writes to the log why it turned
somebody away. Otherwise the site would look installed and never record a thing.

1.3.0

New: what gets recorded is configurable in the Control Panel

What this addon writes and how long it keeps it used to be decisions in config/activity.php.
They are the controller's decisions, not the developer's, and without file access and a deploy
the controller could not reach them. Under Settings → Addon Settings there is now a section
of its own with five groups:

• [new] Recording: the main switch.
• [new] Request context: one switch each for UTM parameters, referrer, page URL and device
  category, plus one that leaves the context out entirely.
• [new] Filter before writing: which keys are dropped from the payload before it is written,
  which event types are not written at all, and the payload's upper limit in bytes.
• [new] Retention: after how many days a row is deleted and after how many it is anonymised.
  Both may stay empty, because "keep everything" is a different state from a number.
• [new] Control Panel: the number of rows per page in the listing.

Only what someone has changed is stored. Everything else keeps following config/activity.php,
so a package update still moves the defaults along and an installation that never opens the
screen behaves no differently from the version before.

Not on the page, and the group texts say so: producers.marketing, producers.leadhub and
cp.enabled are read at boot, source is the label that sits on every row already written,
queue.* belongs to the operation of the machine, and retention.per_event_type is a map from
event type to days, for which the settings layer has no type. A switch that only takes effect
at the next deploy would be a false statement on screen.

New permission manage activity settings. Nobody holds it at first: until it is assigned to
a role the section stays invisible, including for users who may otherwise do everything with
this addon. Existing permissions are unchanged.

Requires goldnead/statamic-brand-context 1.13 or later. Older versions do show the page,
but do not apply its values reliably. On an installation with a single brand, the settings of
the addons that registered last did not apply at all: after a reload the page showed the saved
value, config() answered with the package default for the rest of the process, and the brand
switch that would have caught this up never happens in single-brand operation. On top of that,
up to 1.12 saving the same section a second time deleted the first save's override, without a
message. If you set values between 06.09. and this update, check on the page after updating
whether they are still there.

Fixed: the shipped CP bundle no longer matched core

The committed bundle was from 04.08.2026 and had been built against a Statamic core that did not
yet export usePage from the Inertia module. Since statamic/cms v6.27.0 it does, which made
the shipped file differ from a fresh build. A Composer installation runs without npm and loads
exactly this file, so it has been rebuilt.

v1.2.2

Fixed — the sibling constraint excluded the new majors

goldnead/statamic-leadhub (^1.4) and goldnead/statamic-marketing (^1.4) were pinned to the 1.x line. LeadHub 2.0.0 and Marketing 2.0.0 carry no code change over 1.12.2
and 1.13.0 — that major is the licence switch alone. A site running both this package and an
updated sibling could not resolve its dependencies at all. The constraints now accept both
lines.

1.2.1

Fixed — the breakpoint-less single-column grid utility is no longer used

Every addon in this family ships its own Tailwind build, and @statamic/cms/tailwind.css
routes all of them into the same addon-utilities layer. Media queries add no specificity, so
the bare single-column grid rule from whichever addon stylesheet loads last won against an
earlier addon's sm:/lg: variant and pinned that addon's grid to one column at every width.

Invisible when this addon is checked alone. It only appeared once two addons of the family were
installed together, which is the normal case on a real site.

A grid falls back to one column on its own, so the class bought nothing. The overflow guard its
minmax(0,1fr) track provided is preserved explicitly, because the implicit column is auto.

1.2.0 already removed the class from the markup and explained in the comment beside it why.
Tailwind scans comment text as candidates, so that explanation kept emitting the very rule it
warned about: the fix shipped, and the bundle was unchanged. The comment no longer names the
class, and addon-lint enforces that as ui.bare-single-column-grid, comments included.

1.2.0

Changed — the Control Panel is an Inertia + Vue app now

1.1.0 rebuilt the two screens out of Statamic's own components but kept them as Blade, rendered through core's NonInertiaPage compatibility path. That path is legacy, not a target: no breadcrumbs, no Inertia navigation, no shared props. Both screens are now Inertia pages backed by single-file Vue components, built by Vite like the other addons in this family.

Nothing about what the screens do has changed. Same routes, same route names, same columns, same filters, same JSON contract, same deep links, same permission. This is a port, not a redesign.

• ActivityController returns Inertia::render() for activity::Index and activity::Show. index() still answers the same route twice — the page for a browser, the listing contract for <Listing>.
• The detail payload is assembled field by field. Handing the model to Inertia would put whatever the table happens to carry into a prop the browser can read, including columns a later migration adds. A test pins the exact field list.
• The two documentation URLs are props, not strings baked into the bundle.
• resources/views is gone, and with it loadViewsFrom. The addon ships no Blade views at all.
• resources/dist/build is committed and guarded by npm run build:check plus a CI job. Composer installs never run npm, so the compiled bundle has to ship in git and has to match the source.

Fixed — a stored property can no longer be evaluated as a Vue expression

1.1.0 handled this by putting v-pre on every element that printed ledger content, because the yielded Blade was compiled as a Vue template in the operator's browser. A compiled component interpolates instead of compiling, so the whole class of failure is gone rather than guarded against. The tests that asserted v-pre now assert that a stored mustache arrives as literal text.