Download the PHP package bokshorn-it/filament-activity-timeline without Composer

A Filament plugin that makes spatie/laravel-activitylog readable.

The log stores raw database values. A change comes back looking like this:

Accurate, and useless to look at. This package renders the same entry as Status: Draft → Published, Author: Alex Rivera → Sam Okafor, Due date: 14.08.2026, by running every value back through the subject model's own casts and relationships. A diff ends up reading the way the record does on screen.

There are two ways to read the log: that slide-over timeline on a record, and a filterable resource across everything.

Features

• Record timeline, optionally pulling related records into the same stream
• Readable diffs: enum casts as labels, date casts as dates, foreign keys - polymorphic ones included - as the related record's name, booleans as words
• Models can render their own columns, for the money, quantities and custom casts no schema explains
• Activity resource with filters for event, record type, causer and date range
• Your own events beyond create/update/delete, each with its own icon and colour
• Users, customers, API clients and unattended jobs are told apart as causers
• Opt-in restore, limited to the models you nominate
• Colours come from Filament's palette, so a custom brand colour works
• Ships English and German; every label is translatable

Compatibility

Every one of those is covered by CI, on SQLite, MySQL 8 and PostgreSQL 17.

activitylog v5 keeps the before/after values in an attribute_changes column instead of inside properties. The plugin reads whichever your installed version writes, so there is nothing to configure either way: follow Spatie's upgrade guide when you move, and your timelines carry on reading the same. Note that v5 itself requires PHP 8.4 and Laravel 12.

Installation

Install the package via composer:

[!IMPORTANT] This package ships Blade views that Tailwind has to scan. If you have not set up a custom theme yet, follow Creating a custom theme in the Filament docs first, otherwise there is no theme CSS file to register the views with and the timeline will render unstyled.

Add the package's views to your theme CSS file:

Then rebuild your assets with npm run build.

If activitylog is not set up yet, publish and run its migrations. This package adds no tables of its own:

Register the plugin on your panel:

Optionally publish the config file:

The views and translations are publishable too, if you would rather edit them than configure them:

Usage

Logging a model

Use spatie's trait as usual, and implement ProvidesActivityTitle so the model can say what it is called:

That one method does three jobs: it names the record as the subject of an entry, as the causer of one, and as the resolved value of any foreign key pointing at it.

If your models use $guarded rather than $fillable, reach for logUnguarded() instead, and exclude the timestamps:

The timeline action

A record's history often lives partly on its children. Pull them into the same stream:

Field labels

Only your application knows what its columns mean, so diff labels come from a translation file on your side. Create lang/en/changes.php, keyed by column name:

Unmapped columns fall back to a headline-cased version of the key, so a new column is readable straight away and you can fill these in gradually. Point it somewhere else with ->fieldLabelNamespace('...').

Field values

Diffs resolve what the schema can tell them: enum casts, date casts, foreign keys, morph columns, booleans. What a column means is a different matter - that price_cents is money, that a quantity carries three decimals it should not show, that a custom cast holds a calendar day. Implement ProvidesActivityValues and the model decides for the columns it knows:

Return null for everything else and it falls through to the formatter's own handling, so claiming one column costs you nothing on the rest. The value arrives as it was logged - the raw database value, not the cast one - and empty values and booleans are settled before the model is asked, so an implementation never has to answer for those. A formatter that throws is caught and falls through, since a diff has to render either way.

Put it on a base model or a trait of your own to cover a whole application at once.

Foreign keys

A key resolves through the relationship named after it: author_id follows author() and shows what ProvidesActivityTitle returns, so the diff reads "Ada Lovelace" rather than "14". Soft-deleted records are found too - history keeps pointing at records that have since gone, and their name is the reason for looking them up at all.

Polymorphic keys work the same way, with no configuration: notable_id follows notable(), reads the type from the notable_type logged beside it, and resolves through a morph map if you registered one. When only the id was logged and the type was not, the raw value stays.

Your own events

Log what your domain actually does, not just CRUD:

Give each one an icon and a colour so it reads as a first-class entry rather than a grey fallback:

Labels come from lang/{locale}/activity_events.php, configurable with ->eventLabelNamespace(). Unregistered events still render, just neutrally.

Record type labels

A subject's type is labelled by its Filament resource. Models that no resource manages, such as child records and pivots, take their label from lang/{locale}/activity_subjects.php, keyed by the snake cased class name:

Configurable with ->subjectLabelNamespace(). Without an entry, the class name is used.

Causers

Not every actor is a user. Give each type its own icon:

Names resolve through ProvidesActivityTitle and fall back to the model's name attribute. An entry with no causer shows as "System" instead of an empty cell.

Worth knowing: activitylog attaches the authenticated user by itself. An entry ends up without a causer when nobody was signed in, which is what you want for queue jobs and scheduled commands. Pass causedBy() yourself when the actor is not the logged-in user, for example someone acting through a customer portal.

Bulk writes are usually not worth logging at all. Wrap an import or a sync so it does not bury the changes people actually made:

Restore

Writing old values back onto a record is destructive, and on records that are meant to stay as written it is simply wrong, so it stays off until you name the models it applies to:

It writes past $fillable on purpose, since the values came out of the record itself. It tells you when there was nothing to restore rather than claiming success, and logs the restore as its own entry.

Scoping the log

The resource and the timelines share one callback, so a scope cannot be applied in one place and forgotten in the other. Multi-tenant applications filter here:

Navigation

Authorisation

No policy is registered for you. One is included that uses the permission names filament-shield generates, if that suits you. Note that Activity is a vendor model, so Laravel will not discover a policy for it by convention. Register it yourself:

It denies create, update and delete outright.

Swapping the resource

Subclass it to change the table, the filters or the labels, and hand it back to the plugin. Useful when you want the resource to keep an existing name, URL or set of permissions:

Other options

Trying it

The repository ships a demo application, and the screenshots are taken from it. It runs a stock Filament panel with a few articles that already have a history worth looking at:

Then open /demo and sign in with [email protected] / password.