Closed (works as designed)
Project:
Filter Permissions
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
2 Jul 2011 at 01:07 UTC
Updated:
4 Sep 2020 at 17:39 UTC
Jump to comment: Most recent
Comments
Comment #1
cyu commentedI was unaware of this feature in D7, thank you.
That said, I'm unsure how to apply it to a filtered page. Filtering by a single role, when authenticated has permission, and only seeing a disabled checkbox could be quite confusing to a user. Showing the authenticated role in addition to the selected role might make the reason for the disabled checkbox clearer, but then there would be the confusion of that role appearing when it was not filtered by.
I haven't played with the D7 permissions page much, maybe I'm missing some obvious cues that would alleviate that confusion.
Any suggestions?
Comment #2
lyricnz commentedI presume you'd want to show the same type of mouse-over/message that Core does, when showing disabled checkboxes. However, with that performance fix in place, the need for a page-load time filter might be reduced anyway. I found this module while looking for a dynamic filter (JS), so don't actually use it on any sites.
Comment #3
cyu commentedI've still not looked into the code here, but I'll note that when authenticated permissions are shown and checked in the filtered results the checkboxes behave as expected, disabling them for other roles. So the filter permissions module doesn't necessarily break the inherited-permissions js but that when that js is run on a permissions page without authenticated users shown it does not disable checkboxes for permissions with authenticated access.
Comment #4
my-family commentedThe same problem in the latest -dev. Is there any solution possible?
Comment #5
my-family commentedIs there any progress on this?
Comment #6
cyu commentedIn D8 this is an issue too, since checkboxes are completely removed when Authenticated has permission. Much like in D7, I don't know if simply disabling/removing a checkbox without the context of why it is being done is a good solution, and also the same is that when the Authenticated User role is included in the filtering the boxes are hidden as expected.
Comment #7
cyu commentedI'm going to leave this as is. Whoever is administering permissions can include authenticated user in the list of roles if they will be using that to override individual roles or if they aren't sure which permissions it already overrides.
It is an improvement to not allow a user to check/uncheck boxes that have no consequence because a role is being overridden by the authenticated user role, and I see some scenarios where this could cause confusion, but this seems to have caused minimal issues in the last 9 years, so I'll close it.