Users with view "View moderation history" but no edit access cannot view moderation history

Sub.......

This also breaks viewing drafts.

Regarding the current patch, Is unpublish the only op that should check for node update access?

I'd say we should make a decent effort to see what the possible operations are and rework this function to be correct for all of them.

As it is it doesn't make much sense at all and fixing one-off cases just dusts the rest under the rug.

Not sure if this is right (haven't tested), but illustrates the direction I want this to go in.

This issue is limiting us on a system soon to go to prod.

Specifically we are trying to create a publisher role cannot edit a node, but can move it through transition states.

Due to the issue in this thread, the publisher role does not have the "view moderation history" link unless we give them permission to edit nodes.

Q: When will a patch be released for this?

Thanks for your assistance.

I run into the same issue. I have a simple workflow where anonymous user should be able to see the revision history + each past revision. I was unable to set it because I was not willing to grant them an editing access on the concerned node type.

=> I can confirm your patch (#5) is solving the issue without forgetting any operation where the code shouldn't grant the access ('update', 'unpublish'). It should be ported asap in my opinion since this seems to affect a quite common usage case...
++

#5 works fine for me. Thanks.

+++ b/workbench_moderation.moduleundefined
@@ -450,15 +450,20 @@ function workbench_moderation_node_access($node, $op, $account) {
-function _workbench_moderation_access($op, $node) {
-  global $user;
+function _workbench_moderation_access($op, $node, $account = NULL) {
+  if (empty($account)) {
+    $account = $GLOBALS['user'];
+  }

Looks not good. That's why we have $user, isn't it?

You mean like this?

global $user;
if (empty($account)) {
  $account = $user;
}

Doesn't make any difference to me.

I came accross the same problem and fixed it via a custom module implementing the hook_workbench_moderation_access_alter

function my_module_workbench_moderation_access_alter(&$access, $op, $node) {
  if($op == 'view history') {
    $access = user_access('view moderation history');
  }
}

#12: yes, that's what I mean.

Addressed Hass' remarks from #11 and did some further cleanup.

Unlike other links on the moderation history tab, the "Edit draft" courtesy link doesn't check permissions. Starting at line 165 of workbench_moderation.node.inc:

    // Provide a courtesy edit operation if this is the current revision.
    if ($revision->vid == $node->workbench_moderation['current']->vid) {
      // The edit operation's default link title, "Edit draft", matches
      // the logic tree in workbench_moderation_edit_tab_title().
      $edit_operation_title = t('Edit draft');

      // Modify the edit operation's link title to "New draft", matching the
      // logic tree in workbench_moderation_edit_tab_title() when the current
      // revision is the published node.
      if (isset($node->workbench_moderation['published']) && $revision->vid == $node->workbench_moderation['published']->vid) {
        $edit_operation_title = t('New draft');
      }
      $revision_operations['edit'] = l($edit_operation_title, "node/{$revision->nid}/edit", array('query' => array('destination' => "node/{$revision->nid}/moderation")));
    }

With this patch in place, someone who can view moderation history but not edit will see an "Edit draft" or "New draft" link that leads them to a page with an access denied error. Instead, the courtesy link should check permissions, because it can no longer depend on the fact that this tab isn't visible to someone who can't edit.

The updated patch adds an access check to the edit courtesy link that prevents showing it if the user can't edit the node.

Previous patch failed because the order of arguments was wrong for _workbench_moderation_access - it's the opposite of the order from _workbench_moderation_revision_access.

thanks! it worked.
Fix this issue then "moderator" can do his job with limit permission. I think it is the MOST important feature for this module.

function _workbench_moderation_moderate_access() had this:

$access = node_access('update', $node, $user)  // the user can edit the node
&& $my_revision->is_current // this is the current revision (no branching the revision history)
&& (!empty($next_states)) // there are next states the user may transition to
&& isset($next_states[$state]);  // this state is in the available next states

I think we should allow "moderator" role moderate content without edit node permission, he only need view node and moderate state permission.

about #20, function _workbench_moderation_access(), There is no return value?

+  if ($op == 'view revisions' || $op == 'view history') {
+    // The user must be able to see revisions.
+    _node_revision_access($node, 'view', $account);
+  }

Reading over the patch, I think that @dzy made a good catch in #22 that nothing is being done with the return value of _node_revision_access(). That should either be integrated into $access, or perhaps that whole section should be removed? That bit of code (which up until now has done nothing) has been part of the patch since #5.

First, here's a patch that integrates that into $access - I want to see if any of the automated tests fail.

Tests failed on #23, although, it's not super clear to me that it's from the change I made. I've queued a re-test of #20 just to make sure that patch is still passing (and it's not broken too due to some changes in the 7.x-3.x branch, or changes to Drupal or dependencies or the testbot)

It looks like that was a legitimate failure. Here's an updated patch that attempts to fix.

Basically, my thinking is that previously you needed the ability to update the node for everything. The issue here is to change it so that for 'view revisions' and 'view history' you don't, only the permission to view node revisions. However, my update on the patch is to make is that the users who have update permission still get access, in addition to those with just the ability to view revisions.