action #49202

Updated by cdywan over 2 years 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 The problem common to all of these events:
* the
events is that they either use IDs from database tables which require knowledge of the code internals to construct a URL look up, or SQL query
* some
values which on their own are not sufficient to make use of, sufficient, such as the number of rows affected affected.

To fix this I'm proposing:

* Events carry the minimum info needed
I'd like 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"
* <del>human-readable
propose that human-readable names be used in the events which don't based on the use case of investigating problems from a tester's perspective and making the data unambiguous ie. specify what an ID is so that it doesn't require knowledge of the codebase</del> codebase.

jobtemplate_create { "test_suite": { id: 1234, name: "NAME" } }