User history D8 Roadmap

@geek-merlin. The objective of the user_history module is to NOT use revisions. There is no intention that the user account could ever be reverted back to an earlier state using thus module. What it does is simply note in a history table, the date/time of any change to a user account, along with the user responsible for making the change and limited details of what information was changed.

Note that the user_history module will track changes to the core user account fields, along with any other custom fields that have been added and subsequently specified in the user_history configuration settings. I see a need to update this process form time to time as additional field types are introduced into the Drupal environment.

The idea of the history_table is that it is immutable (there are no provisions to edit or delete a history record), and that this record becomes an audit trail of changes to user accounts, so that any changes can by checked and verified. This is important in an enterprise environment where the auditability of the security of a system is dependent on knowing, amongst other things, who had what permission sets at any given time.

If you want the user entity to be fully revisionable in the same manner as other core entities, then you will need the user_revision module when it has a usable release. I note that the core team has determined that having the user accounts revisionable introduces some potentially significant security issues which will need to be carefully considered.

@geek-merlin: I apologise if what I wrote sounds a bit offending to you. I was not meaning to offend or be confrontational. When I evaluated the user_revision module in October last year for use in a project I was working on, the D8 version did not provide the functionality I required for tracking changes to user entities. I see that there has been a dev release in the last few days, so I assume that it has progressed significantly since then.

At the time, I considered putting effort into development of the user_revision module, making use of the recently released API. However, after reading the existing discussion about making this work, and the notes from the core maintainers that they did not want user revisions (refer to issues referenced in comment #11 and comment #12), I decided that the quickest way to meet my requirements was to pick up the abandoned user_history module and write a D8 release.

I am sure that the team behind user_revisions will be able to solve the issues with the API and potential security problems to produce a fully functional user revisions system. It may be then, that it will be a better solution that the user_history module for many uses. I am trying to keep the user_history module quite light-weight as it only needs to track changes to selected fields/properties of the user account entity, so it will satisfy a different need.