The background for this question is here: Delete nodes using Rules and VBO

Summary: a VBO View selects various nodes of a particular content type. A Rules Action Set is instructed to load this VBO View, loop through the entity objects, and delete them. A Rule runs/is triggered on cron and has this Action Set for its action. So, when cron runs the selected nodes should be deleted.

However, the nodes are not deleted, because cron runs as the Anonymous User (uid=0), and the content type is configured such that anonymous users are not allowed to delete nodes of this content type.

How can this be solved so that the nodes are deleted on cron?

Giving anonymous users permission to delete nodes of this content type is not a good solution on this site.

Presumably, cron runs as Anonymous User (uid=0) for security reasons. Any acceptable solution should not undermine the site's security.

A programmatic solution (e.g. code in a custom module) is certainly acceptable if a "code-less" solution using Rules is not possible.

  • @Pierre.Vriens There were no errors showing up in the drupal log, which Im was viewing via drush. How would I make such errors display?
    – penname
    Commented Nov 22, 2017 at 13:35
  • I've enabled Rules debugging and retested. No log entries at all related to this issue. Logically, the problem seems to be the cron privileges vs content type permissions. Indeed, it's a relatively simple setup, and actually I have an identical setup successfully deleting user accounts when cron runs (apparently nodes get special care, users not so important...! ;) ). So, for this question, I think only answers that solve the stated problem can be acceptable. Thank you though.
    – penname
    Commented Nov 22, 2017 at 14:01

3 Answers 3


Not sure if you want to consider using it, but the Rules switch user module might be an acceptable compromise. Some details about it (from its project page):

This module adds two new Rules actions:

  • Switch to another user
  • Switch back from another user

These actions could be useful when you have an operation that you want an unprivileged user to use but it fails because the user doesn't have sufficient permissions.

Refer to the image on its project page to get the big picture. So if you'd add these 2 Rules Actions at the start / end of your list of existing Rules Actions, and you'd use some user id that does have the right permission, it should work.

As an alternative you could just reuse the relevant code (it's only 76 lines ...) to create your own custom Rules Actions. Similar to what you wrote in your question (= "**...code in a custom module..."). If you make any useful improvements, please consider contributing your changes back to the module's issue queue.

Be aware, however, that this module only has a DEV version for D7 (= not covered by Drupal’s security advisory policy!). This doesn't mean that the module/code is dangerous to use/reference, but it does mean that the code has not been vetted by the Drupal security team.

  • I upvoted this answer but I don't understand how re-using code from the dev version of a module mitigates the security risks of that module (risk: not being covered by the Drupal security advisory policy). In that case, I think re-using the code is less safe than using the module itself, because the module may eventually get a stable release that falls under the security advisory (in which case Update module would notify you of the update), whereas if you take the code "in-house" in a custom module you would never get the update notification. Commented Dec 5, 2017 at 13:00
  • Hey @PatrickKenny , I see your point about that "reuse the relevant code". How about rephasing it to something like "start from the relevant code (and improve what's needed, possibly even contribute that back via the module's issue queue)"? If you can think of a better phrasing, feel free to edit my answer. BTW, merci for the +1 ... Commented Dec 5, 2017 at 13:40
  • 1
    I split the last paragraph in two, separating the security concern from the remarks about writing a custom module. I think addressing them separately is the most clear way to do it. Commented Dec 5, 2017 at 13:50
  • @PatrickKenny Merci for the refinement! Commented Dec 5, 2017 at 15:01

Here's another way to do this.

  • Create a new role and give it permission to delete the content type you want to delete.
  • Create a user of this type and give it the role.
  • Create a custom rules action that logs in as that user and then deletes the node.
  • Call that action in VBO.
  • Thank you. I've never heard of a "rules action that logs in as that user". How would you create that? However, it does seem that if this is solvable in a "Drupal way" custom PHP code is going to be the solution...
    – penname
    Commented Nov 22, 2017 at 14:09
  • 1
    When you add the code to define a rules action in your custom module, in the callback that is the actual "content" of the action, just add code to log in as whatever user you created to carry out this task. Custom code is probably unavoidable in this case because you don't want anonymous users to have delete permission but Rules scheduler by design acts as an anonymous user. Commented Nov 22, 2017 at 14:14

EDIT: You probably shouldn't use this approach, but I'm leaving it here as an example of what you might think is a good idea but actually isn't.

My memory is a little hazy, but I'm pretty sure I did something similar a few years ago.

  • Give anonymous users permission to delete the node.
  • Use hook_form_alter() to remove the "delete" button from the node form.

This approach is dangerous in that the user can modify the URL to delete the node by adding /delete on the end, but if your users aren't particularly sophisticated hiding the delete button may be enough.

  • 1
    What about bots that cycle through /node/[n]/delete? You should replace slightly with extremely IMO, this is a very dangerous approach and shouldn't really be implemented on a production site
    – Clive
    Commented Nov 22, 2017 at 13:15
  • Yes, thank you to Patrick Kenny for the suggestion, but this is certainly not a feasible solution.
    – penname
    Commented Nov 22, 2017 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.