When the author creates a content, the editor needs to review it for which there is "view all unpublished content" permission. It doesn't seem to work. I dont know if it is Interfering with another module or what. i am able to move the content from one state to another but however the roles which were given permission to "view all unpublished content" are not able to view the content before sending the content to the next state. If someone has faced a similiar problem please help!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

crimsondryad’s picture

The view on the user's "Workbench" doesn't show unpublished. They have to click the link at the bottom and then select "view unpublished" from the dropdown. The Workbench "dashboard" is just a view. You can modify this to include unpublished items if you choose.

Jumoke’s picture

This is not a dashboard-view's issue. An author creates content but an editor that has permissions to "View all Unpublished Content" cannot view it. I am running into this issue as well. Any fixes, work around or is there some setting conflicting with this?

Jumoke’s picture

Version: 7.x-1.1 » 7.x-2.x-dev
Component: Miscellaneous » Code

I also just noticed that the editor (in this case) could not "Publish" content even though I had "Moderate all content from Needs Review to Published" on the workbench settings.
Under moderation, it doesn't give the option to Publish either, even when they have permissions to do so.

The only way my editor can publish content in moderation is if I give them the "Bypass moderation restrictions" permissions.

How come? I have now switched to the 7.x-2.x-dev version. Still same.

This is a bug, please help?!!!

Anonymous’s picture

Are there any plans to work this issue in the near future? Do you need more info? I am also experiencing this problem.

alexagui’s picture

The filter criteria in the default block display for the workbench_recent_content view is not ideal.

Customize it by updating the block display under this path /admin/structure/views/view/workbench_recent_content/edit/block_1

and remove the Content: Published (Yes) under FILTER CRITERIA
https://img.skitch.com/20120806-ks42xnwm3dfydhrtmmt59a5tpm.png

VladSavitsky’s picture

Quick and dirty solution is: grant permission 'Bypass content access control'.
If you grant permission 'Bypass content access control' to role then users could see unpublished content.
It's because Workbench Moderation uses views for it's lists of content and Views module respects permission 'Bypass content access control' as it cames from core. See modules/node/node.admin.inc#L406

This means that removing from view's filters Content: Published (Yes) doesn't work. Even if role has 'Bypass views access control' permission.

Better solution:
Instead of 'Content: Published' use 'Workbench Moderation: Published'. This solves problem.

Anonymous’s picture

I tried the Better Solution and used the 'Workbench Moderation: Published' for the filter and field. However, this would not even return the published content.

Anonymous’s picture

I have been doing a lot of troubleshooting and this is what I have found:

1) The Workbench Moderation Access and regular Content Mgmt Views will NOT display unpublished content UNLESS the user has Bypass content access control checked under Node. I tried Bypass content access control under Views only, but that did not help.

2) If the user has the URL to the unpublished node, he/she can go directly to the node and edit/publish as needed. It is just that the view will not display the unpublished content.

3) This happens for the user's content and other content that they have access to via Workbench (i.e. - content by others in the same role)

4) I tried adding the Workbench Moderation Status as part of the filter and/or fields in the View and I also tried removing the Permission: Access My Workbench setting in the view.

Any help would be GREATLY appreciated!

Anonymous’s picture

I have now disabled Workbench Moderation and am only using the Workbench Access and Content Access (with ACL) modules for Access Control. Still experiencing the same problem.

Anonymous’s picture

FIXED: I installed the view_unpublished module and set all roles to be able to view ALL UNPUBLISHED content. Now, the unpublished displays in the views and Workbench/Access Control restricts the displayed content to that which the user has access.

UPDATE: Although that DID fix the unpublished problem, it made some of the menu items disappear for anonymous users. Had to disable the view_unpublished module.

UPDATE 10/01/2012: I had read that the ACL module may cause this problem. I tried using Content Access without ACL. Rebuilt permissions and still the same issue. Next, I will try the suggestion below...

Devin Carlson’s picture

I'm not overly familiar with node access but I don't believe that the view all unpublished content permission will work properly unless a modification similar to #8 in #1461950: Permissions for viewing Drafts is done.

