Using Joomla Action Logs

1. The Basics

1.1 What is the User Actions Log?

The User Actions Log (com_actionlogs) is Joomla's built-in audit-trail component. Joomla introduced it in version 3.9 (May 2018), and it has shipped in core ever since.

A few things make it special:

• It writes one row per recorded action into a single table: #__action_logs.
• It is driven by events, not polling. Every action emits a Joomla event, a plugin catches it, and a row is written.
• Each row stores the user, the timestamp, the extension context, the item id, the IP address, and a language-keyed message.
• It is read-only from the interface. Admins can view, filter, export, or purge the log, but they cannot edit individual rows.

That last point matters. An audit log you can edit is not really an audit log. Joomla deliberately offers no edit screen for log rows.

1.2 A Note on Naming: "Action Logs" vs "User Actions Log"

Before we go further, clear up one common source of confusion. Joomla uses two names for the same thing, and the inconsistency throws a lot of people off:

"User Actions Log" is the formal, original name Joomla gave the feature in 3.9. It still appears in the help docs and the toolbar heading. "Action Logs" is the shorter label people use in everyday speech; the admin menu itself says User Actions Log. They refer to the same component, the same database tables, and the same plugins. There is no separate "User Action Logs" feature.

A historical wrinkle adds to the confusion. In Joomla 3.9 and 3.10 the menu item lived under System → User Actions Log. From Joomla 4 onward it moved to Users → User Actions Log. Older tutorials and screenshots still show the old name and path. In this article "Action Logs" and "User Actions Log" mean the same thing; when in doubt, the canonical identifier is com_actionlogs.

1.3 Where Do I Find It?

In the Joomla 6 backend, these places are relevant:

Users  → User Actions Log                 (the log viewer)
Users  → User Actions Log → Options       (settings)
Users  → Manage → [a user]                (per-user email alerts,
                                          on the User Actions Log Options tab)
System → Manage → Plugins → Action Log - Joomla        (the recorder)
System → Manage → Plugins → System - User Actions Log  (the enabler)

The component lives at administrator/components/com_actionlogs/. The two plugins live at plugins/actionlog/joomla/ (the recorder) and plugins/system/actionlogs/ (the system plugin that loads it).

One note that trips people up: the component sits under Users, not under System. Some older screenshots suggest otherwise.

1.4 The Three Pieces

Action Logs is built from three parts that work together:

Disable the recorder and the log goes silent. Disable the system plugin and the log goes silent too, for the reason set out in 3.3 - it is not an optional extra.

1.5 Your First Look at the Log

Open Users → User Actions Log. The list is sorted newest first. A typical entry looks like this:

The action cell is rendered from the stored language key and its JSON, with links to the item and to the acting user. There is no expandable row: clicking follows those links. The raw JSON is only visible in the database, and we come back to it in section 6.

1.6 Filtering the List

The filter bar on the list view gives you four tools:

• Search: free text against the rendered message.
• User: narrow down to one user's activity.
• Extension: only com_content, only com_users, and so on.
• Date: a preset dropdown - Today, Past week, Past 1 month, Past 3 months, Past 6 months, Past year. There is no start and end date picker.

The most useful combination is User + Date. Because the date filter only offers presets, a question like "everything Alice did last Wednesday" means picking Past week and reading down the list, or querying the table directly (section 8.4).

3. Notifications

3.1 The Opt-in Model

Each user can subscribe to email alerts for one or more extensions on their own account, under Users → Manage → [the user] → User Actions Log Options. The two fields are Email Notifications and Events to Email. The preferences live in #__action_logs_users:

user_id    notify (0/1)    extensions  (JSON array, e.g. ["com_users","com_installer"])

• A user who is not in this table receives no notifications.
• A user with notify = 1 and extensions = com_users,com_installer gets an email every time someone touches users or extensions.

Notifications are a per-user choice, not a site-wide setting. Power users and security officers opt in; everyone else stays quiet.

3.2 What the Email Looks Like

The notifier renders the same human-readable message you see in the list view, plus:

• A direct link to the affected item, where one applies.
• The acting user's name.

The mail uses the system mailer, so check it is configured under System → Global Configuration → Server → Mail before relying on notifications. On a local Docker stack, a tool like MailHog catches every outgoing message so you can test safely.

3.3 The System Plugin's Role

This one is worth getting right, because the obvious reading is the wrong way round. The system plugin is not a notifier sitting on top of a logger. It is what makes the logger run at all.

Joomla only loads a plugin group when something asks for it, and the actionlog group is asked for in exactly one place - plg_system_actionlogs, on every request:

public function onAfterInitialise(AfterInitialiseEvent $event): void
{
    // Import actionlog plugin group so that these plugins will be triggered for events
    PluginHelper::importPlugin('actionlog', null, true, $event->getApplication()->getDispatcher());
}

So the division of labour is:

