Add Transaction Details dispute footer for disputes not awaiting a response #7047
Conversation
…ic/woocommerce-payments into add/6923-dispute-details-notice
Test the buildOption 1. Jetpack Beta
Option 2. Jurassic Ninja - available for logged-in A12s🚀 Launch a JN site with this branch 🚀 ℹ️ Install this Tampermonkey script to get more options. Build info:
Note: the build is updated when a new commit is pushed to this PR. |
|
Size Change: +1.35 kB (0%) Total Size: 1.41 MB
ℹ️ View Unchanged
|
…details-not-awaiting-response
client/tracks/index.js
Outdated
| @@ -95,6 +95,8 @@ const events = { | |||
| 'wcpay_subscriptions_account_not_connected_product_modal_finish_setup', | |||
| SUBSCRIPTIONS_ACCOUNT_NOT_CONNECTED_PRODUCT_MODAL_DISMISS: | |||
| 'wcpay_subscriptions_account_not_connected_product_modal_dismiss', | |||
| DISPUTE_RESOLVED_MESSAGE_VIEW_BUTTON_CLICK: | |||
| 'wcpay_dispute_resolved_message_view_button_click', | |||
There was a problem hiding this comment.
This tracks event is better named 😁
Though I still wonder if the user action here is different things (which we'd need to dig into props to discover). What are the actions here – view_dispute_details_click
OK that confirms how confused I was! 🤣 These buttons all do one action – viewing the dispute details (including submitted evidence etc). So the button function (and the user action / tracks event) is something like wcpay_payment_details_view_dispute_details_click or wcpay_payment_details_view_dispute_submission_click – is that accurate or do I misunderstand?
There was a problem hiding this comment.
Renamed again to wcpay_payment_details_view_dispute_evidence_button_click
Which aims to represent "the merchant clicked the payment details View dispute evidence details button".
There was a problem hiding this comment.
This DisputeDetails component has been renamed to DisputeAwaitingResponseDetails to clarify it's intended use and content.
There was a problem hiding this comment.
Looking good! I retested a couple of disputes and confirmed the correct footers show.
General lost (e.g. timeout, or failed challenge)
Merchant accepted lost
While testing, I noticed some extra padding in the dispute details / take action box (also on develop). Ah… I see this is the focus of #7206 #7093.
client/payment-details/dispute-details/dispute-resolution-footer.tsx
Outdated
Show resolved
Hide resolved
| path: '/payments/disputes/challenge', | ||
| id: dispute?.id, | ||
| } ); | ||
| getHistory().push( challengeUrl ); |
There was a problem hiding this comment.
Hiding the url/href in the onClick handler impacts usability in 2 ways:
- Can't cmd-click to open in new tab (moderate)
- Can't hover over button to see URL (minor)
However I can see that using History::push is much faster and nicer experience (is there a way we can have that AND retain normal browser link handling?). I'd like to get aligned on how we use history API and "soft" page loads in WooPayments and Woo admin generally. Personally I like using regular links as much as possible, so the user has more control (e.g. can open in separate tabs).
Not a blocker, just sharing my personal opinion out loud - in my testing I've been frustrated when various Woo admin links don't let me open a new tab!
There was a problem hiding this comment.
I totally agree, thanks for pointing this out. I've addresses this in fa71276, let me know what you think!
As a workaround (solution), I've wrapped each Button with Link from @woocommerce/components, which already handles the getHistory().push() functionality while allowing the CMD-click for native.
Using Button without the href/onClick provides the correct UI.
There was a problem hiding this comment.
Sounds good to me! So is this a pattern you recommend in general? e.g. <Link><Button /></Link>?
Tested one of the buttons and it's fast and flexible 🙌🏻
There was a problem hiding this comment.
I found a little caveat with this approach – CMD+click won't run the onClick handler provided to Link, therefore, tracks event recording should be conducted within the Button's onClick.
Updated in e6e38ea
|
I've conducted a final round of testing and have added this PR to the merge queue 🚀 |
Fixes #6927
Changes proposed in this Pull Request
This PR renders a
CardFooterwith a message and call-to-action button for disputes that are not awaiting a response from the merchant.TypeScript interfaces for
DisputeandBalanceTransactionhave been updated with properties relevant to dispute metadata and fees.A new tracks event
wcpay_payment_details_view_dispute_evidence_button_clickwill be fired when clicking the view dispute details button.The
DisputeDetailscomponent has been renamedDisputeAwaitingResponseDetailsto clarify the intent and distinguish it from this PR's newDisputeResolutionFootercomponent.See design on Figma: RiEQmaKRI7u9USAI3lyZz0VX-fi-7047_436287
Testing instructions
update_option( '_wcpay_feature_dispute_on_transaction_page', '1' );in WP Console or wp-cli.This dispute was lost on December 14, 2023. The $15 USD fee has been deducted from your account, and the disputed amount returned to the cardholder. Learn more about preventing disputes.#f2f4f5)disputes.metadata.__closed_by_merchant)This dispute was accepted and lost on June 16, 2023. The $15 USD fee has been deducted from your account, and the disputed amount returned to the cardholder. Learn more about preventing disputes.#f2f4f5)dispute.metadata.__evidence_submitted_at)This dispute was lost on December 14, 2023 due to non-response. The $15 USD fee has been deducted from your account, and the disputed amount returned to the cardholder. Learn more about preventing disputes.#f2f4f5)You submitted evidence for this dispute on June 16, 2023. The cardholder’s bank is reviewing the case, which can take 60 days or more. You will be alerted when they make their final decision. Learn more about the dispute process.$wp-blue-0Good news! You won this dispute on December 14, 2023. The disputed amount and the dispute fee have been credited back to your account. Learn more about preventing disputes.#f2f4f5)Testing tip: To progress a test mode dispute to each new status:
won: Provide winning evidence by submitting the challenge form withwinning_evidencein the “Additional details” field.under_review: Provide any evidence by submitting the challenge form.lost(losing evidence): Provide winning evidence by submitting the challenge form withlosing_evidencein the “Additional details” field.lost(accepted): Accept the dispute using theAcceptdispute button on the Dispute Details screen.lost(no response): no way to test this organically in test mode AFAIK. I mocked this state my setting the propertydispute.metadata.__evidence_submitted_at = undefined;within the<DisputeDetails />component (code ref).Screenshots
Lost via challenge
Accepted
Lost via non-response
Under Review
Won
Small viewport
npm run changelogto add a changelog file, choosepatchto leave it empty if the change is not significant. You can add multiple changelog files in one PR by running this command a few times.Post merge