Use Context system for actions

Action module is approved for removal. See 🌱 [Policy] Deprecate Action (UI) module in D10 and move to contrib in D11 Fixed

This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project → and the Extensions approved for removal → policies.

It will be moved to the contributed Action project when the Drupal 11 branch is open.

@quietone is this issue affected? its just actions UI due for removal?

Oops, you are right. I was on 'automatic'. Feel free to change the status on any others I did incorrectly. I think I'll take a break and then come back to this task.

Moving Non UI issue to the base system

Reviving this as I believe Action plugins may be a great pathway to unlock core and contrib en masse as AI tools. However, to do so, actions would need to be able to communicate required contexts.

Much has changed since the last patch, so I tried to work through and map changes accordingly.

I did change the approach for:
Drupal\Core\Action\ActionBase::executeMultiple with the hopes of better backward compatibility.

Original:

/**
   * {@inheritdoc}
   */
  public function executeMultiple(array $entities) {
    foreach ($entities as $entity) {
      $this->execute($entity);
    }
  }

From most recent patch:

  public function executeMultiple($context_name, array $context_values) {
    foreach ($context_values as $context_value) {
      $this->prepareExecutionContext([$context_name => $context_value]);
      $this->execute();
     }

New:

/**
   * {@inheritdoc}
   */
  public function executeMultiple(array $contexts) {
    $context_names = array_keys($this->getContextDefinitions());
    foreach ($contexts as $context_values) {
      if (!empty($context_names) && $context_values instanceof EntityInterface) {
        // Assume a single context of type entity exists.
        $context_values = [$context_names[0] => EntityContext::fromEntity($context_values)];
      }
      // Assume the plugin hasn't been upgraded.
      else {
        $this->execute($context_values);
        continue;
      }
      $this->prepareExecutionContext($context_values);
      $this->execute();
    }
  }

Based on this change, I was looking for feedback of how:
Drupal\user\Plugin\Action\CancelUser and Drupal\user_batch_action_test\Plugin\Action\BatchUserAction used execute and executeMultiple

I also wasn't sure if I needed to add constraints as well?

Looks like it still needs work around access calls.

As a reminder, Rules *still* has context-aware actions working, along the lines being proposed here, with extensive test cases.

This issue was opened because the development of Rules in the Drupal 7->8 transition identified functionality that was needed for Rules and would be useful to core as well. Back then @fago and @klausi were actively involved in developing Rules and were leveraging that work to contribute to the still-evolving core Drupal 8, and this issue was part of that effort.

The patches in here contain a lot of (old) code developed for Rules. This issue seems to have lost traction for inclusion into core when @fago stopped pushing this issue back in 2015 and put the needed functionality directly into Rules rather than wait for core to change.

As prophesized in #9, RulesAction plugins are now a fork of the core Action plugins, made context-aware. If anyone is interested, the commit that did this in the Rules repository was 55fe6db1, and it is similar to what was offered in #75 above. It's a shallow fork, done only because subclassing to get the needed functionality was not possible.

Rules implemented the functionality discussed here long ago. It works. And that functionality (and tests) have been maintained, improved, and ported to Drupal 9, 10, and 11 and is currently being tested weekly on GitLab CI. Rules and Rules-related modules supply hundreds of working examples of these plugins, with many examples and lots of documentation.

I would suggest to anyone who has a need / use case for context-aware actions that you try the Rules implementation as an archetype of how this can be implemented. There's a huge amount of commonality between what Rules has already done and what is being discussed here, precisely because this issue was opened to enable functionality needed by Rules.

I would be happy to help move this Rules functionality into an MR for core, but it would help to first have some feedback on which features should be in core, which should remain in Rules, and what is missing from Rules that core would need.

The newly-changed "Remaining tasks" in the issue summary are not described anywhere, and are not really remaining tasks but rather feature requirements?

I think the first step to make progress here needs to be to open up an MR with a concrete set of changes that can be tested and discussed - there is currently only an old patch file that is horribly out-of-date - for example it doesn't even account for the core change from "context" to "context_definitions" made back in 2019, or the change from Annotations to Attributes made in core last year.

But to do that we need a well-written issue summary stating exactly what the goal of this issue is. The "Problems" section and "Proposed resolution" section still seem relevant (and are still addressed by what was done in Rules), but the "Tasks" and "API changes" sections need clarity.

As I said in #126, I'm willing to offer an MR extracted from Rules, but I would like a little clarity here on what people are looking for from Core.

I removed the remaining tasks for now, it was previously set to 'Review Patch', but that definitely was not sufficient.

In the fork I created, the things I was still sorting through:

• execute / executeMultiple solution and infinite loops
• Node actions extending entity agnostic Drupal\Core\Field\FieldUpdateActionBase, need means to know name of entity context
• Backwards compatibility with Action plugins from contributed modules.

I appreciate the comments and I'll look at the Rules approach to it.