How to permit users to view unpublished nodes which they didn't create? 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?
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:


How to implement a multi step approval with webforms/entityforms based on form components?
How can I allow anonymous visitors to submit content?


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):


Rules.
Node Convert.
Flag.
Content Access (already suggested in the previous answer also).


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 ...