The actions module is just the UI for managing actions, but the actual functionality is in includes.
I was trying to make a bulk form for admin/people, and to do so would mean making user depend on actions...

It should just be in system module.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

Oh, hm, I missed hook_user_operations(). I think I might be severely mistaken here.

dawehner’s picture

Status: Active » Postponed

I think the plan of fago is to put actions into the entity system, and get rid of action.module
but until then action_do, which is used by that field, belongs to actions.module.

tim.plunkett’s picture

Title: Move the Views bulk_form handler out of the actions module » Add a base bulk form handler class and port user operations to it
Status: Postponed » Needs review
Issue tags: +Needs tests
FileSize
12.37 KB

Here's hook_user_operations() as a bulk form handler.

dawehner’s picture

Shouldn't we just postpone this until there is a proper operations/actions API into core? It's a lot of effort to get both
hook_node_operations hook_user_operations in, to remove it finally anyway?

bojanz’s picture

I agree with #4.

hook_user_operations is a relic and it needs to die.

tim.plunkett’s picture

Assigned: Unassigned » tim.plunkett
Status: Needs review » Postponed

It wasn't that much work. And there's been no progress on the other issue.

But you're right.

I still might work on this though.

tim.plunkett’s picture

Title: Add a base bulk form handler class and port user operations to it » Add a base bulk form handler class
Component: entity system » views.module
Status: Postponed » Needs review
Issue tags: -Needs tests
FileSize
10.62 KB

Okay, this should be the first step. Regardless of what happens with other operations, we'll need to have other subclasses of this. So let's get this in, and I'll open up new issues for porting hook_user_operations() and hook_node_operations().

All this does is keep the action.module specific stuff in the subclass, and move everything else to an abstract class. Subclasses have to implement views_form_submit() (an existing method) and getBulkOptions().

The diff looks a little funny since it both modifies and copies the existing action bulk form class.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Green if it's green :)

+++ b/core/modules/system/lib/Drupal/system/Plugin/views/field/BulkFormBase.phpundefined
@@ -35,7 +31,7 @@ public function pre_render(&$values) {
-    if (!empty($this->view->style_plugin) && $this->view->style_plugin instanceof \Drupal\views\Plugin\views\style\Table) {
+    if (!empty($this->view->style_plugin) && $this->view->style_plugin instanceof Table) {

So much better!

+++ b/core/modules/system/lib/Drupal/system/Plugin/views/field/BulkFormBase.phpundefined
@@ -91,7 +81,7 @@ public function views_form(&$form, &$form_state) {
     $form['header'][$this->options['id']]['action'] = array(

I'm wondering whether we should call this action, but yeah operations are somehow similar.

+++ b/core/modules/system/lib/Drupal/system/Plugin/views/field/BulkFormBase.phpundefined
@@ -99,33 +89,22 @@ public function views_form(&$form, &$form_state) {
+  abstract protected function getBulkOptions();

I really like abstract functions as it really helps developers.

+++ b/core/modules/system/lib/Drupal/system/Plugin/views/field/BulkFormBase.phpundefined
@@ -99,33 +89,22 @@ public function views_form(&$form, &$form_state) {
+  abstract public function views_form_submit(&$form, &$form_state);

Just in case someone wonders, camelcase that will be done later, as that is not a new function here.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed to 8.x. Thanks!

tim.plunkett’s picture

See #1894972: Provide a bulk form for user operations for the first usage of this.

tim.plunkett’s picture

tim.plunkett’s picture

Assigned: tim.plunkett » Unassigned

Automatically closed -- issue fixed for 2 weeks with no activity.