[Shipping Labels] Fix missing origin address for previously purchased shipping labels

[RafaelKayumov]

WOOMOB-746

Description

This is a follow up PR for the [Shipping Labels] Fix purchased labels not presenting destination address - addresses the "editable" origin address line in "Shipment details" bottom sheet for purchased labels. The line shouldn't be editable in case if a label is purchased.

The issue cause is the same as for the missing destination address. The selected_origin wasn't requested and therefore mapped from the config/label-purchase/{order_id} endpoint.

• Adds config.shippingLabelData.storedData.selected_origin request parameter for the config/label-purchase/{order_id} endpoint.
• Maps selected_origin content into ShippingLabels following the same logic implemented in #15866
• Extends the WooShippingRemoteTests.swift to cover origin address mapping.
• Adds a [just in case for safety] fallback in WooShippingCreateLabelsView to present the view model origin address in case if origin address lines from shipping labels are missing.

Steps to reproduce

• Open a completed order with previously purchased labels. Or create an order and complete a label purchase for several shipments. For testing purposes make sure to purchase labels with different shipment origin addresses.
• Open "Create shipping labels" flow for that order.
• Expand the "Shipment details" bottom sheet.
• Make sure the origin address line ("Ship from") is presented.
• Make sure the origin address line ("Ship from") is not editable.
• Make sure the origin address line ("Ship from") is presents different addresses for different fulfilled shipments.
• Consider testing the same order on web to confirm behaviour parity.
• Consider testing with Proxyman. Make sure the config/label-purchase/{order_id} endpoint request sends the config.shippingLabelData.storedData.selected_origin argument. Make sure the response contains selected_origin payload.

Testing information

• Tested on iPhone 16 (iOS 18.4) Simulator. Confirmed that origin address are mapped an presented as non-editable lines in bottom sheet. For shipments with missing data the fallback address is presented.
• WooShippingRemoteTests extended to cover origin address mapping.

Screenshots

Before	After

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS Prototype
	Build Number	31023
	Version	PR #15872
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	548904a
	Installation URL	00lgarim0r8n0

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[itsmeichigo]

Please consider applying the same fix as suggested here to support the array case.

[RafaelKayumov]

Implemented in a separate PR: [Shipping Labels] Handle address array in selected_destination and selected_origin

[itsmeichigo]

I'm concerned that this fallback may cause the app to display incorrect data. Do you think we can remove the workaround if we add support for the origin address array as suggested above?

[RafaelKayumov]

I don't have a strong preference here.

It would be either a blank space or the viewModel.originAddress fallback if selected_origin addresses aren't mapped for some reason. And it seems to be super rare for potential edge cases where a fallback wouldn't work.

I checked - web does present just a blank space for this case. But for the destination web does a fallback to the order destination address if the shipping label destination is missing.

@itsmeichigo Are we ok to leave a blank space there?

[itsmeichigo]

I'm good with having a blank space, it's easier to know that there's an issue than having incorrect data.

[RafaelKayumov]

Done in 548904a

[itsmeichigo]

Thanks for the update. Just a note: when both addresses cannot be found, I see that the layout becomes horizontal:

I hope the workaround in #15876 would prevent this case to happen.

[dangermattic]

	1 Warning
⚠️	This PR is assigned to the milestone 22.7 ❄️. The due date for this milestone has already passed. Please assign it to a milestone with a later deadline or check whether the release for this milestone has already been finished.

	1 Message
📖	This PR contains changes to RELEASE-NOTES.txt. Note that these changes won't affect the final version of the release notes as this version is in code freeze. Please, get in touch with a release manager if you want to update the final release notes.

Generated by 🚫 Danger