Jeff-Thompson12
commented
1 year ago I'm starting to look into this idea (which I really like). Here are the challenges I'm facing:
- [ ] We have processes that are delete/insert instead of update (see reweighting). This poses a problem with tracking.
- [ ] SQLite does not use variables, so we will have to have some way to track who is making the changes. This would be straightforward except that some changes are done by the system (such as auto decisions).
- [ ] It is unclear if any database re-structuring needs to take place (e.g. are our primary keys properly defined? Does it even matter for this process?)
- [ ] What are the implications with creating functions to update databases once this is implemented?
- [ ] How are we going to allow the audit tables to be viewed by administrators? Does this affect how we can store the logged information?
- [ ] Does this phase out using the logging file? If not, how do we see these serving different purposes?
It looks like there has been discussion and development around creating an audit trail for user activity in #134.
Has the addition of adding audit logging capabilities to the database been discussed?
This can be achieved pretty quickly by adding some triggers to the existing tables that log info to an audit table about what changes were made during a given transaction (e.g. what table what changed, new & old values, time of change, etc.).
In addition to #244, I think this is something that organizations will look for when assessing the stability of the product.