Skip to content
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

Fix order and subscription numbers on transaction list report #1556

Merged
merged 2 commits into from
Apr 14, 2021

Conversation

luizreis
Copy link
Contributor

Fixes #1548

Changes proposed in this Pull Request

This PR fixes the order and subscription values when generating the transaction list, to fix the CSV download report.

I haven't added a changelog entry as this fix only impacts the transaction list download, which hasn't been shipped yet.

Testing instructions

  • Submit 3 orders: one with a Simple product, one with a Subscriptions product, and another with two Subscription products that are charged on different days. Your transactions list should look like this:
    image
  • Click on the "Download" button to export the data and assert that the order and subscription IDs have been exported correctly
  • Disable the Subscriptions plugin and refresh the transactions list
    • Make sure the "Subscription #" column is not shown
    • Click on the "Download" button and assert that the order IDs have been exported correctly

Make sure the transaction list is rendered correctly and no console errors are thrown when rendering it.

Missing order test:

  • Modify the add_order_info_to_object in ./includes/wc-payment-api/class-wc-payments-api-client.php:1119 to simulate an order not found response
  • Reload the transactions list and assert that no errors show up in the console

  • Added changelog entry (or does not apply)
  • Covered with tests (or have a good reason not to test in description ☝️)
  • Tested on mobile (or does not apply)

The order.value was being incorrectly assigned. Since it was not
used outside of the CSV download functionality we didn't notice
it until the table export was implemented. This commit fixes it,
fixing the report download as well.
The subscriptions.value was being incorrectly assigned. Since it
was not used outside of the CSV download functionality we didn't
notice it until the table export was implemented. This commit
fixes it, fixing the report download as well.
@luizreis
Copy link
Contributor Author

cc @kalessil as you're handling this release 😄

@kalessil kalessil self-requested a review April 14, 2021 09:46
@kalessil
Copy link
Contributor

Thanks for the ping and quick bug-fix @luizreis, I'll review and test the PR today.

Copy link
Contributor

@kalessil kalessil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, :shipit:

@luizreis luizreis merged commit c23999f into develop Apr 14, 2021
@luizreis luizreis deleted the fix/order-number-value-transaction-list branch April 14, 2021 14:59
] );
wcpaySettings.isSubscriptionsActive && orderSubscriptions
? orderSubscriptions.map( ( subscription, i, all ) => [
<OrderLink key={ i } order={ subscription } />,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, sorry for the drive-by review. Do we have a better choice than to use the index for the key? If the order changes things can get messy behind the scenes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries at all, thank you for bringing this to our attention! We have this pattern being used in some other parts of the code, though it's not that common, so I created #1789 to track it and fix it in all of the places it's used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants