Am 19.06.2012 um 14:36 schrieb John Mazzitelli:
This is something Jay talked about (and others) a while ago. What we
should have done in the beginning was create a generic "Audit Trail" subsystem -
and have all the other subsystems log messages there. That way, we don't have N
different, isolated "history" trails and N different ways to purge and query
them. Unfortunately, we didn't do that - so we have things like (what you see) the
operation history audit, we also have rsource config history, plugin config history, etc.
Yep. And what "bothers" me most here, is that it is no "real" audit in
sort of a "write-only" mode.
It would be alot of work (though probably doable - maybe not easy to
upgrade from old schema to new however) - we could rip out all these isolated history
tables and design and build an "Audit" subsystem that all other subsystems can
share.
What we could do is to have a central audit subsystem with a relatively simple table
id,timestamp,user,subsystem,<code>,<message>
where the code is some subsystem specific code (e.g. 'alert' or
'alertdefiniton') to denote the internal part of the subsystem.
We would add a simple "Audit.submit()" method, that internally adds data to the
audit table, and which can be accessed a little bit
like a Logger call.
So when above "deleteOperationHistory" runs, it could call
Audit.submit("operations","delete history","Item with id xyz and
status bla");
So even if the operation history item itself is deleted, a trail of its existence is still
there.
Similar for changes in alert conditions.
Audit.submit("alert","condition","Changed conditions from abc to
xyz");
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera