Fix updating of the remote CIM after a processor change. #3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We had been using Authorize.Net CIM services successfully for quite a while now. Then, a few weeks ago, the bank and authorize.net decided they didn't like each other(for various reasons), and moqui started saying to connect authorize.net to update the config. Ok, no issues, this sort of thing happens. So, while that reconfiguring was going on(at a snails pace), moqui still needed to be able to process transactions. We then switched the processor to TEST_APPROVE.
Meanwhile, due to another bug(timezone shift), there was a window of time where the end of month subscription hadn't been renewed. Said user then created a new CreditCard, and signed back up again.
So now, the database had, over time, a Party with a gatewayCimId. Then, a paymentMethod with a gatewayCimId, followed by a paymentMethod with out a gatewayCimId(during the point when TEST_APPROVE was active).
Upon switching the processor back to Authorize.Net, and attempting to call store#PaymentMethodInfo, there was an error from the remote that a duplicate entry already existed. This was due to moqui calling "create" instead of "update".
The attached patch fixes this, by checking to see if any previous paymentMethods have a valid gatewayCimId, and using that when the current paymentMethod doesn't have one.