Add an action for sending via ECA

Here's an example plugin I have working in another project. This works fine in custom code, but if it's added here as is, it would require adding a dependency on ECA, because without it you will get a whitescreen -- this is because ECA Actions share the same namespace as core actions, so the plugin does get loaded on cache rebuilds, and if the base Action plugin from ECA isn't found, Drupal is not happy.

So this either needs to be in a submodule with an ECA dependency, or should get adjusted to be a native Drupal action...

namespace Drupal\my_module\Plugin\Action;

use Drupal\Component\Datetime\TimeInterface;
use Drupal\Core\Access\AccessResult;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Drupal\Core\Session\AccountInterface;
use Drupal\Core\Session\AccountProxyInterface;
use Drupal\easy_email\Service\EmailHandlerInterface;
use Drupal\eca\EcaState;
use Drupal\eca\Plugin\Action\ActionBase;
use Drupal\eca\Token\TokenInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * Provides a Send Easy Email action.
 *
 * @Action(
 *   id = "my_module_send_easy_email",
 *   label = @Translation("Send Easy Email"),
 *   type = "easy_email",
 *   category = @Translation("Custom")
 * )
 *
 */
class SendEasyEmail extends ActionBase implements ContainerFactoryPluginInterface {

  /**
   * @var EmailHandlerInterface
   */
  protected EmailHandlerInterface $emailHandler;

  public function __construct(array $configuration, $plugin_id, $plugin_definition, EntityTypeManagerInterface $entity_type_manager, TokenInterface $token_services, AccountProxyInterface $current_user, TimeInterface $time, EcaState $state, EmailHandlerInterface $emailHandler) {
    parent::__construct($configuration, $plugin_id, $plugin_definition, $entity_type_manager, $token_services, $current_user, $time, $state);
    $this->emailHandler = $emailHandler;
  }

  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition): ActionBase {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('entity_type.manager'),
      $container->get('eca.token_services'),
      $container->get('current_user'),
      $container->get('datetime.time'),
      $container->get('eca.state'),
      $container->get('easy_email.handler')
    );
  }

  /**
   * {@inheritdoc}
   */
  public function access($email, AccountInterface $account = NULL, $return_as_object = FALSE) {
    /** @var \Drupal\node\NodeInterface $node */
    if ($return_as_object) {
      return AccessResult::allowed();
    }
    return TRUE;
  }

  /**
   * {@inheritdoc}
   */
  public function execute($entity = null) {
    $this->emailHandler->sendEmail($entity);
  }

}

Do ECA Actions provide any functionality required for this to work? If not, I would say it's better to move it to a core Action rather than create a submodule just for this one class.

No, I would recommend moving it to a core action. There's nothing needed from the ECA base class...

I took the code from #2 and put it into a merge request.

I notice that the access callback always returns true (or the equivalent object). I can imagine that when used with a system like ECA the default assumption should be that emails can be sent, but should we consider a permission specifically for triggering the sending of emails?

should we consider a permission specifically for triggering the sending of emails?

It's a good idea, but we'd need to write an update function to migrate roles that can send now so that they have that new permission. And we'd need to update the add/edit form to respect that permission.

At the moment, anyone with "administer email entities", "add email entities", and "edit email entities" can send. So, we could start with that and then create a follow-up issue about the explicit send permission.

All that said, if we added that access rule here, would that break the expected behavior of ECA? For example, let's say you want to send yourself an email every time someone logs into the website. That user who is logging in doesn't have permission, but you'd still want to get the email. Would the access method stop the ECA rule from firing? I don't know enough about what that access method does in ECA.

I believe you're right about ECA. If we were going to add that permission we should probably set it to be abled for all users by default.

I also agree that this is probably something better addressed in a separate issue.

With ECA you can switch users, to execute any action as user 1 - and this is pretty routine. You can capture the previous user in a token, too. I do think a specific permission to send an email makes sense, but ECA can work around it either way...

Merged in. Thanks everyone!

The namespace needs to be updated.

@boinkster good catch. I updated the namespace in 🐛 Update namespace of new Action class Fixed .

Trying to piece this together in ECA...
The plugin asks for an entity token, assuming that's an easy_mail entity. So would ECA need to create the entity as part of the model? Or how would you ref existing easy_mail entities?

@boinkster

1. Yes, your ECA model first needs to create a new entity. Your easy email templates should show up in the create entity dropdown for type/bundle.
2. You can't pass the tokens directly -- what I do is add fields to the email template, which you can then set in ECA before triggering the message send.

I don't understand this. Now Easy Email, which is a great module by the way, will be dependent on Eca. The integration is good, but the plugin fails if not Eca is enabled due to the inclusion of classes from Eca in plugin SendEasyEmail. Could this be a submodule providing this instead? It's a big dependency to add to Easy Email I would say and should be optional.

Thanks for pointing this out, mnlund. We discussed earlier in this issue that this class could be a core action class that would not require ECA. I've opened a follow-up issue to make this change: 📌 Remove ECA dependency from Action class Fixed

@freelock, I was able to use ECA to send an email with a attachment using Easy Email 2.1/Drupal Symfony Mail 1.3 with the patch here: 🐛 Update for Drupal Symphony Mailer 1.3 Fixed
Also, in ECA, loading a node before creating the Easy Email entity enabled content to be passed via tokens to the template before sending.

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