`ticketing` was not one of the apps `audit_events` had ever seen — 4,378
rows, fifteen apps, none of them this one, since the table was created. A
super admin created a ticket and replied to it and the only new row
afterwards was the shell recording their own visit to the log page.
Nothing in core was wrong: AuditRegistry's docblock is explicit that
snap-ins declare their own models from their own providers and that core
never references a snap-in. Ticketing simply never declared.
TicketingServiceProvider::boot() now declares four models, in the shape
FormsServiceProvider uses for FormCollaborator — the exact precedent, for
the exact reason:
- TicketingAgentAccess — the grant. `settings.agents.store`/`.destroy`
hand out and take back access to a whole queue of other people's
correspondence and left no trace at all. This is the one that matters.
- TicketingGroup — name, prefix, email_address, archived_at, so the one
button that archives-or-deletes a desk says which it did.
- Ticket — created, deleted, moved, re-assigned, re-prioritised, closed,
merged.
- TicketParticipant — the narrower way somebody comes to see a ticket.
Nothing is declared `sensitive`: that buys read-audit, which on Ticket
would record every agent opening every ticket all day and bury the writes
this card is about. TicketMessage is deliberately not declared either —
it can only ever be created (one controller method, no edit, no delete
route), every inbound email writes one under `system`, and the thread is
already the permanent record of what was said.
removeParticipant deleted through the query builder, which fires no model
events, so it would have recorded every add and no removal — a trail that
reads as though nobody is ever taken off a ticket. It now deletes through
the model.
428a9e42c6