The functionality introduced in #78941: Usability: Auto-check permissions if "authenticated" has them is disabled by Filter permissions. This module will also need to check if "authenticated" role is shown, which is the root for that behaviour.

Comments

cyu’s picture

I 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?

lyricnz’s picture

I 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.

cyu’s picture

I'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.

my-family’s picture

The same problem in the latest -dev. Is there any solution possible?

my-family’s picture

Issue summary: View changes

Is there any progress on this?

cyu’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev

In 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.

cyu’s picture

Status: Active » Closed (works as designed)

I'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.