[POS Orders] Persist sales channel filter in order settings

[iamgabrielma]

Closes WOOMOB-711

Description

This PR adds persistence between sessions to the sales channel filter.

Testing information

• In a POS-eligible store, with existing POS orders (make a couple of new ones if not), tap on Filter and select any combination of filters that include the Point of Sale option, then tap on Show orders.
• After loading, rerun the app
• Navigate to orders, observe that the filter its persisted
• Tap the Filter history icon, observe that has been logged accordingly.

Screen.Recording.2025-07-10.at.18.02.59.mov

---

• 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	pr15891-7cdb10b
	Version	22.7
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	7cdb10b
	Installation URL	6gmbgslta02ro

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

[jaclync]

The sales channel filer is persisted after relaunching the app & switching stores as expected!

I was wondering why some orders shown with POS sales channel filter didn't have the POS badge in a test store (just for one of the test stores) 🤔 For some other test stores, I also felt like there should be more POS orders but maybe the WC version was before 9.9 when created_via can be overridden remotely.

filter set to POS orders only	only some orders had the POS badge

[jaclync]

nit: I think this value can be a value for the use case, instead of matching the created_via value in the networking layer. Like pos or point_of_sale with the same casing as other order filters like OrderDateRangeFilter.

[iamgabrielma]

True, I didn't realized we don't need the raw value from the API here, we just case match when creating the query on the OrderListViewModel and create the predicate we need from there. We actually don't need any raw value at all and can just use the enum case.

Let me know if you'd prefer to have some here for a specific case, otherwise I've removed these on 7cdb10b

[jaclync]

non-blocking 💭 do you think we might update our naming to match the definition in pfZP8i-c4-p2#comment-158 at some point? If so, we might want to call it checkout_channel_filter in the storage. Naming for the code structs/classes/enums/vars can be changed anytime, while the storage value would require a migration or duplicated values for backward compatibility. Not a big deal if we have a legacy naming though.

[iamgabrielma]

Good question, this is something that I thought about when adding it. Since we do not know when we'll need these, or if the terms will change or evolve further before we do, I'd keep with sales_channel_filter for now. Later on we can decide if makes more sense to either keep the legacy naming or to make a migration if needed.

[iamgabrielma]

Thanks for the review!

I was wondering why some orders shown with POS sales channel filter didn't have the POS badge in a test store (just for one of the test stores) 🤔 For some other test stores, I also felt like there should be more POS orders but maybe the WC version was before 9.9 when created_via can be overridden remotely.

Yes, if the order was created before 9.9 or before we updated the core data model then it wouldn't show the badge since we're not backfilling pre-existing orders. We'll be adding this to the test plan in any case to confirm that nothing is off.