'Field value has changed' doesn't work for phone number field

In general, this should work for all fields. But it looks as if the phone_number field plugin does something special. Here are the values that we received when we compare the original with the new value:

$originalValue = [
  'value' => '+491727321251',
  'country' => 'DE',
  'local_number' => '01727321251',
  'extension' => NULL,
];

$newValue = [
  'value' => '+491727321251',
  'country' => 'DE',
  'local_number' => '01727321251',
  'extension' => NULL,
  'country-code' => 'DE',
  'phone' => '0172 7321251',
];

As a human, I would say, the phone number hasn't changed. However, technically, the 2 arrays are different, as the value from the edited entity contains 2 additional properties that are not present in the original value: country-code and phone.

I might be wrong, but this is most likely a question that should be brought to the attention of the phone_number module, and hopefully, they can throw some light on it and maybe even fix that. If there is anything ECA could be doing to "fix" this, I'm happy to discuss that, but I doubt we can, without writing some proprietary code for phone_number fields.

Thank you for looking into this and the very detailed reply, that makes sense when you see what the phone_number field is actually doing.

@Problue Solutions have you had a chance to check this with the phone_number module's maintainer?

I did indeed, unfortunately I received no response almost a month since I posted: https://www.drupal.org/project/phone_number/issues/3362855 💬 'Field value has changed' doesn't work for phone number field Active

That's unfortunate, but quite possible in open-source context where volunteers are involved. Best thing you can do, as you already offered to write some code in the other issue, that you create an issue fork for the phone_number module and propose the necessary changes as a merge request. This should then be very little effort for the maintainer, to review and merge that proposed code. Of course, to do so, you first would have to find out why this module produces different data arrays.

Thank you for following up. Very encouraging to see such attention paid to the ECA module, even for a very minor edge case like this.

Unfortunately this particular project doesnt have a budget that would allow forking the module and solving the issue. We have decided to not use the phone number module as the workflow is more important than the validation.

Such is the life of small business Drupal development, there are still some of us around post D7 that dont always have budgets to spend time on things like this, so we just have to compromise :)

Fair enough. Let's keep this issue open, nevertheless, somebody may come along and have some spare time to allocate.