Orphan Processor with "Delete the account and make its content belong to the Anonymous user." may delete content

Created on 22 April 2022, over 2 years ago
Updated 8 January 2025, 7 days ago

Problem/Motivation

If the "Periodic orphaned accounts update mechanism" under user settings is set to "Delete the account and make its content belong to the Anonymous user." it may delete content too.
The process triggers the normal user_cancel()-process. Usually the process is triggered via the user interface by an authorized user. But in the orphan processor it is triggered by a cron job, which runs as an anonymous user. This difference becomes relevant during the reassignment of the content. If the to-be-deleted-account has not more than 10 nodes, the reassignment happens immediately without problems. If the to-be-deleted-account has more than 10 nodes, the reassignment happens within a batch process, which fails. (See node_mass_update() for the switch). After the reassignment of the nodes the account gets deleted and all nodes beloning to the account too. In the first case (nodes <= 10) this isn't a problem, since all nodes are reassigned. In the later case (nodes > 10) it is, because the reassignment failed and nodes get deleted.

Steps to reproduce

The setup should be quite common. I tested against a standard Drupal 9.3.11 and LDAP-Module 4.3.0. All submodules, except LDAP Authorization Provider, are active. Obviously, the orphan processor is on and, set to "Delete the account and make its content belong to the Anonymous user.". After the configuration is set up correctly:

  1. Make sure an LDAP account is created.
  2. Create more than 10 nodes with an LDAP account as owner (uid).
  3. Make that LDAP account a candidate for the orphan processor.
  4. Run cron.
  5. Check if the nodes survived and belong to Anonymous.

Proposed resolution

The problem comes with a batch process inside a cron job, which seems to be problematic and not recommended: https://drupal.stackexchange.com/a/225279
Therefore the orphaned accounts update mechanisms can't rely on user_cancel(), at least not those mechanisms that trigger node_mass_update().
Maybe it's possible to reassign x nodes of an account in each cron run and only use user_cancel() once there are only 10 or less nodes beloning to that account. This might take a while though if an account has a lot of content or if there are a lot of users.

🐛 Bug report
Status

Active

Version

4.3

Component

Code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Offload user cancelation to a queue. In this queue the nodes will be updated one after another until no more need updating. Only if no more nodes are present the user will be deleted, thus preventing nodes from being deleted unintentionally.

Production build 0.71.5 2024