One of my current clients is an institute where only the web team may publish content. All other teams may create and edit certain node types which then go into moderation and are subsequently published by web team. Special case is human resources (HR) team because they create content which may become obsolete any time (i.e. job offers). So HR team shall be able to unpublish current revision, but only node type 'job_offer'.

In addition to module_grant and revisioning I installed publishcontent module which splits the administer nodes permission into un/publish (own) NODETYPE permissions.

However, it's not working well with revisioning/module_grant, user with permission to 'unpublish current revision' are still able to unpublish revisions of all node types even though they do not have this permission as of pbulishcontent module.

I tried to create a patch to have revisioning/module_grant check for existance of publishcontent and retrieve its permission information, but I couldn't get it to work.

In revisioning.module there's a function _revision_tasks_menu_access_callback() [l. 336] where tabs of local tasks are defined. At this point I can suppress display of 'Unpublish' tab by adding following snippet after line 396 (just before the break; of case 'unpublish current revision'):

      if ( module_exists('publishcontent') && !_publishcontent_unpublish_access($node) ) {
        return FALSE;
      }

NOTE: This is of course breaking the underscore-function rule (is there a better or offiocial name?) as these functions shouldn't be called from outside the respective module but there's no alternative yet in publishcontent module (as far as I've seen).

Nonetheless, it works for the tab. But it doesn't work for the submenu_link which is created in revisioning_theme.inc, l. 227. There the function generate_node_links_according_to_permissions() of revisioning.module (around l. 826) is called which further down accesses module_grants_node_revision_access('unpublish current revision', $node) of module_grant module where I tried the same snippet as above. But this time the user not only doesn't see the 'unpublish current revision' link but is denied access altogether.

If it has been considered so far to add like functionality, maybe you could give me a hint as what I am missing. I'd like to develop the solution myself but I got stuck now. Either the HR team members may unpublish all node types or they don't have access to the revisioning pages at all.

Thanks for patience and advice in advance,
sin

Comments

rdeboer’s picture

rdeboer
Location Melbourne
commented

Your hack sounds right. Can you show us the exact code you applied to generate_node_links_according_to_permissions()?

rdeboer’s picture

rdeboer
Location Melbourne
commented

Your approach sounds like it should work. Please show us the exact code you placed in generate_node_links_according_to_permissions() and we'll have a look.

broon’s picture

broon
Location Potsdam
commented

Hi Rik,

I did _not_ alter generate_node_links_according_to_permissions(). Rather, within this the function module_grants_node_revision_access('unpublish current revision', $node) (provided by module_grants) is called and that function has been altered by me. In module_grants.module (from l. 178, dev version of November 10th) I changed the default block of the switch statement from

    default:
      // Not so elegant: checking for permissions that apply to Revisioning
      // Note that 'revert revisions' is a core permission, not related to
      // revision moderation and therefore not part of this check.
      if (!user_access('administer nodes') && in_array($revision_permission, array('publish revisions', 'unpublish current revision'))
        && !is_moderated($node->type)) {
        return FALSE;
      }
      $op = 'view';
      break;

to 

    default:
      // Not so elegant: checking for permissions that apply to Revisioning
      // Note that 'revert revisions' is a core permission, not related to
      // revision moderation and therefore not part of this check.
      if (!user_access('administer nodes') && in_array($revision_permission, array('publish revisions', 'unpublish current revision'))
        && !is_moderated($node->type)) {
        return FALSE;
      }
      if ( module_exists('publishcontent') && !_publishcontent_unpublish_access($node) ) {
        return FALSE;
      }
      $op = 'view';
      break;

but as I said, now the user who may not unpublish a certain content type got an 'access denied' message. I applied this patch to a former version (of October 14th) where the function is located around line 387 and it worked.
Now I tried it with the latest dev version again (as of yesterday, function starts at line 182) and now it's working again. So I guess this works now and except for the subtle glitch of using an underscore function this is it.

Best,
sin

rdeboer’s picture

rdeboer
Location Melbourne
commented
Status: Active » Closed (fixed)

Great! Let's close this issue
Rik

broon’s picture

broon
Location Potsdam
commented
Status: Closed (fixed) » Needs work

Unfortunately, this does breaks a few pages.
This hack prohibits users to view the revision list (node/%node/revisions/list) if they don't have the right to unpublish the appropiate content type.

I will look into it further but probably is getting harder to solve. Why is all the revisioning stuff handled y the default switch value? Isn't there a way to redirect that to some permission function in revisioning module?

I'm thinking of something like this (untested, just for layout):

    default:
      // More elegant: checking for permissions that apply to Revisioning
      if ( module_exists('revisioning') ) {
        if ( !revisioning_node_revision_access($revision_permission, $node) ) {
          return FALSE;
        }
      }
      $op = 'view';
      break;
rdeboer’s picture

rdeboer
Location Melbourne
commented
Status: Needs work » Closed (fixed)

Access control in Module Grants and Revisioning has been cleaned up recently and I believe the Publish content module has also undergone some changes, see [#606516.]
This may make your implementation more straightforward.

If there's still an issue, please repost it after trying with the latest and greatest versions of all modules involved.