• Main Audit Log
• Audit Event Types
• Allowing Non-Admins to See the Audit Log
• Other Logs
• Setting Audit Detail Level
• Write Audit Log to Filesystem

• View Primary Site Log
• Site HTTP Access Logs
• SQL Query Logging

Main Audit Log

The main Audit Log is available to site administrators from the Admin Console. Users with the site-wide role "Troubleshooter" can also read the audit log.

• Select (Admin) > Site > Admin Console.
• Under Management, click Audit Log.
• Use the dropdown to select the specific category of logged events to view. See below for detailed descriptions of each option.

Audit Event Types

• Assay/Experiment events: Assay run import and deletion, assay publishing and recall.
• Comments entered when assay data is deleted from Sample Manager or Biologics LIMS will be shown in the User Comment column.
• Attachment events: Adding, deleting, and downloading attachments on wiki pages and issues.
• Authentication settings events: Information about modifications to authentication configurations and global authentication settings.
• Client API Actions: Information about audit events created by client API calls. See Insert into Audit Table via API.
• Compliance Activity Events (Premium Feature): Shows the Terms of Use, IRB, and PHI level declared by users on login. Learn more here: Compliance: Logging

• Data Transaction events: Basic information about certain types of transactions performed on data, such as insert/update/delete of sample management data.
• Dataset events: Inserting, updating, and deleting dataset records. QC state changes.
• For dataset updates, the audit log will record only the fields that have changed. Both values, "before" and "after" the merge are recorded in the detailed audit log.
• Note that dataset events that occurred prior to upgrading to the 20.11 release will show all key/value pairs, not only the ones that have changed.
• Domain events: Data about creation, deletion, and modification of domains: i.e. data structures with sets of fields like lists, datasets, etc.

• Domain property events: Records per-property changes to any domain.
• If a user changed 3 properties in a given domain, the "Domain events" log would record one event for changes to any properties; the "Domain property events" log would show all three events.
• The Comment field of a domain property event shows the values of the attributes of the property that were created or changed, such as PHI level, URL, dimension, etc.
• Any comments entered when users delete Sample Types or Sources from Sample Manager or Biologics LIMS are recorded in the User Comments column.
• File batch events: Processing batches of files.
• File events: Changes to a file repository.
• Flow events: Information about keyword changes in the flow module.
• Group and role events: Information about group modifications and role assignments. The following are logged:
• Administrator created a group.
• Administrator deleted a group.
• Administrator added a user or group to a group.
• Administrator removed a user or group from a group.
• Administrator assigned a role to a user or group.
• Administrator unassigned a role from a user or group.
• Administrator cloned the permissions of a user from another user.
• Administrator renamed a group.
• Administrator configured a container to inherit permissions from its parent.
• Administrator configured a container to no longer inherit permissions from its parent.
• Inventory Events: (Premium Feature): Events related to freezer and other storage inventory locations, boxes, and items.
• LDAP Sync Events (Premium Feature): The history of LDAP sync events and summary of changes made.
• Link to Study events: Events related to linking assay and/or sample data to a study.
• List events: Creating and deleting lists. Inserting, updating, and deleting records in lists.
• Details for list update events show both "before" and "after" values of what has changed.
• Logged query events - Shows the SQL query that was submitted to the database. Learn more here: Compliance: Logging
• Logged select query events (Premium Feature): Lists specific columns and identified data relating to explicitly logged queries, such as a list of participant id's that were accessed, as well as the set of PHI-marked columns that were accessed. Learn more here: Compliance: Logging
• Logged sql queries (Premium Feature): SQL queries sent to external datasources configured for explicit logging, including the date, the container, the user, and any impersonation information. See SQL Query Logging.
• Message events: Message board activity, such as email messages sent.
• Module Property events: Displays information about modifications to module properties.
• Notebook events (Premium Feature): Events related to Electronic Lab Notebooks (ELN).
• Participant Group Events: Events related to the creation and modification of participant groups and categories.
• Pipeline protocol events: Changes to pipeline protocols
• Project and Folder events: Creation, deletion, renaming, and moving of projects and folders. Changes to file roots are also audited.
• Query export events: Query exports to different formats, such as Excel, TSV, and script formats.
• Query update events: Changes made via SQL queries, such as inserting and updating records using the query. Note that changes to samples are not recorded in the query update events section; they are tracked in sample timeline events instead.
• Sample timeline events: Events occurring for individual samples in the system.
• Creation, update, storage activity, and check in/out are all logged.
• Comments entered when Samples are deleted from Sample Manager or Biologics LIMS will be shown in the User Comment column.
• Sample Type events: Summarizes events including Sample Type creation and modification.
• Samples workflow events: Events related to jobs and tasks created for managing samples in Sample Manager and Biologics.
• Search: Text searches requested by users and indexing actions.
• Signed Snapshots: Shows the user who signed, i.e. created, the signed snapshot and other details. For a full list, see Electronic Signatures / Sign Data
• Site Settings events: Changes to the site settings made on the "Customize Site" and "Look and Feel Settings" pages.
• Study events: Study events, including sharing of R reports with other users.
• Study Security Escalations: Audits use of study security escalation.
• TargetedMS Representative State Event: When uploading multiple Panorama libraries, logs the number of proteins in a conflicted state and their resolutions.

