Introduce grace period before asking guests to verify their email address

[barryhughes]

Submission Review Guidelines:

• I have followed the WooCommerce Contributing Guidelines and the WordPress Coding Standards.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have reviewed my code for security best practices.
• Following the above guidelines will result in quick merges and clear and detailed feedback when appropriate.

Changes proposed in this Pull Request:

In our latest release, we introduced a change that requires shoppers to verify their email address before seeing the order confirmation page, or order payment page, but only if WooCommerce is unable to recognize them.

Naturally, the desire was to make this as friction-free as possible and, for example, shoppers should not have to verify their email address immediately after checking out ... unfortunately, depending on the payment gateway in use, that became possible.

Therefore, this change introduces a grace period during which email verification will not be required. Further, the grace period is filterable so can be removed (or extended) as desired.

💡 To clarify, this softens the requirement for email verification for guest shoppers. By itself, it does not touch the requirement for authenticated shoppers to be logged in before they can see their order confirmation.

How to test the changes in this Pull Request:

Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:

1. As a guest shopper, make a purchase.
2. After checking out, you should see the Order Received page.
3. Copy the URL and open this page in a new browser context (ie, an incognito mode tab or else a container tab, if you are using Firefox):
   • If we are within 10 minutes of the order being placed, then the Order Received page should be visible in both tabs (ie, the original tab where the shopper is 'known' and the separate tab where the shopper is unknown).
   • After 10 minutes, refreshing the second tab should result in you being asked to verify your email address (but in the original tab, the Order Received page should still be accessible).
4. There is no change for authenticated shoppers. In this case, if you repeat the above exercise, there is no grace period and if we cannot identify the shopper (as in the second browser context) they will be required to login.

Notes

1. You don't have to wait 10 minutes when testing, as you can temporarily modify this line of code and replace 10 * MINUTE_IN_SECONDS with 0 to simulate having waited 10 minutes. Or, if you don't like to touch core code, you could setup the following snippet in a suitable place (such as wp-content/mu-plugins/test-39191.php) then remove after testing:

<?php
add_filter( 'woocommerce_order_email_verification_grace_period', '__return_zero' );

2. I am aware of this related discussion. We still need to decide on the best course of action there (possibly following up with a second PR).

Changelog entry

• Automatically create a changelog entry from the details below.

Significance

• Patch
• Minor
• Major

Type

• Fix - Fixes an existing bug
• Add - Adds functionality
• Update - Update existing functionality
• Dev - Development related task
• Tweak - A minor adjustment to the codebase
• Performance - Address performance issues
• Enhancement

Message

Adds a grace period during which email verification will not be needed before the order confirmation (or payment) page is rendered.

Comment

[github-actions]

Test Results Summary

Commit SHA: 2343236

Test 🧪	Passed ✅	Failed 🚨	Broken 🚧	Skipped ⏭️	Unknown ❔	Total 📊	Duration ⏱️
API Tests	259	0	0	2	0	261	0m 51s
E2E Tests	189	0	0	19	0	208	13m 27s

---

To view the full API test report, click here.
To view the full E2E test report, click here.
To view all test reports, visit the WooCommerce Test Reports Dashboard.

[github-actions]

Hi @rodelgc,

Apart from reviewing the code changes, please make sure to review the testing instructions as well.

You can follow this guide to find out what good testing instructions should look like:
https://github.com/woocommerce/woocommerce/wiki/Writing-high-quality-testing-instructions

[barryhughes]

• Requesting review, but let's not merge until we have agreement from all parties (for instance, we may want to request a further review from a payments-focused team).
• Also interested in non-technical perspectives on this (from a high-level, are there any concerns with this strategy?).
• Requested a Solaris review, partly in relation to my last point but also because of the E2E changes (maybe there is an existing and more elegant approach that I missed, regarding temporarily setting filters from E2E tests...or maybe that is simply a malpractice).

[vedanshujain]

Left a minor optional comment, I tested dby eleting the cookie to simulate the condition where the session won't have the email and worked as expected. Went again after 10 minutes, and as expected, I was required to verify the email.

[rodelgc]

Done with my review and left some comments. Thanks so much for making the necessary updates on the E2E tests @barryhughes! They tested well on localhost. I requested some changes so that E2E changes you made would also work on permanent test sites.

Summary of tests I did for this PR:

• ✔️ Ran the allows guest customer to place an order test just by itself
• ✔️ Ran allows guest customer to place an order twice in a row to ensure it's repeatable. I used the arguments --retries=0 --repeat-each=2 --workers=1
• ✔️ Ran all tests in shopper/checkout.spec.js
• ⚠️ allows guest customer to place an order test failed when I ran all tests in shopper/checkout.spec.js against an external WooCommerce test site.

[coreymckrill]

@rodelgc I'm taking over this PR since Barry is AFK. I've addressed your feedback, let me know what you think.

[nigeljamesstevenson]

Thanks a lot for making these updates @coreymckrill !

⚠️ allows guest customer to place an order test still failed when I ran all tests in shopper/checkout.spec.js against a JN.

Interestingly, it was failing on the line 349 assertion

		await expect( page.locator( 'h1.entry-title' ) ).toContainText(
		 	'Order received'
		);

but looked good when I updated it to

		await expect(
			page.getByRole( 'heading', { name: 'Order received' } )
		).toBeVisible();

(which you updated on a previous similar update in this PR) - so it certainly seem those locators are more stable..
I think it would be good to get this one updated also..

@rodelgc - any idea if this was the location at which your test was failing originally?

[coreymckrill]

🤔 @nigeljamesstevenson Line 349 is in a separate test, allows existing customer to place order, which isn't modified in this PR. Can you confirm which test is failing for you?

[nigeljamesstevenson]

Line 349 is in a separate test, allows existing customer to place order, which isn't modified in this PR. Can you confirm which test is failing for you?

Doh! 🤦‍♂️ My bad @coreymckrill ! - It was indeed the allows existing customer to place order that was failing for me. I will create a task for myself and take a peek at this. allows guest customer to place an order looks great!

[coreymckrill]

Since Nigel re-ran the tests and they are working, and we already have one approval here, I'm going to go ahead and merge.

[coreymckrill]

Actually, looks like I can't until @rodelgc confirms that requested changes were made.

[lanej0]

Going to try another approval to get this out of "approval gridlock"

Narrator: the attempt didn't work.

Confirmed that tests pass locally and on a remote site and that changes have been made.

[lanej0]

I did re-run the tests locally and against a Jurassic Ninja site and everything is good. So I've unblocked this.

[coreymckrill]

Thank you!