Restrict profile2 type per roles

+1 for this feature.

+1 This would be extremely useful. Any workaround at the moment?

@Bob Newby

You can accomplish what you are looking to do with the Field Permissions module. After installing it, select custom permissions for each field and select the role you wish.

Hope this helps.

I post this issue, because I've tried Field Permissions and the result is not good enough. You can confirme this with my report. If is not clear, let me know that. I'll try to explain a little more. Thanks.

I'm experimenting some frustration with Profile2.
I'm using Profile2 on Drupal7 combined with profile2 Registration path and Filter permissions.
In next lines, I explain my installation and problem related.

First step: Creation of 3 profiles
I've created 3 different profiles to associate to 3 user groups. Each profile type shares some fields (e.g real name) and has also specific fields.

Second step: Assign each profile to a user group
Using Profile2 Path registration, I've related each profile with 3 different user groups.

Third step: Edition of permissions
Then I edited permissions. Each group/ profile can edit it's own profile, but a special profile (staff profile) must also edit any profile, if necessary.
And is there the problem.
When I login and edit the 2 normal profiles, I only see one tab editing profile.
But when I'm logged with "staff" profile, I can see in my profile page 3 editing tabs (profiles 1, 2 and 3). However, staff is related to profile 3.
The same occurs when I visit other user profiles types.
I expected to have access to edit tab profile of this profile type, not all profile types tabs.

How can I hide tab editing profile not related to the profile viewed? I want to avoid errors.

Thanks in advance for all kind of help,
cláudia

Claudia,

Can you share a screenshot of the roles you have created for each profile type? Also, please share a screenshot of your permissions .

Thanks

Hi oystercrackher,

Sorry, sorry for the lack of feedback. I've not been notified and the project related to this issue was canceled.
Meanwhile I've not discovered the solution. But I still curious about, so I'll try to explain with more details and screenshots like you suggested.

Img1 - Profiles types
You have: formador, formando, staff

Img2 - Assign each profile to a user group on users/people edit account
This is Drupal normal association user/ role on user account

Img3 - Permissions on field permissions
I'm using field permissions but I think it's not related.
Tabs presentation on user account editing is controled by Profile2.
On the image, you can see an example of a field type repeated on all profile types: Nome completo (Real name)

Img4 - Permissions on Profile2
Staff can edit any profile from formando and formador.
Formador only can see formando profile.

Img5 - Staff user edits own account
This image shows what happens when a staff user edit own profile.
There are 3 tabs on his account - 3 profile types that he can edit. I expected only his profile, because he is editing his account.

user/5/edit (OK)
user/5/edit/user_formador
user/5/edit/user_formando
user/5/edit/user_staff (OK)

Img6 - Staff user edits an account from a formador type
user/2/edit (OK)
user/2/edit/user_formador (OK)
user/2/edit/user_formando

Img7 - Formador edit own account
user/2/edit (OK)
user/2/edit/user_formador (OK)

Img8 - Formador view formando profile
user/28 (OK)

Like you can see, all permissions work well.
The problem are the tabs on user/%/edit. The criteria is based on profiles that current user can edit (Edit any profile on permissions Profile2) and not based on the users's account profile viewed.
It represents a problem because when you open a tab from other profile, there are default values or fields required and it can generate errors, because a unique user is associated to different profiles.
Also, it's confusing for people that has permissions to edit any profile type.

I don't see a good way to filtering the correct tab editing profile based on users account viewed.

If you can help, it will be great.

Thanks
cláudia

That feature was very important in content profile, and cannot be replaced with the permissions because it´s not the same to "assign a profile to a specific user role" than to simply permit a specific role to view or edit a certain type of profile.

Example:
I´m the administrator and want to have a profile field "payment" inside the role "student" that I don´t want the students to access in any way, but I still need to fill in and keep track of it.

That case scenario you can fullfill now with Profile2, but its different if you want that field to be inside a profile type that you want to only be assigned to "professor" role.

Field permissions is fine if you only have a few fields, but when you have something that has 3 different profiles and 7 fields per profile. That is 21 separate permissions that have to be set.

Field permissions is fine if you only have a few fields, but when you have something that has 3 different profiles and 7 fields per profile. That is 21 separate permissions that have to be set.

hear hear!

