Condition: field value changed - not working for booleans

Thanks @lexsoft for reporting this. Just wondering where your status message is coming from?

The comparison in the condition plugin looks like this:

$changed = $property->getValue() !== $original_property->getValue()

where property comes from the current entity and original_property comes from the original entity. If those 2 deliver the same typed data in different format, that would be terrible as all that data comes directly from the Drupal core API.

Note, I've changed the version of this issue to 1.2.x as bug reports always need to be addressed in the latest version, from where they can sometimes be back ported.

Hi @jurgenhaas,

I've just done a dpm on the values to debug why it's always triggered.
dpm($property->getValue());
dpm($original_property->getValue());

The test was done on a clean install of Drupal 9.5.9.
Also, I've noticed that we don't have $entity->original when working with entity reference in inline_entity_form. Is there a way around this?

Hmm, that sounds bad. I've no idea what we could do about it when core provides the same value in 2 different ways. That makes comparison almost impossible.

Also, I've noticed that we don't have $entity->original when working with entity reference in inline_entity_form. Is there a way around this?

AFAIK the property $entity->original is only made available during entity-related events like pre-save and update. Form events don't provide that at all, and referenced entities neither.

Can we just change the condition to not check data types, I think in the majority of cases people would want to see if the content has changed rather then data type.
$changed = $property->getValue() != $original_property->getValue()

And maybe add another condition where we also check for data types? Something like field value changed strict.

I'm thinking maybe just a checkbox to enable/disable strict data types.
Will provide an example shortly.

We've just discussed this in the team as well, and @boromino suggested to check, if the value is scalar and if so, if it's 0, 1, "0" or "1" and if so, cast the value to a string before comparison.

That way we could keep the strict comparison.

Another option would be to check the field type first, and if it's a boolean, cast the value to a boolean first. But that one is probably to time consuming.

Also when used on entity reference the array is different as well:

It might be useful to have 2 more conditions to maybe get data from revisions rather then original.
1. Check if revisions exists for entity
2. Check field value changed from revision

What do you think?

Also when used on entity reference using inline_entity_form the array is different as well

I'd say, we should maybe switch to the other approach to check the field type and do special treatment for booleans and entity references.

1. Check if revisions exists for entity

Not sure if that's necessary, if I got this right. There is the action Entity load which allows to load a specific revision. Maybe that needs to be extended a bit to load e.g. the previous revision instead of the latest revision. But from there you can load revisions, which also acts like a condition: if the revision doesn't exist, the model processing ends at that point.

2. Check field value changed from revision

You mean like comparing 2 given entity revisions? That sounds useful and that condition could be implemented as a sub-class of this one.

I'd say, we should maybe switch to the other approach to check the field type and do special treatment for booleans and entity references.

That's sound great to me. I can help with testing when it's done.

You mean like comparing 2 given entity revisions? That sounds useful and that condition could be implemented as a sub-class of this one.

Essentially I would like to check if the entity I'm saving (current or loaded via reference) has a revision and if it does has the value of the field changed compared to what it's saved in latest revision prior to the one created on save.

My scenario is really simple.
I have a node form that clients need to complete.
After they complete the form a supervisor is notified, reviews the form and flags changes needed on the form.
Finally here is where I need the condition to check if changes to the specified fields are made, if so I need to notify the supervisor again and the process repeats until done.

Essentially I would like to check if the entity I'm saving (current or loaded via reference) has a revision and if it does has the value of the field changed compared to what it's saved in latest revision prior to the one created on save.

When saving a node, the latest revision is always what you get in $entity->original. Why would we need something extra here?

And when saving a node, referenced entities don't change at all, The field value of the saved entity which references other entities may change, but that is already covered.

So, if we still needed more conditions, let's address them in new issues as feature requests, please. I'll be working on the bug fix with booleans and entity refs.

I'm sorry if I made things more confusing, I have not mastered yet ECA.
Getting this condition to work with Booleans and inline entity forms will probably fix all my problems.

I've now implemented the comparison such that field types boolean and entity reference get sanitized before comparison. That's included in the new MR !369

I can confirm it works for booleans and entity references using inline entity form.

There is a weird thing where on a text editor the array is inverted, I wonder if we need to count for that as well.

Very strange indeed. Maybe sorting all the arrays with ksort before comparison?

Please fix the tests first, it doesn't make sense to review something that breaks tests.

ksort might be worth a try.

I have added tests for Boolean fields.

Cool, thanks for fixing and extending the tests :)

Now also added the ksort for all fields that are neither boolean nor entity references. Please give that a try too and if it resolves your editor issue, please set it to RTBC.

That is a cool approach to tackle this problem

jurgenhaas → closed merge request !368

Merged and back ported to 1.1

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