action #49202

Updated by cdywan about 1 year ago

The audit events which can be found on and respectively in production currently look like so

`acarvajal job_restart { "id": "2539127", "result": { "2539127": 2540030, "2539128": 2540031, "2539129": 2540032, "2539130": 2540033 } }
coolo job_create { "id": 2540028 }
system command_enqueue { "command": "cancel", "workerid": 1061 }
cfconrad jobtemplate_delete { "id": "16093" }
cfconrad jobtemplate_create { "affected_rows": null }`

With [the PR fixing the value of `affected_rows`]( the last example might look like so
cfconrad jobtemplate_create { "affected_rows": 2 }`

Two kinds of problems are common to all of these events:
* the IDs require knowledge of the code to construct a URL or SQL query
* some values on their own are not sufficient to make use of, such as the number of rows affected

To fix this I'm proposing:

* Events carry the minimum info needed to lookup the real data ie. [iso_create only needs to contain the product id](
* The audit log UI should link to the relevant page, making it easy to check the details ie. `Job 1234 restarted` would be a hyperlink displayed for events of type "job_restart"
* ~~human-readable <del>human-readable names be used in the events which don't require knowledge of the codebase~~ codebase</del>

## Acceptance criteria
* **AC1:** All events have an id
* **AC2:** Events have a clickable link