Audit log
Settings → Audit Log is a field-level record of who changed what, and when. It covers almost every write in the system — bookings, folios, payments, customers, products, configuration, users — and stores the value before and after each change.
It is read-only. Nothing on this screen can be edited or deleted, which is the point of having it.
The audit log
Reading the list
| Column | What it shows |
|---|---|
| Created At | When the change happened — stamped at the moment of the write, not when the entry was filed, so the order is true. |
| Actions | CREATE, UPDATE, PATCH, DELETE, plus sign-in events (LOGIN, LOGOUT, AUTH-FAILED) and MIGRATION summaries. |
| Collection | What kind of record — Booking, Customer, Config, DiveCenterGuest. |
| Actor | Who did it: the user, how they connected, and from which address — Admin · http · 127.0.0.1. Reads System for anything with no request behind it, such as a scheduled job or a start-up task. |
| Changes | The field names that changed. |
| Source | Service for a normal change made through the application, Direct write for one made straight against the database layer. |
The detail
Expand a row and every changed field is listed as path — before → after:
status Confirmed → Cancelled
expenses.due.price 1 240 → 0A create shows the fields the new record was given, or its key identifying values. A very large change is stored up to a size limit and then marked (truncated). A row with nothing recorded reads No recorded detail.
Start-up and migration entries are collapsed into one summary per collection rather than one row per record, shown as 1 482 documents touched.
What is deliberately not recorded
The audit log is designed so that reading it can never leak a credential.
- Passwords, hashes, salts, tokens, secrets, API keys, IBAN and BIC are never stored. The field is recorded as having changed; the value is not.
- Configuration values are stripped. Integration settings hold OAuth tokens and API secrets in a field simply called value, so no value from configuration is ever kept — only the fact that a particular setting changed, and by whom.
- Caches, queues, sessions and counters are skipped entirely; they are machinery, not records.
- Records that are already permanent logs are skipped — booking logs, login attempts, stock movement logs and similar. They keep their own history, and duplicating it would double the storage for no extra information.
Retention
Entries are kept for 30 days and then removed automatically. The window is deliberately short because entries carry real values: a longer history would mean holding old copies of guest and financial data indefinitely.
Warning: 30 days is not an archive. If you need a change preserved beyond that — a disputed cancellation, a payment argument — take a copy while the entry is still there.
Turning it on
Auditing is an installation-level switch, not a company setting, and it ships off. It has to be enabled by whoever runs your Gurita installation; there is no field on any settings screen that turns it on or off. That is intentional: coverage cannot be quietly disabled by someone who is about to change something.
If the menu entry is present but the list is empty, either auditing has not been enabled for your installation, or nothing has been written since it was.
Note: Auditing never blocks or slows a change. Entries are written in the background, and a failure to record one can never fail the underlying save.
Who can access this: requires the Audit permission, which in practice means an administrator. There is no write access for anybody — the log cannot be edited or cleared from the application.
Related chapters
- Users and access — the roles and permissions this log records changes to.
- Booking statuses & lifecycle — the booking log, which keeps its own permanent history separately.