As it's been pointed out in another issue (#425144: Other user's profile creation requires "administer content" privilege.), it would be really great to allow a group of users to create profiles for other users, too. Unfortunately, currently it's only possible using the 'administer nodes' permission, which is not very nice. (We don't necessarily want users with 'editor' role to see all the node settings.)

So I'm proposing a solution here by attaching a patch that introduces a new permission called 'create profile for users'.

In a nutshell, users with this permission will be able to access the profile creation form - even if they already have an existing profile node - and will also be able to set author of the node (hence the profile's owner) by accessing the node author field.

Diffed against HEAD, should also work with 6.x-1.0-beta4.

Comments

Status:Active» Needs review

Marking as CNR.

And the patch...

Status:Needs review» Reviewed & tested by the community

I applied your patch and tested it. It seems to work.

Status:Reviewed & tested by the community» Needs work

+ $form['#submit'] = array('content_profile_form_submit') + (array)$form['#submit'];

This would overwrite an already existing submit handler with key 0.

+ } else {

Code style violation.

"create profile for users" doesn't seem that clear to me. What's important is the ability to create it for others, right? Perhaps that should be reflected better by the permission name.

Here's an updated patch to address comments in #4

Took a quick look at it, looks good. Will test it soon.
Thanks!

Status:Needs work» Needs review

Thanks for the patch! But having problems. I applied this patch against 6.x-1.0-beta4. I see the permission available for me to set and was available to apply this permission to a role. But the role to which I added this permission still doesn't seem to have access. I'm expecting to see the same link that the admin sees on the user profile page "Create the user's profile", nor is there a "Profile" tab on the user's edit screen to create it there. Should I see it there?

Thanks!

Status:Needs review» Needs work

see above?

Title:Introduce new permission: 'create profile for users'Patch does not work properly
Category:feature» bug
Priority:Normal» Critical

Using this, when I edit a user content profile the patch updates the uid in the node table with 0 and the content profile information for that user is no longer available.

If you change it manually with the user id you can see the information again

Title:Patch does not work properlyIntroduce new permission: 'create profile for users'
Category:bug» feature
Priority:Critical» Normal

+1 really useful feature !!

Status:Needs work» Needs review
StatusFileSize
new3.66 KB

I think this slight modification fixes the issues at #8 above. Can't duplicate the symptoms reported at #10.

here is how we allowed other users to handle profiles of others in our setup by calling it 'administer content profile nodes' as a permission that could be given to someone for this purpose.

I would suggest re-naming the permission to "administer content profile nodes".

"create profile for any user" is less exact, and more case-specific.

This is a serious limitation and definitely needs addressing. It seems that we already have permissions in the system that would do the job just as adequately though? Instead of introducing new permissions, why can't we use the " can create content" ? That way we can segregate permissions when there are more than one profile types in play. Alternatively we could just remove the checks for "administer nodes" which seem to be unnecessary in any case?

Edit: I've tried bcmiller's patch and it seems to work fine. There is one issue tho - rather than simply replacing the "administer nodes" permission with the new one, it would make sense to leave the previous permission there and simply use the new one as an additional perm. It makes no sense to preclude users with the "administer nodes" permission from editing content profile nodes, after al! :)

I think there is an issue with this patch... I can't quite work out what's happening, but when I create profiles for users whilst logged in as a user that has the "administer content profile nodes" permission, the author of the node is set to the user who created the node, not the user who the profile relates to, as is the proper method.

Subscribing

Subscribing

Patch at #13 works for me. However, I have two types of content_profile nodes, each one is used for users of a different role on the site. Administrators have the permissions to create both of these content types, and with this patch, when an administrator visits the profile page of another user, he sees 2 tabs - one for each content type. I want to be able to limit the tabs that show so that only the one that is relevant to the role of this user is visible. I think this is probably out of the scope of this patch however.

Status:Needs review» Needs work

Actually, which this patch does kinda work. This is what happens.

1. Admin user creates new user
2. Admin user visits new users profile page
3. Admin user clicks the tab for the content profile node
4. Admin user fills in the form and saves te content profile node.
5. Admin user is now redirected to his own profile page

step 5 should really send the user back to the profile page of the user who he just created the profile for rather than his own profile.

mrfelton: can you attempt to confirm the bug I address in #17? I think the profiles are not correctly linked to the relevant user when created by a user that is not using the existing permissions...

Furthermore, I totally agree with your suggestion in #20, I am at this exact moment looking at a way to do this in code, and came to the queue looking for a patch when I saw this issue was updated! :) It's definitely out of scope however - I think what we need is extra config available on the node type c_p options, so that we can control visibility of tabs OR strictly tie role(s) to profile(s) type(s). Shouldn't be too hard I don't think?

