Access control to create parents or childs requires edit access rights for users!
jochend - November 2, 2006 - 13:45
| Project: | Node Relativity |
| Version: | 5.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Omar |
| Status: | needs work |
Description
Hello,
I just realized that users need full edit rights for node to create new attached parent or child nodes.
Shouldn´t there be a way that other users create related nodes, without having the right to edit the node?
Thanks
Cheers,
Jochen
#1
#2
what about inroducing new access permissions for "updating relationships" for each content type
#3
The current relativity check (if $user == $author) the author (with Create & Edit Own #ParentType permissions in Access Control) is allowed:
However a #UserRole (with 'Edit #ParentType content' permission in Access Control) is allowed:
Please could someone verify this ?
@#1 Omar's patch allows (and please correct if I've misunderstood) a parent node type (eg 'question' node type) to adopt child nodes of another specific type (eg 'answer' node type) created by any $user with the 'create answer' permission. Thus the $author has full edit rights over the question but any other $user is able to submit an answer which is automatically attached to the parent question. This behaviour is comparable to drupal's native node / comment relationship (but of course allows greater workflow flexibility). I assume that only the $author of the question is able to 'Remove' an answer from their question?
@#2 Tobias, are you suggesting separate permissions for 'Edit #ParentType content' and 'Edit #ParentType children' ? IMO the list of a node's children is part of it's content ... ? (As if my Access Control table wasn't bloated enough ;)
#4
not sure if this is in the same vain as this thread.. but pretty close.
i think the discussion here and the patch are only very limited solutions to the real issue with this???
there should be control of the following:
you should be able to set:
- whether a user can add a child if they are not the owner of the parent
From the sound of this thread that is the default case and this patch is removing that... but i don't think this is really the default case. All the module does (which i think is incorrect) and what this patch fixes (which is also limited) is control of the link that shows up for adding children. There doesnt seem to be any control on limiting a user from simply entering node/add/mytype/parent/123 on the url???
or at least not as far as i can see.
the code that is mentioned here (and for some reason removed with the patch) seems to do the right thing... i.e. check if user owns parent.. but it does it at the wrong place... it shouldn't be to determine if the link should be added but it should be to determine of the node can be added.
not exactly sure of the best way to do this but i suspect that:
- default code should only allow children if parent allows edits (either for "own" or for "role") via access control for the parent type
- and then there likely needs to be admin/relativity/settings to disable this for the case where you want to allow other users to add children
also, would be nice.. and in a similar vain to
- limit the number of children that a user can add to a parent of theirs independent of how many children can be added (by users in general) - in other words would be nice to allow only one child per user.
at the moment i will fix all of these with nodeapi hooks outside of the rel module.. but certainly the first 2 items seem like "bugs" to me.. and the 3rd would be a feature request.
#5
User A creates a course (parent node) and users B and C should be able to register seats (children). Does the patch allow this? I don't want B and C to be able to modify A's course, or each other's registration.
Thanx in advance.
#6
@ #5 keysar7: Yes it does allow this. You may also be interested in the signup module ( http://drupal.org/project/signup ) which might be a better solution for the course/seat example but not for the auction/bid example ... :)
#7
I generally would like to see a better permission system for relativity but I would like also to see relativity creating its own hooks.
I suggest for starters:
- hook_relativity_attach_child() to allow other modules to allow/disallow users to attach a specific node type to a specific parent node type.
I will roll a module very soon to allow integration between workflow and relativity via which you can specify at which workflow state which user role can attach a specific child, I could have never done that unless relativity "listens" to other modules in the scope of permissions for example.
Relativity is a gate for other modules not the end of the story for me. So I think I will keep extending relativity as far as I and it can reach.
#8
This small patch (which can be applied on a clean 5.x-1.x-dev relativity.module file) will allow other modules to "talk" to relativity about showing links to create/remove children.
#9
Thanks for your contributions, Omar. Once I am back next week, I'll start applying some patches to the development version of relativity. A new issue for this small patch would be nice, too, please. Thanks,
Darius
#10
I have encountered a problem...
But first, thanks go to Omar and Darius for their continued ingenuity.
I have a CCK parent node that is also an OG homepage. Naturally, users unsubscribed to the Organic Group should not be able to create a child node for the OG homepage, but they can. Even after applying patch5.
Any ideas? Am I right in thinking that the patch is supposed to stop this?
#11
again, i would like to stress that these patches for limiting who can add children are not the correct way to do this.. simply turning the links on or off is not a secure/reliable way to support the existing or additional ordinality rules.
Currently the relativity module allows admin to set number of children of a specific parent type - but this doesnt work!! (I guess i should raise it as a bug). It simply removes the link - again nothing stopiing someone from entering /node/add/mytype/parent/12 as many times as they like as the url.
I think either a menu hook or formalter hook is required (menu hook will simply give "Access denied"; whereas formalter could create error msg and return to last page.
#12
According to:
if (!$may_cache) {if (arg(0) == 'node' && arg(1) == 'add' && array_key_exists(arg(2),relativity_node_list()) && arg(3) == 'parent' && is_numeric(arg(4))) {
// this is my crafty way of creating new nodes as children of parents, and
// not displaying any links to create them otherwise.
$_GET['parent_node'] = arg(4);
$items[] = array('path' => 'node/add/'. arg(2).'/parent/'.arg(4), 'title' => t('create content'),
'callback' => 'node_add',
'callback arguments' => array(arg(2)),
'access' => node_access('create', arg(2)),
'type' => MENU_CALLBACK,
'weight' => 1
);
}
I think that the patch is working fine since the menu hook also checks only for create permission on child node without the extra check for update on parent node. So ptalindstrom, it's not just about hiding a link.
What I introduced in http://drupal.org/node/92552#comment-219398 is a different approach and should go in a different issue which is introducing a hook to other modules to allow the show/hide of the link and thus ptalindstrom idea is totally right, it's not just about hiding/showing the link. Some more work is required in the hook_menu().
#13
About permissions, I want add a voice for this use case:
1. content creators must create a parent 1st, and then children.
2. creating child nodes by themselves would not be allowed.
3. 'remove' relativity links should be an option, configurable, so I don't have to comment them out, hehe.
4. content types used as a child, would not show on the 'create content page' because they are not a parent type
4.1 would need permission to create the content type and it be a parent type to show here.
John
#14
I see now that comment #11 makes more sense: it's not about "hiding" the link. We need something based on node permissions.
#15
Is there a way to do the same like this patch does for the 6.x-Version ?
#16
#465798: Permissions patch seems to do exactly that.