Hi,
I just installed the view_unpublished module with great expectations (btw, can't figure out why these permissions not in D7 native!?!). So far, it just plainly doesn't work, at all... I'm sure it cannot be so because 2400+ sites report using it. That's why I'm requesting support instead of reporting a bug. However, on my install, no matter how I set the permissions, I just can't access unpublished content. No error message. Just like the module wasn't enabled. Yes, I tried rebuilding the permissions. Any idea?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mesr01’s picture

Title: Not granting access to unpublished access » Not granting access to unpublished content

Corrected error in title

RedTop’s picture

Same here D7.2. Installed module, granted the role permissions to view any unpublished content (for all and also per content type). No change?

Aaaaah.. it does grant view permissions, content just doesn't appear in content filter screen. Guess I'll have to find another solution.
http://drupal.org/node/1154318

Thanks though!

djmy’s picture

is there any way this module can be reflected on the Content filter screen. Had the same issue, i would like to find a way that i can view unpublished content other than my own, under "Content" (as an editor role) without allowing access to "Bypass content access control" to be turned on. I just want a specific content type to show unpublished to certain roles and have it displayed on their "Find Content/Content".

Matt V.’s picture

Component: Code » Documentation
Category: support » feature

It would definitely be nice if the module could be modified to also change the behavior of the "Content" screen. Until then, it would be helpful to have a note on the view_unpublished project page explaining the behavior.

entendu’s picture

Component: Documentation » Code
Priority: Major » Normal

Added a note to the project page. This would be a nice feature to get in.

C. Lee’s picture

subscribing

Pitcher’s picture

subscribing

TravisCarden’s picture

For the public good: Stop subscribing, start following. ;)

John Pitcairn’s picture

#4: Override the query made by admin/content with hook_query_alter in a module. This example tests for the permission "view all unpublished content" which is supplied by workbench_moderation, but that can easily be modified to whatever view_unpublished supplies, as can the path:

<?php
/**
 * Implements hook_query_alter().
 */
function mymodule_query_alter($query) {
  if (arg(0) == 'admin' && arg(1) == 'content' && user_access('view all unpublished content')) {
    $conditions =& $query->conditions();
  
    foreach ($conditions as &$condition) {
      if (isset($condition['field']) && $condition['field'] == 'n.status') {
        $condition['value'] = -1;
        $condition['operator'] = '>';
      }
    }
  }
}
Matt V.’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
Status: Active » Needs review
FileSize
727 bytes

Thanks John!

I created a patch based on your suggestion above in comment #9. It appears to be working for me. I'm attaching the patch.

jox’s picture

This is not a great solution.

First of all it should be 'view any unpublished content' and not 'view all unpublished content'. Maybe this has changed just recently. (In the patch by Matt V. it is correct.)

The main problem is, it will make the status filter useless. For example, it is not possible to list unpublished content only.

By the way, responsible for hiding non-own unpublished content is the following code in modules/node/node.admin.inc (within function node_admin_nodes()):

  if (!user_access('bypass node access')) {
    // If the user is able to view their own unpublished nodes, allow them
    // to see these in addition to published nodes. Check that they actually
    // have some unpublished nodes to view before adding the condition.
    if (user_access('view own unpublished content') && $own_unpublished = db_query('SELECT nid FROM {node} WHERE uid = :uid AND status = :status', array(':uid' => $GLOBALS['user']->uid, ':status' => 0))->fetchCol()) {
      $query->condition(db_or()
        ->condition('n.status', 1)
        ->condition('n.nid', $own_unpublished, 'IN')
      );
    }
    else {
      // If not, restrict the query to published nodes.
      $query->condition('n.status', 1);
    }
  }
jox’s picture

