Let "Token: set value" use new objects when referring to existing ones

Here is what I tried

1. Switch to "Entity: Create New" -> "Token: Set Value" -> GATEWAY. What I got is exactly the same as the original error.

2. Use "Entity: Get Field Value" ( Fieldname use Token [node:field_test_paragraph] )-> GATEWAY. This seems to work, no error but it's actually failed since the beginning with this log
Failed execution of Activity_0a5ez0r (Activity_0a5ez0r) from ECA Multi value field loop (TEST Paragraph) (clone) (process_e8yukm8) for event Drupal\eca_content\Event\ContentEntityPreSave: The provided field <div class="paragraph paragraph--type--test-paragraph paragraph--view-mode--default"> <div class="w3-row field field--name-field-paragraph-tet field--type-string-long field--label-above"> <label class="field__label">Paragraph Text</label> <div class="w3-bar-item field__item">Paragraph 01</div> </div> </div> , <div class="paragraph paragraph--type--test-paragraph paragraph--view-mode--default"> <div class="w3-row field field--name-field-paragraph-tet field--type-string-long field--label-above"> <label class="field__label">Paragraph Text</label> <div class="w3-bar-item field__item">Paragraph 02 - Test</div> </div> </div> does not exist as a property path on the paragraph entity having ID ..\n\n#0...............................

3. Use "Entity: Get Field Value" ( Fieldname use field_test_paragraph )-> GATEWAY. ECA stop after "Entity: Load" - with no entity available
Access denied to Load term (ID_LOAD_ITEM) from ECA Multi value field loop (TEST Paragraph) (clone) (process_e8yukm8) for event Drupal\eca_content\Event\ContentEntityPreSave: No entity available.

Should I keep trying or it's impossible for now?

Thank you,

You need to look at the description of the configuration input fields of the used actions. Within "Entity: Get Field Value" it requires - as noted at the input description - to specify a field name in the field "Field name" - not a token. In your case it would be "field_test_paragraph". And since this action is an entity-related one, you should specify "node" for the configuration input "Entity".

I think it works now. What I did is set it to use "Entity: Get Field Value" as mxh suggested. However, with Paragraph, it uses "id" in "Entity: Load", not "target_id" (Example in Multi value field loop is target_id)

Also test with "node" or without "node" and it didn't make a different for my use case.

Another problem I found was when I tested with "Token: Set Value", value inside the content was changed and that made everything not work the way it should when switched to "Entity: Get Field Value". I had to delete all paragraph contents and re-added all content to make it loop correctly.

Thank you,

Ok, thanks for your feedback.

I'm setting this back to active since this is a task now (see #8). @jurgenhaas in case you think this should be moved out into a separate issue, feel free to close this one.

I just took a second look into that, and I think it makes more sense to change the behavior like the following:

Given we refer to an existing token data:

• For entities, we stay with the current behavior.
• For any other sort of data (typed data / DTO), we use the value from it and wrap it with a new DTO.

This would mean a major behavior change of the action, because it won't directly refer to a field item list anymore. But I think this isn't a case anyway a user of that action might expect.

Created a first draft of the suggested behavior change. It now acts very similar to the "Get field value" action when dealing with fields. However, am not sure ATM whether that's the right approach. Feedback and reviewing of the merge request welcome.

I also don't have enough time available to continue on this, so if someone else could continue on that, this would be great.

The MR is looking good to me, and I agree with @mxh that this new behaviour is most likely what users expected in the first place. Unfortunately, we can't back port that to 1.1.x because it would break existing stuff. Or is that up for debate?

Unfortunately, we can't back port that to 1.1.x because it would break existing stuff. Or is that up for debate?

That's hard to estimate. Since it's possible that it's breaking existing models, we maybe should not backport this.

Another thing that may need to be considered is checking for field access.
Plus if we need to filter out any loaded referenced entity that is not accessible for the current user (using "view" operation). If so, we also need to correct that for GetFieldValue and possibly other places where we automatically load referenced entities.

OK, let's forget about back porting, it's too risky.

... checking ... access ...

That's for a separate issue then. But good point.

Sorry, just noticed a small bug. Will take care of it and I'll create a follow-up issue regards the access topic.

MR326 contains the fix.

Ah, missed that while reviewing too. Also merged.

Thanks! Here is the follow-up regards access checks: 📌 Evaluate consistency of access checks when using fields and loading referenced entities Active

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