• Action Log - Joomla subscribes to the content, user and extension events and writes the rows - but only once the system plugin has loaded it.
• System - User Actions Log loads that group, adds the User Actions Log Options tab to the user edit form (the Email Notifications and Events to Email fields), and keeps #__action_logs_users in step when users are saved or deleted.
• com_actionlogs, the component, does the rest: ActionlogModel::addLog() writes each row and then calls sendNotificationEmails(), and ActionlogsHelper::getHumanReadableLogMessage() turns a stored language key plus its JSON into the sentence you read in the list.

The practical consequence is the opposite of what you might expect: disabling the system plugin stops logging entirely. The recorder is never loaded, so no rows are written, and with no new rows there are no emails either. It does not leave you with a growing log and a quiet mailbox.

If you want to silence email blasts during a bulk migration and keep the audit trail, do not touch the plugins. Clear Events to Email on the accounts that subscribe, or set Email Notifications to No for the duration.

5. IP Logging and Privacy

5.1 The Default: IP Logging Off

Out of the box, Options → IP Logging = No. When IP logging is off, every row stores a placeholder instead of a real IP, and the list view shows "Disabled".

When you turn it on, Joomla reads the visitor's IP and honours the X-Forwarded-For and Client-Ip headers. This is a single on/off switch, Behind Load Balancer (default No) under Global Configuration → Server → Proxy; core keeps no trusted-proxy list. If the resolved value is not a valid IP, the row records "Invalid" instead.

5.2 GDPR Considerations

An IP address is personal data under GDPR. Turning IP logging on means you should:

1. Have a lawful basis. Legitimate interest for security is usually fine.
2. Mention IP logging in your privacy policy.
3. Define a retention policy. IPs kept forever are hard to justify.

Reasonable defaults for a public Joomla site:

• IP logging on: you will want it the day you get hacked.
• Retention of about 90 days: purge older rows with a Scheduler task.
• A line in the privacy policy under "Security logs".

5.3 Right-to-be-forgotten Requests

When a user asks to be deleted, you do not have to destroy the whole audit trail. Anonymise instead:

1. Delete the user through com_users. This writes one final log row that references the deleted account by id.
2. Run an SQL update to scrub the historical rows:

UPDATE jos_action_logs
SET user_id    = 0,
    ip_address = '0.0.0.0',
    message    = REPLACE(message, 'OldUsername', 'deleted-user')
WHERE user_id = 123;

The audit trail stays intact; only the personally identifying parts are removed. Replace jos_ with your actual database prefix.

7. Permissions and Access

7.1 There Is No Per-Component ACL

This section used to describe an Options → Permissions tab and a view-only "audit officer" group. Neither exists. It is worth stating plainly, because the pattern is appealing and people do go looking for it.

com_actionlogs ships no access.xml - 23 other core components do - and its config.xml declares a single fieldset, actionlogs, holding the six logging options and nothing else. The component Options screen is built only from that file, so there is no Permissions tab to open and no per-component actions to grant or withhold.

Access is decided in one place instead, and it is blunt:

// administrator/components/com_actionlogs/src/Dispatcher/Dispatcher.php
protected function checkAccess()
{
    $user = $this->app->getIdentity();

    // Access check
    if (!$user->authorise('core.admin')) {
        throw new NotAllowed(..., 403);
    }
}

That is site-wide core.admin, the Super User permission. Anyone who cannot pass it gets a 403 on the whole component.

7.2 What This Means in Practice

The consequences are worth spelling out, because they cut against how most people expect an audit log to work:

• Only Super Users can read the log. There is no way to grant a manager, a security officer or an auditor read access to Action Logs through the Joomla interface.
• There is no view-only mode. Everyone who can read the log can also clear it. The toolbar offers Delete for the selected rows and Clear Log for all of them, and nothing gates one differently from the other.
• Everyone who can read it can also erase their own tracks - not with raw SQL, but with two clicks in the list view.

So Action Logs is an audit trail for a site where you trust every Super User. It is not a control that constrains them. If you need separation of duties - someone who can review activity but not alter the record, or a Super User whose actions are recorded somewhere they cannot reach - you need that outside Joomla: ship the rows to an external log collector, replicate the table, or take database backups an administrator cannot delete.

What the component does get right is the shape of the record itself. There is no Create and no Edit anywhere in the interface: you cannot add a row by hand and you cannot alter one. Rows are written by the recorder or not at all.

9. Common Mistakes and Pitfalls

9.1 "Nothing is being logged"

Work through this checklist, in order:

1. Is the Action Log - Joomla plugin enabled?
2. Is the affected component in the Logged Extensions list?
3. Did the action actually succeed? The recorder hooks the "after" events, so a save that fails validation never reaches it.
4. Are you looking at the right time range in the filter?

9.2 "Failed logins are not all logged"

This is intentional. The plugin ignores failed logins for unknown usernames so that automated scanners do not flood the table. Only failures for an existing username get a row.

9.3 "Article saves are logged twice"

