The code in the install file currently is not robust and can lead to data loss when the module is enabled from the UI.
Workaround: Use drush to enable the module.

We now have a core API that we can leverage:
New Entity Update API for converting the schema of a content entity type, with or without pre-existing data | Drupal.org#1869582

See https://api.drupal.org/api/drupal/core%21modules%21taxonomy%21taxonomy.p...

Comments

axel.rutz created an issue. See original summary.

znak’s picture

Assigned: Unassigned » znak
znak’s picture

Assigned: znak » Unassigned
geek-merlin’s picture

Priority: Normal » Critical
geek-merlin’s picture

Also installing via web can result in data loss so bonus points for adding a batch. Example see here.

thomasmurphy’s picture

If anyone can come up with a hours estimate to get this module working again (via this issue, at least according to the discussion at https://www.drupal.org/project/user_revision/issues/3057189) then I can look into funding the work. Also, does it seem to other people like this module is actually abandoned based on the level of developer activity on the issue queue?

geek-merlin’s picture

Just seen by chance that some code that leverages batch api for the update is in #2794019: Installation issues and support for role IDs.

geek-merlin’s picture

#6: As co-maintainer, i can say i have no bandwidth, paid or not. You might want to PM @attiks.

I have no permission to flag this module as "seeking co-maintainers", but i'd support an issue to do this.

thomasmurphy’s picture

#8: thanks for the context. We've decided to pursue a different "audit log" approach, because our use case is needing visibility over who changed what when, rather than need to revert specifically. Also I've heard that core has decided to not go down the route of revisionable users because of security vulnerabilities, so this module's approach seems to be moving towards unsupportable, which is a pity because I've found it very useful on D7.

geek-merlin’s picture

I wouldn't say that user revisions are dead (or do you have a reference for that claim?) but do not see much traction here either. Crosslinking core issue.

jayelless’s picture

Refer to the discussion on #2745619: [policy, no patch] Which core entities get revisions? for statements by core maintainers that user entity revisions will not be included in core. Refer also to the following issues for additional background:

In light of this, I have updated the user_history module to provide the functionality for a change audit or log of updates to user entities that is necessary to allow Drupal system to satisfy criteria for use in enterprise systems. This module had a D6 version, but was never updated for a D7 release.

geek-merlin’s picture

Issue summary: View changes

Yes, as i read that discussion, user does not have revisions for now, and the followup issue was "closed/outdated" with no discusstion. So if someone works that issue, it may imho land.

That said, thanks for rolling and linking the other module! 👍

geek-merlin’s picture

Wow, we can do even better by leveraging a core service: Content entity types with existing data can now be converted to be revisionable

geek-merlin’s picture

Title: Leverage EntityUpdate API » Leverage EntityUpdate API (without this installing via web can lead to timeout and data loss)

Clarifying title. I guess the risk enabling the module via drush is low, but any install via UI can lead to data loss on timeout for not-very-small user counts.

geek-merlin’s picture

Priority: Critical » Major
Issue summary: View changes

Clarified to use drush in the IS.

geek-merlin’s picture

Issue summary: View changes
geek-merlin’s picture

Status: Active » Closed (outdated)
Related issues: +#3197068: Modernize conversion process on install

Here's the party now.