Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Giving this privilege administrator grants modification rights to any node visible to user. Also form became overloaded with useless and dangerous controls. We need only create other user's content profiles without administer nodes permission.
Comment | File | Size | Author |
---|---|---|---|
#7 | content_profile-administer_users.patch | 471 bytes | e5sego |
Comments
Comment #1
fagoYep, thats how the permissions from drupal are. I don't think this module should try to change that, however you might workaround it by using:
* a user-reference field for selecting the author
* field permissions for granting access to it
* a rule (with rules module) which set the node author to the selected user.
Comment #2
raintonr CreditAttribution: raintonr commentedI just found this bug too. Sorry, but how can you say it's by design?
I notice a problem
content_profile_nodeapi
thatuser_access('administer nodes')
is being checked.I have given the 'user admin' role on our site the permission to create/edit all/delete all the content profile types but when they try and create the node for users they are re-directed to their own profile type node edit page. If nothing more this is a problem as it should show an 'access denied' message.
We also have override_node_options in use on the site and have specified that this user can change the 'authored by' for the content profile type nodes but of course that has no effect given the above check.
Instead of doing a global check for 'administer nodes' surely a check on the ability to create profile type nodes should be done?
FWIW, if users already have the node profile page created (done with the super user for example) 'user admin' role can edit them just fine as you would expect.
Comment #3
sammys CreditAttribution: sammys commentedI've used this module on three sites in the past couple months. I do believe there is a problem with the permissions though it's a little more complex than reported in this thread. I'll try to summarize to give maintainers some clue into what's wrong with it.
Let's start with the users. They need to be able to create/edit/delete content_profile nodes according to the node module permissions. I.e 'create content', 'edit own content' and 'delete own content'. This does not work in the current release. The user does not see the tabs even when they have permission to create that type of content.
An administrator can see a tab for each content_profile type on every user's profile page regardless of the permissions for the users themselves. This, most certainly, does not make sense.
Ideally it would be possible to use tabs, links or both. It's quite possible to do this and I can write the patch if maintainer(s) agree with it. I'd create a tab for adding the profile node and editing the profile node and fix content_profile_page_access() so it does permissions as discussed above.
Comment #4
eliza411 CreditAttribution: eliza411 commentedFor what it's worth, I agree that administer nodes is too cumbersome a permission to be required for the creation of user profiles on behalf of others. Either administer users or a module specific 'create profiles for all users' sort of check seems much more in order for sites where users are employees and their records are less-often created and maintained by the users themselves.
Comment #5
Encarte CreditAttribution: Encarte commentedIt would be useful (don't know if it possible) if there where some kind of permission (in each node profile type) like this: Roles who can create this kind of nodes besides the node author.
Comment #6
fagoNo way for content profile to change this. You can use a module like content access to have more control about the permissions.
Comment #7
e5sego CreditAttribution: e5sego commentedFor me it makes more sense if the "administer users" permission is checked on creating content profiles for others.
Attached the patch for it.
Comment #8
Cyberwolf CreditAttribution: Cyberwolf commentedI also agree that the requirement of the "administer nodes" permission goes a bit too far. Giving that permission also enables editing the revision and publication options, which you might not want to expose. Checking the "administer users" permission instead sounds like a good idea.
It does not seem to work properly though without the "administer nodes" permission. When I create another user's profile, the uid of that node is set to the uid of the currently logged in user. Probably there is some code in drupal core, that sets the uid to the id of the currently logged in user when the "authoring information" field set is not available (which is only there when the current user has the "administer nodes" permission).
http://drupal.org/node/611068 seems to provide a solution for this, according to its description. But to me the solution does not seem to be a clean one at all:
This code seems to add a new requirement to the profile nodes: their name needs to match the user login name. I don't think that will be a flexible situation either.
Comment #9
Cyberwolf CreditAttribution: Cyberwolf commentedNever mind my remarks about the patch. $node->name apparently refers to the name of the user with id $node->uid. It gets loaded into $node by node_load().
Comment #10
FiNeX CreditAttribution: FiNeX commentedIsn't possible to add a perm which allow a specific role to create node profiles?
Comment #11
FiNeX CreditAttribution: FiNeX commentedWhat about #10 ?
Comment #12
muhleder CreditAttribution: muhleder commentedGot to admit I'd love to see this fixed as well. Have to hack the module on every site I use it on.
'Administer nodes' is an awful permission (from a UX perspective) to give content editors as they end up with all sorts of confusing options that they don't need to know about when editing/creating a node.
Comment #13
zserno CreditAttribution: zserno commentedFYI: just submitted a patch as a new issue: #697856: Introduce new permission: 'administer content profiles'
Please take a look at it.
Comment #14
mrfelton CreditAttribution: mrfelton commentedYep, this one hit me to.
Comment #15
kvvnn CreditAttribution: kvvnn commentedUsers: go to http://drupal.org/node/697856 for updated patch and information.
This is a good patch. Thanks.