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
Comment #1
zserno CreditAttribution: zserno commentedMarking as CNR.
Comment #2
zserno CreditAttribution: zserno commentedAnd the patch...
Comment #3
Denes.Szabo CreditAttribution: Denes.Szabo commentedI applied your patch and tested it. It seems to work.
Comment #4
fago+ $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.
Comment #5
tedfordgif CreditAttribution: tedfordgif commentedHere's an updated patch to address comments in #4
Comment #6
zserno CreditAttribution: zserno commentedTook a quick look at it, looks good. Will test it soon.
Thanks!
Comment #7
zserno CreditAttribution: zserno commentedComment #8
michellezeedru CreditAttribution: michellezeedru commentedThanks 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!
Comment #9
fagosee above?
Comment #10
noemed7 CreditAttribution: noemed7 commentedUsing 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
Comment #11
fagoComment #12
vstmusic CreditAttribution: vstmusic commented+1 really useful feature !!
Comment #13
Matthew Davidson CreditAttribution: Matthew Davidson commentedI think this slight modification fixes the issues at #8 above. Can't duplicate the symptoms reported at #10.
Comment #14
bcmiller0 CreditAttribution: bcmiller0 commentedhere 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.
Comment #15
coreyp_1 CreditAttribution: coreyp_1 commentedI would suggest re-naming the permission to "administer content profile nodes".
"create profile for any user" is less exact, and more case-specific.
Comment #16
NikLP CreditAttribution: NikLP commentedThis 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! :)
Comment #17
NikLP CreditAttribution: NikLP commentedI 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.
Comment #18
druplicate CreditAttribution: druplicate commentedSubscribing
Comment #19
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing
Comment #20
mrfelton CreditAttribution: mrfelton commentedPatch 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.
Comment #21
mrfelton CreditAttribution: mrfelton commentedActually, 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.
Comment #22
NikLP CreditAttribution: NikLP commentedmrfelton: 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?
Comment #23
mrfelton CreditAttribution: mrfelton commented@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.
Comment #24
NikLP CreditAttribution: NikLP commentedQuite, 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 :)
Comment #25
druplicate CreditAttribution: druplicate commentedIt 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.
Comment #26
Cyberwolf CreditAttribution: Cyberwolf commentedPatch 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.
Comment #27
Cyberwolf CreditAttribution: Cyberwolf commentedNever mind my previous comment, it was caused by another module.
Comment #28
NikLP CreditAttribution: NikLP commentedCan 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!
Comment #29
NikLP CreditAttribution: NikLP commentedCan 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!
Comment #30
Cyberwolf CreditAttribution: Cyberwolf commentedI had the author text field disabled by the formfilter module, that caused the patch not to work as intended.
Comment #31
kvvnn CreditAttribution: kvvnn commented#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.
Comment #32
Chris Gillis CreditAttribution: Chris Gillis commented#13 is also working for me. Thank you very much Matthew. I'm interested in seeing this committed.
Comment #33
Encarte CreditAttribution: Encarte commentedsubscribe
Comment #34
NikLP CreditAttribution: NikLP commentedI 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! ;) ]
Comment #35
fagoMakes 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.
Wrong comment.
Also I think we should add an update routine that assigns the permission to all roles that have administer nodes.
Comment #36
Matthew Davidson CreditAttribution: Matthew Davidson commentedThe attached merges the patches at #13 and #14, plus the above suggestions.
Comment #37
aschiwi CreditAttribution: aschiwi commentedI 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 :)
Comment #38
marcdecaluwe CreditAttribution: marcdecaluwe commentedsubscribing
Comment #39
GlitchFreak CreditAttribution: GlitchFreak commentedSubscribing
Comment #40
tim.plunkettCode 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.Comment #41
Ron Williams CreditAttribution: Ron Williams commentedPatch #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?
Comment #42
tim.plunkett@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".
Comment #43
fagoReviewing the patch #36:
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?
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.
Why that array_merge() trickery? A $form['#submit'][] = 'callback'; should be fine too?
First off the comment is wrong, it's a permission. Then, why does the submit handler check access again? That's not needed.
Comment #44
blakehall CreditAttribution: blakehall commentedsubscribe.
Interested in this patch as a dependency for #571660: Creating profile with the user creation
Comment #45
havran CreditAttribution: havran commentedsubscribe
Comment #46
ashhishhh CreditAttribution: ashhishhh commentedTo Stop redirection to current user profile page,
Comment #47
sgerbino CreditAttribution: sgerbino commentedI'm now using patch #13, looking forward to seeing this get committed
Comment #48
Dubs CreditAttribution: Dubs commented+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.
Comment #49
sarhansg CreditAttribution: sarhansg commented#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?
Comment #50
jvieille CreditAttribution: jvieille commentedThe 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.
Comment #52
greg.1.anderson CreditAttribution: greg.1.anderson commentedHere 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.
Comment #53
greg.1.anderson CreditAttribution: greg.1.anderson commentedI have deployed #52 to production, and it is working fine.
Comment #54
smartsystems160 CreditAttribution: smartsystems160 commentedPatch 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.
Comment #55
greg.1.anderson CreditAttribution: greg.1.anderson commented#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?
Comment #56
smartsystems160 CreditAttribution: smartsystems160 commentedActually 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.
Comment #57
m.stentaRe-rolled patch from #52. Changes:
$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).