Admin shipment form AJAX does not load the correct address with profile reuse

Going to work on a test for this today.

Confirmed. If you recalculate a shipment it sets the billing address to null.

This does not account for editing the existing address

This works for new or edited profiles. We need a test that has a shipping method that restricts a specific address component and modifies the address to prove it becomes valid or invalid.

And here's the test that verifies a shipping method with a Zone condition becomes available when the address is changed.

End of the day here, not sure why that failed. It passes locally, there must be something in my environment.

Just a reroll...

Debugging this...

Ok... found this error:

AssertionError: assert($selected_profile instanceof ProfileInterface)

The reason for that is that we're trying to load a profile with $selected_profile_id = '_original'.

Ok, this time tests should be passing.
Instead of setting the address on the profile, I'm directly setting the profile on the shipment when available... This way, if custom fields other than the address are attached to a profile, and conditions are targeting them, the correct values should be used.

Ok, so setting the shipment profile doesn't seem to be a good idea... The ValidReferenceConstraint returns a violation indicating that the profile cannot be referenced for some reason (This normally happens because of the access)...

So setting the address on the profile instead like in the previous patches...

Since $selected_profile_id could also contain "_new" and "_original", I'm now testing that $selected_profile_id is numeric.

Hopefully the last attempt (Tests are passing locally)...

+++ b/src/Form/ShipmentForm.php
@@ -218,9 +219,19 @@ class ShipmentForm extends ContentEntityForm {
+      $selected_profile_key = array_merge($base_form_key, ['select_address']);
+      $selected_profile_id = $form_state->getValue($selected_profile_key);
+      $address_key = array_merge($base_form_key, ['address', '0', 'address']);
+      $address = $form_state->getValue($address_key);
+      if ($address === NULL && (!empty($selected_profile_id) && is_numeric($selected_profile_id))) {
+        $profile_storage = $this->entityTypeManager->getStorage('profile');
+        $selected_profile = $profile_storage->load($selected_profile_id);
+        assert($selected_profile instanceof ProfileInterface);
+        $address = $selected_profile->get('address')->first()->getValue();
+      }
+      $shipment->getShippingProfile()->get('address')->setValue($address);

Discussed with @jsacksick and the problem was _original for the selected profile ID.

I cannot reproduce where _original exists, as the CustomerProfile form only lets it exist as a way to go back to an original entity. But this adds some safeguards. I also added a test to assert the first calculation accounts for the current profile. @jsacksick can reproduce, so this is definitely a safe bet to guard against.

Okay so @jsacksick and I did a call and determined there's something with chromedriver. It's skipping the first press of the recalculate button which sends _original.

It's due to manually clicking links, which doesn't wait for Drupal JavaScript behaviors to attach. So the first button press does nothing.

😱 fixed!