Closed (fixed)
Project:
Forum Access
Version:
6.x-1.0-beta3
Component:
Code
Priority:
Minor
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 Apr 2009 at 14:33 UTC
Updated:
5 Jun 2009 at 22:30 UTC
Hi,
Drupal 6.8
ACL 1.0-B4
Forum Acces 1.0-B3
Multiple content types assigned to forum taxonomy - core problem, described in http://drupal.org/node/422218 , patch applied
While editing permissions of containers/forums, a number of roles' checkboxes cannot be (un)ticked. I am aware that roles with administer nodes permissions the boxes are 'blocked', described in http://drupal.org/node/413708 . However, it seems that roles that not have the access content permission explicitly permitted also get greyed out, whilst they implicitly might have the permission (inherit it from the authenticated user role, in my case)
Just something I came across, not too important it seems :)
Great module btw
Comments
Comment #1
salvisPlease respond to #422218: $node->tid can get the wrong tid if a forum content type has additional vocabularies if that patch works for you, so that we have a chance to get it into core.
When you hover your mouse over the text of the grayed out checkboxes, FA should tell you why they're grayed out. Is it really because of the missing access content permission? If the authenticated user role has the access content permission, no other role (except anonymous user) should be grayed out for that reason.
However, I have tweaked that code somewhat in the meantime and it specifically adds all authenticated user permissions to all roles except the anonymous user role. Please try BETA4 which should come out shortly and let us know if you still see this issue.
Comment #2
OHGE commentedI din't know about the hovering, that helps :) situation is as follows (again, authenticated user does have the access content permission)
- Role 1, access content not explicitly enabled - greyed - hover: b/c of no access content
- anonymous user, no access content - greyed - hover: b/c of no access content
- Role 2, access content not explicitly enabled - checkable
- Role 3, access content not explicitly enabled - checkable
- Role 4, access content not explicitly enabled - checkable
Possible reason that comes to my mind is the alphabetical order of the role names, 'AUthenticated user' as compared to 'ALumni'(name of Role 1), so I guess if the inheritance is done in alphabetical order that would explain this
but I'll check with Beta4 and report back :)
Comment #3
salvisBETA4 is finally out, and I think this should be fixed. Please reopen if it isn't.