Hi everyone
I've looked everywhere and cannot appear to find an answer to a problem I have and was hoping that someone might be able to advise.
To cut a long story short Profile2 permissions do not appear to be working properly whereby if you want a certain profile to exclude an authenticated user from being able to 'edit' the profile and only 'view' this is not possible (basically permissions only appear to work for Admin) - [for those that are interested please see http://drupal.org/node/1954290]
With this in mind I'm trying to figure out a way in which I can get around this with a Rule to fire on the basis of:
1) If a user clicks on the 'edit' link of profile X (for instance) they are presented with a 'you can't do that' screen message and are then redirected back to the standard 'view' page.
I've tried a lot of things and certainly know how to achieve the last 2 requirements (screen message and re-direction) but for the life of me I cannot work out if there's a way to confirm whether the user has clicked the 'edit' button of an entity (in this case the profile).
If anyone has any ideas I'd be very pleased to hear them.
Thank you
Stephen
PS If there is a solution it would helpful to know if this could also be applied to a node i.e. have they clicked node edit.
Comments
Please note that I have
Please note that I have managed to use 'text comparison' in the Rules conditions (with event 'profile viewed') to assess a URL however even though I get the 'text comparison' to see 'profile-name/[profile2:user:uid]' it won't appear to work if I use 'profile-name/[profile2:user:uid]/edit'.
Does anyone know why or how to get around this?
I've realised that
I've realised that 'profile-name/[profile2:user:uid]/edit' will only work if the Event is 'before saving a profile'. I'm assuming it won't work on Event 'Profile Viewed' because it reacting on a 'view' and not 'edit'. However the issue is still that the page will only redirect on 'saving' the edit page which by then is too late (I still want them be redirected as soon as they hit the 'edit' button).
Current Rule export is:
{ "rules_stop_authenticated_users_from_editing_their_survey_profile" : {
"LABEL" : "Stop authenticated users from editing their survey profiles",
"PLUGIN" : "reaction rule",
"TAGS" : [ "profile2", "profiles", "survey", "survey profiles" ],
"REQUIRES" : [ "rules", "profile2" ],
"ON" : [ "profile2_presave" ],
"IF" : [
{ "entity_is_of_type" : {
"entity" : [ "profile2:user:profile-live-surveys" ],
"type" : "profile2"
}
},
{ "AND" : [ ] },
{ "text_matches" : {
"text" : [ "site:current-page:path" ],
"match" : "profile-live_surveys\u002F[profile2:user:uid]\u002Fedit"
}
}
],
"DO" : [
{ "drupal_message" : { "message" : "Oy.... you shouldn\u0027t be in the edit page!!!" } },
{ "redirect" : { "url" : "profile-my_personal_profile" } }
]
}
}
There may be a way to achieve
There may be a way to achieve this with rules, but my first inclination to solving this would be one of two methods:
1: Implement hook_form_alter for the profile form at which point you'll have the $user object and can run whatever tests you need to see if the current user has permission to edit their profile. If not, you can do a drupal_set_message("You can't do that") followed by a drupal_goto("redirect_page").
2: (My preference) Implement hook_menu_alter for the profile edit form path. You can add your own access callback in addition to the default one that will be called before the default one. Do your tests for the current user having permission to access the edit page, and if they don't, return FALSE in your callback. This will not only disallow them from editing their profile, it will also prevent the menu link from even being displayed if they don't have permission. If your custom access callback allows the current user to view the menu item, then you can return the original access callback provided by the profile module to keep the existing access logic.
Hopefully that makes sense, or maybe someone else has done what you want with rules and they'll chime in too.
Good luck
Thanks again for your input
Thanks again for your input on this. It appears I always seem to run into some erroneous issue every time I think I've nearly completed a task! ;)
Admittedly I'm not much of a coder so again I'm going to have look into this to fully understand it. However, I wondering if point (2) will work on the basis that Profile2 appears not to be following the permissions that are set in the first place hence the original problem.
Thanks again :)