@NikLP: No, for me the author of the node is set correctly. I just get redirected to the wrong place. For the problem mentioned in #20, I think it be made so that content profile nodes can be tied to specific roles only - not just a permission on the visibility of the tab. eg from my use case - If a user is in the 'client' role, they may have a 'client_profile' node. If a user is in the 'vendor' role, they may only have a 'vendor_profile' node. It should not be possible to create a vendor_profile node for anyone who is not in the vendor role. Currently, you can create any type of content_profile node for any type of user.

Quite, so in the settings for each content_profile type, we need an array of roles checkboxes, and allow for selection of possible roles that can be assigned this content type as a profile. Then just filter add/edit links etc for who can be assigned these types :)

It appears that @NikLP and @mrfelton are referring to different patches.

@NikLP is referring to #14, and @mrfelton to #13, I believe.

What is the consensus as to which patch is best?

Just want some opinion before I try either one.

Patch at #14 does not seem to work as intended, I don't seem to be able to create a profile as a user with "administer content profile nodes". I get the message "Profile has been created" but the "Create the user's Profile." is still there and none of the info I entered in edit/profile appears in that form again.

Never mind my previous comment, it was caused by another module.

Can you leave details please Cyberwolf? I have the same problem - I didn't think it was caused by another module - the side effects you describe relate to the fact that the author of the profile node in question is not set to that of the user who "owns" the profile. That would be normal behaviour for content_profile nodes.

This explains why the link appears, and also why the profile doesn't show up on the user's page. If you can offer more details, *please* leave them here!

Can you leave details please Cyberwolf? I have the same problem - I didn't think it was caused by another module - the side effects you describe relate to the fact that the author of the profile node in question is not set to that of the user who "owns" the profile. That would be normal behaviour for content_profile nodes.

This explains why the link appears, and also why the profile doesn't show up on the user's page. If you can offer more details, *please* leave them here!

I had the author text field disabled by the formfilter module, that caused the patch not to work as intended.

#13 is working for me. I am allowing a higher-permissioned administrator to create users and fill out their content profiles. The user can also edit the content profile. The admin does not have "administer nodes" enabled, but "create profiles for any user" from the patch.

------------------

#14 caused me the same issue that NikLP is reporting : The creator of another user's profile results in the creator's uid taking over said profile.

#14 also caused my site to have some very tripped out permissions issues once it was unpatched. I highly recommend using node_access_rebuild() in a php file or rebuilding your permissions some other way after unpatching.

#14 should be removed from this thread, please.

#13 is also working for me. Thank you very much Matthew. I'm interested in seeing this committed.

subscribe

Status:Needs work» Reviewed & tested by the community

I had someone else check this issue out for me and I can confirm that the patch in #13 does indeed function correctly.