• User events: All user events are subject to the 10 minute timer. For example, the server will skip adding user events to the log if the same user signs in from the same location within 10 minutes of their initial login. If the user waits 10 minutes to login again then the server will log it.
• User added to the system (via an administrator, self sign-up, LDAP, or SSO authentication).
• User verified and chose a password.
• User logged in successfully (including the authentication provider used, whether it is database, LDAP, etc).
• User logged out.
• User login failed (including the reason for the failure, such as the user does not exist, incorrect password, etc). The IP address from which the attempt was made is logged for failed login attempts. Log only reflects one failed login attempt every 10 minutes. See the Primary Site Log File for more frequent logging. Failed login attempts using API Keys are not logged. Instead, see the Tomcat Access logs.
• User changed password.
• User reset password.
• User login disabled because too many login attempts were made.
• Administrator impersonated a user.
• Administrator stopped impersonating a user.
• Administrator changed a user's email address.
• Administrator reset a user's password.
• Administrator disabled a user's account.
• Administrator re-enabled a user's account.
• Administrator deleted a user's account.

Allowing Non-Admins to See the Audit Log

By default, only administrators and troubleshooters can view audit log events and queries. If an administrator would like to grant access to read audit log information to a non-admin user or group, they can do so assigning the role "See Audit Log Events". For details see Security Roles Reference.

Other Logs

Other event-specific logs are available in the following locations:

Setting Audit Detail Level

For some table types, you can set the level of auditing detail on a table-by-table basis, determining the level of auditing for insert, update, and delete operations. This ability is supported for:

• Lists
• Study Datasets
• Participant Groups
• Sample Types
• Inventory (Freezer Managment) tables
• Workflow
• Electronic Lab Notebooks

Audit Level Options

Auditing level options include:

• NONE - No audit record.
• SUMMARY - Audit log reflects that a change was made, but does not mention the nature of the change.
• DETAILED - Provides full details on what change was made, including values before and after the change.

The audit level is set by modifying the metadata XML attached to the table. For details see Query Metadata: Examples.

Write Audit Log to File System

Audit Log messages can be written to the filesystem in addition to being stored in the database. Such additional archiving may be required for compliance with standards and other requirements.

To configure filesystem logging, an administrator edits the log4j2.xml file. Note that any other options permitted by log4j can be enabled, including writing the audit log content to the console, using multiple files, etc.

The administrator first creates a log name corresponding to the name of the particular log to record on the filesystem. For example, the GroupAuditEvent log would be written to "labkey.audit.GroupAuditEvent." Within the default log4j2.xml file, there is a default template available showing how to include the audit logs and columns to be written to each designated file. See comments in the file close to this line for more detail:

<Logger name="org.labkey.audit.event.UserAuditEvent" additivity="false" level="OFF">

These log messages are not part of any transaction, so even if the writing of the audit event to the database fails, the writing to the filesystem will already have been attempted.

The format of audit messages written to the designated file(s) or other output source is:

<eventType> - key: value | key: value | …

For example:

UserAuditEvent - user: username@labkey.com (1003) | auditEventCreatedBy: username@labkey.com (1003) 
  | container: / (48d37d74-fbbb-1034-871f-73f01f3f7272) | comment: username@labkey.com logged in
  successfully via Database authentication. |

Audit Event Types

• AppPropsEvent - written upon change to a System setting (such as one of the Compliance settings)
• AssayPublishAuditEvent - written when an assay is published
• AttachmentAuditEvent - one action that triggers this is to attach a file to a message
• AuthenticationProviderConfiguration - written upon a change to authentication settings (e.g., enable/disable self-signon)
• ClientAPIActions - triggered when client script code explicitly calls the log
• ComplianceActivityAuditEvent - written from the complianceActivities module
• ContainerAuditEvent - creating or deleting containers are two examples
• DatasetAuditEvent -
• DomainAuditEvent - creating a new list will create a domain audit event
• ExperimentAuditEvent
• FileSystem
• FileSystemBatch
• GroupAuditEvent - creating or modifying a group will create one of these events
• ListAuditEvent - updating a list will create such an event
• LoggedQuery - written from the compliance module
• MessageAuditEvent - generated when an email message is sent
• PipelineProtocolEvent
• QueryExportAuditEvent
• QueryUpdateAuditEvent
• SampleSetAuditEvent (legacy name used for Sample Type Audit Events)
• SearchAuditEvent
• SelectQuery

Biologics: Actions Allowing User-entered Reasons

To find the list of actions that allow a user entered reason, see the Sample Manager documentation here:

• Require Users Provide Reasons for Certain Actions

Related Topics

• Insert into Audit Table via API
• Compliance: Logging
• Site HTTP Access Logs
• SQL Query Logging