The audit log
/logs. Requires audit.view.
A searchable, clickable record of who did what across the system.
What is recorded
Section titled “What is recorded”Examples of operations with audit records:
| Area | Examples |
|---|---|
| Submissions | Created, status changed, assigned, closed, outcome recorded |
| Tickets | Created, replied, closed, merged |
| Ticket time | Time logged, edited or deleted, estimate changed, time tracking settings changed |
| Quick time | Logged, edited, deleted, turned into a ticket |
| Loans | Issued, returned, registered, bulk actions |
| Devices | MDM commands sent |
| Charges | Raised, approved, declined, waived |
| Sessions | A person signed out everywhere after a retired sign-in token was presented again, shown as Refresh token reuse detected |
| Configuration | Modules, workflow, roles, users, campuses, branding, connectors |
| Backups | Run, verified, failed |
| Kiosks | Reserved, set up, revoked, new setup code issued - and a device presenting a kiosk credential that matches no kiosk |
| Vendor access | Support restore and administrator setup-link operations |
From 0.17.1, time tracking adds these actions:
| Action | Shown as |
|---|---|
ticket.timeEdit |
Ticket time entry edited |
ticket.estimate |
Ticket estimate changed |
ticket.timeSettings |
Time tracking settings changed |
time.quickLog |
Quick time logged |
time.quickEdit |
Quick time edited |
time.quickDelete |
Quick time deleted |
time.quickConvert |
Quick time turned into a ticket |
ticket.timeLog (Ticket time logged) and ticket.timeDelete (Ticket time entry
deleted) already existed. An edit records the entry before and after. Starting,
pausing and discarding a timer is not recorded; logging one writes
ticket.timeLog.
Entries identify the actor, action, time and recorded details. Coverage varies by operation and version; see current gaps.
Refresh token reuse alerts
Section titled “Refresh token reuse alerts”An alert means a retired refresh token was presented outside the short grace window. The first detection ends that account’s live sessions and records how many were ended. No live sessions means there were none left at that moment; it does not identify why the token was presented. Check the account, time and other sign-in evidence, and ask the user about stale tabs or devices. Treat an unexpected first detection as a possible credential replay.
In versions before 0.22.1, the same stale browser could produce repeated alerts even after the account had no live sessions. From 0.22.1, each retired token produces at most one reuse alert. A new alert for another token still needs review. See session security and the 0.22.1 release note.
Append-only
Section titled “Append-only”The application has no interface to edit an entry or delete one by ID. Hosting and database administrators have separate authority; the restricted production Docker database role adds enforcement that demo/native owner connections do not. Within the product, entries leave when they fall outside the retention window, which cannot be set shorter than 90 days, and a purge writes its own entry saying who ran it and what it removed.
What is not recorded
Section titled “What is not recorded”Some access and write operations. Authentication, API-key lifecycle and some configuration changes have coverage gaps. Do not infer that no action occurred merely because no event appears.
Secret values. Configuring a connector is logged; the token you pasted is not.
Read operations, mostly. Looking at a person’s profile is not logged. Changing it is. A log of every page view would be large and would bury the entries that matter.
Message bodies. That a ticket reply was sent is logged. The text lives on the ticket.
Using it
Section titled “Using it”Search and filter by actor, action, date and target.
Every entry is clickable, so you go from “somebody changed this submission” to the submission.
What to use it for
Section titled “What to use it for”Accountability, which is the obvious one. Who closed this, who approved that charge, who sent that wipe.
Troubleshooting, which is the underrated one. “It stopped working on Tuesday” plus the log usually equals “somebody changed a connector on Tuesday”. That is faster than any amount of reading code.
Reviewing access. Once a term, look at what a role has been used for. It is usually narrower than what people asked for, and that is a chance to tighten permissions with evidence rather than argument.
Answering a question from outside ICT. For example, trace a disputed charge to the recorded approval. For operations without audit coverage, use the related ticket and the provider’s own records too.
Retention
Section titled “Retention”Configurable. Longer is better for investigation and worse for disk and for privacy.
The audit log is the largest table on any mature install, so retention is also the main lever on database size. See audit and retention.
Some jurisdictions set a minimum retention for records of access to student data. Check before setting it short.
Vendor access
Section titled “Vendor access”Support restores and setup links record the caller’s stated requester. Support reads and direct infrastructure administration are not all represented here. The product support API can be disabled from Admin, Compliance; that switch does not revoke hosting access.
Permissions
Section titled “Permissions”| Permission | Allows |
|---|---|
audit.view |
Read the log |
There is no permission to write to it, and none to delete from it, for anyone
including administrators. user.manage sets the retention window and can run the
purge, which is the only thing in the product that removes entries at all; both
ask for a fresh confirmation of who you are, and the purge records itself. See
audit and retention.