New condition: Contains for lists

Started a first draft for this new condition. It most likely requires more cases to be checked when iterating through the list.

We're using such a condition since a couple of weeks. I've created MR349 which contains the implementation of that plugin. It's funny that the plugin ID matches with your suggestion. Feel free to use / reuse / not use anything from it.

@mxh thanks for MR!349, I've looked into it, and it covers all that's in MR!339, plus more. I'm happy to use yours instead of the original one and left a couple of comments in the MR. I'm happy to "fix" them myself, but wanted to get your feedback on them first.

Sure, will take a look.

Answered the comments in the MR.

Got it, thanks for the clarification. I've now committed a couple of code clean-ups and PHP 8.1 adjustments.

Thanks. Would it be possible to stick with "list_token" instead of "list_token_name"? As we are already using the plugin, otherwise I'd need to take care of it with update hooks and proper config synchronization on quite a few installations. However I also understand that "list_token_name" is better regards consistency with other plugin configurations, so I'm also fine by using that.

TBH we do have the same situation the other way round, and I thought the consistency argument would weigh more here.

Just took another look. Actually the current name is "list_token" in the other plugins. For example in Drupal\eca_base\Plugin\Action\ListCountand Drupal\eca\Plugin\Action\ListOperationBase. "list_token_name" is currently not used.

That's really unfortunate. We're using token_name (almost) everywhere, but for the list related plugins, there is list_token. My problem is that this is not a token, it's a token name. And we know from support that this is a huge source of confusion to when the token syntax needs to be used vs. just the token name.

Now, the variable name is not so crucial for end users, that's more for the developers.

But the field label should NOT call this a token, it's a token name. So, we stick with the variable name list_token, but I've updated the label to make clear, it's the name of a token.

Yes, definitely the label needs that explicit description as you now applied. I agree that "list_token" is not a good choice, "list_token_name" would be more consistent regards existing "token_name" keys.

As we are not in a good position to change that config key now, it looks like this is RTBC for MR!349?

I'd say as always for new features, it needs test coverage.

jurgenhaas → closed merge request !339

@mxh Hello Max, perhaps you can help me here.

I have written some tests for the standard lists containing by index and value.

Now I want to test the part where the value to check is an entity and the list is an instance of EntityReferenceFieldItemListInterface.

How do I create such a constellation programmatically? For example, a node with a field containing an unlimited amount of EntityReferences.

You can test this using nodes.

Sample code creating a multi-value entity reference field:

    // Create the multi-value reference, using inlimited cardinality.
    $field_definition = FieldStorageConfig::create([
      'field_name' => 'field_node_multi',
      'type' => 'entity_reference',
      'entity_type' => 'node',
      'settings' => [
        'target_type' => 'node',
      ],
      'cardinality' => FieldStorageConfig::CARDINALITY_UNLIMITED,
    ]);
    $field_definition->save();
    $field = FieldConfig::create([
      'field_storage' => $field_definition,
      'label' => 'A multi-valued entity reference.',
      'entity_type' => 'node',
      'bundle' => 'article',
    ]);
    $field->save();

Then you can just create let's say three nodes, add the other two to the first one, and then add the nodes to the token service:

<?php
$node1 = Node::create([...]);
$node2 = Node::create([...]);
$node3 = Node::create([...]);
$node2->save();
$node3->save();

$node1->get('field_node_multi')->setValue([$node2, $node3]);
$node1->save();

$this->token_services->addTokenData('node1', $node1);
$this->token_services->addTokenData('node2', $node1);
$this->token_services->addTokenData('node3', $node1);
?>

And then finally check with the condition plugin whether for example "node2" is contained in "[node:field_node_multi]". For that to make it work, it might be that you need to add the token module to the list of modules to install. But it could also be that it works already without it, not sure.

I'm trying to use this to check if a media item is in an entity reference list. The list values is an array of media objects, and the value I want to match is the mid. Is it possible to specify that with tokens?

@mortona2k the list comes from an entity field, right? Then you can refer to that with [node:field_NAME] in the "Name of token containing the list" field.

As for the value you want to lookup, you can use the Entity: load action to load the entity into a token of your own and then use that token in the value field.

Thank you very much, I got it working as you described, using the field name token. I was trying to load the entity reference field values to use as a list before using this.

I actually had it working without this plugin, but it took a lot of extra logic loops. Basically I popped each item off the list and did a value comparison. This workflow is much simpler and easy to read now.

I have added another test for entity references.

@mxh Thanks for the input. It works great.

Tests are looking great, thanks!

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

Hi thanks so much for this module.

I am confused by something though, I can’t find this condition when using the UI and I don’t see the code for list contains in the 1.14 version of the module

I see that docs were started here https://ecaguide.org/plugins/eca/base/conditions/eca_list_contains/

Am I missing something simple?

Thanks

Hi @sascher, new features are always going into the latest branch, which is 2.0.x - so, that's where that new plugin exists. The ECA Guide currently doesn't yet expose, in which version plugins got introduced, but we may change that hopefully soon, see 📌 Annotate ECA plugins with version when they got introduced Active .

If you want to use that in your ECA 1.1 version, then you can apply the diff from the MR as a patch.

Thanks @Jurgenhass. I tried applying the patch with composer to 1.1.4 version and got some errors. I will report back if I figure this out .

  "drupal/eca": {
              "https://www.drupal.org/project/eca/issues/3352393": "https://git.drupalcode.org/project/eca/-/merge_requests/349.patch"
          }
                 

some of the errors I got upon running cache clear were

In YamlSymfony.php line 40:

Duplicate key "eca.execution.render_subscriber" detected at line 107 (nea

r " - { name: event_subscriber }").

In Parser.php line 347:

Duplicate key "eca.execution.render_subscriber" detected at line 107 (nea

r " - { name: event_subscriber }").

Please use https://git.drupalcode.org/project/eca/-/merge_requests/349.diff instead of https://git.drupalcode.org/project/eca/-/merge_requests/349.patch as it only contains the effective changes, not the long history of commits.

Thanks @Jurgenhass I see the condition in there now!