Removing 'Edit' permission for a Profile removes the Profile from the Menu link (please note user does have View permission)

Please also note I have rebuilt permissions.

Please also note that you can view the authenticated user's page (once the edit permissions are removed and view is granted) if the user ID is entered into the URL. So for example:

http://localhost/path/path/profile-live_surveys will not work in this instance and will show a 403 page. However:

http://localhost/path/path/profile-live_surveys/352 will work and you can see the page. (But please note you can still not see the link).

I think this might need to be upgraded to priority 'major'?

Please note from further investigation there definitely appears to be something not quite right with the way Profile2 translates a URL path/token. Considering the original problem whereby it is impossible for the user to only have a 'view' tab and no 'edit' tab I tried the following (see below to redirect a user if they click the edit tab of the profile) and noticed tokens only appear to work for the Administrator and will not work for any other user.

It's a bit of work-around the way I have tried to delve into the problem but to recreate please do the following:

1. Install 'Redirect' module;
2. Create a small bespoke module to allow the 'Redirect' to use tokens. Code below:

<?php
/**
* Implements hook_redirect_alter
*/
function ste_survey_edit_redirect_redirect_alter(&$redirect){
global $user;
// Only act if user token in redirect path
if(!empty($redirect->redirect) && strpos($redirect->redirect, 'user') !== FALSE){
if(!user_is_logged_in()){
// Bounce via login back to source path
$redirect->redirect = 'user/login';
$redirect->redirect_options['query'] = array('destination' => $redirect->source);
}else{
// Apply user tokens to redirect path
$redirect->redirect = token_replace($redirect->redirect, array('user' => $user));
}
}
}

3. Create two redirects in the 'Redirect' configuration window. (1) from profile-profile_name/317/edit (where 317 can be any user ID you have) redirecting to some other page and (2) profile-live_surveys/[profile2:user:uid]/edit redirecting to some other page aswell.

You should notice that (1)'s redirection - where the user ID is specifically identified - works and redirects. However (2) does not work for any user OTHER THAN ADMIN.

Please also note in the example (2) above where the redirect works only for Administrator if you duplicate the Administrator role in permissions as expected this role does also work with example (2), however interestingly if you check the other authenticated user's access rights to mirror those of the administrators, example (2) does not work and he will not be re-directed like the administrator is (even though they have exactly the same access rights!?)

Hi Andy

I'm sure I tried this but couldn't get it to work. I'll give it another shot at some point. In the mean time I end up using 'Tab Tamer', although not a great solution basically it means I can maintain the usual permissions i.e. keep 'edit' but tell Tab Tamer to remove the 'Edit' tab for that particular page which kind of solves my issue but not very eloquently (I needed to hide 'edit' from all roles for that particular menu items, I'm not sure it would work if you needed to do it on a role basis).