I think at that point, view all unpublished content essentially becomes the same as the view revisions permission and might be better off being provided by a module like View Unpublished.

If you currently need certain roles to be able to view unpublished content then I'd suggest you apply patch in #1461950: Permissions for viewing Drafts and add the view revisions permission to your desired roles.

Anonymous’s picture

UPDATE 10/01/2012, #2: After much troubleshooting, I found the following:

Installed the -dev version of Workbench Access. Disabled Content Access and ACL. Rebuilt permissions.

At this time, Unpublished nodes were showing in My Workbench. I added back Content Access and it still worked.

I am not going to enable ACL and see if all works fine.

bbinkovitz’s picture

When I test it out, I am able to view unpublished nodes if I navigate directly to them by URL, but they do not appear in the list of content on My Workbench.

bbinkovitz’s picture

Here's a patch containing tests (and nothing else!) that will pass if your user can view unpublished nodes with the 'view all unpublished content' permission and *without* bypassing restrictions.

I don't know how to write tests for what appears in views, so I was unable to write a failing test for whether the allowed, unpublished nodes show up in the main My Workbench views.

bbinkovitz’s picture

Status: Active » Needs review
chris_hall_hu_cheng’s picture

Still something odd here.

My use-case is a 'Writer' role who can write content, move from 'draft' to 'needs review' but cannot publish.

If this Writer then goes to 'My Workbench' the content is no-where to be found because it has never once been published. Everything is fine if the content has been published (by another role) and the Writer starts working on a new draft.

My site is a new build, with very modules installed,

The ONLY work around I can get without hacking something (or finding a more elegant code workaround) is to install the the View Unpublished module and adding that permission to the Writer role.

Going to look at the patches on the other issue in a bit more detail and see if they do the job.

nasia123’s picture

Views Unpublished did not solved my issue.
My Drafts still don't show any content.

It looks like there is no way for Content Access to work with Workbench Moderation.

By if the user has access too the content overview page, he can see his unpublished content and he can edit it from this page.

Also you could check out this article, as it explains things really nice about workbench moderation and the conflicts that are caused by other modules
http://www.myplanetdigital.com/article/troubleshooting-workbench

nasia123’s picture

FileSize
7.34 KB

Maybe this can be solved with another view for displaying Drafts.
(with module View unpublished installed, also having Content Access installed)

I created a new view for displaying Drafts -- My New Drafts (actually cloned the default view of workbench moderation My Drafts, to a new one) and added the filter "Published or Admin".
I can now view all unpublished nodes with their revisions .

I am also using the filter "Workbench Moderation:Current" to only show the latest node and not all of its revisions.

joachim’s picture

The problem is that this module's 'view all unpublished content' is only applied in hook_node_access(), and hook_node_access() is NOT used for listings: https://api.drupal.org/api/drupal/modules!node!node.module/group/node_ac...

Hence when the editor users looks at the 'needs review' list, hook_node_access() isn't called, and the 'view all unpublished content' permission that Workbench Moderation provides is ignored.

Enabling https://drupal.org/project/view_unpublished and granting *its* 'view all unpublished content' worked for me. That's because view_unpublished ALSO implements hook_node_grants(), which is what is used for listings of nodes.

I would suggest that either:

- Workbench Moderation should implement hook_node_grants() so that its permission works correctly
- Workbench Moderation should remove its 'view all unpublished content' and depend/recommend the https://drupal.org/project/view_unpublished module

joachim’s picture

Issue tags: +Needs tests

I strongly suspect that this problem occurs when node grants modules are present.

I can't find it in the docs, but it's clear from the code in node.module that the {node_access} table isn't consulted when there are no modules present that implement hook_node_grants().

So in most people's cases, this will work fine. But once you add something like OG access to the mix, you get this problem.

tmctighe’s picture

I've worked through exactly what you are describing jaochim:

workbench moderation was working great, as soon as we decided to turn organic groups on (with og access) things started disappearing (in my case, i18n/translations were being lost).

for a quick fix, what i've done is:

/**
 * Implements hook_node_access_records().
 */
