Skip to main content
ScribeLog is a standard Eloquent model that represents a single row in the audit log table. It ships with four query scopes for the most common filtering patterns, two morphTo relationships for loading the audited model and the actor who triggered the event, and a pair of convenience accessors for reading the before-and-after attribute state. You can use it anywhere you would use any other Eloquent model — in controllers, Livewire components, Nova resources, or Blade views.

Query Scopes

Constrains the query to entries whose subject_type and subject_id match the given model instance. Use this to retrieve the complete audit history for a specific record.
Constrains the query to entries whose causer_type and causer_id match the given model instance. Use this to see every action a particular user has performed across the entire application.
Filters entries by the event column. The value should match one of the ScribeEvent enum string values: 'created', 'updated', 'deleted', 'restored', 'retrieved', or 'custom'.
Filters entries by the log_name column. Use this when you have multiple named log stores (e.g. 'orders', 'invoices') and want to query only one of them.

Common Query Patterns

Scopes are chainable, so you can compose them to build precise queries:
Always eager-load the subject and causer relationships when iterating over a collection of log entries. Using ->with(['subject', 'causer']) prevents N+1 queries when you access $log->subject or $log->causer inside a loop or a Blade template.

Relationships

A polymorphic morphTo relationship that resolves the Eloquent model the log entry is about. The morph pair is stored in the subject_type and subject_id columns. The return type depends on the model that was audited — an Order, Invoice, or any other model using HasAuditLog.
A polymorphic morphTo relationship that resolves the Eloquent model that triggered the event. For observer-driven entries this is the authenticated user at the time of the event. For manual log entries it is whatever model you passed as the causer argument. May be null if no causer was present.

Casts

ScribeLog automatically casts two JSON columns to PHP arrays:

Attribute Accessors

Rather than digging into the properties array manually, ScribeLog provides two named accessors for the most commonly accessed keys.
array
Returns $log->properties['attributes'] ?? [] — the state of the audited attributes after the event was applied. For created and restored events this is the full captured attribute set. For updated events it contains only the keys that changed.
array
Returns $log->properties['old'] ?? [] — the state of the audited attributes before the event. For updated events this contains the previous values of every changed key. For deleted events it contains the model’s attributes at the time of deletion. For created events it is an empty array.

Displaying Logs in a Blade Template

The accessors and relationships make it straightforward to render a human-readable change history:

Table Resolution

ScribeLog::getTable() resolves the table name from config('model-scribe.drivers.database.table'), falling back to 'model_scribe_logs' if the config key is absent. If you use a custom table for a named log store, query that table directly by calling ->setTable('invoices_logs') on a fresh model instance:
Alternatively, subclass ScribeLog and override $table for each named store you want to query in a strongly-typed way.