I am running profile types to this function with a set $account parameter to determine which profiles are related to what types.
The function does not pass the $account variable to profile2_access on line 531:
/**
* Menu item access callback - check if a user has access to a profile category.
*/
function profile2_category_access($account, $type_name) {
// As there might be no profile yet, create a new object for being able to run
// a proper access check.
$profile = profile2_create(array('type' => $type_name, 'uid' => $account->uid));
return ($account->uid > 0 && $profile->type()->userCategory && profile2_access('edit', $profile));
}
see the difference from the above to the below on the return statement, arguments passed to profile2_access()
/**
* Menu item access callback - check if a user has access to a profile category.
*/
function profile2_category_access($account, $type_name) {
// As there might be no profile yet, create a new object for being able to run
// a proper access check.
$profile = profile2_create(array('type' => $type_name, 'uid' => $account->uid));
return ($account->uid > 0 && $profile->type()->userCategory && profile2_access('edit', $profile, $account));
}
I know it's a menu callback and this won't be often called with a different $account variable, but in a certain case where I'm altering a menu for an admin based on the viewed user, I want to do just that.
Comments
Comment #1
hitfactory commentedJust came across this today where the profile menu local tasks were showing to a user without permission to see them.
In case it helps, we're using the Me module to alias the profile edit URLs. Seems like the problem only occurs when other modules need to check access.
Attaching suggested fix above (which I can confirm works) as a patch.
Comment #2
hitfactory commentedHave since discovered the culprit was in fact the Tabs block of the Delta module which was caching the tabs with the menu items per page rather than per role so perhaps this is less bug, more feature?
Comment #3
CarstenHarnisch commentedDefinetly the patch is fine. Working on an user on the own profile will let profile2_access() use the current user. If an admin will access the profile the account should be the user of the profile data and not of the admin (which is the current user). So is makes sense to accept the patch.