Do not allow a user to delete a node but allow to delete through Views Bulk Operations

Question

I have the following scenario:

• Editor Role should not be allowed to delete nodes. Therefore the corresponding permission is de-selected in the permissions page.
• However Editor should be able to to delete nodes from Views Bulk operations. Using Rules an action is created called "safe delete" that checks things like if the node is not published etc. before deleting the node.

The problem is the Views Bulk Operations respects Node permissions. Editor will not be able to delete the node as he has not been given that permission. Is there a way that Editor can become a higher role user (as sort of sudo) while performing that action in VBO? Alternatively is there a way to tell VBO to ignore node access for this action?

I'm sure this is a mainstream requirement but I can't seem to find a solution.

Solutions which do not involve programming will be preferred.

Answer 1

The simple, but not-so-clean way, is the route you already took, but with an additional, small module to help it.

• has a function my_module_can_delete($user), that returns TRUE if the user is allowed to delete, FALSE if the user is not.
• implements hook_form_alter() to modify and delete the button on the node_edit form, if my_module_can_delete($user)
• implements hook_form_alter() to modify the confirm form that is called on /node/%nid/delete, and add a message there, telling the user he or she my_module_can_delete($user). This should be enough, since disabling this form will result in users not being able to get past this form. FORM-API will take care of that.

However, you can make it more sturdy, to catch other deleting modules:

• implements hook_nodeapi(), $op == 'delete' to catch delete actions and halt (by invoking drupal_goto(), or calling drupal_access_denied() to enforce a user-error. Only catch delete-actions if the referer was the delete-confirm-form as mentioned above. Or, more secure, whitelist your VBO-action and return false on all other referers. A referer can often be found by reading out the $node passed along to hook_nodeapi().

A, IMHO, much cleaner, but probably more intensive alternative, would be to simply make sure your batches/actions are called on every delete action.

In a module, you could do this by avoiding all the VBO-configuration and leaving all the extra-delete actions out of there. Then write a module that implements hook_nodeapi() and then calls all the cleaning actions from there. That way you can be sure that your delete-actions are called on every delete-action on any node. Obviously you can add some conditions into your hook_nodeapi() to only invoke your modules in certain cases (node-types, user-roles, permissions and so on).

Answer 2

Well, it seems to me that you've got a setup where you don't want Editor Role users to delete things, really, except in certain extreme situations. Here's my suggestion:

1) Install Flag module. Create a 'To Be Deleted' flag that can only be assigned by Editor Role people.

2) I haven't looked into it, but I"m sure there's probably a rule or trigger/action combo which will unpublish the node when the 'To Be Deleted' flag is assigned to it. This will remove the node from casual view.

3) Then either set up some cron run activity (trigger/action or rule) to delete nodes with 'To Be Deleted' flag set on them, or have another user with higher permissions come in occasionally and delete out the flagged items.

This way you're not actually bypassing the permissions system, and yet things are still being removed from your site.

Answer 3

I got caught out of this for a while until I noticed the "actions_permissions" module, enable this and on the Permissions page you can provide access to specific actions on a role by role basis.

Answer 4

I don't have a good no-coding solution, and I'm not sure I would call this solution "great" - but one way might be to implement a simple module with a form_alter hook that removes the delete button from the node edit forms as they are built.

In general it seems like the role either has permission to delete nodes or not, and monkeying around like this is going to be less robust that you might like.