function mymodule_node_access_records($node) {
  if (!isset($node->og_group_ref) && $node->status == 0) {
    $grants[] = array (
      'realm' => 'mymodule:unpub',
      'gid' => 5,
      'grant_view' => 1,
      'grant_update' => 0,
      'grant_delete' => 0,
      'priority' => 0,
    );
  }
  return !empty($grants) ? $grants : array();
}

/**
 * Implements hook_node_grants().
 */
function mymodule_node_grants($account, $op) {
  if (user_access('view all unpublished content', $account)) {
    $grants['mymodule:unpub'] = array(5);
  }
  return !empty($grants) ? $grants : array();
}

To make it work retroactively, I had to write an update script which applies this permission to all unpublished content.

Since this seems to be what workbench moderation needs, I'll submit a patch with it as soon as I have the time for it.

vgriffin’s picture

Because the view-unpublished permission is associated with Workbench, that's where the hook_node_access_records and hook_node_grants code should probably be. I was just going to put similar code into my installation's Workbench module. It's much easier when I can borrow some of the code!

vgriffin’s picture

It's only the documentation that says "view all unpublished content" was part of the Workbench module. It really is defined and used in the Workbench Moderation module.

I've got ACL, forum_access, node view permissions, and Workbench Moderation enabled. Workbench Moderation is working! Drafts are being shown and hidden appropriately.

I added the following code to workbench_moderation. making sure to disable and re-enable Workbench Moderation to force the module hook list to be rebuilt before the node permissions were rebuilt.

/**
* Implements hook_node_grants().
*
* We associated role IDs with the 'view all unpublished content' permission with the
* workbench_moderation realm in the node_access table. Here, we return the role ID
* values associated with the user.
*/
function workbench_moderation_node_grants($user, $op) {
$grants['workbench_moderation'] = array_keys($user->roles);
return $grants;
}

/**
* Implements hook_node_access_records().
*
* This function supplies the workbench moderation grants for unpublished content.
* workbench_moderation adds the 'view all unpublished content' permission so it
* captures and returns the role IDs which include that permission.
*/
function workbench_moderation_node_access_records($node) {
$result = db_query("SELECT rid FROM {role_permission} WHERE permission = ('view all unpublished content')");
foreach ($result as $grant) {
$grants[] = array(
'realm' => 'workbench_moderation',
'gid' => $grant->rid,
'grant_view' => 1,
'grant_update' => 0,
'grant_delete' => 0,
'priority' => 0,
);
}

return !empty($grants) ? $grants : array();
}

vgriffin’s picture

I noticed that I posted the version prior to the one that lets users who can view published content actually view it! Use this instead....

/**
 * Implements hook_node_grants().
 *
 * We associated role IDs with the 'view all unpublished content' permission with the
 * workbench_moderation realm in the node_access table. Here, we return the role ID
 * values associated with the user.
 */
function workbench_moderation_node_grants($user, $op) {
  $grants['workbench_moderation'] = array_keys($user->roles);
  return $grants;
}

/**
 * Implements hook_node_access_records().
 *
 * This function supplies the workbench moderation grants for unpublished content. 
 * workbench_moderation adds the 'view all unpublished content' permission so it
 * captures and returns the role IDs which include that permission.
 */
function workbench_moderation_node_access_records($node) {
  if ($node->status)
  {
    // it's published, default handling is okay
    return;
  }
  
  $result = db_query("SELECT rid FROM {role_permission} WHERE permission = ('view all unpublished content')");
  foreach ($result as $grant) {
    $grants[] = array(
      'realm'        => 'workbench_moderation',
      'gid'          => $grant->rid,
      'grant_view'   => 1,
      'grant_update' => 0,
      'grant_delete' => 0,
      'priority'     => 0,
    );
  }

  return !empty($grants) ? $grants : array();
}
nasia123’s picture

A solution to this issue will be really great...

I have not tried your code yet , because I don't understand the process you are applying to enable the ACL related modules and workbench moderation.
for example I already have workbench moderation installed, and not any ACL module, and I want to install Content access module.
Do I first apply the patch and the enable the content access ?
Because content access after enabling it asks, you to rebuild permissions.

