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.