Make CP role aware

hmm this is how it works for me... check in permissions. i have 4 roles and 4 different content types and you can specify what roles are allowed to create, update, delete each of the various content types.

The patch failed. Patch applied to latest, beta3 version. Wrong version perhaps?

# ls
LICENSE.txt                                            
README.txt                                             
content_profile-display-view.tpl.php    
content_profile.css                                 
content_profile.info                               
content_profile.install                            
content_profile.module                         
content_profile.panels.inc                     
content_profile.rules.inc
content_profile.rules_defaults.inc
content_profile.theme.inc
content_profile.theme_vars.inc
modules
tests
views
cp_roles_aware_1.patch

# patch <cp_roles_aware_1.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git content_profile.module content_profile.module
|index 5095ddb..575c041 100644
|--- content_profile.module
|+++ content_profile.module
--------------------------
Patching file content_profile.module using Plan A...
Hunk #1 failed at 78.
Hunk #2 failed at 267.
Hunk #3 succeeded at 602 with fuzz 2.
2 out of 3 hunks failed--saving rejects to content_profile.module.rej
done

No matter what I try it fails to patch with exactly the same error message.

I downloaded a fresh copy of content_profile-6.x-1.0-beta3.tar.gz and the patch file too.

I attached the .rej file (renamed to .txt) if that helps.

I did this on FreeBSD 6.3, but that shouldn't matter.

I finally got around to testing the patched module, but it doesn't seem to work.

When I create a new content type and look in the content profile section of the form it shows the check boxes for roles to associate with.

When I create a new user (logged in as admin) and then open the user's account, it still has choices for creating a content profile for all the roles.

If I log in as the user without permissions, there are of course no choices. If I give the role the permission to create a content profile for his role, than only that choice shows up, but I think that's the way the unpatched module works.

Am I missing something (drank an awful lot of beer last night...)?

More:

If I create a new content profile type and a new user with the corresponding role, as admin I see the old content profile types listed, but NOT the new one that's associated with the user's role, so it seems to be doing the opposite of what's it's supposed to do.

There are two other modules that create similar functionality for information added to a standard profile that might help with understanding how to accomplish the same for the content profile module:

Profile
Profile Role

I've just committed some significant improvements to the registration integration. Now this should be easier to do.

-> I think the setting of CPR itself, can stay and be interprated as "add to the default registration page". For other non-default pages I think we would just need a separate option to turn it additionally on by path.

edit: or by role depending on how AAR works.

HI All,

the last few post are a little unclear. Is it now possible to restrict content profiles to roles with the patch provided in this thread or not?