You have a point too, Bob (at #12), and I agree partially with it, but the case is that there are some people that still thinks that the old way is better or easier. Maybe we´re more comfortable with the ways we already know, or maybe we still are in the "alarmed" stage. :)

Maybe this stackexchange answer could help someone develop a patch or module to accomplish Role <=> Profile2 mapping ?

I'm also stuck on this problem and can't find a solution. I want Teacher roles with a Teacher profile to be able to edit any Student roles' Student profiles. But I don't want them to see themselves having a student profile on their own profile page.

If you are using tabs you can try this.
It checks each profile type to see if the user being viewed has 'Edit own profile' permissions. Then removes the tab if the user doesn't.

/*
 * Implements hook_menu_local_tasks_alter()
 */
function mymodule_menu_local_tasks_alter(&$data, $router_item, $root_path) {
  $path = $router_item['path'];
  
  // check that we are at one of the pages we want
  if (strpos($path, 'user/%/edit') !== FALSE) {
  
    $user = $router_item['page_arguments'][1];
    $item_array = $data['tabs'][1]['output'];
    
    foreach ($item_array as $key => $item) {
    
      $path = $item['#link']['path'];
      $path_end = str_replace("user/%/edit/", "", $path);     
      if ($path_end != 'account') {     
        // remove the tab if 'Edit own profile' permission is not set for this user
        $access_string = 'edit own ' . $path_end . ' profile';
        $has_access = user_access($access_string, $user);
        if (!($has_access)) {
          unset($data['tabs'][1]['output'][$key]);
        }       
      }     
 
    } 	

  }
}

Thanks! It´s a good idea!

While the permissions do work as expected, the problem that my client had (and possibly others) is that if you have one of the 'Edit any profile' permissions then you will see the Profile on any user, regardless of whether that use is in a role that has permission to have said profile.

Example: Admin isn't supposed to have 'Personal profile', but admin has permission 'Personal profile: Edit any profile', therefore when admin is on own user edit page the 'Personal profile' tab will appear even though that user/role isn't supposed to have that profile.

While the solution Kionn posted is acceptable, it does highlight that maybe this functionality could be implemented directly in the module itself instead of people have to implement a workaround.

I propose (and will shortly be rolling a patch to do so) that in addition to the already confirmed working permissions that each Profile could also have an allowed Roles checkboxes setting so that even if a Role has the permission to 'Edit any profile', if they don't have a Profile type assigned to their current permissions they won't see the tab on their own user edit page.

Patch attached does exactly what I proposed.

I haven't tested the Simpletests yet due to the configuration of my environment, but I will try to do so and make any fixes (if required) at some point in the future.

Patch #22 works perfectly fine. Let's commit this. It's pretty useful.

@cursor,

If you have reviewed the patch and you think it's ready to be committed, please change the status of the issue to 'Reviewed & tested by the community'.

Thanks :)

Patch #22 works like a charm! Thanks, dude.

Let's commit this. It's a great feature and significantly enhances Profile2

Use Profile2 Role Restriction

https://drupal.org/sandbox/rsvirani/2046785

It would be better to have the patch included instead of adding a new module. RTBC++

I've tested the patch in #22 and it works great. Really improves the module.

Shai Gluskin

The Patch #22 ist really Good Stuff. A Great and a Good Feature. Thanks for it!

Just an fyi profile2_one_page doesn't play nice with this setting but I guess that makes sense since it is in a patch :) If we can get this committed, then someone can patch that one :)

I don't think that embedding roles into the profile type object is the right way to go about this. We are generally moving away from that pattern in Drupal.

I think the better pattern would be to add permissions along the lines of 'Own a profile of type Foobar'.

It would be really helpful if the summary could be updated. In particular, an explanation of why the current permissions are not sufficient would be good.

#22 Worked for me too!
Thanks!!!

Hello,

the patch #22 is a great feature !!!
Do you include this new feature in the next version of this module?

Thanks.

Patch #22 worked for me too.
It helped a lot.

Thanks

I applied Patch #22 and it did limit the tabs to that of the user under inspection (when viewed by an admin role).

However, the profile that the user has but can't view or edit (only admin is supposed to be able to access it) does not appear even to the admin user (user 1). Or is this a separate matter (not addressed in Patch #22)?

