Issue/woomob 370 handle displaying refunded shipments

[irfano]

Part of WOOMOB-373

Description

This PR makes following changes:

• Before, we had two models, PurchasedLabelModel and ShippingLabelModel. They were similar, but I initially created them as two models because one used a String type for the id, and the other used an Int. I noticed that this string/int difference is not based on the endpoint, it's based on the shipment. In other words, even in same response, a shipment may have "id: 0" and the next shipment may have "id": "small_box_id". This inconsistency is likely due to mobile platforms calling the purchase endpoint with the wrong ID type (I will fix this later and it's already discussed in p1749620015063859-slack-C05VBLKHHV1). In this PR, I've removed PurchasedLabelModel and used string id in ShippingLabelModel. This way, we can support both string and number formats without any issue.
• Before, we were using purchased labels data to determine whether a shipment had been purchased. Now, we additionally check if the label has been refunded. If it has, we no longer consider the shipment as purchased. This behavior is consistent with the web.
• Before, The "Create shipping label" button was hidden if all shipments were fulfilled. I’ve updated the logic to match the behavior on the web and iOS, where the button remains visible.

[!WARNING]
Known issue: After refunding a label and navigating back to the main creation screen, the label is still being displayed as purchased. I’ll address this in a subsequent PR.

Steps to reproduce

1. On the web prepare an order with multiple shipments. Do not purchase from the app, because currently purchase flow send some incorrect data and may break orders.
2. Purchase two orders.
3. Refund one of them.
4. Open the order from the app and compare it with the web.
5. Purchase all shipments.
6. Navigate back and ensure "Create shipping label" button is visible for fulfilled shipments.

The tests that have been performed

Steps above

Images/gif

• [x] I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

[wpmobilebot]

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

	App Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	88c3d659b04fa03475571b1188b1225d4d0d2d77
	Direct Download	woocommerce-wear-prototype-build-pr14190-88c3d65.apk

[wpmobilebot]

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

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Commit	88c3d659b04fa03475571b1188b1225d4d0d2d77
	Direct Download	woocommerce-prototype-build-pr14190-88c3d65.apk

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 41.66667% with 14 lines in your changes missing coverage. Please review.

Project coverage is 37.83%. Comparing base (98f5ebd) to head (88c3d65).

Files with missing lines	Patch %	Lines
...ndroid/ui/orders/wooshippinglabels/GetShipments.kt	0.00%	6 Missing and 3 partials :warning:
...oid/ui/orders/wooshippinglabels/networking/DTOs.kt	60.00%	2 Missing :warning:
...ers/wooshippinglabels/models/PurchasedLabelData.kt	0.00%	1 Missing :warning:
...ers/wooshippinglabels/models/ShippingLabelModel.kt	85.71%	1 Missing :warning:
...nglabels/networking/WooShippingNetworkingMapper.kt	0.00%	1 Missing :warning:

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk   #14190      +/-   ##
============================================
+ Coverage     37.78%   37.83%   +0.04%     
+ Complexity     8933     8931       -2     
============================================
  Files          1956     1955       -1     
  Lines        109724   109676      -48     
  Branches      14390    14380      -10     
============================================
+ Hits          41461    41491      +30     
+ Misses        64472    64396      -76     
+ Partials       3791     3789       -2     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hichamboushaba]

Another case here, when the order has the a single label, the result is a bit different, the mobile app thinks we have multiple shipments:

Web	Mobile

[hichamboushaba]

Another case here, when the order has the a single label, the result is a bit different, the mobile app thinks we have multiple shipments:

Actually the same behavior happens on the web after refreshing the page, I'm not sure if it's the expected behavior or not, personally I think it should show just the single purchased label, WDYT?

[irfano]

Purchase a label. Refund it. Re-purchase it. The app will keep displaying it as non purchased, even though it's purchased now.

This might be related to the missing id parameter in the purchase endpoint. I tested the case in the PR where I added the id, and it worked as expected. Could you please test it when you're reviewing #14207

Another case here, when the order has the a single label, the result is a bit different, the mobile app thinks we have multiple shipments:

This is also related to missing id parameter. Please also test this in the same PR.

Actually the same behavior happens on the web after refreshing the page, I'm not sure if it's the expected behavior or not, personally I think it should show just the single purchased label, WDYT?

It's expected. In this PR, we send an incorrect shipment id, such as "custom_box" instead of "2". The backend treats it as a new shipment and creates a new one.

[hichamboushaba]

It's expected. In this PR, we send an incorrect shipment id, such as "custom_box" instead of "2". The backend treats it as a new shipment and creates a new one.

The mobile app wasn't involved at all in the test, all of the steps were done in wp-admin, so if it's not expected to see to shipments, then it's a bug in the plugin, can you test it on your side and confirm if it happens to you or not? (For an order with one shipment, make a purchase, refund it, then re-purchase it, then refresh the page)

---

For the other issue, I will retest it using the other PR and report back. Currently, it's unclear to me how the id parameter might affect things, since my purchase was made through wp-admin, not the mobile app.

[irfano]

The issues I found were actually caused by a bug in the plugin, but it's fixed in the last version

Yes, it may still break things if we don't use id parameter. The new fix assumes mobile platforms always send the id, so it's safer not to test purchases on PRs earlier than #14207

[hichamboushaba]

Yes, it may still break things if we don't use id parameter. The new fix assumes mobile platforms always send the id, so it's safer not to test purchases on PRs earlier than https://github.com/woocommerce/woocommerce-android/pull/14207

Yes, I'm aware, I used only the web for all purchases in the tests of this PR.