@hixster: it looks that this problem is still unresolved... :-(

I took a look at the patch in #3 and made the same changes to the content_profile.module from Content Profile 6.x-1-0-BETA4
It seemed to work, but had some unwanted side effects, so I am going back through it to see if I can figure it out.

Our use case is as follows:

2 content profile types:
- staff profile
- member profile

3 roles that concern this:
- webmaster role (able to add/edit staff profiles or member profiles)
- staff role (able to add/edit own staff profile or add/edit/delete member profiles)
- member role (able to edit own member profile)

Currently, when a user with the 'staff' role edits a user with the 'member' role, they can see the tab to create a 'staff profile' - when this 'member' should never have a 'staff' profile.

So it sounds like we are looking for the same functionality - namely the ability to restrict the user profile tabs and "Create user's profile" links to display only on user profiles who's role is associated with the profile type.

If anyone else has made progress with this, do let us know.

#18 : I'm in a similar situation, I'm trying a lot of user/role modules, but it looks that this particular use case is not solvable with the current modules and core status.

Look at:
- http://drupal.org/node/673732
- http://drupal.org/node/673760

for some ideas I've had.

Have to excuse; new to all this so not sure if I should be commenting as status is closed.

My programming skills are skant, but I've been tinkering with this this morning and may have found a couple of things related to this (sorry if this is a bit verbose).

In 'content_profile.module' on line 539 there is a line which has something to do with generating the 'create profile' links.

elseif (user_access('create '. $type .' content') && content_profile_get_settings($type, 'add_link') && !$node && ($uid == $user->uid ||     user_access('administer nodes'))) {

user_access('create '. $type .' content')

will check the logged in user's access, not the account user's access. Wouldn't

user_access('create '. $type .' content', user_load($uid))

check permissions for the account instead?

And for the edit tabs, they seem to be generated by looping through all the content types marked as content profiles. The link's access is controlled by the function 'content_profile_page_access'. If a node related to the account is found everything's good, but if not line 92 appears to check node access for either the account user or someone who has 'administer nodes' privileges.

if ($user->uid == $account->uid || user_access('administer nodes') ){

So in the case where you have a user administering someone else's profile, again, all nodes they have access to will be returned. Couldn't it be limited to the account holder's profiles by wrapping the return in a further if statement?

if (user_access('create '. $type .' content', $account)) {
      return node_access('create', $type);
    }

I tried it & it seems to work, but I've probably missed stuff. Maybe someone who knows what they're doing would be kind enough to look into it.

It's a superb module, but the aspect of allowing users to administer other users' profiles doesn't really work currently.

I'm not sure if this is a best thread since there are multiple pertaining to roles, but I would also like to see an option to restrict access and show/hide a tab based on role.

In my situation I have two roles: manager and specialist. Specialists have a "Specialties" content profile type, but mangers do not. Managers are allowed to edit the specialties of specialists, but don't have specialties of their own. This works well except "managers" are provided a "Specialties" tab of their own on each respective user account page. In other words managers are not allowed to define specialties of their own. I therefore need the ability to control the visibility and access of the "specialty" tab.

It's possible this behavior is more suited for a custom companion module instead of in Content Profile, but I would be interested in hearing from others.

I wonder why this issue was closed - it is clearly unresolved, i.e. there is still no way to restrict the admins from adding all profile types to a user of a particular role.. (at least not in here, and there is no reference to a duplicate/related issue where that is fixed).

I have to agree with arski, this issue is unresolved and still needs to be resolved.

I also believe that sukasan is right, the central problem is that the access in the menu logic checks whether or not the current user has access to create the content type, rather than whether or not the user being browsed (as defined by the URL argument) should be allowed such content as part of their profile based on role.

I believe the issue is in the content_profile_page_access function. It only does node_access checks for the current user.

Here is an alternate version of content_profile_page_access that works for the tabs:

function content_profile_page_access($type, $account) {
  if ($node = content_profile_load($type, $account->uid)) {
    return node_access('update', $node) && node_access('update', $node, $account);
  }
  // Else user may view the page when they are going to create their own profile
  // or have permission to create it for others.
  global $user;
  if ($user->uid == $account->uid || user_access('administer nodes') ){
    return node_access('create', $type) && node_access('create', $type, $account);
  }
  return FALSE;
}

As sukasan pointed out, we also need to fix content_profile_show_profiles or other users may still see inappropriate links on the profile pages. Here's a variation that incorporates that change.

function content_profile_show_profiles($uid) {
  global $user;

  $content = array();
  foreach (content_profile_get_types('names') as $type => $type_name) {
    $node = content_profile_load($type, $uid);

    if (($style = content_profile_get_settings($type, 'user_display')) && $node && node_access('view', $node)) {
      $content['content_profile_'. $type] = array(
        '#theme' => ($style == 'link') ? 'content_profile_display_link' : 'content_profile_display_view',
        '#edit_link' => content_profile_get_settings($type, 'edit_link'),
        '#uid' => $uid,
        '#style' => $style,
        '#content_type' => $type,
        '#weight' => content_profile_get_settings($type, 'weight'),
        '#suffix' => '<br />',
      );

      // Working around the bug described at http://drupal.org/node/302873
      module_load_include('inc', 'content_profile', 'content_profile.theme');
    }
    elseif (user_access('create '. $type .' content') && user_access('create '. $type .' content', user_load($uid)) && content_profile_get_settings($type, 'add_link') && !$node && ($uid == $user->uid || user_access('administer nodes'))) {
      $content['content_profile_'. $type] = array(
        '#admin' => $uid != $user->uid,
        '#theme' => 'content_profile_display_add_link',
        '#uid' => $uid,
        '#content_type' => $type,
        '#weight' => content_profile_get_settings($type, 'weight'),
        '#suffix' => '<br />',
      );
    }
  }
  if ($content) {
    $content['#prefix'] = '<p id="content-profile-view">';
    $content['#suffix'] = '</p>';
  }
  return $content;
}

Note that I've set it to check creation permission for both the user being browsed and the current user. These fixes seem to work for me. I can roll a patch if anyone else wants to try these out.

I tried this and it works, and I figured it was time I learn how to roll a patch finally, so I did.

subscribing

I expected I'd be able to select which roles have access to a content profile tab from the content profile section of the cck type, but I don't see anything like that.

Are there any plans to add the patch that fixed the admin tab issue into the latest dev release?
Manually applying sukasan's changes in #20 worked for me, the patch in #25 didn't

Subscribe

Any progress on committing the working patch?