6

I have created two roles: Editor and Reviewer.

Editor must only create unpublished nodes; instead, Reviewer must publish and view these nodes.

How can I make users with a role see unpublished nodes? If I set the permission "Access the content overview page", the users with that role can modify all contents and I don't want this.

I tried the View unpublished module, but it has an issue, as reported in View unpublished breaks access rules defined by Views.

How to permit users to view unpublished nodes which they didn't create?

4
  • If somebody does not have role Editor and also not Reviewer, should it then yes or no be possible to "view" these nodes? Commented Feb 18, 2016 at 13:09
  • Role Editor must view only own unpublished node, instead Reviewer can view own unpublished node and any unpublished nodes of the users belonging to Editor role. If somebody does not have role Editor and also not Reviewer must view only published node.
    – kb8
    Commented Feb 18, 2016 at 13:53
  • Wow, that seems like another (new?) requirement that you added to your question now. Be careful about that, that's not something you're allowed to do in the same question, instead that might be like a followup (new) question (I'll try to enhance my answer later on, after you found a solution for the original question). But: you did not answer to my prior comment ... i.e. what "if somebody does not have role Editor and also not have role Reviewer"? Commented Feb 18, 2016 at 14:03
  • No, if somebody does not have role Editor and also not Reviewe must view only published nodes. In other words I want to do what makes the module "view_unpublished" .
    – kb8
    Commented Feb 18, 2016 at 14:11

4 Answers 4

3

Solution 1

I would "set the permissions 'Access the content overview page' ...", and combine that with using the Rules module to prevent "the Reviewer can modify all contents". Read on for more details about how to do so.

Create a rule (using the Rules module), that is a variation of the rule I included (in export format) in my answer to the question about "How to restrict access to a node via node/12 and allow access via a path like content/sometitle?".

These are the changes to that rule to make it work for this case also:

  • Append /edit at the end anywhere there is already something like node/% (I assume when somebody tries to edit a node, they use a node with /edit at the end, though any variation of that should work in a similar way).
  • Add a Rules 'Condition' to verify that the current user trying to do such edit does NOT have role "Editor".
  • You probably also need to add another Rules condition like "content is of type" (i.e. 'article' in your case, something that is not mentioned in your original question, but in an extra comment). That way the rules action does NOT apply for ay other content type.
  • Change the "Message" (in the Rules 'Action') to something that fits your needs.
  • Modify the Rules 'Action' to fit your own requirements, e.g. to issue a redirect to some other page.

Note that the Rules Event is "Drupal Is Initializing" ... Otherwise you are, for sure, "too late": you don't want the rule to be triggered after the edit session has been started already, instead it should be triggered before that. I.e when Drupal is getting ready to start an edit session.

Haven't experimented/tried creating this rule (= variation of the rule in the answer I mentioned above). But pretty sure it'll work.

You may also want to look at my answer to "https://drupal.stackexchange.com/questions/182958/how-to-limit-appearance-settings-based-on-roles-permissions/182959#182959" for another example of a rule, which uses some techniques similar to what you'd need here.

Solution 2

Solution 1 should work, but its weakness is that it's based on "Bypass Content Access Control". Personally I do not like that either. So I agree with your comment about that (a comment which has been removed via moderation). But hey, it's "a" solution to answer "your" (original) question.

If it was up to me to implement a "real" solution for the challenge you're trying to solve, I'd go for a plan b, as further detailed below.

Have a look at my answers to either of these questions:

These answers explain how you can implement a workflow that is pretty (though not exactly) similar to what you are looking for.

To do so, it "only" requires you to use these modules (and regular content types):

And by using such approach, it does not require modules like "Webform" or "Workbench" (modules that are typically involved for these kinds of workfows).

If you're not familiar with Rules, checkout the video tutorials Learn the Rules framework. And/or the similar set of 8 video tutorials about the Flag module.

Note: This "Solution 2" is also how I implemented a variation of your question on 1 of our own sites: it starts from an Issue (= problem or feature request), evolves to a Recipe (= instructions about how to get something to work) and ends with a Software solution (= a plugin or so, whereas the Recipe becomes part of the documentation). Node Convert and Content Access do most of the work for this, and even works in D6 ...

3
  • Comments have been removed. Please don't use them for extended discussion, or other topics not related to the question.
    – avpaderno
    Commented Feb 19, 2016 at 14:24
  • 1
    Sorry ... But is it true that "comments cannot really be removed", and that they can only be "marked hidden for anybody except for moderators"? Also, is there a way to somehow restore those (crucial) comments that I referred to in the 1st paragraph within "Solution 2"? If not, how to adapt that paragraph so that it still makes sense if anybody ever wonders where that "Solution 2" came from (which clearly deviates from the original question, but some of the deleted comments from OPer do explain that) ... Commented Feb 19, 2016 at 14:37
  • I just found this module drupal.org/project/view_unpublished
    – James
    Commented May 2, 2017 at 14:04
2

Content Access

This module allows you to manage permissions for content types by role and author. It allows you to specifiy custom view, edit and delete permissions for each content type. Optionally you can enable per content access settings, so you can customize the access for each content node.

enter image description here

17
  • But If I grant the Editor to administer nodes, it can edit all content! Or I do not understand how work this module. I want that the Editor can view the unpublished node of other user by content type.
    – kb8
    Commented Feb 18, 2016 at 0:36
  • @kb8 you can do the screenshot settings for each content type. So for content type B, don't allow editor to edit any content.
    – No Sssweat
    Commented Feb 18, 2016 at 0:40
  • link and link @No Sssweat thank you
    – kb8
    Commented Feb 18, 2016 at 0:51
  • I not understand if this module allows the Editor role to view all unpublished node (own and not) only for a specific content type.
    – kb8
    Commented Feb 18, 2016 at 1:13
  • 1
    @kb8, After further investiation/testing Content Access does not have a view unpublished content permission. As per this article Viewing unpublished content, The only way to allow users access to all unpublished content in Drupal 7 (without using a contributed module), is to enable the permission 'Bypass content access control'. which is no good for you, since they will be able to edit everything, even if content access module is enabled. So it looks like you need to use the view_unpublished module.
    – No Sssweat
    Commented Feb 18, 2016 at 1:27
1

You can use unpublished_node_permissions which creates granular permissions for each role which can be edited by an admin under admin/people/permissions to view unpublished nodes per content type.

It also takes care views permissions so for example admin/content view will filter nodes correctly as per the user's role permissions.

NOTE: there is a known bug with D8 multilingual sites and views that might create undersireable results.

0

You can use https://www.drupal.org/project/access_unpublished. You do not need to worry about the role or even creating user. This module generate a hash key as query parameter along with node URL. You can also set lifetime of the hash key before it expires. You just need to pass this to the person whom you want to give access to. This is very useful in case of proofreaders.

Hope this is helpful for others too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.