Impact: major
Type: bugfix

Issue

Discovered a few issues with recently added refunds GraphQL queries. In general, these are blocking being able to check out and view the order on storefront, and being able to capture the payments on admin (using Stripe).

• There are extra permission checks on refunds and refundsByPaymentIds queries. getOrderQuery util function already does permission checks.
• imports/plugins/core/orders/server/no-meteor/resolvers/Order/payments.js is calling refundsByPaymentId with order.token for the token param, but that's the hashed token so it fails.
• When capturing the payment, it fails and there's a server error complaining about the ID namespace not being "reaction/order". I'm guessing somewhere there's a resolver layer that's passing an already-internal ID where an opaque ID is expected.

Solution

• Removed the extra permission checks
• There's no reason why refundsByPaymentId should be looking up the order from DB again in cases where we already have it. Maybe payments.js should just pass the whole order, and update refundsByPaymentId to skip the permission / lookup stuff when the order is passed in.
• Remove comments from the lines of code that convert IDs before calling captureOrderPayment from browser

Breaking changes

None

Testing

• With Stripe payment set up, verify that you can place an anonymous order from develop branch of the example storefront, and then capture that order payment in Reaction Admin.
• Same test but with an account order