[UX] Add an instant search filter to the permissions page.

[klonos]

Part of #503.

Module Filter module for D7 does this:

...although unfortunately the search is limited to the module sections/headers and not to each of the individual permissions (that's what we should implement):

---

Minor release update:

• Add a conclusion suitable for blog post + release notes
• N/AAdd Documentation label if the feature needs to be documented (or needs docs to be updated)
• N/A Add Needs change record label if the the issue contains an API change.
• Add Needs translation label if the the issue contains string translations.

conclusion suitable for blog post

You can now quickly search permissions by name, module name, or description.

[klonos]

...although unfortunately the search is limited to the module sections/headers and not to each of the individual permissions

...oh how stupid am I! Read the help Greg - READ THE HELP!!!:

I think we should have it default to search by permissions. If we need to limit to searching by module/by permission, then these should be checkbox toggles - not special "search operators" because end users ([cough] me [cough]) are stupid: https://en.wikipedia.org/wiki/Don't_Make_Me_Think

[quicksketch]

Thanks @klonos! Great suggestion! I'd love to have this in place as well. I don't understand why you'd make users append that prefix for the more expected functionality. I expect that by default, it should search both module name and permission.

I think we should have it default to search by permissions. If we need to limit to searching by module/by permission, then these should be checkbox toggles - not special "search operators" because end users ([cough] me [cough]) are stupid

Exactly what I was thinking.

[klonos]

Yep, just found some time and I am slowly opening separate child issues for the meta.

[klonos]

I was thinking... you know how in the modules page we have a "Permissions" action for certain modules? This link points to the permissions page and the respective module section is appended as an anchor to the link (/admin/config/people/permissions#module-contextual for example). With the search filter implemented, we could pass this as a search argument instead or even have the respective permissions pop up in a modal so that the user does not have to leave the modules page.

Just a thought.

[klonos]

Would it be unrealistic to request this to be targeted for 1.4.0?

[quicksketch]

I'm taking a stab at this as the second place to add instant filtering (we already have it on the modules page). The difference in form structure between permissions and modules make this unlikely to be exactly the same code.

[quicksketch]

Filed a Work In Progress PR at backdrop/backdrop#4292 to keep track of this work.

[quicksketch]

The PR at backdrop/backdrop#4292 is ready for testing and review. Like the module filter, it's the simplest possible implementation, with no special prefixes or options. The implementation is similar but different at the same time, since the structure of the permissions form is quite different than the modules form, such as having a single table with rows as dividers instead of fieldsets.

I also copied the same behavior from the modules form for being able to auto-populate the field from the URL, and saving the current search after submitting the form.

[olafgrabienski]

Thanks for the PR! I've tested it quickly in the sandbox website, and it works like a charm.

I also copied the same behavior from the modules form for being able to auto-populate the field from the URL, and saving the current search after submitting the form.

I've not tested this behavior. How does an auto-populating URL look like?

[quicksketch]

When you submit the form to save the permissions (after filtering), a query string will be added to the URL: ?search=foo. You can manually append this same query string if you want to prepopulate the search.

[yorkshire-pudding]

I'm in two minds about this. For context, I ported the Filter Permissions module and also added a check for max_input_vars, adding a warning and hiding save button if the form will not save.

In general this PR is great for filtering and a brilliant user experience addition. It also negates part of the need for that module on usability grounds (it doesn't filter to only show selected roles - note @bugfolder 's Role Help module also provides a role filtering function so might need to check whether this breaks it) and I think this filtering from a usability perspective is better than the module filter provided in Filter Permissions as it can also filter on the type of permissions (e.g. create, edit etc).

However, it doesn't fix the issue like the filter_perms module if max_input_vars is too low. I know we have done quite a bit to try and help max_input_vars, like in .htaccess (note, I have found this doesn't currently work for PHP8 and have added a PR), but could it still be the case that some hosts won't allow that setting to be overridden? If so, I think we should consider that.

I enabled Filter Permissions with this patch on and the two work on the same screen so someone with the max_input_vars issue that is only affected on the permissions page could use that module in addition, even though it looks clunky with the two filters on the same screen.

[olafgrabienski]

When you submit the form to save the permissions (after filtering), a query string will be added to the URL (...)

I see! Now also tested, e.g. admin/config/people/permissions?search=block, works fine.

[jenlampton]

However, it doesn't fix the issue like the filter_perms module if max_input_vars is too low.

We do have several other issues that target the max_input_vars problem (as mentioned), but this is not one of them :) This issue is to make it possible to search the permissions page, and I think it does that beautifully ❤️

I enabled Filter Permissions with this patch on and the two work on the same screen so someone with the max_input_vars issue that is only affected on the permissions page could use that module in addition, even though it looks clunky with the two filters on the same screen.

I expect we should make an issue for the contrib module to replace the core search when it adds it's own. That version of the module could be dependant on the version of core that gets this feature, so hopefully it can be less experience soon :)

PS: Someone else needs to set the milestone for this, since I was the one to set the milestone label.

Hello there!

I am so excited about this one! I've been so happy that we had the instant_filter search on the modules page, but must admit that I've missed it on the permissions page. This is going to be a huge UX win for Backdrop 🎉

[quicksketch]

Although this issue is now past feature freeze, as a UX improvement it can make it in before the January 15th release. I'm planning to merge it tomorrow before making the 1.24.0-preview release.

[quicksketch]

I merged backdrop/backdrop#4292 into 1.x for 1.24.0! Thanks everyone for the helpful reviewing and feedback.

[bugfolder]

Realized this is already merged, so I will file a new bug report.