Cancel User Account: Delete account and make content belong to "Anonymous" issue

I can confirm that we've recently been hit by this issue under exactly the same circumstances. On a VBO view that lists users we select one account, and then use the Delete button. We are asked how to handle the user's content and we select "Delete account and make content belong to "Anonymous".

At the end of the batch operation we receive the error and all of the user content has been deleted.

I can also confirm this issue. The circumstances are the same but on the progress page I get a ajax HTTP error - so I wondered if ajax had anything to do with it. I turned off ajax in the people view but still got the same error. I can delete the user from the user edit page with no problems - it just happens when using VBO operations from the people page.

I am having the same issue with one of my project, all content deleted from the site while deleting few users.
I choose the option "Delete the account and make its content belong to the Anonymous user. " but still it deleted the contents, i am using VBO version "7.x-3.3".

Updating the priority as people are losing content.

Hi,
Sorry for my late Post,This can be solved by fixing the VBO but we can also create actions for the same.
Just create new actions for the same in Views in your module with hook_action_info, and complete the functionality.

Ran into the same issue, canceled all my accounts (needed to do a fresh account sync from AD), and I selected to cancel and make all content available to anonymous user.

It seems for all the accounts that were not owned by my logged in user-id they were removed completely, instead of being owned by anonymous.

It did seem that about 10 nodes got owned by anonymous, but I had *a lot more* nodes that disappears.

Luckily I had a snapshot I reverted back to.

I am having the same issue. I choose "Delete the account and make its content belong to the Anonymous user" with admin views and I got an error 500. My log says:

[error] [client 127.0.0.1] PHP Fatal error: __clone method called on non-object in /modules/node/node.admin.inc on line 323, referer: /batch?op=start&id=4740

All content from that user is now deleted and I had to restore a backup. Any ideas?

Same symptoms as Jorge Navarro.
This deletes all content that is supposed to be assigned to anonymous user.
Hence changing priority to critical.

Same here, I lost content and luckily I made a backup just before cancelling accounts.

The issue here appears on VBO 3.2 and 3.3 In particular this happens when Drupal is using a second batch helper process to deal with updating the deleted nodes. However, the real issue is that VBO action to cancel the user is simply a copy and paste of code later executed. Which is not necessary and causing pain.

@csevb10 - Did all the heavy lifting. Achieve Internet is happy to help.

This issue impacts both 7.x-3.2 and 7.x-3.3

We have had this issue on a number of sites when users attempted to cancel accounts and reassign content belonging to the cancelled users to anonymous. The content is deleted rather than reassigned and an error

Fatal error: __clone method called on non-object in /.../node.admin.inc on line 323

was displayed.

We have confirmed this only occurred when there are more than 10 nodes belonging to a user being cancelled and function node_mass_update() tries to update those nodes in a batch job. The operation completed successfully when there are less than or equal to 10 nodes belong to a user being cancelled.

We tried the patch in #11 but unfortunately it did not fix the issue and nodes were still deleted (Drupal 7.44 and VBO 7.x-3.3).

@Jason Guo i also reproduced it, when i tried to delete user and reasign it to anonymous user (user_cancel_reassign), it deleted everything :|

In the code the function called is node_mass_update, with a batch operation (because there's more than 10 nodes to update)

#15 - I also reproduced it. I did the same thing (user_cancel_reassign + and there was more than 10 nodes to update, so it launch the batch in node.admin.inc, function node_mass_update) and it deleted every nodes from this user.

Drupal 7.52 and VBO 7.x-3.3

Does the patch in #11 solve the problem? If so please mark this issue as RTBC (Reviewed and tested by the community)

I'm afraid that patch does not solve the problem, at least as I understand it (I have applied and tested the patch on a site suffering from the issue without success).

After quite a bit of debugging I think the issue lies within views_bulk_operations_user_cancel_action() and the order of processing. module_invoke_all('user_cancel') invokes node_user_cancel which adds a series of batch api queue items for reassigning nodes to UID 0. These get added (but not executed yet), and then within views_bulk_operations_user_cancel_action() user_delete() is called. This is the cause of the problem. The tasks to reassign nodes to UID 0 will happen during the next batch api run, but the user_delete() runs within the first batch request. user_delete ultimately results in all nodes belonging to that user being deleted. Then, when batch api begins a new request and picks one of the _node_mass_update_batch_process() tasks from the queue the nodes no longer exist to reassign, which causes the issue we're experiencing.

This bug hit quite a large site for a client of my company's (and during the christmas break, no less!), and I've spent quite a bit of time this week diagnosing the cause and fundamental issue. My solution to this issue is to add the user_delete invocation as a batch api queue item too, and make sure it gets picked out of the queue at the correct point (*after* the batch task for reassigning the nodes for the particular user has run). I'm attaching the patch, I've tested it pretty thoroughly and it's working well, keen to get feedback and testing from the community :)

One thing of note is that because of the way the batch api orders sets, we end up in a situation where the queue items are in the correct order, but the sets within $batch['sets'] have placed user_delete sets in the wrong order (before the mass node updates). Basically the order of sets gets messed up each time views_bulk_operations_user_cancel_action() is called, however the important bit, the queue items, remain in the correct order. What this does mean is that sometimes the wrong set will be active for the right queue item. Because _node_mass_update_batch_process requires the inclusion of node.admin.inc I've added this to the user_delete batch set to prevent any circumstances where a _node_mass_update_batch_process() item may be active while the wrong current_set is in place. I spent a long time trying to determine a nicer method than this, but was ultimately not able to. From what I can tell it has no other side-effect so I've gone with it. If anyone has a better idea of how to address this I'd be keen to implement it.

7.53 with VBO 7.x-3.3

Use the bulk operations dropdown in the People view to "Cancel user account" - on a user that has 97 nodes.

Process is interrupted with:
Fatal error: __clone method called on non-object in /modules/node/node.admin.inc on line 323

All 97 nodes are now deleted.

Apply patch in #19 and repeat the same process - no errors - content is reassigned and user is then deleted.

@sambonner I need a bit more information from you why the patch in #11 didn't work. From testing it, it seemed to do what was intended and I agree this issue is critical so I plan on committing it as soon as I can clear up why the patch in #11 is not working for you.

#19 does work too but it makes the cancel user action a bit more complicated so I need to understand the difference before committing.

I know why it was done the way it was in the first place from the original issue the performance of the cache clears https://www.drupal.org/node/1799484#comment-8248467

Still curious about why #11 didn't work but I'll commit this anyway.