I was investigating why I had a role that permissions to create/edit/delete content profiles could NOT create content profiles on behalf of other users. I started digging into the code, and it seems the problem exists in at least two places.

==========

One place is the access callback 'content_profile_page_access'. This callback is what allows users to edit a content profile from the user's Edit tab (look at the menu alter above the function). It first checks to see if the content profile already exists for the user. If it does, then returns if the logged in user has permission to update it.

However, for new content profiles, it checks to see if the logged in user matches the users profile id (a user trying to create their own profile) OR if the logged in user has administer nodes permission. This is wrong, it should instead check to see if the logged in user has create permission for the specific content type of the content profile.

==========

The second place is what determines if the link to "Create user's content profile" shows up on the users page or not. This is because of a similar problem as above...

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

The last condition group isn't needed. If the user has access to create the content profile (first check in the if), then why do we need that last check at all? I just removed it.

==========

Patch coming. Please review and let me know if I missed anything.

CommentFileSizeAuthor
#1 incorrect_logic-1257614.patch1.24 KBbkosborne
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bkosborne’s picture

bkosborne’s picture

Ahh I believe re: my first logic change, that it may have originally been implemented that way to prevent other users from creating content profiles for profiles that don't belong to them (or if they can administer content).

Something needs to change here still....