Views permissions

// 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?

https://wtools.io/paste-code/bPX9

the Krumo dump of denied perms

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.

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.