The case is something like #11 Rosamunda's, where there are several user profiles connected to different user roles (3 membership types). Then there's a profile that holds all administrative fields that only staff should be able to see.

The Roles set for this Administrative profile using Patch #22 is all 3 membership types, while the view and edit Permissions set to this profile is only the Member Manager and Administrator. With this setting, even Member Manager and Administrator doesn't see the Administrative fields (this is not what we want). Or am I missing something?

Patch doesn't seem to be working as menu item is not showing although profile is assigned to role.

update: I still can't get whether this patch is for

attaching a profile to role , making only available to particular role
or
is it about permission, like who can view/edit this profile.

On settings page instead of just "Roles", it could be made something more informative like , "select role to which profile should be attached" or "select which role can have access to this profile".

by further checking it is found out that

1. "xxxx : Edit own profile" and "xxxx : View own profile" has to be checked under permissions page, so that menu item can be displayed.

2. regardless of role settings,ie if none are selected, menu item is still displayed under user block if (1) is true.

3. when link is visited then it lead to access denied error page.

4. if particular role is checked under profile2 settings, then profile page is accessible.

I see the problem with permissions, but how would this work together with permissions?

Patch #22 works for me with no problem Thanks Mr

@fago, do we need this permission-based restriction? I think that configuration in settings form is enough to restict access to a profile types based on user role.

Problem/Motivation

1. Create 2 or more profile types
2. Assign each profile to a role
3. Edit permissions
- Each group/role can edit it's own profile, but a special profile (staff profile) can edit any profile.

And here we have the problem.
When I login and edit the with a normal role (non-staff) profiles, I only see one profile tab.
But when I'm logged with "staff" profile, I can see in my profile page a tab for each profile, even if staff is supposed to have one profile type.
The same occurs when I visit the edit account page of users having other roles.

Expected behavior is to see only the profile available for that role and not all the profile types I can edit.

Proposed resolution

Possible solutions:

1. Add an option to the profile type page to select the roles that can have the profile tab. Patch for this is available in #22.
- advantages: who can add/edit profile types can also change the roles allowed to have a profile type

2. Add a new permission "has $profile_type profile"
- advantages: more in line with the direction Drupal moves in
-disadvantages: only users with "edit permission" permission can assign profile types to role. And that permission is (or at least it should be) restricted only to admins of the site.

3. Use a combination of permissions and field access permissions.
- disadvantages: hard to maintain and still with enough permissions you can see profile type tabs on pages of users who shouldn't have that profile type.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

If first solution is implemented a list of checkboxes on the profile type edit page.
If the 2nd solution is implemented a new permission for profile2 in the permissions page.

Original report by @alexweber

For each type, we can specify what user roles are allowed to have a profile.

Just wondering whether this will be a feature or whether we should control this ourselves using permissions and rules or something?

A patch for the 2nd proposed solution.

@joachim I don't know the reasoning behind this. But adding this in permissions limits the users on a site who can assign profiles to roles. Like this only people with "edit permissions" permission will be able to assign profile types to roles. And that permission should be given to only a few trusted users.

Add the new permission to the test.

tested and worked well for me!
thanks!

Why can't you set permissions "Edit own $type_name profile" and "view own $type_name profile" ? What the benefit of creation another access that is doing the same?

@Spleshka,

The issue, when I had to deal with it, was that it granted admins who had the ability to edit others profiles also the ability to edit that same profile type on their own user even though they weren't supposed to have that type of profile themselves.

New patch based on the patch #22 with some improvements in profile form:

• Roles field description is added
• Anonymous role is excluded from the roles list
• All roles are pre-selected by default

Thanks @Alex Bukach, @Deciphered and other guys for patches/support. After a long discussion about right way to go, we agreed that patch from #22 fits our needs best, because it has more end-user clear UX, but it is still needs some love. Now I am glad that we finally commited this.

54: profile2-roles-1593230-54.patch queued for re-testing.

Will committed patch solves the problem I mentioned in #40,#41 or shall have to create another issue if it is not related to this thread?

If we want this functionality, should we use 7.x-1.x-dev?

@nithinkolekar, please open a separate issue if this problem is still exists.

@matt.rad, yes.

@jotHA, why have you changed issue status? It is currently solved.

@Spleshka: Works like a charm. Thanks!