-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Woo POS] Order Update vs Recreation - summarize pros and cons #12385
Comments
Thanks for reporting! 👍 |
@joshheald @staskus @iamgabrielma Is the behavior on iOS still the same? If so, please consider whether we want to move to the Android solution or continue re-using the order. I'd personally vote for syncing the platforms, as the solution which throws away the order feels more robust and future-proof to me. Wdyt? |
The situation's still the same, yes. We could move to discarding the order. From a merchant's perspective, the only slight argument against that I can see is the potential for the creation of a lot of Order objects on their site over time; I'm not sure whether unused drafts get discarded or not, and their order numbers will go up rapidly. I don't think either of these are a big problem. From our perspective, there's been lots of testing of the current approach, moving to a new one may not be a huge benefit right now... but it's not going to get any easier, and I agree that it would be better if both platforms did the same thing here. @staskus @iamgabrielma what do you think? |
I recall that @samiuelson told me that auto-draft orders got cleaned up automatically after some time |
I have no strong opinion in one or the other, only a personal preference of "there's no need to create a new order if the previous one its still ongoing". As mentioned, the only downside seems to be creating useless drafts in the merchant's end, but this shouldn't happen often enough to be an issue. |
Creating a new order seems more fail-proof. And it's appealing especially if auto-draft orders are removed. |
Android currently creates a completely new order whenever the user goes back to the product selection from the checkout screen => this makes the code quite simple as a new order is always created and no comparisons are being done. The main downside is that we are creating gaps in the order numbers.
iOS in such cases updates the original order. It's also quite simple, but requires a custom logic to compare what is new and what to update. More importantly, as we introduce more features - discounts, coupons, ... - this logic might get more complex and less reliable.
Goal of this task is to consider all the tradeoffs and publish a P2 proposal so we can make a final decision and ensure consistency between the platforms.
The text was updated successfully, but these errors were encountered: