Troubleshooting
This is a compilation of common problems and their respective solutions and/or workarounds.
Auditing does not work
You followed the documentation to the letter and yet, Audit
records are not being created?
Builder vs. Eloquent
Bear in mind that this package relies on Eloquent events and if they don't fire, an Audit
cannot be created.
The most common mistake is performing an update
or delete
using a Builder
instance, rather than an using an Eloquent Model
.
Using the Builder
won't trigger an Audit
:
Article::where('id', $id)->update($data);
But using Eloquent
will:
Article::find($id)->update($data);
Console/CLI and Jobs
Eloquent events fired from a Job or from the console (i.e. migrations, tests, commands, Tinker, ...), WILL NOT be audited by default.
Please refer to the General Configuration for more information.
Attributes are considered modified, when they're not
False positives cause Audit records to be created. This happens when model attributes are updated with BOOLEAN and/or DATE values.
The internal data of the Eloquent model will be as follows:
In the $attributes array attribute:
true
staystrue
false
staysfalse
YYYY-MM-DD
staysYYYY-MM-DD
In the $original array attribute:
true
becomes1
false
becomes0
YYYY-MM-DD
becomesYYYY-MM-DD 00:00:00
This makes the getDirty()
and isDirty()
methods to consider wrongful attribute changes when comparing data.
According to a maintainer, this is an expected behaviour.
As a workaround, consider passing 1
and 0
, instead of true
and false
. For date values, append 00:00:00
.
At the time of writing, this is the only open issue about this subject.
Argument 1 passed to Illuminate\Database\Eloquent\Model::serializeDate() must implement interface DateTimeInterface, null given
This might happen in version 4.1.x, because the updated_at
column values in the audits
table are set to NULL
.
After upgrading the table schema for 4.1.x, don't forget to set the updated_at
values to match the ones from created_at
.
Read the Upgrading documentation for more details.