Improve change history log of a user to include all relevant events

[kainhofer]

Currently, the change history of a user contains all profile field changes (including old values and the account doing the change), but it does not contain

• [ ] changes/deletions/creations of group/role memberships
• [ ] account creations and deletions
• [ ] Password and user name changes

From a formal standpoint, for a properly compliant internal control system (as it is required by law for commercial entities, but the lack of a proper ICS might also lead to personal liability for officers of non-profit associations), it is relevant to keep track of all data changes and in particular, be aware who has admin access (and when!) and the membership types of all members (including when they started and who changed them).

From a practical standpoint, larger organisations typically have some admin staff (interns, secretaries, etc) that keep the data up-to-date, but they need to be supervised by some admin, so the admin should be aware of all relevant changes.

[kainhofer]

PR #1068 provides a (singleton) object of class ChangeNotification that could provide all required functionality to store these changes to the database.

So far, that class only stores profile field changes to the database and sends email-notifications for all other changes. It wouldn't be hard to extend that class to log user/password/role changes to the database, too (the code already includes proper "TODO:" markers for that).

The only issue is that the log table in the database is tailored towards profile fields only, so for user/role changes, new database log tables would need to be introduced or the change log table fundamentally restructured...

[Fasse]

Hmm, for a good implementation we need to redesing the log table and make it more flexible to log all changes of all tables if needed. But this will be a bigger step.

I quick hack for the user table could be a logic that's identical to the list configuration where we add fields that save the name of the column that will be changed. Than we could add usr_login_name, usr_password und usr_photo to it.

[Fasse]

@kainhofer Could you please give a short summary of your implmentation. Which of points are done and which are still open?

[kainhofer]

I have not done any work on this particular feature, so all tasks in the original issue report are still open. I merely pointed to the fact that the ChangeNotification framework could be used for this. The main issue -- as you noted -- is the structure of the database table, which would need to be generalized.

[Fasse]

Ok, than I will remove that feature request for version 4.1 or did you want to implement it within the next weeks?