Form field actions for multi-property fields

Thanks for the report. This rather looks like a bug that got introduced from the linked parent issue. I can have a look at it this evening or tomorrow.

Meanwhile, you'd need to use the previously working version until this got fixed.

What could help speeding this up, is an export of your affected model configuration. Each ECA config has an export link at the listing page. If that's part of a bigger model, creating a smaller one that only contains the relevant part would be highly appreciated.

Hm, I can confirm the problem, however I get the same problem using either one of 1.1.1, 1.1.2 or 1.1.3.

Which version was the one that worked for you before, since you posted something about "after update"?

The lookup function is currently not finding the targeted element of a multi-column field when #parents / #array_parents are not yet set. This is the case wit the date range field, as it seems that it's being inserted into the form array a bit late. I've adjusted the lookup function a bit, so that it should also be able to find the targeted element, even when the form array has a "widget" key in-between of it.

Thanks for the info.
In version 1.1.2 it worked as expected - I needed to disable one field (start date) in a multivalued field - date range. I just gave the machine name of the field - that was enough for me. After update, it disables both fields (start date and end date). So far, I have not used myfield.0.value syntax. In the parent issue #3346508 🐛 eca_form: Form field actions are not working well for multi-property fields Fixed there was a description that this correctly selects the desired fields.

Thanks for the update, that explains why it worked before on your config. However, using the more specific syntax to disable a certain element (like field_mydate.0.value) is supposed to be the correct approach. Just specifying field_mydate is supposed to disable the whole field widget.

If you have time to try out the merge request, it would be highly appreciated and may speed things up to fix this issue.

Reviewed the patches and the code looks good. @mxh the difference of the 2 patches is just the line numbers, right? I think, each patch should therefore work in both branches, but never mind, it's good to have them both.

@mdnsoft before we merge this, could you please confirm if this resolves your issue and if so, set the status of this issue to RTBC?

@jurgenhaas Yes both MR are basically identical. I was just writing the patch for 1.1.x first this time, and then just pushed it. MR351 could probably be dropped in case we have some work left to do for avoiding mistakes due to redundant commits.

I checked the effect after the patches - unfortunately it still does not work. The first field (value) cannot be disabled at all. However, it is possible to disable the second field (end_value). However, the syntax field.end_value and field.0.end_value do not work. Fields can be disabled using the syntax field:end_value and field:0:end_value.
I attach model configuration.

It's weird, I created a new field and a new model and everything is fine. Even weirder, it now works on the old field as well - syntax field.0.value / field.0.end_value. The syntax I wrote about previously does not work. I'm confused.

Confirming that using ":" instead of "." does not work. It's most probably due to a bug in the validation of the field name input. Will have a look.

This should be now ready for another try using ":" as a separator.

Works ":" as well as "."

Thanks for the feedback, that's great news.

Great work everyone, thanks so much.

jurgenhaas → closed merge request !351

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