They are not. The recorder does subscribe to onContentAfterSave for both the backend edit screen and the frontend submit form, but it aliases one to the other before writing:

protected $contextAliases = ['com_content.form' => 'com_content.article'];

So a front-end submission produces one row, recorded against com_content.article. If you really are seeing two rows for one save, look for a second extension subscribing to the same event rather than assuming core does it.

9.4 "The user shown is not who did it"

The recorder logs the currently authenticated user at the moment the event fires. CLI scripts and Scheduler tasks run as the guest user, so they appear with user_id = 0. A user_id = 0 usually means one of three things:

• A genuinely unauthenticated frontend event, such as a forgot-password request.
• A scheduled task or CLI command.
• A custom plugin running outside an HTTP request.

The extension column, and the IP address if logging is on, usually tell the cases apart.

9.5 "The message says 'User undefined updated ...'"

That is a missing language key. It happens when a custom extension fires an event but does not ship the matching PLG_ACTIONLOG_... strings, or when the active language pack lacks the key. The fix is to add the key to the language file or register the prefix in #__action_log_config.

9.6 "Purge wiped my evidence"

There is no undo. Before you ever purge:

1. Export to CSV first (toolbar, Export All as CSV).
2. Archive the CSV outside the Joomla install.
3. Then purge.

For any site under a compliance regime, the rule is simple: never purge without an exported copy and a record of who did it.

9.7 "I cannot find Action Logs in the menu"

It is under Users, not System. And the component refuses anyone without site-wide core.admin, so a non-Super-User account will not see the link and gets a 403 if it navigates there directly (section 7.1).

11. Customisation for Developers

11.1 Registering a Custom Component for Logging

You can make your own component log-aware in two steps, without writing a plugin. First, add it to the loggable list:

INSERT INTO jos_action_logs_extensions (extension)
VALUES ('com_mycomponent');

Second, add content-type rows so the renderer knows how to format the messages:

INSERT INTO jos_action_log_config
  (type_title, type_alias, id_holder, title_holder, table_name, text_prefix)
VALUES
  ('myitem', 'com_mycomponent.item', 'id', 'name',
   '#__mycomponent_items', 'PLG_ACTIONLOG_MYCOMPONENT');

Then ship language strings that start with PLG_ACTIONLOG_MYCOMPONENT_... for each action. As long as your component emits the standard onContentAfterSave and similar events with the right context, the existing recorder handles the rest.

11.2 Logging From Your Own Code

For a one-off log entry from a controller, model, or import script:

$model = $this->app->bootComponent('com_actionlogs')
    ->getMVCFactory()
    ->createModel('Actionlog', 'Administrator');

$model->addLog(
    [['action' => 'custom', 'detail' => 'Manual entry from import script']],
    'COM_MYCOMPONENT_LOG_IMPORT_RAN',
    'com_mycomponent.import',
    $userId   // 0 = current user
);

This is handy for batch scripts that need to leave a footprint in the audit trail without going through the event system.

11.3 Scheduled Pruning

Core ships a retention task for exactly this. You do not need a raw SQL job, and the "SQL Operations" task type that older advice points at does not exist in Joomla 6 at all.

Enable the Task - Delete Action Logs plugin, then go to System → Manage → Scheduled Tasks → New and pick Delete ActionLogs:

The task deletes from #__action_logs where log_date is older than the window you set. Nothing else is touched: the notification preferences in #__action_logs_users and the extension list in #__action_log_config stay as they are.

Watch the default. At 7 days a task created without changing that field will throw away almost everything, which is the opposite of what most people set a retention task up for. Decide the number before you save.

For the most reliable timing, trigger the Scheduler from a real system cron job rather than relying on website traffic.

13. Best Practices

If you remember only a few things from this article, remember these:

• Keep both Action Logs plugins enabled in production.
• Trim the Logged Extensions list to cut noise on busy sites.
• Turn on IP logging, but pair it with a retention task and a privacy-policy line.
• Never purge without an exported CSV stored safely outside Joomla.
• Restrict the Delete permission to one dedicated account.
• Leave API logging off unless you are actively investigating something.

15. Summary

The User Actions Log is one of those Joomla features that asks for nothing and gives a lot. It sits quietly in the background, recording every meaningful change, and the first time a client asks "who unpublished the homepage?" it earns its keep many times over.

For a few minutes of setup you get:

• Out-of-the-box auditing for 21 core components, with no extra extensions.
• Translated, human-readable messages built from JSON placeholders.
• Per-user notifications with opt-in granularity.
• CSV export with injection protection for safe review in spreadsheets.
• Optional IP logging that respects privacy by default.
• An indexed schema that scales comfortably to millions of rows.

It is not perfect. It is not tamper-evident on its own, and a determined super-user can still edit the database directly. But as a detection layer, paired with sensible permissions and a response plan, it turns "we have no idea what happened" into "here is exactly who did what, and when". If you run a Joomla site you care about, switch it on, tune it, and learn to read it before you need it.