Steps required to reproduce bug:
- Create an Organic Group with its own vocabulary and at least one term in the vocabulary
- Create a role with "Administer Taxonomy" permissions
- Make this an og user role and apply it to a user
- With this user click "Categories" > "list terms" > "edit" one of the terms > "submit" (submit with or without changes)
- Try to edit the same term again and it will show "access denied"
Behavior expected:
- That I would be able to edit terms as long as I have "administer taxonomy" permissions
What happened instead:
- I can only edit a term once. To edit terms again, I have to resave the "Configure Member Roles" page, which then allows me one edit until I lose access again.
This occurs on Drupal-5.x on RHEL5, with og-5.x-3.1, og vocabularies 5.x-1.x-dev, og forum 5.x-2.x-dev. I'm running Drupal as a virtual host with clean urls enabled and not in a subdirectory (webroot for virtual host is /var/www/html/kb).
Thank you, Geoff
Comments
Comment #1
somebodysysop commentedDon't have time to reproduce this right now. However, if you give me the exact URL you see in your browser when you get the "Access Denied" message, I might have a quick resolution.
OG User Roles will only work when your user is either in Group context or accessing a URL it recognizes as a group page. Never used OG Vocabularies with OG User Roles, but so far it sounds like the problem may be the latter.
Please advise.
Thanks.
Comment #2
gmayes commentedHi,
URL when "edit" gives an "Access denied" (this is also the exact same URL when "edit" works):
http://kb-test.eng.vmware.com/admin/content/taxonomy/edit/term/86?destin...
Also, when this og group user in role with "administer taxonomy" permissions is still able to edit terms (e.g. the one opportunity to edit terms has not been used yet), their user block displays "Categories" (as well as "Comments," "Moderated Content," and "Content Moderation Log" because this og user role has admin permissions for comments and modr8). After a term is edited, all of these block links disappear.
I'd be happy to do further testing of any sort.
Thank you, Geoff
Comment #3
somebodysysop commentedThis url is never going to work with OG User Roles because it's outside of OG group context. I could probably make it work, but that would, in my opinion, be outside the scope of OG User Roles, not to mention creating a situation where a group user could have the unintended ability to access a sites admin area.
From my testing of og_vocab, a "Categories" tab will appear on your Group Home Page, and by clicking on it all group taxonomy admin tasks are handled here: http://kb-test.eng.vmware.com/node/29/og/vocab
I created a test user, put him in a group, in that group I gave him a groupadmin role, and I gave that role the "administer taxonomy" permission. The user is now able to create vocabulary and terms and everything else he needs to under the "Categories" tab of the group home page.
I don't have time to put the necessary files together to create a patch, but if you wish to edit your og_user_roles.module file, here's what you do:
Insert this code:
directly after this code:
This should resolve your issue until the next release.
Let me know if it works.
Comment #4
gmayes commentedFantastic stuff. It totally works.
Your module saved my life when I discovered it a couple days ago, and now I love it even more. I am incredibly impressed with your responsiveness.
Many, many thanks, Geoff
Comment #5
somebodysysop commentedCan you edit og_vocab terms? I can create and edit vocab, but I can't edit terms.
I can't. But then again, I may be using an outdated version of og_vocab.
Let me know.
Comment #6
somebodysysop commentedThis is fixed in next release. Hope to get it out soon.
Comment #7
gmayes commentedI just logged on as one of my test users that has og_user_group permissions to administer taxonomy and this user was not able to edit terms but was able to last Friday. I re-saved the "Configure Member Roles" page (not changing any settings, just re-saving) and this user was then able to edit terms. I'm clicking all over the place trying to lose this user's permissions to edit terms, but am unable to. If I found out an exact sequence of steps that loses the user's edit term permissions, I'll let you know. Regardless, this change is still much, much better than what was occurring before.
Thanks, Geoff
Comment #8
somebodysysop commentedI've written code into OG User Roles that guarantees that a user with OG role "administer taxonomy" will be able to edit his og_vocab terms. Basically, I did what I hope og_vocab itself will do eventually: moved the "edit term" function to within the og_vocab group context.
This modification will be in the update to be released shortly.
Comment #9
somebodysysop commentedOG User Roles 2.0 now released with this fix.
Comment #10
moshe weitzman commentedplease make sure there is an og_vocab issue for setting group context as suggested.