vgriffin’s picture

If you apply the patch before you enable content access, it will be in place before the permissions are rebuilt for content access. Then, it will be exercised during the rebuild.

nasia123’s picture

it did not work for me...
I applyed the patch then my node access module, after the permissions were rebuild , my drafts does not show user's drafts

vgriffin’s picture

Had it been working before you turned on ACL?

Are there overlaps between the node types you're trying to control through node access and Workbench? On my site, there are no such overlaps. I'm using Forum Access for forum content only and Node view permissions to control visibility of specific other content which is not known to Workbench.

nasia123’s picture

yes, it was working before ACL.

I an using a new module for groups , called GCC, and it's node access submodule to create private content withing a group.

if I disable my current ACL, can I revert back to the state before the permissions were build, so I can try a different ACL module to test your solution ?

vgriffin’s picture

Yes. It should rebuild the permissions to the previous state.

nasia123’s picture

Ok , I just realized what I had to do
a. apply the code you provided
b. disable workbench moderation
c. enable it again (this is the part I was not doing the first time, and it is important for this solution to work)
d. rebuild permissions is then invoked -> do that.
e. after that I enable GCC node access
f. another rebuild permissions is required for the new module -> ok done that.
e. Success! My Drafts work as expected.

vgriffin’s picture

Great! Thanks for letting me know!

nasia123’s picture

vgriffin's solution also works with og access...

jeroen_drenth’s picture

#24 works for me too!

pbattino’s picture

#24 seems to work for me... shouldn't be merged into current release?

ronny89’s picture

Issue summary: View changes

i can confirm it works for us with Content Access.
i'd also like this as a patch in the next release.

code-drupal’s picture

As suggested by VladSavitsky
Quick and dirty solution is: grant permission 'Bypass content access control'.
If you grant permission 'Bypass content access control' to role then users could see unpublished content.

vgriffin’s picture

The whole point of access permission levels is to allow specific users access to the unpublished content they're working on, even if the users have the same role. That's the key strength of Workbench Moderation. When I was working on a fix, I did grant Bypass content access to verify that it was a content access issue. Of course, this test-only setting granted a lot of undesired access and was not appropriate for our production site. Because we need to control access to some forums, via ACL, while independently controlling access, I had to create a fix that let them play nicely together.

jmuzz’s picture

FileSize
1.57 KB

Ignore this.

jmuzz’s picture

FileSize
5.63 KB

This is #24 and the tests from #14.

robcarr’s picture

Patch at #40 will not roll against DEV. Fails at line 15 of .info file

kukle’s picture

I installed administration views (Admin Views) and removed in de admin views the 'published' in the criteria.
Here you can also remove the 'use ajax' which is a solution for the problem people having troubles using ajax in search forms.

joelpittet’s picture

Issue tags: -Needs tests
FileSize
1.94 KB

Here's a re-roll. This didn't fix my problem but maybe someone else can confirm?

joelpittet’s picture

Woops forgot tests... Ok so here is two, a tests only patch (which should fail) and both which should pass.

bbinkovitz’s picture

Issue summary: View changes
arx-e’s picture

The dev version7.x-1.3+10-dev plus the patch in #44 (1492118-44-pass.patch) solved the problem for me.

I am not using ACL.
I am only using Workbench Moderation and Field Permissions.

delphian’s picture

#16 This may be due to _workbench_moderation_access_current_draft() which requires the node to be published at least once. My specific use case required the author to be able to always preview the latest draft (/node/X/draft), regardless if it had been approved for publishing or not.

dmsmidt’s picture

@joelpittet & @arx-e

For me the patch in #44 works as well in combination with the latest 1.x-dev. (Don't forget to do a database update).

ak55’s picture

I haven't read all comments but for me, check the option 'Disable SQL rewriting' in here fixed the problem. admin/structure/views/view/workbench_moderation/edit

ericjgruber’s picture

I was having the same issue today.

I went into the view for the Needs Review tab, and under Filter Criteria, I clicked on Workbench Moderation State.