[Edit: it was Stella, so you know it's ok to commit this! ;) ]

Title:Introduce new permission: 'create profile for users'Introduce new permission: 'administer content profiles'
Status:Reviewed & tested by the community» Needs work

Makes sense to me.

The permission name should probably be "administer content profiles" instead of "administer content profile nodes". Else I fear users would expect being able to do the usual administer nodes stuff too.

/**
+ * Implementation of hook_nodeapi().
+ */
+ function content_profile_perm() {

Wrong comment.

Also I think we should add an update routine that assigns the permission to all roles that have administer nodes.

Status:Needs work» Needs review
StatusFileSize
new5.11 KB

The attached merges the patches at #13 and #14, plus the above suggestions.

I admit NikLPs comment about him having Stella test it caused me to just use the patch in #13. Due to time constraints I just needed this to work and couldn't test #36 (unfortunately). #13 works like a charm though. How about committing that one, then working on the other suggestions? I promise I'll help test :)

subscribing

Subscribing

Status:Needs review» Reviewed & tested by the community

Code looks good, and it works as expected.
The patch introduces one character of trailing whitespace at the very beginning: "Give any users with 'administer nodes' permission the new ", but that shouldn't hold this up.

Patch #36 seems to remove administer nodes permissions and replaces it with "administer content profiles." We should remove an existing permissions simply because this module no longer needs them to function.

Then again, maybe I messed up somewhere. Can anyone verify whether they had the administer node permission removed?

@Ron Williams, the patch creates a new permission, and then later checks for it instead of the core permission. It will not affect the older permissions assigned to your users in any way, just assign them the new one if they had "administer users".

Status:Reviewed & tested by the community» Needs work

Reviewing the patch #36:

/**
+ * Implementation of hook_perm().
+ */
+ function content_profile_perm() {
+  return array('administer content profiles');
+}

Generally this makes sense, however the naming of the permission would suggest me that I'm able to credit/edit/delete all content-profile-nodes. However the patch does not do so and I do not see a way to do so in d6 without implementing the node access API and providing node grants, what is clearly overkill.

So, perhaps we can find a better name for the permission what implies what it does?

   // 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') ){
+  if ($user->uid == $account->uid || user_access('administer content profiles') ){
     return node_access('create', $type);

Still, with 'administer nodes' I can create profiles for others. So we need to check it too, or better replace the permission part with a node_access() check. I guess this applies to other hunks in the patch too.

+    if (user_access('administer content profiles')) {
+      $form['author']['#access'] = TRUE;
+      $form['#submit'] = array_merge(array('content_profile_form_submit'), (array)$form['#submit']);
+    }

Why that array_merge() trickery? A $form['#submit'][] = 'callback'; should be fine too?

+/**
+ * Special submit handler for users with 'administer content profiles' role.
+ */
+function content_profile_form_submit($form, &$form_state) {
+  if (user_access('administer content profiles')) {

First off the comment is wrong, it's a permission. Then, why does the submit handler check access again? That's not needed.

subscribe.

Interested in this patch as a dependency for #571660: Creating profile with the user creation

subscribe

Version:6.x-1.x-dev» 6.x-1.0

To Stop redirection to current user profile page,

if (user_access('administer content profile nodes')) {
      //$form['author']['#access'] = TRUE;
      $form['#submit'] = array_merge(array('content_profile_form_submit'), (array)$form['#submit']);
      $form['#redirect'] = arg(2) == 'profile' ? 'user/'. arg(1) : $_GET['q'];
    }

I'm now using patch #13, looking forward to seeing this get committed

+1 - I would love to see this committed too. It seems like the logical thing to do. I wouldn't want my content profile editors to be able to edit all pages on the site.

#13 does not work for me.

I have two roles - Authenticated User and Administrative User. Only the latter has the permission "create profile for any user". The former only has the permission "access user profiles" and "change own username" (under User Module).

Besides this I also have Content Permissions Module on with permissions for Authenticate User to edit some fields. Could this be a possible conflict?

Priority:Normal» Major

The proposed patch cannot be applied to the latest dev - the module looks completely different

°1 for this really missing feature
It is actually a major blocker for a normal use of this module.

Status:Needs work» Needs review
StatusFileSize
new2.85 KB
new5.7 KB

Here is an updated version of the patch #13, re-rolled on the latest 6.x-1.x and adjusted per #49: either 'administer content profiles' or 'create [profile] content' permissions will allow users to create profile content for other users. The 'administer content profiles' permission also allows access to the admin settings in the content types section.

Lightly tested; seems to work for me.

Note: Re-posted #51 due to a problem I had with the attachments the first time. Deleted the old #51 to avoid confusion.

I have deployed #52 to production, and it is working fine.

Status:Needs review» Needs work

Patch in #52 introduces a new security vulnerability which makes ordinary users without "administer content profile" permission to be able to edit the content profile of users created with the Subuser module (Note: These sub-users were not created by them). I am currently using the Subuser and Shared email modules.

I expect only user1, the parent of the sub-user, and the subuser himself to be able to edit their content profile fields, not any authenticated user who does not even have a permission to create subusers. Security vulnerability is removed when patch is reversed.

FYI: If this info is helpful or necessary, the subuser module came with a patch to the core user module to work, and the module works as designed.

FYI 2: There is also an eye on this content_profile issue to enable 2 patches at http://drupal.org/node/571660 committed to the subuser module.

#54 does not describe a security vulnerability, but rather a permissions bug. Note also that the patch in #52 intentionally gives access to edit profiles to anyone who has 'create [profile] content' permissions. Is there any chance that the modules. Is there some chance that the configuration you describe above might directly or indirectly grant this permission?

Actually from my observation, this issue only affects users created using the subuser module. After applying patch, any user who has "create profile content" and "edit own profile content" permissions is also able to edit the content profile of *any user* created by other users using the subuser module. (I mean, A can edit the content profile of C who was created by B using the subuser module). Note that the subuser module comes with its own permissions "administer subusers" and "create subusers" etc.

Status:Needs work» Needs review
StatusFileSize
new2.17 KB
new5.28 KB

Re-rolled patch from #52. Changes:

  • Fixed code in new hook_update_N(). Was giving the new 'administer content profiles' permission to users with the 'administer users' permission, rather than the 'administer nodes' permission which is what it was supposed to be doing (based on all discussion in this thread and the comment above the hook_update_N code itself).
  • Removed trailing whitespace from new hook_update_N function comment (per tim.plunkett in #40).
  • Added comment describing the content_profile_page_access() function.
  • Replace $form['#submit'] = array_merge(array('content_profile_form_submit'), (array)$form['#submit']); with $form['#submit'][] = 'content_profile_form_submit'; in content_profile_form_alter() (per fago in #43).
  • Removed extraneous permissions checks in content_profile_form_submit() (per fago in #43).