Make the actions exposed in the views bulk operation handler configurable

One possible UI would be to choose whether to include/exclude and a select element to choose which one to include/exclude?

At the moment VBO in d7 just supports including elements.

First version with a horrible UI and no tests.

Fixed the test errors (just a left over dsm) and provided actual tests for this new feature.

The current UI looks like that.

Even one radio + a list of checkboxes itself doesn't feel like the perfect UI,
so it seems to be that we should some feedback from the UX team for a proper way, first.

There is no UI to review? I dont see screens?

Perhaps silly question, but do we want to retain the ability to include all actions?

(Technically that's identical to choosing "exclude" and selecting no action to exclude, but that may not be clear to all users.)

We can still have a two-option UI -- 'All actions, except the following:' and 'Only the following:' would make it clearer without having to provide an explicit third option.

Well making screenshots is easy, but don't forget to upload them, that's hard ;)

agreed tp #11
all other looks good for RTBC

#13 works for me

I think we needed a bit more logic to do the correct conditional filtering of the actions, as we were getting no actions for 'include'. I also changed the view field key to be 'action_bulk_form' and not just 'bulk_form', as that's what you would get if you actually just saved a view with this field.

Awesome!

+1RTBC

BTW
this is not feature request, it looks like a real task to make actions much more configurable via views

#16: 1845836-16.patch queued for re-testing.

#16: 1845836-16.patch queued for re-testing.

#16: 1845836-16.patch queued for re-testing.

This one was already RTBC before the random test failure time loop.

Congrats on this issue title by the way :-)

What about "Allow to configure actions to expose in the views bulk operations field handler configuration modal" ^^

"Allow to configure" isn't really idiomatic... is this what we're trying to say? ;)

#16: 1845836-16.patch queued for re-testing.

This is pretty useful for #1851086: Replace admin/people with a View, which is major, so bumping the priority.

And, never mind.

I will give a bag of jellybeans to the person who commits this patch.

Here's what this patch adds.

Thanks for the screenshot. Makes me wonder though: why the added complexity of 'All except selected' vs 'Selected'?

Is this list of options really that long that it's useful to add the 'all except selected' option? It reverses the meaning of what checking the box does.
It makes me think.
Don't make me think! :-)

Removing that bit can be a follow-up if need be, but if it is added with this patch, might as well remove it now.

Yoroy, see the comments above. There was a lot of talk about this before.

Thanks for the pointer. I don't understand wether/how the the issue discussed in #2 applies to how this ui is presented. The discussion after that is about wether select all is still needed, then usability feedback was requested. I gave some :-)

If there's a technical need to have both ways, I missed it. From a ux point of view this is featuritis that I think will slow people down instead of helpping them get the thing done.

...because it inherently means that the default views provided by admin_views will only ever expose the actions that have been explicitly included. And because core can only know about core, the only actions that can reasonably be included are the actions defined in core.

Yes I read that. i don't understand how that makes it necessary to have the two ways to (not) select stuff.

I don't understand why you wouldn't want this. It's not like it makes it ridiculously complex.

Some people might want to create a view that only exposes 1 operation. We want to ship with more for core, and not restrict other actions added by other modules. So I think it makes alot of sense to have the include/exclude logic for this.

Here is the problem if we don't have this extra toggle.

You decide that you never want to expose sticky and promoted, because your site doesn't use them. You check all the other boxes, and save your view, and you have what you want. Maybe you do this in more than one view.
Then you download and enable a new module that provides new actions that you want to expose. You now have to go through EVERY view, to click those checkboxes.

Or, you have this toggle, you select "All except selected" and check off sticky/promoted, and everything works as you continue adding modules.

This exact pattern has existed in core for a long time:

If there's a technical need to have both ways, I missed it. From a ux point of view this is featuritis that I think will slow people down instead of helpping them get the thing done.

In a nutshell, the previous Views Bulk Operations maintainers identified three basic ways that VBO views were being created:

1. The user should be able to perform a specific set of actions
2. The user should be able to perform any action currently supported by the site's installed modules
3. The user should be able to perform any action supported by the installed modules except for a few dangerous ones.

It's very similar to the block visibility question -- "Appear everywhere, appear on select pages, appear on all BUT select pages." It's important to remember that the users of this feature will be site administrators who are themselves building administrative/management tools. VBO currently supports this distinction and it's used quite often; I'd hate to see it crippled in core.

Do you think there's a clearer or better way of capturing the distinction between these three selection approaches?

UPDATE: Ignore me, listen to Tim.

Thanks for the explanation! I did recognize it from blocks ui. It makes a bit more sense there because you're applying settings against dozens if not hundreds of pages.

Damiankloip: if ridiculously complex is the treshold then yes, almost anything goes. But Drupal UX suffers especially from the total of small issues like these. I wanted to understand why it is needed, now I do. I think it might be solved more elegantly, but sure, rtbc.

I like jellybeans!

Reviewing this now.

Thanks eaton, that helps as well, it's good to point out that this is very much a site builder task. A better ui might well be possible. Lets not do that in here :-)

We reviewed this patch live with @WEBCHICK!!! and @MOSHE WEITZMAN!!! and @EFFULGENTSIA! and it looks great EXCEPT we found some pre-existing bugs in HEAD which I'll document shortly. For now though, some minor nitpicks that I'll clean up so we can get this one in:

+++ b/core/modules/action/lib/Drupal/action/Plugin/views/field/BulkForm.phpundefined
@@ -21,19 +21,76 @@
+  public function validateOptionsForm(&$form, &$form_state) {

Missing docblock.

+++ b/core/modules/action/lib/Drupal/action/Plugin/views/field/BulkForm.phpundefined
@@ -21,19 +21,76 @@
     // Filter actions by entity type and build select options.

This comment should probably be updated to reflect the extended logic.

+++ b/core/modules/action/lib/Drupal/action/Tests/BulkFormTest.phpundefined
@@ -78,6 +78,30 @@ public function testBulkForm() {
+    // Setup to include just the sticky actions.
...
+    // Setup to exclude the sticky actions.

"Set up" should be two words.

More soon! <3

Back to @webchick.

Meanwhile, I'll file a couple followups for:

1. Swap the feed and page display order on the frontpage view if possible. Seriously, I edit the feed display by mistake EVERY TIME. :)
2. HTML validation cancel failure in the Views UI.
3. Empty views with bulk options say "Array"! Yay, hooray, array!

Since this is just changing comments, I'm going to live dangerously and commit without waiting for testbot. ;)

Committed and pushed to 8.x. Thanks!

Followup ONE AH AH AH
#1967092: Reorder the frontpage view so that the page display is first

Oopsie.

Followup TWO, AH AH AH
#1967112: HTML 5 validation breaks the cancel button in Views UI dialogs

Followup THREE, AH AH AH.
#1967124: Bulk action views array to string conversion when there are no results