Every change in Quevell is recorded. Not selectively and not by configuration: the record is written by the same core that carries out the change, so no single feature is in a position to forget.
What a record holds
One record is one change:
| Field | What it is |
|---|---|
| Command | what happened, such as issue.transitioned or workflow.updated |
| Target | the type and id of what changed, and its version afterwards |
| Actor | who did it |
| Time | when |
| Change set | the values before and after |
| Result | SUCCEEDED: the trail records changes that happened |
| Chain | a correlation id, and the id of the event that caused this one |
| On whose behalf | if somebody acted under another user's name, both are recorded |
| Rule | if an automation rule acted, its id, its revision and the cascade depth |
The last two are worth reading twice. Entering the product as somebody else is never silent: both names are in the record, and the user whose name was worn gets a letter about it. And a rule's work never looks like a user's: the record names the rule and the revision of it that fired.
The chain ties an effect to its cause. If one change triggered a rule and the rule changed something else, every link carries the same correlation id, and "why did this suddenly move" is one filter away.
Where to read it
There are two levels.
An issue's history. On the issue itself, a feed shows what happened to it: field changes, transitions, comments, attachments. It is what you need while working, and it is open to anybody who can see the issue.
The company's trail. Administration, the security section: every record in the company, filtered and paged. It takes the right to view the audit trail; company administrators hold it by office.
Searching it
The company trail filters on three things, and they combine:
- actor: everything one user did;
- command: one kind of change. The list of commands comes from the product rather than being typed, so there is nothing to misspell;
- result: the filter exists, but today the trail holds only successful changes, so it narrows nothing.
Results are paged by cursor, newest first, and the total number of records is shown beside them, not the size of the page. That distinction matters: "how many times did this happen" used to be answered by the length of the first page, and the answer was always twenty-five.
What is not here
The trail records changes that happened. An attempt at something the user had no right to do never becomes a change and never reaches it: the refusal is visible to whoever got it and in the server logs, but not here.
Automation is different on this point: a rule refused by permissions is recorded, in the automation journal, which is a separate feed. See automation.
Records cannot be changed
A record cannot be edited and cannot be deleted. That is enforced by the database rather than by a check in the code: any attempt to change or remove a row fails with "audit events are immutable".
This matters more than it sounds. The refusal lives on the table itself, not in the application layer, so it is not routed around by a bug in a new feature, by a company administrator, or by anybody who obtains the application's own database account. While the company exists there is no tidying up after yourself.
There is exactly one exception, and it is the company's own deletion: a record can be removed only once the company it belongs to no longer exists. That is not a flag the application sets but a condition the database checks - to erase a trail you would have to delete the company first, which is not covering your tracks.
How long records live
The trail is not swept on a schedule and has no depth past which records are dropped. A company's records live as long as the company does.