The Audit Trail entry is missing from the admin menu
The menu entry is shown only to Super Users, and to Admin users when Admins may view the log is on (Plugins > Audit Trail > Configure). Contributors and Researchers never see it. Also check on the Plugins page that the plugin is installed and active.
Nothing is being logged
- Check that Enable audit trail is on in the settings.
- Check that the kind of event is ticked under Events to log.
- Only saves that succeed are logged; reads, searches and saves that fail validation are not. Saving a settings form without changing anything is not logged either.
- Look in PHP's error log for lines starting with
[AuditTrail]. The plugin never interrupts a request when logging fails; it reports the problem there instead. A common cause is a missing table after a failed installation: uninstall and install the plugin again.
An edit appears without saying what changed
Only a few columns are compared on update (visibility, roles, titles and slugs; see Logged Events). Changes to an item's metadata are logged as an update without a list of fields. Install Resource Versioning to keep each version of the texts.
A batch edit or import fills the log
It does not have to: tick Group bulk operations (on by default) and each batch is one row. Click its event count to see the events. To keep jobs out of the log entirely, untick their kinds of records under Events to log while they run.
Failed logins show Visitor as the actor
Nobody is signed in during a failed login. The username typed is the entry's resource (and is in its data), and the entry is in that account's Activity tab when the username exists.
The Actor column says System
The action was made by a background job or a command-line script without a user, such as a scheduled purge or an import script. Jobs started from the admin carry the user who started them.
All entries show the same IP address
The site is behind a proxy or load balancer that does not pass the client's address in X-Forwarded-For, or whose own address is public. The header is only believed from private and loopback addresses; ask your host to send it from such an address, or to forward the client's address.
IP addresses look cut short
Redact IP addresses is on: IPv4 addresses end in .0 and IPv6 addresses in :****. Turn it off to store full addresses for new entries; existing entries keep what was stored.
The Retention purge section is not on the log page
Only Super Users see it. Admins can view and export the log, but not purge it.
I clicked Run purge now but old entries are still there
- Check the Retention period: if it is
0, purges do nothing. - Entries are deleted only when older than the retention period at the moment the purge runs.
- The purge runs as a background job, which needs the path to PHP's command-line program (
background.php.pathinapplication/config/config.ini). If background jobs do not run on your server, turn on Purge automatically or use the command-line script (see Purging Old Entries).
The command-line script says it cannot find an Omeka installation
It looks three folders up from bin/, following the path as you typed it. Run it from your Omeka folder as php plugins/AuditTrail/bin/purge-audit-log.php, or give the folder with --omeka=/path/to/omeka.
The command-line script says logging is turned off
Enable audit trail is off, so the scheduled purge skips its run. Turn logging back on, or pass --days N to purge anyway.
Audit Trail's own activation is not in the log
A plugin that is off cannot log anything, including being turned on. Its deactivation is logged; after reactivation, logging resumes with the next event.
Does uninstalling delete the log?
Yes. Uninstalling drops the table and every entry with it. Export the log first if you need to keep it.