[IPPInAppFeedback] Banner business logic and merchant eligibility in Orders screen

[iamgabrielma]

Part of #8530

Description

This PR adds the logic to discern which in-app feedback banner we should show to the merchant, based on if the Store is eligible ( has COD enabled, and the country is IPP-supported ), and three conditions:

• Haven't collected any IPP payments.
• Have collected less than 10 IPP transactions in the last 30 days.
• Have collected more than 10 IPP transactions in the last 30 days.

At the moment we're not displaying or populating any specific content when any of the 3 conditions occur, this will be dealt with on a different PR.

Changes

• Call to displayIPPFeedbackBannerIfEligible() in OrderListViewController's init, which will perform the logic to check if COD is enabled, and fetch IPP transactions from storage (if any) as well as those within 30 days.

Testing instructions

1. On a Store with IPP transactions, and COD enabled. Navigate to Menu > Orders
2. Check Xcode console and confirm that transactions within 30 days are logged:

hasResults? true
IPP transactions within 30 days: 3

[
  "OrderID: 1475 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-02 01:55:33 +0000)", 
  "OrderID: 1481 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-05 10:45:27 +0000)", 
  "OrderID: 1488 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-10 10:00:19 +0000)"
]

< 10 transactions within 30 days. Banner 2 shown

Due to the nature of fetching orders from Storage and how we use this layer as a sort of caching mechanism rather than as a source of truth, in some cases you may encounter 0 IPP transactions despite that these exist, for example if you install the app and go directly to the payments view without visiting the Orders view first. This is "expected" at this time, as we're looking for a fast solution to get us 90% there. The solution is to go to Orders > wait until are fetched > go back to Payments.

One potential way to smooth this problem is to add pull-to-refresh, this can be worked on a different PR or in i2 ( tracked here )

Edit: As new requirements have changed the logic from Payments to Orders, this may no longer be a problem.

[wpmobilebot]

You can test the changes from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr8549-c3fef0d on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[iamgabrielma]

Thanks for the pairing session yesterday @joshheald , this PR is ready for review 🙇

As discussed, in fe967c7 I've added an extra check to be sure that the IPP transactions we're getting are coming from the app, and not the web, by checking if their metadata contains a receipts_url key.

I couldn't find an easy way to do so directly via the resultsController predicate, so I opted for filtering the fetched objects once we get back the results from Storage.

[joshheald]

@iamgabrielma Initial testing: all of my IPP stores say this –

COD enabled? true - Eligible Country? true
hasResults? false
IPP transactions within 30 days: 0
[]
0 transactions. Banner 1 shown

It was not possible to sync local orders settings: noOrdersSettings

However... some of those stores are full of recent IPP transactions, and all have at least some. I pulled to refresh and it says the same thing.

We can pair on why it's doing that if you like?

[joshheald]

Hmm. I had to launch it again to hit a breakpoint (because I wanted to hit the one in viewDidLoad) and the second time round, it came up with

COD enabled? true - Eligible Country? true
hasResults? true
IPP transactions within 30 days: 10
["OrderID: 440 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-11 18:49:54 +0000)", "OrderID: 445 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-13 14:24:28 +0000)", "OrderID: 450 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-16 10:50:36 +0000)", "OrderID: 451 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-13 17:40:57 +0000)", "OrderID: 452 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-13 16:48:11 +0000)", "OrderID: 455 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-13 17:45:11 +0000)", "OrderID: 456 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-16 10:49:15 +0000)", "OrderID: 457 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-16 10:37:57 +0000)", "OrderID: 458 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-16 10:22:59 +0000)", "OrderID: 459 - PaymentMethodID: woocommerce_payments (WooCommerce In-Person Payments - DatePaid: Optional(2023-01-16 11:06:49 +0000)"]
>= 10 transactions within 30 days. Banner 3 shown

So that's correct, there are exactly 10 paid IPP transactions in the last 30 days.

I think the fix is probably to refresh the results on viewWillAppear, or when we fetch orders, or something like that.

[joshheald]

Second time round it worked for me: I suspect there's something about the first time run for each site which means it's not quite working right. Worth investigating but can be done as follow on work if you want to merge this – it's feature flagged.

Consider adding tests for this logic too: it could help you work faster on it, even though this is a temporary addition to the app.

[iamgabrielma]

Thanks for the review!

some of those stores are full of recent IPP transactions, and all have at least some. I pulled to refresh and it says the same thing.

That's interesting, from these 2 lines would seem that not only failed to fetch IPP orders but also to sync stored Orders settings:

hasResults? false
It was not possible to sync local orders settings: noOrdersSettings

I've opened a new issue here to investigate this further, happy to pair at any time 🙇

Consider adding tests for this logic too: it could help you work faster on it, even though this is a temporary addition to the app.

Will do!