In my case, I had an additional state called "Needs Published." It was unchecked. So, I checked it, saved the view, and now it works.

aerozeppelin’s picture

#49, worked for me. Thanks a million!

kthull’s picture

#49 also worked for me.

  • colan committed 5c2769a on 7.x-1.x authored by jmuzz
    Issue #1492118 by joelpittet, jmuzz, nasia123, bbinkovitz, delphian: Set...
colan’s picture

Status: Needs review » Patch (to be ported)

Committed #44 to 7.x-1.x-dev. Thanks all!

Remember: You'll need to rebuild permissions over at Administration -> Reports -> Status report -> Rebuild permissions after getting the code for this to work.

MrSasquatch’s picture

Do these views get replaced when the Workbench Moderation module is updated? Could the problem be that I have old views that I got from Workbench Moderation 2+ years ago?

colan’s picture

@HardTimes: Views don't get touched in this patch, but there are some reports that they broke on 1.3 -> 1.4. Maybe you're running into #2430515: 7.x-1.4 breaks Workbench Views (revised date) and Node Order module ?

agentrickard’s picture

Title: view all unpublished content permission not working » Revert view all unpublished content permission changes
Version: 7.x-2.x-dev » 7.x-1.x-dev
Status: Patch (to be ported) » Needs work

This approach violates the documented standard from https://www.drupal.org/node/310077 and needs to be reverted. It is an abuse of the node access system and will cause numerous problems with other access control modules.

This issue should only affect administrative queries provided by Views. The proper solution is to fix those Views definitions.

  • colan committed 296ce87 on
    Revert "Issue #1492118 by joelpittet, jmuzz, nasia123, bbinkovitz,...
colan’s picture

Title: Revert view all unpublished content permission changes » View all unpublished content permission not working

Reverted #53.

jmuzz’s picture

Edit - It probably is an issue with the views. One of the comments said otherwise but most seem to indicate it is.

agentrickard’s picture

We should move known issues into a tracking ticket to update Views. If necessary, we could write a Views filter handler or, as noted above, point people to the other module.

colan’s picture

Does anyone have time to look into updating the views? I'd really like to have this resolved in the next release. If it's a big enough job, yes, let's split it into several tickets.

I'm actually tempted to tag this as a release blocker.

FreekVR’s picture

If we want this module to work with other modules implementing node grants (say: domain, or og, or content_access) then implementing the node grants hooks is the best way. Yes, you can also alter based on the node_access query tag, but that's basically the same.

The original approach was wrong however, because whenever you'd assign the permission to "view all unpublished" you'd have to rebuild all the permissions. A better way is to use a generic "gid" which allows view permissions, then in hook_node_grants, simply pass this generic gid whenever a user with the correct permissions hits the page.

We can also wrap the hooks in conditional statements so that this module only implements grants if another also does.

Rolling a patch tomorrow, unless someone beats me to it ;)

FreekVR’s picture

Status: Needs work » Needs review
FileSize
5.72 KB

This patch is largely based on the earlier commit, except that it reverses the logic so that only one grant is needed for an unpublished node, and no access rebuilds are required when changing permissions.

The patch resolves issues with any query using the node access tag, not just views, when also using other modules implementing node grants.

vanessakovalsky’s picture

The last patch work for me, thank you @FreekVR

weri’s picture

It would be great to have a setting/an option to define, should grants and node access records used or not. Because we want to use the workbench module, but prevent the use of the node_access table. I know, that we have to be aware of the node access tag, but in our case is this not a problem and with more than 1'000'000 nodes, we have more problems when we have to rebuild the permissions, based on grants.

The other way is to alter the node_access query tag. This could be a solution when grants are "disabled". It would be great to have an option for this in the workbench moderation module. Makes this sense or not?

compa’s picture

@FreekVr / @vanessakovalsky