So another (better?) quick hack/solution would be to replace the line:

  if (!user_access('bypass node access')) {

with:

  if (!user_access('bypass node access') && !user_access('view any unpublished content')) {

in modules/node/node.admin.inc.

fb-multimedia’s picture

thanks for the solution, but can somebody implement this as a hook in the module ?

Matt V.’s picture

@fb_multimedia, the patch I posted in Comment #10 above adds a hook_query_alter that should fix the issue. If you'd like to speed up getting it applied to the module, you can try applying it and reviewing it.

John Pitcairn’s picture

The hook_query_alter() does have the unavoidable side-effect of making the "status" filter ineffectual. For me, that's not an issue as I hook_form_alter() that form element out anyway, and just let users click-sort on the column.

The only other clean way around this I can think of is to override the admin/content menu path with a custom page callback function in hook_menu_alter(), and duplicate the entire content of node module's original page callback, with slight modifications as per #12. That's a lot of code to maintain.

Chaulky’s picture

You could recreate the admin/content page pretty easily with Contextual Administration and a Views Bulk Operations view. http://drupal.org/project/context_admin

This is actually how I got around this issue, though in my case I planned on replacing the Content Overview page anyways.

azarzag’s picture

If you install VBO and use the default "content" view to "Emulates the Drupal content administration page", You can get the same functionality as a the default admin/content page AND the unpublished nodes will show up according to the permissions set with this module.

jeni_dc’s picture

I'm running into a problem with roles and content types, Drupal 7.12, View Unpublished 7.x-1.0. If I grant a role access to view unpublished for a particular content type they cannot view the content on node display or in admin screens built with views bulk operations. Node display gives "Access denied" and in the VBO just doesn't display that node.

But, if I then give that role the "View any unpublished content" they can view the unpublished content on node display and in admin screens.

Chaulky’s picture

The problem with VBO views is a separate issue and has been resolved, just isn't in a released version yet. You can grab a patch for Views integration from http://drupal.org/node/768206#comment-5144408.

Chaulky’s picture

Title: Not granting access to unpublished content » Respect View_Unpublished permissions on the Content overview page

Changed the title to more accurately reflect the purpose of the feature request

czigor’s picture

I've made some corrections on the patch in #10, now it is possible to filter for status as well.

It is still not working for content type-like view permissions, only for 'view any unpublished content'.

Eric_A’s picture

From Drupal 7.13 on life has changed for the better...

entendu’s picture

Thanks for the hard work on this, everyone. I think I've found a solution for filtering on content-type permissions as well.

Basically, the content overview page should act like you'd expect it to: if you've got per-content-type permissions, filtering on "not published" will show you unpublished nodes you have access to. Same thing if you have "view all unpublished" perms, or admin (uid 1) or 'admin nodes' rights.

Committing to dev, would be great to get a second set of eyes on this one to make sure it works like I think it does.

Eric_A’s picture

The current fix is hard coded for the admin/content/node path.

Drupal 7.13 added the node_access query tag to the content administration page (and the forum listings), which makes it possible to dramatically clean up, simplify and improve this code by implementing hook_query_TAG_alter(). (It's not just "admin/content/node" suffering from this issue.)

Of course there's no dependency on 7.13 right now. We could either add the dependency or try to use both hooks to try and catch as much listings as possible.

acbramley’s picture

I'm on Drupal 7.14, and using the --dev branch of this module. I've tried giving a role all the view unpublished permissions but I still can't see them in the Content screen. I'm using the content_access module as well, will this be conflicting? The role also has permissions to edit these content types etc.

entendu’s picture

@Eric_A:

It's not just "admin/content/node" suffering from this issue.

That's all this ticket was opened for; what other pages are affected?

@acbranbley:

I'm using the content_access module as well, will this be conflicting?

Could be. Have you tried rebuilding permissions?

Eric_A’s picture

That's all this ticket was opened for; what other pages are affected?

In core we have the Books overview: admin/content/book. It matches "admin/content", but no TableSort here if I'm not mistaken.
Checking with hasTagg('node_access') or implementing hook_query_TAG_alter() smells better than path matching in query altering.

acbramley’s picture

@entendu yup, several times

fuse’s picture

Dev version doesn't work because sometimes conditions aren't met and unsetting the "status" condition isn't executed.

The code checks if $confition['field'] equals n.status. But if I dump the conditions variable I sometimes get the following object instead of "n.status".

DatabaseCondition Object ( [conditions:protected] => Array ( [#conjunction] => OR [0] => Array ( [field] => n.status [value] => 1 [operator] => = ) [1] => Array ( [field] => n.nid [value] => Array ( [0] => 260 ) [operator] => IN ) ) [arguments:protected] => Array ( ) [changed:protected] => 1 [queryPlaceholderIdentifier:protected] => )

The IF statement is therefore never met and status condition is not removed.

fuse’s picture

I have searched a bit more and was able to slove this. I am not a Drupal expert so I don't know how to create a patch and the code might need some more optimalisation but for me it is working now.

/**
 * Implements hook_query_alter();
 *
 * Modify the Content Overview page to account for view unpublished
 * permissions.
 */
function view_unpublished_query_alter($query) {
	
  global $user;
  if (arg(0) == 'admin' && arg(1) == 'content' && get_class($query) == 'TableSort'
      && $user->uid !== "1" ) {
    $perms = view_unpublished_user_perms();
    // "any" in this case means at least 1 view unpublished permission is set to TRUE.
    if ($perms['any']) {
      $conditions =& $query->conditions();
	   
	  foreach ($conditions as $key => $condition) {

        // For some queries $condition['field'] is not a string so we need a check for that.	
        if (isset($condition['field']) && $condition['field'] === 'n.status') {
	
              // This condition is (probably) coming from modules/node/node.admin.inc,
              // function node_admin_nodes():       $query->condition('n.status', 1);
              // We don't want it.
              unset($conditions[$key]);
			  
        }elseif( is_object($condition['field']) ){

			$subconditions = $conditions[$key]["field"]->conditions();		
			
			$new_conditions = db_or();
			$new_conditions->condition('n.status', 1, '=');
			$new_conditions->condition('n.status', 0, '=');
			
			$conditions[$key]["field"] = $new_conditions;
		}
		
      }
      // If "view any unpublished content" (aka $perms['full']) is set, then
      // leave the rest of the query as-is and return all unpublished content.
      // Otherwise, add a WHERE/OR to the query that specifies content type, as
      // dictated by the user's permissions, e.g. "view any unpublished page content"
      if (!$perms['full']) {
        $content_perms = array_filter($perms['content_type']);
        if (count($content_perms) === 1) {
          $query->condition('n.type', key($content_perms));
        }
        else {
          $db_or = db_or();
          foreach ($content_perms as $k => $v) {
            $db_or->condition('n.type', $k);
          }
          $query->condition($db_or);
        }
      }
    }
  }
}
iSylence’s picture

Tidied up code submitted by fuse #30.
Works as advertised.
Patch is attached.

lotyrin’s picture

Status: Needs review » Needs work

Could we get this without the unrelated whitespace changes?

iSylence’s picture

Status: Needs work » Needs review

The changes that were made were to make it conform with drupal coding standards, for example I wrapped comments which were exceeding the 80 character limit to be on multiple lines.
I also made an if statement more human readable/understandable by splitting it into separate variables, and I noticed a spelling mistake in a comment so I fixed that.

Eric_A’s picture

Note that the recent block from node module calls node_get_recent() running another node_access query. Ultimately all of those should be rewritten by view_unpublished, just like node module itself does and node access control modules do.

steveoriol’s picture

I love this patch, ;-)
thank you.

entendu’s picture

Status: Needs review » Fixed

Committed #31 to dev version. Thanks fuse/iSylence.

kenwest’s picture

Folks,

Not sure if I should post this comment here or in a new issue, as this issue is marked as 'fixed'.

I'm using the 7.x-1.x-dev version containing the #36 patch. When I filter on Status and set that to 'not published', I still see the Published content. I note this has been a problem observed in earlier posts on this thread.

Thanks to fuse, iSylence, and entendu for the fix, by the way.

Status: Fixed » Closed (fixed)

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

dotist’s picture

Same here - using the dev version, but the content page filter still isn't working.

ed.hollinghurst’s picture

I have modified this module slightly to do a check on whether the content list should filter unpublished content only. The attached seems to work for me but I'd welcome any feedback on this.

ed.hollinghurst’s picture

Status: Closed (fixed) » Active

Putting this back to 'active' as I believe there is still an issue here that needs to be resolved.

VladSavitsky’s picture

.

ed.hollinghurst’s picture

Status: Active » Needs review
FileSize
1.13 KB

Please ignore previous patch I posted in comment #40.

I actually found that by simply removing the part where the n.status condition is initially unset everything now works completely fine for me. Revised patch attached.

Anonymous’s picture

Status: Needs review » Needs work

Yer with the latest dev, I now see the unpublished nodes on the Find Content page, but filtering by published or not published doesn't work (both options show all content i.e. published and unpublished).

Unfortunately #43 doesn't work for me. It actually no longer shows any unpublished content, both when you first come to the Find Content page, and when you filter by status=not published.

ed.hollinghurst’s picture

Status: Needs work » Needs review
FileSize
924 bytes

OK.. yes having reviewed this again I think we just want the n.status condition to be unset if the value is 1.

Revised patch attached (third time lucky!).

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community

Thanks ed - this now works with the status filter!

VladSavitsky’s picture

Thanks for this patch.
I used patch from comment #45 and changed path to file in patch. Now you can use:
cd sites/all/modules/view_unpublished
wget http://drupal.org/files/view_unpublished_content_admin-1192074-47.patch
patch -p1 < view_unpublished_content_admin-1192074-47.patch

ellen.davis’s picture

Installed view_unpublished-7.x-1.x-dev.tar.gz and then patched with view_unpublished_content_admin-1192074-47.patch

Now with the view unpublished permission set, users can view others unpublished content on the admin/content page.

Thanks.

Ramirez’s picture

This works only if you grant access to view any type of nodes.
If you grant access only a specific content type, the general content pane shows this only. Everything else is hidden, which is definitely a bug.

Anonymous’s picture

Status: Reviewed & tested by the community » Needs work

I can confirm this bug: if you only have the permission "view any unpublished content" for a specific type, then you can't see nodes of any other type on the admin/content page (published or not).

j.slemmer’s picture

Category: feature » bug

Let's mark this as a bug and not a feature request anymore...

Geijutsuka’s picture

Has there been any progress on this?

I know #1154318: How to allow users to find unpublished content was closed and marked as "fixed" but I don't see making a separate view for content managers as a fix—it's silly to make end users go to a separate overview page to see unpublished content when the main content overview page offers them filters to show unpublished content. I think I'll go ahead and mark that issue as a duplicate instead...

steveoriol’s picture

You can also avoid to modify the module by using an other module Administration views.
With this module, the roles that are allowed to modify unpublish nodes, can have the pleasure to see them in the page "admin / content" even if they are not the author of this nodes. => it's cool :-)
Dependencies [Views, Views Bulk Operations, Chaos Tools (implicit) and Entity API (implicit) ]
It can help ...

hansfn’s picture

Status: Needs work » Reviewed & tested by the community

I confirm that the patch in comment 47 is good (as reported by other users). Please commit that fix so this issue can focus on any unresolved problems.

kevinquillen’s picture

Used patch #47, did not work for default Content overview for an administrator. Also used dev branch, does not work.

kevinquillen’s picture

Having the view_unpublished_query_alter require the current user to not have bypass node access and administer nodes cuts out a handful of configuration scenarios. In my case, even letting a role have Administer Content still did not permit them to see unpublished nodes. Sorry I do not have a proper diff offhand. Also, it seems that if you do not use Override Node Options (and thus, don't assign Administer Content permission) does it really matter to check for them?

I also had to simplify the logic for this to work for me. I could not get unpublished content to show in the default Content overview otherwise.

From:

  if (arg(0) == 'admin' && arg(1) == 'content' && get_class($query) == 'TableSort'
      && $user->uid !== "1" && !user_access('bypass node access') && !user_access('administer nodes')) {
    $perms = view_unpublished_user_perms();
    // "any" in this case means at least 1 view unpublished permission is set to TRUE.
    if ($perms['any']) {
      $conditions =& $query->conditions();
      foreach ($conditions as $key => $condition) {
        // For some queries $condition['field'] is not a string so we need a check for that.
        if (isset($condition['field']) && $condition['field'] === 'n.status') {
          if (TRUE) {
            if ($key == count($conditions) - 2) {
              // This condition is (probably) coming from modules/node/node.admin.inc,
              // function node_admin_nodes():       $query->condition('n.status', 1);
              // We don't want it.
              unset($conditions[$key]);
            }
          }
        }
      }
     // rest of code

To:

if (arg(0) == 'admin' && arg(1) == 'content' && get_class($query) == 'TableSort'
      && $user->uid !== "1" && !user_access('bypass node access')) {
    $perms = view_unpublished_user_perms();
    // "any" in this case means at least 1 view unpublished permission is set to TRUE.
    if ($perms['any']) {
      $conditions =& $query->conditions();
      foreach ($conditions as $key => $condition) {
        // For some queries $condition['field'] is not a string so we need a check for that.
        if (isset($condition['field']) && $condition['field'] === 'n.status' && $condition['value'] === 1) {
          // This condition is (probably) coming from modules/node/node.admin.inc,
          // function node_admin_nodes():       $query->condition('n.status', 1);
          // We don't want it.
          unset($conditions[$key]);
        }
      }
   // rest of code
Openfed’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
1.72 KB

I have the same problem as kevinquillen. His version, which works in my environment , is in the patch below.

rickdonohoe’s picture

I'm using patch #57 and it works fine for me.

Leeteq’s picture

IMO, given the fact that early half-baked versions is already in -dev, #57 should be committed to -dev now.

Ronino’s picture

#57 does not work if the user has the "view own unpublished content" permission. I enhanced the patch to also work with that permission set and also included parts of #40 to only list published nodes if the user has set the filter like that.

HairMachine’s picture

#60 appears to work nicely for me - thanks!

Leeteq’s picture

3 days ago, the -dev version was updated, but not including (and unrelated to) #60, and the patch in #60 is against 1.1, so now there are several (other) differences between the current -dev, and what we get if we patch 1.1 with #60... (and #60 fails against the current -dev)

Edit:
So it would be nice if #60 could be made against the current -dev.

anrikun’s picture

#60 seems to work for me too. Thanks!

DuaelFr’s picture

Issue summary: View changes
Status: Needs review » Needs work
Issue tags: +Needs reroll

The patch needs to be rerolled against the lateste dev version.

DuaelFr’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
8.56 KB

Here is a new patch inspired by previous ones and work made on the dev branch.
It fixes access grants and query alter to be fully working and compatible with the 'view own unpublished content' permission from core Node module.

For each unpublished node it now checks if:
- you have the 'view any unpublished content' permission
- you have the 'view any unpublished TYPE content' permission from the node type
- you have the 'view own unpublished content' permission and the node's uid is yours

I made a lot of manual testing but I think this module should implement some SimpleTests to be more robust.
Please review carefully.

This patch is part of the #1day1patch initiative.

DuaelFr’s picture

This patch file will be better ;)

jasonawant’s picture

Hi,

Thanks for everyone's work on this. A new project I'm working on required this functionality and of course the community has a solution! Woohoo!

The patch in #66 works for these tested permissions using different user roles on the node view and the content overview page:
- 'view any unpublished content' permission
- 'view any unpublished TYPE content' permission from the node type
- 'view own unpublished content' permission and the node's uid is yours

$git apply did not work, but patch -p1 did.

I had originally came to the issue queue searching for a bug I discovered while trying to view comments of an unpublished node as the node author with the 'view own unpublished content' permission. The bug prevent the node author, who could their unpublished node, but could not view the comments. I imagine this is related to the same permissioning for the content overview page.

Thanks again, Jason.

DuaelFr’s picture

Thank you for your feedback.
You may open another issue for the comments as I don't think it is exactly the same behavior used in both nodes and comments.

DuaelFr’s picture

Here is a new patch that only focus on this issue as the fix of the core 'view own unpublished content' is provided by #1762904: Fails to respect core 'view own unpublished content' permission.
I also removed from this patch a minor code improvement that will be asked in another issue.

jabberwooki’s picture

Bad luck, it doesn't work for me.
I couldn't apply the patch. A dry run test gives :

patch -p1 --dry-run < view_unpublished-content_admin_fix-1192074-69.patch
patching file view_unpublished.module
Hunk #2 FAILED at 122.
Hunk #3 succeeded at 152 (offset 2 lines).
1 out of 3 hunks FAILED -- saving rejects to file view_unpublished.module.rej

izmeez’s picture

@jabberwooki have you looked at the patch and tried applying it manually by editing the file?

DuaelFr’s picture

@jabberwooki I just tried to apply this patch on the last dev version and it works well. Try to use git apply instead of patch -p1.

Leeteq’s picture

Priority: Normal » Major
tierso’s picture

patches 57 och 60 worked for the dev-version available for download on the drupal site, but none of the other patches (tried both git apply and patch). Is there a dev-version somewhere else available for download?

entendu’s picture

Thanks for all the hard work on this issue. view_unpublished_query_alter() is now view_unpublished_query_node_access_alter() (Implements hook_query_TAG_alter()) because of Issue #1857656, so the patch in #69 is out of date.

Can I get a reroll? The changes should show up in the dev branch shortly.

DuaelFr’s picture

cannandev’s picture

Will this patch be included as a Recommended Release?

5kot’s picture

#76 worked for me. Thanks guys!

brettbirschbach’s picture

#76 is working great for me as well! Thank you DuaelFr!

DuaelFr’s picture

Status: Needs review » Reviewed & tested by the community

Tested on an other website in an other context and it still works well.
Time to RTBC !

Please commit and tag this in a new stable release as this is a major issue for this module.

pachabhaiya’s picture

#76 works great for me in the latest dev-version.
Thanks

TravisJohnston’s picture

Can't get this to work. Using the newest 7 dev release, applied #76 patch, and latest Override Node Options. I am using this for an HR role, that needs to be able to create, edit, publish, unpublish, and re-publish job listings.

Here are the permissions set as CHECKED for the role HR

Job Listing: Create new content
Job Listing: Edit own content
Job Listing: Edit any content
Job Listing: Delete own content
Job Listing: Delete any content

Override Job Listing published option
Override Job Listing promote to front page option
Override Job Listing sticky option
Override Job Listing revision option
Enter Job Listing revision log entry
Override Job Listing authored on option
Override Job Listing authored by option

Job Listing: View any unpublished content

I've also tried without the Override settings, but still when I log in with an HR user, I can't see any unpublished. Cleared Caches.

*EDIT: I can see my OWN unpublished Job Listings, but no one else's.

TravisJohnston’s picture

Oh wait, ... It works. Only for all nodes that are saved AFTER this is configured. So previously unpublished Job Listings still do not show unless I use either an admin account to edit and save them or use a direct edit link and save them with the HR role.

Ronino’s picture

TravisJohnston, you might need to rebuild permissions at /admin/content/node-settings/rebuild.

TravisJohnston’s picture

Thanks Ronino, that did it!

And just for reference, in D7 it's located at /admin/reports/status/rebuild

Ronino’s picture

TravisJohnston wrote:

Thanks Ronino, that did it!

And just for reference, in D7 it's located at /admin/reports/status/rebuild

Ah, thanks for the information. I just looked up the path on the web as the page is not linked anywhere if Drupal thinks there is nothing to rebuild ;-)

Leeteq’s picture

Is this ready to be committed to -dev?

dan3h’s picture

It works for me, but I noticed a new problem, which I suspect was brought on by this fix: You can no longer filter by "published" or "not published", at the page "admin/content".

(Not for site-admins, but for users who are seeing unpublished content due to the view_unpublished module.)

Leeteq’s picture

#88: That should be possible to (at least temporarily) work around using the https://www.drupal.org/project/admin_views module, I guess, which I am using anyway. (It takes over the content overview page, allowing customizations like more/other columns, exposed filters, etc.)

thedigitalnative’s picture

I just tested the 7.x-1.x-dev from 2014-Apr-11 on Drupal 7 an want to let you know that we at Digitalcourage.de still experiencing the issue. This problem is influencing our work negatively since some time. The issue is known since on June 2011 but still has not been fixed. Please work on a fix that is available at least in the dev branch soon. (Sorry, I did not hat time to read everything above)

DuaelFr’s picture

The patch in #76 is RTBC.
You can try to contact the module maintainer to propose him to fund his work on this or you can add this patch to your own websites as explained here.

  • entendu committed 3b430b6 on 7.x-1.x authored by DuaelFr
    Issue #1192074 by mesr01, Matt V., DuaelFr, et. al.: Respect...
entendu’s picture

Status: Reviewed & tested by the community » Closed (fixed)

Thanks for the hard work, everyone. Rolled a new 7.x-1.2 release today.