I'm having difficulty with a particular View of a content type, where the lower-privileged staff user can access and edit the draft content if given the URL directly, but when dealing with a View that collates all of those that are Draft, the staff member cannot see the list. As though there are extra perms being set in the View than is what is in the rest of the system. The View's perms are "Administer Content", I have also tried setting to Role, and choosing the appropriate roles, without any difference.  The staff member can access the view , but one of the exposed filters is the Published:Yes/No. If published=Yes, they get the table. Published=No they get the Zero Results global text.

Accepted answer

Found it by doing a diff against the working managers.

Bypass node access. Set TRUE for the team allows the views to work properly. Which suggests that Views has a different way of checking access perms from the regular node access, as these nodes were viewable/editable directly.

Most helpful answers

I'm glad you found it! It may be worth creating an issue for this. What did you have in the Views' display's "Access" field before? A role check?

Did some light testing, and can't reproduce the problem. I gave "Authenticated" the permission above (View any unpublished content). I accessed the view from that user, and it does show the unpublished node:

Comments

Have you given these users the "View any unpublished content" permission?

(Unrelated: WOW! That's a LOT of Displays for a single view. That will make the json file huge. You may consider splitting those into separate ones) 

Yes. VHB Team is the one.

Agreed about the size of the json files. Will tidy it up when I have it all working. So many views...

Did some light testing, and can't reproduce the problem. I gave "Authenticated" the permission above (View any unpublished content). I accessed the view from that user, and it does show the unpublished node:

// by appending ?debug_perms=1&user=5748 (5748 being the user's UID) to the url of a content type we can determine the privileges for that user at that screen

global $user;

global $debug;

$vhbu = $user;

if(isset($_GET['debug_perms'])&& !isset($debug)){

if(isset($_GET['user'])){

if(is_numeric($_GET['user'])){

$u=$_GET['user'];

if($su = user_load($u)){

//we have a user passed by user number to the function and they load so let's use them instead

$vhbu=$su;

dpm("Switching to user:".$vhbu->uid);

}

}

}

dpm($vhbu->roles, 'user roles');

$permissions = user_permission_get_modules();

foreach ($permissions as $key=>$value) {

$has_perm = user_access($key, $vhbu);

$perms["$value:$key"] = $has_perm;

if ($has_perm) {

$perms_true["$value:$key"] = $has_perm;

} else {

$perms_false["$value:$key"] = $has_perm;

}

}

dpm($perms, 'all user permissions');

dpm($perms_true, 'granted user permissions');

dpm($perms_false, 'denied user permissions');

$debug=1; // stop the second output if there is one.

}

I added the above code to a custom module's hook_form_alter, and using that I can get the entire list of the user's perms. What I haven't found is which one is the issue! Any other clues?

Found it by doing a diff against the working managers.

Bypass node access. Set TRUE for the team allows the views to work properly. Which suggests that Views has a different way of checking access perms from the regular node access, as these nodes were viewable/editable directly.

I'm glad you found it! It may be worth creating an issue for this. What did you have in the Views' display's "Access" field before? A role check?

This is what was and is the Views access:

So I am hoping, and from tests so far can see that it is fine, that the Team members don't have access beyond what Views would normally give them.