Posted by hubrt on February 9, 2006 at 7:31pm
14 followers
| Project: | Taxonomy Access Control |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Having problems with Hierarchy: Multiple, Multiple select.
Creating nodes is only possible with the parent of the term set to create. If the parent term is set to deny, the categorie window is empty (but the term is still required, if set so).
Example:
animal
- dog
-- terrier
- cat
It's possible to restrict the creation of cat nodes or terrier nodes.
It's not possible to allow the creation terrier nodes but deny the creation of animal and dog nodes ...
Comments
#1
At the moment, it is not possible. (If you dont have permission to list/create a parent term, the child terms are not listed either)
My idea would be to show the parent term (if child have 'create' permission) in node creation form, but at validation, when user select the parent term, it would give a message "You do not have permission to create node with term: ...."
At the moment, i do not have time to write the code.
Any suggestion, how it should work?
#2
hmm, had it up and running in 4.6.
showing the parent term and giving the message "You do not have permission to create node with term ..." wouldn't be too elegant, but workable ;-)
#3
Ok, but if i do not show the parent, then it will brake the tree structure.
That is (i have to check the codes), but i think
When no create right for animal and dog, it would seem like:
terrier
cat
instead of this:
animal
- dog
-- terrier
- cat
When parent is shown:
Unfortunately, i cannot change anything else w/ hook_db_rewrite, only if term is seen or not.
I cannot change color, make notes or '*' comment beside the parent term, which cannot be chosen by user when creating node. (Only i can do validation, in this case).
I am not sure which approach is better.
#4
usability wise, this approach should be better:
terrier
cat
as its usually is kind of annoying for a user to offer him a choice - and then tell him, he's not allowed to take what's on the table.
#5
Does the new form API allow for any wiggle room? By invoking form_alter, you could remove the parent term as an option and replace it with something static perhaps). I do not actually know if this is possible. But I thought I'd share.
I agree this is an irritating problem.
#6
Seems a good idea. I will check.
#7
Sadly this won't work.
I'm working on a major redesign of the workflow module to use taxonomy (basically, so I can use workflow + TAC + other taxonomy aware modules). You can see progress here:
http://drupal.org/node/49537
The problem with form_alter is that it is not recursive. What happens is that it is called once for the node_edit form and taxonomy adds it's stuff there. Since taxonomy never calls
drupal_get_formthe form_alter hook is never invoked for the taxonomy specific stuff.I had to do a hack job by patching taxonomy (there's a link on the above issue) so that it ignored my vocabularies when displaying forms and then display my own form. :-(
I'm going to post in the forums and see if I'm missing something.
-M
#8
I've listed my complaints with taxonomy here:
http://drupal.org/node/38221#comment-73950
If we can fix #1, we can fix this problem in taxonomy_access pretty easily.
#9
#10
I have a problem with the existing behavior as well-- I have "departments" as a parent term and under this I have various departments: administration, Board, Library, etc. Users who can create content only for library, should not see or be able to create content for "departments," but should only be able to see and create content associated with the "library" term. Is there an easy hack to make taxonomny_access allow permissions for "creating" with child terms when the parent term is not allowed? Please help!
#11
It's funny that with UPDATE and DELETE *explicitly denied* on the parent, you can still update and delete pages that are contained by its child, as long as you have UPDATE and DELETE enabled for the child. You can even see the entire list of categories and pick whatever you want. But when you try to create a page in a category that has CREATE enabled, but who's parent has CREATE disabled, you can't see any categories because for some reason in this case the CREATE permission on the parent overrides that of the child. There is definitely a consistency issue to be worked out here.
#12
Just curious if there is an update to this bug. Has this been fixed or is this still an issue? We are struggling with it this week. Thanks.
#13
It is still an issue. Term permissions does not consider the permission of its parent term at the moment.
#14
After 10 months, I have come to think that what keve suggested in #1 is probably the simplest solution which would serve most cases. That is, a message telling the user that only a child category can be selected.
At least this is what the forum module does when a user tries to post to a forum container.
The only inconsistency is that the user would see the parent even without list permission for the parent. Unfortunately I can't write php to do it...
#15
I'm having issues with this as well. Changing title a bit.
Any work done on this? I need this for a client and will carry the torch if some work has already been done. I'm fine with #1.
#16
Subscribing...
#17
I think this is still an issue in 5.x-2.x-dev or 6.x-dev version.
It needs to be tested.
#18
#19
#20
keve, yes I can confirm this is still occuring on my Drupal 5.8 setup which is using Taxonomy Access Control 5.x-2.x-dev.
So long as the top level term has the create box ticked all accesible children terms will be listed, if create isn't ticked, no terms will be listed even if they are granted in Taxonomy access permissions.
This leads to users being able to create pages using the parent term that they don't, and shouldn't, have access to edit, but ideally they wouldn't be able to create pages at this level.
#21
My "feeling" is that this is something that needs fixing in the taxonomy module itself.
Treating it as an access control problem means that we want some users to be able to use a parent term and other users not. But usually what we need is "placeholder" terms which are never intended to be used for tagging but only to keep the structure together.
Support for placeholder terms would be useful for the forum module as well.
#22
Subscribing. I need a fix for this as well!
#23
We should test whether this issue still exists. #112307: Cannot create node in taxonomy term without create permission for parent term seems like it might be related, also.
#24
Actually, upon further review, this is a full duplicate of #112307: Cannot create node in taxonomy term without create permission for parent term; the issue title was misleading.
#25
#26
I don't know if anybody actually fixed this.
I came upon a neat solution myself after reading 2 or 3 comments...
I changed from "Taxonomy Superselect" to "Better select". I tested a few modules to change the term selection to checkboxes and "Better Select" did it best in the rubik theme (rubik and superselect are not compatible).
Superselect automatically does this so it might be a good solution for non-rubik users.
I just changed it via css (look at the attached pic to see how it displays using better select)
(this is in the core.css for the rubik admin theme used for editing nodes)
the element names can be found in the sourcecode of the node/add/* page ( i.E. using firebug or google chrome)
.column-side #edit-taxonomy-8-80, /*the parent 1*/.column-side #edit-taxonomy-8-89 { /*the parent2*/
display:none;
}
Hope this can help somebody ...even though this is an old post
#27
found another way using formfilter to exclude the terms. Works like a charm
(for the rubik admin theme using better select)
In the comment before this one, the labels were still clickable.
updated code: ...even though I don't use it anymore, for people not using formfilter
.column-side #edit-taxonomy-8-80-wrapper, /*the parent 1*/.column-side #edit-taxonomy-8-89-wrapper { /*the parent2*/
display:none;
}
Still styling it in css (i.E. creating new parent labels after hiding them with formfilter.)
.column-side #edit-taxonomy-8-82-wrapper {padding-top:35px;
background:url('/sites/default/files/parent1.png') top left no-repeat;
}
.column-side #edit-taxonomy-8-99-wrapper {
padding-top:35px;
background:url('/sites/default/files/parent2.png') top left no-repeat;
}
btw. I left the original vid and tid to make it easier to understand.
Images are set as background for the first term under its parent.
In general it would be (I guess)
.(block) #edit-taxonomy-(vid)-(tid)-wrapper. {padding-top:35px; /*extend the background by the size of the image to be used*/
background:url('/sites/default/files/parent2.png') top left no-repeat; /*Image as Parent (optionally use an icon) with a max width of the padding-top*/
display:block; /*make sure it is printed in a new row (play around with this for different effects)/*
}
Images should have a border of a few pixels so the don't touch the term this is applied to.
The example shows an image with 35 pixels height.
I know this is kind of a tricky workaround but works perfect and gives the opportunity to use some nice effects.
YEAH... hope it helps...
#28
Only issue with using display:none; is that it has issues with accessibility and I would need this to work for blind users using a screen reader. Any other ideas to fix this?
#29
The active issue is at #112307: Cannot create node in taxonomy term without create permission for parent term.