Provide a bulk form for user operations

This looks really good so far.

+++ b/core/modules/user/lib/Drupal/user/Plugin/views/field/UserBulkForm.phpundefined
@@ -0,0 +1,57 @@
+    }, module_invoke_all('user_operations'));

Don't we want to use the ExtensionHandler already?

+++ b/core/modules/user/user.views.incundefined
@@ -313,6 +313,14 @@ function user_views_data() {
+      'id' => 'user_bulk_form',

Now that click sortable is the default, we probably don't want to mark that as click sortable.

Just two really small points, before I think this is RTBC.

+++ b/core/modules/user/lib/Drupal/user/Plugin/views/field/UserBulkForm.phpundefined
@@ -0,0 +1,57 @@
+      foreach (array_intersect_key($this->view->result, $selected) as $account) {
+        $account_id = $this->get_entity($account)->id();

Just to avoid confusion I would suggest to use $row_index here instead of $account.

+++ b/core/modules/user/lib/Drupal/user/Tests/Views/BulkFormTest.phpundefined
@@ -0,0 +1,55 @@
+    $this->assertIdentical(count($elements), 5, 'All user operations are found.');

We could load all available user operations in the test, so it's clearer why we have 5 of them.

Yeah, this is looking pretty good.

+++ b/core/modules/user/lib/Drupal/user/Plugin/views/field/UserBulkForm.phpundefined
@@ -0,0 +1,57 @@
+    return array_map(function($operation) {
+      return $operation['label'];
+    }, drupal_container()->get('module_handler')->invokeAll('user_operations'));

Nice!

+++ b/core/modules/user/lib/Drupal/user/Plugin/views/field/UserBulkForm.phpundefined
@@ -0,0 +1,57 @@
+        $accounts[$account_id] = $account_id;

Probably not, but is it any better to just collect the ids here and use drupal_map_assoc below in the $submit array?

+++ b/core/modules/user/lib/Drupal/user/Tests/Views/BulkFormTest.phpundefined
@@ -0,0 +1,55 @@
+    $this->assertIdentical(count($elements), 5, 'All user operations are found.');

I guess this is what Daniel means, but we could assert these values against the values (or just count) of ...->invokeAll('user_operations').

+++ b/core/modules/user/lib/Drupal/user/Tests/Views/BulkFormTest.phpundefined
@@ -0,0 +1,55 @@
+    $this->drupalPost(NULL, $edit, t('Apply'));
+    // Re-load the user and check their status.
+    $account = entity_load('user', $account->id());
+    $this->assertFalse($account->status);

This should/could probably assert that the user is not actually listed in the view anymore? I know we had a couple of issues with that in the initial patch for the action bulk form stuff.

+++ b/core/modules/user/user.views.incundefined
@@ -313,6 +313,15 @@ function user_views_data() {
+    'help' => t('Add a form element that lets you run operations on multiple users.'),

I'm not sure what this should be changed to but I'm not sure about what it is currently :?

I went with $result instead of $row_index, since its a stdClass not an integer, but that is much less confusing than $account.

Oh you are right. Your change is way better.

Tested this, and still needs a little bit of work:

1) It seems to break the views preview once I add one of these fields to the view.

2) To be a total jerk, I attempted to add the Administrator role to Anonymous, and that resulted in a fatal error:

Fatal error: Call to a member function id() on a non-object in /Users/webchick/Sites/8.x/core/modules/user/lib/Drupal/user/Plugin/views/field/UserBulkForm.php on line 52

Granted, I'm being a jerk, but it still seems like it should fail more gracefully in that case.

3) In non-jerk land, I attempted to add the Administrator role and Cancel the account of an account called "blockme", and got:

Notice: Undefined index: add_role-administrator in user_admin_account_submit() (line 264 of core/modules/user/user.admin.inc).

and

Notice: Undefined index: callback in user_admin_account_submit() (line 267 of core/modules/user/user.admin.inc).

...respectively. The user was of course blocked, in case that makes a difference. Tim says this is a known thing and it's already dealt with in #1851086: Replace admin/people with a View.

4) Then one minor cosmetic thing. It'd be nice if it didn't default to having a label, because I'm going to absolutely never want a label of "User bulk operations form" on this checkbox. :D

Also discovered that Views's contextual links are broken, and "Place a colon after the label" defaults to true, which is the opposite of core, but those don't have anything to do with this patch specifically.