Do not allow the user to delete the node, but allow the deletion using bulk representation operations

Question

I have the following script:

• The editor role should not be allowed to remove nodes. Therefore, the corresponding permission is canceled in the permissions page.
• However, the editor must be able to remove nodes from the Bulk Operations views. Using the Create Action Rule, a "safe delete" is called, which checks if the node is not published, etc. before removing node.

The problem is that Masked View operations correspond to node permissions. The editor will not be able to remove the node because it has not been granted this permission. Is there a way that the Editor can become a higher-ranking user (like sudo) by doing this in VBO? Alternatively, is there a way to tell VBO to ignore access to this node action?

I am sure this is a basic requirement, but I cannot find a solution.

Solutions that are not related to programming would be preferable.

Answer 1

A simple but not very clean way is a route that you have already done, but with an additional small module to help it.

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

However, you can make it more robust to catch other removal modules:

• implements hook_nodeapi() , $op == 'delete' to catch actions and stop the deletion (by calling drupal_goto() or calling drupal_access_denied() to force a user error. Refer only to deletion actions if the referent was a deletion - form, like indicated above, or a safer, white list of your VBO actions and return false for all other referees.The referent can often be found by reading the $ node passed by hook_nodeapi() .

A, IMHO, a much cleaner, but probably more intense alternative , would just make sure your parties / actions are called up with every delete action.

In the module, you can do this by avoiding all VBO settings and leaving all unnecessary remote actions. Then write a module that implements hook_nodeapi() , and then calls all the cleanup actions from there. That way, you can be sure that your delete actions are invoked with every delete action on any node. Obviously, you can add some conditions to your hook_nodeapi () to call only your modules in certain cases (node ​​types, user roles, permissions, etc.).

Answer 2

Well, it seems to me that you have a setting in which you do not want users of the Editor’s role to delete things, indeed, with the exception of some extreme situations. Here is my suggestion:

1) Install the Flag module. Create a "To Be Deleted" flag that can only be assigned to people with the Editor role.

2) I did not view it, but I am sure that there is probably a rule or trigger / action that will cancel the publication of the node when it is assigned the “To Be Deleted” flag. node from random view.

3) Then either configure some cron launch activity (trigger / action or rule) to delete nodes with the “To Be Deleted” flag set on them, or sometimes another user with higher permissions appears and deletes the marked elements.

Thus, you do not actually bypass the permission system, but still you are removed from your site.

Answer 3

I lingered for a while until I noticed the actions_permissions module, turning it on and on the Permissions page you can provide access to specific actions based on the role by role.

Answer 4

I don’t have a good solution without coding, and I'm not sure that I would call this solution “excellent”, but one way could be a simple module with a form_alter hook, which removes the delete button from the node to edit forms as they are created.

In general, it seems that the role either has permission to delete nodes or not, and a monkey around like this will be less reliable than you might like.