Finlay.worksBareBones Ticketing manual

Operate

Audit And Evidence

How to scope, review, and export audit records, how to read a ticket's history, and exactly what append-only does and does not protect.

RC2 approved for evaluation Status: release-candidate Audience: System Administrator Source: c4b4d41

Audit And Evidence

BareBones Ticketing records what happened in two places: an installation-wide audit log an administrator reviews and exports, and a per-ticket history an agent reads. This page covers both, and defines what "append-only" means here.

What append-only means

The application runs as a restricted PostgreSQL identity created by the package installer. That identity can insert audit rows and read them. It is denied UPDATE, DELETE, and TRUNCATE on audit history, denied data definition language (DDL), denied trigger and ownership changes, and denied paths that would reach audit rows through a cascade. Audit Administration itself has no edit or delete action.

Startup checks the identity's authority and refuses to run if it has more than that — but only when the environment is set to Production. On any other ASPNETCORE_ENVIRONMENT value the check is skipped entirely and the application starts whatever authority the database identity holds. An installation running as Staging or Development gets no part of this guarantee. Confirm the environment setting before relying on anything in this section.

That is the whole of it. The claim is: the long-running application account cannot rewrite historical audit rows.

It is not a claim about anyone else. The following are all outside that boundary and can change or destroy audit history:

  • the database owner and any PostgreSQL superuser;
  • the setup login the installer used;
  • anyone who can restore or replace the database files;
  • anyone who controls the backups;
  • anyone who controls the storage underneath.

There is no hash chain. There is no write-once-read-many (WORM) storage. Nothing detects that someone restored an older database over a newer one — see Backup and restore, which is where you record the recovery point and any resulting gap yourself. An attacker who compromises the running application can append events that are false but structurally valid.

Audit review does not prove that every relevant event was recorded, and this manual sets no retention period.

Review and export audit records

Audit Administration at /admin/audit needs SystemAdmin and a recent step-up. Audit dates are in Coordinated Universal Time (UTC).

Agree the purpose, the narrowest useful scope, the format, who receives it, and where it will be stored before you start. An export is sensitive evidence.

  1. Complete the step-up and open Audit Administration.

  2. Set Start date (UTC) and End date (UTC).

  3. Narrow the scope. There are four pairs of pickers, and each has an include and an exclude side: Include actions / Exclude actions, Include actors / Exclude actors, Include entity types / Exclude entity types, and Include entity IDs / Exclude entity IDs. Add only what you need.

    Include and exclude are for different jobs. An include picker narrows the history to only the values you choose. An exclude picker keeps the broad view and removes something noisy from it — directory sync actions being the usual case, since they can outnumber everything else. Reach for exclude when you want nearly everything.

    Values must match what was recorded, exactly. A name that is nearly right returns nothing, and nothing looks the same as "this never happened". See Audit events for the names that do not work.

  4. Choose a page size: 50, 100, 250, or 500.

  5. Select Apply filters.

  6. Read the scope summary before reading any events. Check it describes the scope you meant. The filter options offered are drawn from the current time window; selections you pinned stay pinned.

  7. Page through with Previous page and Next page. Paging changes what you see. It does not change what an export will contain.

  8. Read each row: Recorded, Action, Actor, Entity, Entity ID, and Request ID. Those six columns are the whole of the on-screen view. Before-and-after values and other event payload are not shown here at all — they appear only in an export.

  9. Use Clear filters or Clear everything before defining a different scope. Do not assume a filter you did not clear has gone.

To export:

  1. Reconfirm the applied filters and where the file is going.

  2. Select Export applied scope CSV for comma-separated values, or Export applied scope JSONL for JSON Lines.

  3. Move the file straight into your approved private evidence location.

The export covers the full matching scope, not just the page on screen. The export action is itself audited, with the scope, the count, and a hash.

That hash is not a checksum of the file. It is a SHA-256 value computed over the identifiers of the rows that were selected, so two exports of the same rows produce the same hash. It records which rows were in scope. It cannot tell you whether the downloaded file was later edited. If you need to prove the file has not changed, take your own checksum of it when you file it.

Where a redaction is active, the export carries a redaction note in place of the original content. See Redaction.

Exporting does not authorize disclosing what is in the file.

Read a ticket's history

The History tab on a ticket is a read-only chronology of that ticket, scoped to actions the reader is allowed to see. It is not the full audit log, and it is not a substitute for Audit Administration.

You need current agent visibility of the ticket.

  1. Open the ticket and select History.

  2. Read Read-only ticket history from newest recorded action to oldest.

  3. For each entry, read the timestamp, the actor label, the affected record, the summary, and any captured before and after evidence.

  4. Times display in the tenant time zone. UTC is the underlying reference.

  5. Follow a retained attachment link only where your current authorization allows it.

Actions the chronology does not recognise, and facts about the far side of a hidden relationship, are left out rather than partly shown.

What each evidence state means

State Meaning
Captured The chronology retained evidence for that action
Redacted or withheld Content is suppressed and a marker is shown instead
Legacy limitation An older row that genuinely did not capture the create or edit text
Retained attachment evidence The record survives; the file may not still be downloadable
Signature or approval evidence The product's record of an approval, not proof of a legally sufficient signature

Comment-create snapshots are internal. Requesters and external surfaces never see this view.

Use Audit Administration instead when the question spans more than one ticket.

If it does not work

The result set is far larger than expected. Do not export it. Narrow the scope and apply again.

The step-up expired mid-review. Verify again. Do not work around it.

History appears to show a record the reader should not see. Stop and report it before continuing.

A retained attachment link does not resolve. The history entry stands. Route the file recovery separately; it is a storage question, not an audit question.

An export was sent somewhere it should not have gone. Stop copying it and start your organization's evidence incident process.