Audit log plugin

The Audit log plugin creates a log of administration events in a table called <DB prefix>auditlog_log. This table is only created once the plugin is activated in Plugin Manager — before that, no logging takes place and the table does not exist.

There is no log viewer inside LimeSurvey itself: an administrator has to query the <DB prefix>auditlog_log table directly (for example with a database tool) to read the logged events. The plugin also has no built-in export or retention/cleanup feature — logged rows are kept indefinitely unless removed manually.

Logged events

The list of events that can be logged is:

• Survey administrator is created or modified
• Survey administrator has logged in successfully
• Survey administrator has logged out
• Survey administrator tried to log in but failed
• Survey administrator is deleted
• A survey admin creates a response
• A survey admin modifies a response
• A survey admin deletes a response
• A survey admin imports responses
• Survey participant is created or modified
• Survey participant is deleted (including bulk/multiple deletion)
• Central database participant is created or modified
• Central database participant is deleted
• User permissions modifications
• Survey settings modifications

Each of these can be switched on or off individually — see Configuration below.

Database table

Fields

Columns of the auditlog_log table are:

• id: integer, incremental identifier of the log entry.
• created: date and time the log entry was created.
• uid: ID of the user who performed the logged action (left empty for a failed login attempt — see below).
• entity: the type of object the event applies to (for example user, token_<survey id>, responses_<survey id>, participant, permission or survey).
• entityid: ID of the object referred to by entity.
• action: name of the logged action. For most events this is a plain verb (create, update, delete, import); for the three login/logout-related events it is instead the literal event name (afterSuccessfulLogin, beforeLogout, afterFailedLoginAttempt).
• fields: names of the fields affected by the action.
• oldvalues: previous values of those fields (for example before a modification).
• newvalues: new values of those fields (for example after a modification).

  When a survey participant's password field is changed, LimeSurvey administrator account passwords are masked in this table (stored as *MASKED*PASSWORD* rather than the real value). This masking only applies to administrator/user accounts — changes to survey participant or token records (which can include personal data such as names and email addresses) are logged with their real old/new values, unmasked.

Because entity is not always built the same way for the same kind of object (for example, saving a participant/token logs token_<survey id>, while deleting one logs plain token, without the survey id), do not rely on entity alone to correlate every row for the same participant across create/update/delete actions.

Login and logout events

The three login-related events behave differently from each other:

• For afterSuccessfulLogin and beforeLogout, uid and entityid both contain the numeric ID of the user logging in or out, and newvalues is left empty.
• For afterFailedLoginAttempt, there is no authenticated user to attribute the row to, so uid and entityid are left empty. Instead, the attempted username is stored in newvalues, as JSON, e.g. {"username": "someuser"}.

Configuration

Which of the events above are logged can be configured with checkboxes on the plugin's own settings page (Configuration -> Plugin Manager -> AuditLog -> Settings). All of them are enabled by default.

Some of these events are tied to a specific survey (response create/update/delete/import, participant/token create/delete, and survey settings changes). For these, logging additionally depends on a per-survey setting, found in the survey's sidebar under the Survey menu section (not the "Survey settings" section) -> Plugins -> Settings for plugin AuditLog -> Audit log for this survey:. Both the relevant global checkbox and this per-survey setting need to be enabled for that survey's events to be logged.

  Logging of user-permission changes is controlled only by its global checkbox ("Log if a user permissions changes") — it is not affected by the per-survey "Audit log for this survey" setting, unlike the other survey-scoped events.

Central database participant events (creation, modification, deletion) are not tied to a specific survey and are therefore only controlled by their global checkboxes, with no per-survey setting involved.