[Shipping labels] Use legacy logic for setting origin and destination addresses

rachelmcr commented 1 week ago

Part of: #14393

Description

This updates the Woo Shipping labels flow to set the origin and destination addresses in the same way as the legacy shipping labels flow. This sets up the view model to be better prepared for using these addresses in remote requests (e.g. to get label rates) and ensures consistency with the previous address behavior.

Note that in a future milestone we'll be updating how we set the origin address for the shipping label.

How

Uses the legacy logic to generate the origin and destination addresses as ShippingLabelAddress objects, and saves them as properties to use with the shipping service view model in a future PR.
Adds an initializer for existing shipping labels, so we use the origin and destination addresses from the label itself. This initializer also skips setting properties that we don't need to existing labels (including the shipping service view model, which is now optional).

Testing information

Prerequisite: The Woo Shipping extension installed and activated, with at least one order with the processing status and a physical product.

Build and run the app with the revampedShippingLabelCreation feature flag enabled.
Go to the Orders tab.
Select an order eligible for a shipping label.
Tap "Create Shipping Label."
Open the Shipment Details bottom sheet and confirm the origin and destination addresses appear as expected.

You can also check an order with a purchased shipping label:

Build and run the app with the revampedShippingLabelCreation feature flag enabled.
Go to the Orders tab.
Select an order with a purchased shipping label.
In the shipping labels section, select "View purchased shipping label."
Open the Shipment Details bottom sheet and confirm the origin and destination addresses appear as expected.

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

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

[x] The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
[x] Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
[x] Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on all devices (phone/tablet) and no regressions are added.

dangermattic commented 1 week ago

	1 Warning
:warning:	View files have been modified, but no screenshot or video is included in the pull request. Consider adding some for clarity.

Generated by :no_entry_sign: Danger

wpmobilebot commented 1 week ago

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

	App Name	WooCommerce iOS
	Build Number	pr14411-67adab6
	Version	21.1
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	67adab6eed06390da79ef16e91d5543572351347
	App Center Build	WooCommerce - Prototype Builds #11585

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

woocommerce / woocommerce-ios