Migration updates to fix Localization, uol, and paymentMethod errors on 1.0 > 1.5

[impactmass]

Fixes:

1. Reported error on Localization dashboard in comments and localization tab is broken on latest marketplace branch #2965
2. Fixes errors with "Units of length" when creating new shops
3. Updates shipping migration with new status (picked and labeled - introduced in [Marketplace] Set order(s) to a specific status #2613)
4. Error on refunds (an order with captured payment (at <1.4 Reaction), when migrated to marketplace/release1.5 branch, throws an error if you try to refund (caused by changes introduced in Cancel Order #2022)

How to test

1. Follow instructions in Create migration files for upgrade from 1.0 to 1.5 #2962 about creating orders in v 1.0 and moving back to marketplace version. While in v1.0 capture payment in one of the orders (we'll use it to test refund later)
2. After moving from <1.4 to 1.5, confirm that:

• Localization dashboard works. No errors should be thrown when it opened
• Creating new shops work fine without any Units of Length errors.

3. In the Order dashboard, visit the order with captured payment and try to do a refund. You should get a success message and no errors.

[impactmass]

Currently working on fixing the last item on this (i.e the refunds issue)

[spencern]

@impactmass great to hear, thanks for the update

[impactmass]

@spencern you can test this out now.
@kieha I tagged you as well because of the picked/labeled status you spotted. Help check if the update on that looks good

[brent-hoover]

When I go into the Localization panel and select the dropdown for "Base Unit of Length" I get "no results" and can't set it. Also probably not related to this PR but isn't there supposed to be a "save" button somewhere?

[brent-hoover]

I haven't tested if this also happens on the main branch but doing a refund on an order processed with Paypal Express gives me this error

Exception in delivering result of invoking 'orders/refunds/create': TypeError: Cannot read property 'split' of undefined
    at setParameters (http://localhost:3000/packages/modules.js?hash=b2faf2cb75c484b5324fa66592304113bc3ffa4f:1782:36)
    at sweetAlert (http://localhost:3000/packages/modules.js?hash=b2faf2cb75c484b5324fa66592304113bc3ffa4f:2116:3)
    at Object.alert (http://localhost:3000/app/app.js?hash=82043065b1802510af5eae8cbe0b84fb55332c82:60406:14)
    at http://localhost:3000/app/app.js?hash=82043065b1802510af5eae8cbe0b84fb55332c82:70505:24
    at MethodInvoker._callback (http://localhost:3000/packages/meteor.js?hash=6d285d84547b3dad9717a7c89c664b61b45ea3d8:1117:22)
    at MethodInvoker._maybeInvokeCallback (http://localhost:3000/packages/ddp-client.js?hash=df770fd9a6a02fd730939b97d266ea2b12938e95:3682:12)
    at MethodInvoker.receiveResult (http://localhost:3000/packages/ddp-client.js?hash=df770fd9a6a02fd730939b97d266ea2b12938e95:3702:10)
    at Connection._livedata_result (http://localhost:3000/packages/ddp-client.js?hash=df770fd9a6a02fd730939b97d266ea2b12938e95:4824:9)
    at onMessage (http://localhost:3000/packages/ddp-client.js?hash=df770fd9a6a02fd730939b97d266ea2b12938e95:3528:206)
    at http://localhost:3000/packages/ddp-client.js?hash=df770fd9a6a02fd730939b97d266ea2b12938e95:2908:9

[brent-hoover]

Units of Length seems to work fine after reset so something is still not right.

[spencern]

@impactmass I've identified the issue with UOL and added a migration for that.

I've been playing around with the refunds for a bit and have not been able to successfully get a refund to process for an order placed and captured on 1.0.0 to refund on this branch.

This commit tweaks 76a03de the billing migration a bit, but I'm still unable to process a refund for paypal-express.

[spencern]

I think we still need a little bit of work to make this work for refunds.

[impactmass]

Hmm. On refunds, I tested with Example Provider, Stripe and AuthNet, and thought the others will follow suit. I'll have to test with each payment method individually starting with PayPal Express. I'll check on the Localisation too. Thanks.

[spencern]

@impactmass I did not test with any of those, so it's possible this is an issue exclusively related to Paypal, but I do think in this particular instance it would be good to check each payment provider individually.

[brent-hoover]

Without even looking at the code I am going to guess that the split that's failing there is trying to parse a credit card number that doesn't exist with Paypal Express. Always need to test PPE when testing payment methods since it's the one outlier.

[brent-hoover]

Tested Paypal refunds on both the release branch and v1.0.0 and they work correctly.

[brent-hoover]

Tested placing orders on v1.0.0 and migrating to this branch and placing refunds multiple times and did not get an error. 🤔

[impactmass]

Yes. I also tested a few hours ago. Three times with Paypal Express. With refunds working on this branch. I'm going to do another run of tests to be sure that all is working correctly (with all current Payment methods).

The split error that came up in previous test might have been due to the way the response is processed here:

reaction/imports/plugins/included/payments-paypal/server/methods/express.js

Lines 337 to 340 in b49d5a1

	const pieces = response.content.split("&");
	pieces.forEach(function (piece) {
	const subpieces = piece.split("=");
	const decodedResult = result[subpieces[0]] = decodeURIComponent(subpieces[1]);

[spencern]

@zenweasel @impactmass are you suggesting that it's migrating correctly now?

[impactmass]

I think it was migrating correctly before. I haven't made any change and refunds worked in my tests for PayPal (Flow and Express), Stripe, Example. I'm currently testing AuthNet and Braintree.

If you can, test again, and see if you can reproduce the error you got before.

Update: I've tested all current payment providers.

[spencern]

@impactmass I'll run through some tests as soon as I get out of meetings this am

[spencern]

This worked for me with PayPal Express this am. I think the issues I was experiencing were probably because of the refund not appearing reactively on the order detail action view.

My guess is that this is because we do not store refunds, but make a separate call to the payment provider for them with orders/refunds/list. This is necessary because a user could grant a refund in the payment provider dashboard as well as within the Reaction instance, so we can't rely on our list of order refunds being accurate without building some type of webhook that the payment API can push to.

Merging 👍