Based on the handling of "set to read" in the nodes core module and advanced forum, I programmed an action for it that updates the history table. Then I wanted to use the action in VBO, with the following effect:

* Action works with Batch API
* Action does NOT work for normal users when "invoke them directly" is selected. In that case, nothing is updated because of "insufficient permissions".

Since the latter would look more unobtrusive for the user, it would be my preference, but it just doesn't work. I tried to use "action_permission" but it didn't help either. I don't know if the code could be improved (not unlikely :) or if it's something in the two different ways of handling the action in VBO.

Module code is:


/**
* Implementation of hook_action_info().
*/
function set_to_read_action_info() {
  return array('set_to_read_noderead_action' => array(
      'description' => t('Set to read'),
      'type' => 'node',
      'configurable' => FALSE,
      'behavior' => array('changes_node_property'),
      'hooks' => array(
        'nodeapi' => array('presave'),
        'comment' => array('insert', 'update'),  )    
      )
  );
}

/**
* Implementation of the actual function set_to_read_noderead_action()
*/

function set_to_read_noderead_action(&$node) {
 global $user;

 if ($user->uid) {
   
   $sql = 'delete from {history} ' .
      "where nid='" . $node->nid . "' ".    
      "and uid='" . $user->uid . "'";

     db_query($sql);

   $sql = 'insert into {history} (nid,uid,timestamp) ' .
      "values ('" . $node->nid . "', '" . $user->uid . "', unix_timestamp()) ";

     db_query($sql);
     
  }     
}

Comments

infojunkie’s picture

Your action declares the behavior "changes_node_property" even though it doesn't really change any node properties. The presence of this flag forces VBO to check the write permission of every selected node against the current user. It might be that the non-admin user doesn't have the permission to update these nodes. But since your logic doesn't need to update the node anyway (since it only updates the history table manually), then it is probably safe to remove the behavior declaration altogether.

itsnotme’s picture

Perfect, thank you!

I had been unsure if I should keep any of those lines - I deleted the line now and all works. Great :)

infojunkie’s picture

Status: Active » Closed (fixed)
mstef’s picture

@itsnotme: nice work - I was looking for this.