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

feat: For Shipping Zones Zip Regex - Correctly handle UK postcodes redacted by Apple Pay #3592

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

majikandy
Copy link

@majikandy majikandy commented Nov 6, 2024

Improved upon idea in #2646 So that user does not need to add special syntax into shipping zones regex

Fixes #2645

Changes proposed in this Pull Request:

UK Postcodes consist of an outcode 2,3 or 4 characters long, then an optional space, and then 3 more characters.

Apple Pay intelligently truncates the UK postcode removing the outcode. Futhermore It keeps the optional space at the end of it's redacted string if it was there in the original.

With this behaviour known, we need to code it more intelligently when padding with stars than just assuming a UK postcode is 7 characters long.

This PR implements that behaviour.

This also enabled full support for the Regex within Shipping Zones so that Regex like

N1 * (N1 space star) correctly match postcodes like N12AA and N1 2AA to mean all N1 postcodes and correctly avoids accidental matches of N10, N11, N12 postcodes etc

This enabled proper bevaviour of shipping zones such that a user can ship to N1 for one price and N19 for another. The main scenario of this is an artistan seller/maker who will drive or walk to N1 to hand deliver, but won't to N19 without a fee (or even not at all)

Questions for the PR author:

  • How can this code break?
    If Apple changed the way it redacts the postcodes
  • What are we doing to make sure this code doesn't break?
    if the truncated postcode excluding space is more than 5 characters, it just returns it as is as it is highly likely it is has not been truncated. This is because it would be a bad implementation by a third party to truncate a postcode to 5 chars for privacy reasons, when many true valid postcodes are 5 characters long.

Also the only impact of the postcode not validating is that shipping zones come up wrong due to non matches of the truncated/altered postcode. Therefore the behaviour cannot be made any worse than now.

Testing instructions

  • Admin: Enable Apple pay via Stripe on the Basket

  • Admin: Setup shipping zones with a regex like 'N1 *' for free and 'N10 * for a fee.

  • Customer: Setup addresses in your real apple pay on your device eg N1 4AB, N10 5BC, N11AA, N191AA (you can set any addresses as you don't need to complete purchases or validate addresses)

  • Customer: Add items to the basket

  • Customer: for each of the addresses in apple pay

    • Trigger apple pay,
    • choose address,
    • see correct option.
    • Now press cancel, refresh the page,
    • see the redacted address like N1 *** near the delivery options on the screen (also here the options should be correctly available as it uses the same code to determine it and the triggering of apple pay actually updates that address)

Unit tests not added as this piece of code yet as it didn't have any before - however can easily add some if this change is likely to progress into the codebase


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

Post merge

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

Successfully merging this pull request may close these issues.

Apple Pay postcode backfill blocks address checks
1 participant