I might be doing something wrong, but can't get #64 to work ... apply the patch simply breaks up the server to spit out 500's all across drupal.
The unfortunate (https://www.drupal.org/node/2128555) is in place again (just wiping that && = published from the module).

Not sure what goes wrong though, what's the best approach?
Deinstall the module, patch, re-enable & reACL everything? or ..

_doyle_’s picture

@compa I believe you are having issues because the patch was rolled against version 7.x-1.3 and not 7.x-1.4 which already has patch #44 committed into it. This is causing duplicate functions to be defined.

I am still seeing the issue with unpublished content not showing in the "All Recent Content" view and it is being caused by the "Published or Admin" filter on the view. I did some digging and it looks like there is an issue with that filter - removing it will fix the issue. (You may need to rebuild your node permissions).

It seems that this is the only view display with this filter on it, is there a specific reason it is there or can we roll out a patch to remove it?

Here is some example code to help remove it without cloning the entire view until it gets resolved in the module:

/**
 * Implements hook_views_default_views_alter()
 * @param $views
 */
function mymodule_views_default_views_alter(&$views) {
  //Alter items specific to the workbench_recent_content view.
  if (isset($views['workbench_recent_content'])) {
    //Unset the "Published or Admin" field from all recent content as it is broken.
    $handler =& $views['workbench_recent_content']->display['default']->handler;
    //Unset the status_extra handler since it is broken.
    if (isset($handler->display->display_options['filters']['status_extra'])) {
      unset($handler->display->display_options['filters']['status_extra']);
    }

  }
}

**Note - you may need to revert the view after clearing the cache to get this change to take effect.

colan’s picture

Status: Needs review » Needs work

I finally had a chance to delve into this. I don't think we need to do anything with the node access/grants system (nor should we).

To summarize, the problem seems to be that the "Content: Published or admin" filter on the "Workbench: Recent content" view (provided by Workbench, not Workbench Moderation) doesn't account for the "View all unpublished content" permission that ships with Workbench Moderation (this module). We can't bake that permission into the view because WM isn't guaranteed to be installed when using Workbench.

So I think the best way forward (unless I'm missing something or we can come up with a better option) is to implement hook_views_default_views_alter() via workbench_moderation_views_default_views_alter() and override the filter to allow unpublished content if the "View all unpublished content" permission is enabled.

I'll try to come up with a patch for this sometime this week, unless somebody else beats me to it.

colan’s picture

colan’s picture

Priority: Critical » Major

With the latest dev, I can't seem to reproduce this issue (but I'm not using any of the node access modules).

Is this still a problem for anyone else? I'll leave this open for now assuming it is, but changing status as it doesn't seem to be a problem for everybody.

charginghawk’s picture

I was experiencing this issue using the latest release (without any access modules), but using the 7.x-1.x-dev version fixed it.

colan’s picture

Status: Needs work » Fixed

Looks like this got fixed through some other commits then.

redka’s picture

Had same problems as above i.e. role (authorised user or similar) that could not see there draft basic page/post content type in the My Drafts tab. It seem to work after this same content was first published e.g. subsequent draft revisions but not straight away.

Checked against another installation I had (added in Workbench Email (7.x-2.2) and this fixed the problem. It did not show previous drafts that have never been pbulished, but new drafts did appear from this point on. So something in this module resolved the issue of the moderation module possibly?

Modules:
Workbench 7.x-1.2
Workbench access 7.x-1.2
Workbench Moderation 7.x-1.4

then added
workbench Email 7.x-2.2 and My Drafts now works.

Hopes this helps. don't know what the problem is but may help narrow the solution.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

thomasmurphy’s picture

I'm getting a very similar issue with a view, which has a published or admin filter, and the nodes are visible as a result of a workbench moderation grant, but the nodes aren't displaying in the view. I tried switching from the 7.x 1.4 to the 7.x 1.x-dev version but didn't help. Any suggestions welcome.

John Pitcairn’s picture

Does the problem go away if you disable the module?

sylus’s picture

Just attaching the revert as a patch for Drush Make purposes against 1.4.

ann b’s picture

I'm having the same problem as #76. I also tried switching from 7.x 1.4 to 7.x 1.x-dev, but this brought down my dev site. Apache kept giving me this message:

PHP Fatal error: require_once(): Failed opening required '.../sites/all/modules/workbench_moderation/workbench_moderation.install' (include_path='.:/usr/share/pear:/usr/share/php') in .../includes/module.inc on line 330

So I went back to 7.x 1.4 and my site is back up. I'm just going to remove the 'Content: Published or admin' filter from All Recent Content view.

dutchyoda’s picture

We have a patch for the node module that check if a grant is applied per module. With patch 64 the published nodes were no longer visible. This patch makes sure that published nodes are still visible.

bryanhirsch’s picture

I tested view_all_unpublished-1492118-80.patch. This doesn't do the trick for me. I've got "View all unpublished content" checked, but my users still can't see the unpublished nodes.

vinothg’s picture

Status: Closed (fixed) » Needs work

I checked all revisions 7.x-1.x-dev, 7.x-2.x-dev, and 7.x-1.4, the issue is not fixed yet.

Forget about the views, when you grant view all unpublished content, the "View draft" tab is not visible in the node view page and we are getting access denied for "node/[nid]/draft" menu callback.

kwiliarty’s picture

Using 7.x-1.4 I find that moderators see all items under "My Workbench > Needs Review", but that authors do not see their own drafts listed under "My Workbench > My Drafts" or "My Workbench > Needs Review". The grants applied by commit 5c2769a apply only for users with 'view all unpublished content'. I can fix this problem by adding a grant for authors with 'view own unpublished content' using a patch like this:

--- a/workbench_moderation.module
+++ b/workbench_moderation.module
@@ -455,6 +455,9 @@ function workbench_moderation_node_access($node, $op, $account) {
  */
 function workbench_moderation_node_grants($user, $op) {
   $grants['workbench_moderation'] = array_keys($user->roles);
+  if (user_access('view own unpublished content')) {
+    $grants['workbench_moderation_author'] = array($user->uid);
+  }
   return $grants;
 }
 
@@ -482,6 +485,14 @@ function workbench_moderation_node_access_records($node) {
       'priority' => 0,
     );
   }
+  array_push($grants, array(
+      'realm' => 'workbench_moderation_author',
+      'gid' => $node->uid,
+      'grant_view' => 1,
+      'grant_update' => 0,
+      'grant_delete' => 0,
+      'priority' => 0,
+  ));
   return !empty($grants) ? $grants : array();
 }

But then I am worried because it seems that beyond 7.x-1.4 the grants are reverted in #58. Am I pursuing a dead end by adjusting the grants?

vistree’s picture

Hi,
I want to be able to show users there OWN drafts in the "My Edits" and "My Drafts" views of workbench.
So I don't want users to have the "view all unpublished content" permisision.
Instead, I want to use "view own unpublished content". This seems to be the same as in #84

Therefor I want to combine #80 and #84.

/**
 * Implements hook_node_grants().
 */
function workbench_moderation_node_grants($account, $op) {
  $grants['workbench_moderation'] = array_keys($account->roles);
    if (user_access('view own unpublished content')) {
        $grants['workbench_moderation_author'] = array($account->uid);
      }
  $grants['workbench_moderation_published'] = array((int) user_access('access content', $account));
  return $grants;
}

/**
 * Implements hook_node_access_records().
 */
function workbench_moderation_node_access_records($node) {
  $grants = array();
  if (!$node->status) {
    // We implement an access record for unpublished content.
    $grants[] = array(
        'realm' => 'workbench_moderation_author',
        'gid' => $node->uid,
        'grant_view' => 1,
        'grant_update' => 0,
        'grant_delete' => 0,
        'priority' => 0,
    );
  }
  else {
    // We implement an access record for published content.
    $grants[] = array(
      'realm' => 'workbench_moderation_published',
      'gid' => 1,
      'grant_view' => 1,
      'grant_update' => 0,
      'grant_delete' => 0,
      'priority' => 0,
    );
  }
  return $grants;
}

To be sure to do things right I have the following questions:
- Regarding #57: is it save to use hook_node_access_records ???
- is it correct to use 'gid' => $node->uid for drafts and 'gid' => 1 for published nodes???
- why does #80 uses the public part? Isn't there already an access record if the node is published?

  • colan committed 296ce87 on 7.x-3.x
    Revert "Issue #1492118 by joelpittet, jmuzz, nasia123, bbinkovitz,...
  • colan committed 5c2769a on 7.x-3.x authored by jmuzz
    Issue #1492118 by joelpittet, jmuzz, nasia123, bbinkovitz, delphian: Set...
gambry’s picture

I see a lot of issues about "authors not be able to see his/her nodes progress/moderation-state" linked to this one, but reading the whole queue I can't see how things are related.
The only related work/comment is #84 which actually fix it, while the rest of the discussion here seems to be about the 'view all unpublished content' permission which I'm sure is not something you want to give to any node author.

I do suggest to open a different issue and fix the node owner related bug there, instead of redirecting the users here, or at least update the issue title and description to reflect what this is really about.

If community agrees to the split I can create the issue and make #84 an initial patch.

dutchyoda’s picture

Version: 7.x-1.x-dev » 7.x-1.4
FileSize
1.46 KB

I couldn't apply my patch any more, so I fixed it based on the 1.4 tag.

matt.lynberg’s picture

Workbench moderation also provides an access_alter hook. This little snippit fixed it for me.

function hook_workbench_moderation_access_alter(&$access, $op, $node) {
  if (user_access('view all unpublished content')) {
    $access = TRUE;
  }
}
d8v15’s picture

What is the final solution? It seems to me that workbench doesnt work according to the above.

hass’s picture

Version: 7.x-1.4 » 7.x-1.x-dev
Francis47’s picture

#49 worked for me with the same specific needs.

npoku’s picture

Also confirming #49 worked. Problem was with Content Access module was interfering (it was doing what it was suppose to do). #49 allowed me to override the content Access module rule, just for that View display. here is some backup info.

Scroll Down to the Content Access module @ this link https://www.drupal.org/docs/7/managing-users/viewing-unpublished-content

samtny’s picture

#49 worked for me as well. in our case editors were unable to observe unpublished nodes at '/admin/content'. disabling the node_access check for this particular view resolved this issue satisfactorily.

delacosta456’s picture

hi i on my one side instead of disabling rewrite or patch, this module https://www.drupal.org/project/view_unpublished (providing a "View any unpublish of [type]") has help

MiroslavBanov’s picture

This issue is caused by modules that use hook_node_access_records (Content Access, Organic Groups). There similar/related issues opened in them: #1683074: unpublished content not visible in admin/content, #1225520: Add 'View own unpublished content' setting

MiroslavBanov’s picture

omarlopesino’s picture

Status: Needs work » Needs review
FileSize
506 bytes

We have a use case similar:
1) a editor makes a draft of a content
2) he sends it to a reviewer to validate it, but he does not have access even when reviewer has 'view all content published'.

In this case he can't see it because is trying to access to 'node/XXX/draft' and the permissions checks are: view moderation state, node access to update content.

In this case the operation that the user is doing is view revisions, so we can check 'view revisions' permissions from node module.

I attach a patch which checks this permission in _workbench_moderation_access function , in case operation is 'view revisions'.
Can you check this is a correct change?

oana.hulpoi’s picture

Hey,
Checking 'Disable SQL rewriting' in view query settings fixed the issue for me. All content (draft, needs_review, published) is being displayed now in my custom view.

tunic’s picture

#99 (oana.hulpoi) It's normal because disabling SQL rewriting effectively disables Drupal access system. While it could be a workaround in some cases this is not a solution, only if you don't care about access system.

Charles Belov’s picture

Re #85: @vistree: If you don't want to grant permission to view all unpublished content then I believe this issue does not apply to your situation. You would simply not check the permission "View all unpublished content." This issue is for the situation where someone has checked the permission "View all unpublished content" and it doesn't achieve that result.

Charles Belov’s picture

re #87 @gambry: Yes, I really do want the "View all unpublished content" permission to enable certain user roles to view all unpublished content as described in the permission name. I believe this issue is correctly worded. If a site admin does not want to grant that permission, then they need to not check that permission.