Closed brent-hoover closed 7 years ago
This error is more of an edge case than I had originally thought. It only occurs when you process payments via Braintree and then later disable BT (because you enable another payment method), so then the getRefunds
method breaks because the package is not enabled. While it should probably handle this more gracefully this is also in the "just don't do that" category of workarounds.
Here are some details about this bug and what fixed it:
The origin of the bug is getAccountOptions()
in imports/plugins/included/payments-braintree/server/methods/braintreeApi.js
. It was querying the DB for data about Braintree but assumed that BT would always be the payment processor in use, which is wrong. I took a look around for code that calls that function, and I found that it is only called by getGateway()
in the same file. However, the latter function has multiple clients i.e all the other functions below it in that same file. And the only scenario where the BT plugin must be enabled is in paymentSubmit()
. So, rather than make that a condition for all other functions, I made it a condition for that one only.
However, while searching around, I stumbled on:
imports/plugins/included/payments-authnet/server/methods/authnet.js
I noticed that it has an almost identical getAccountOptions()
. I wondered why this hadn't thrown an error before, and checked again by testing it with the error-producing steps for the BT plugin. And guess what? It did. (For capturing payment, that is.) However, this one was kinda wrapped in a try...catch
, so it was displayed by Logger
or something instead of the error's entire stack trace. I fixed this one too, to make sure the plugin asserted that the Authorize.net plugin was enabled only when a user is making a payment.
Closed via #2659
Expected behavior
No errors in server console
Actual Behavior
Receive the following errors when visiting the order panel where there have been Braintree orders
Steps to Reproduce the Behavior
Versions