[HOLD for payment 2024-12-05] [$250] Android - Profile - Zip code field is auto populated with invalid format when adding address
If you havenβt already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: 9.0.59-0 Reproducible in staging?: Y Reproducible in production?: Y If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5196117&group_by=cases:section_id&group_order=asc&group_id=229064 Issue reported by: Applause Internal Team
Action Performed:
- Open the Expensify app.
- Tap on "Settings" on the bottom of the screen.
- Tap on "Profile"
- Scroll down to "Address" and open the section.
- Tap on "Address Line 1"
- Complete with "123 Paddington Street" and select the "UK, London" option when it appears on suggestions.
- Verify each field is auto populated correctly and tap on "Save"
Expected Result:
When selecting an address from suggestions, all the fields should be auto populated properly and the user should be able to save this address.
Actual Result:
When selecting "123 Paddington Street, UK, London" from address suggestions, the zip code field gets auto populated with an invalid format and the user is unable to save this address.
Workaround:
Unknown
Platforms:
- [x] Android: Standalone
- [x] Android: HybridApp
- [ ] Android: mWeb Chrome
- [ ] iOS: Standalone
- [ ] iOS: HybridApp
- [ ] iOS: mWeb Safari
- [ ] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
https://github.com/user-attachments/assets/c36c3018-ca90-4e95-bdbb-1faff602c45b
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021856693783876183313
- Upwork Job ID: 1856693783876183313
- Last Price Increase: 2024-11-13
- Automatic offers:
- FitseTLT | Contributor | 104983746
Issue Owner
Current Issue Owner: @JmillsExpensify
Triggered auto assignment to @JmillsExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
Proposalβ¨
Please re-state the problem that we are trying to solve in this issue.
Android - Profile - Zip code field is auto populated with invalid format when adding address
What is the root cause of that problem?
- We only get the
outward codefor UK addresses and our regex is configred for acceptingoutward code&inward codetogether.
https://github.com/Expensify/App/blob/17cae112dd45a4cb80b8dbbab020102f70ba7407/src/CONST.ts#L3761-L3764
What changes do you think we should make in order to solve the problem?β¨
- We should update the regex to accept
outward codewithout inward code` also. We can also update the samples.
GB: {
// regex: /^[A-Z]{1,2}[0-9R][0-9A-Z]?\s*[0-9][A-Z-CIKMOV]{2}$/,
regex: /^[A-Z]{1,2}[0-9R][0-9A-Z]?\s*[0-9]?[A-Z-CIKMOV]{0,2}$/,
samples: 'LA102UX, BL2F8FX, BD1S9LU, WR4G 6LH',
},
What alternative solutions did you explore? (Optional)
Result
@JmillsExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@JmillsExpensify Eep! 4 days overdue now. Issues have feelings too...
Opening up to the community since we already have a proposal.
Job added to Upwork: https://www.upwork.com/jobs/~021856693783876183313
Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)
Edited by proposal-police: This proposal was edited at 2024-11-14 22:59:01 UTC.
Proposal
Please re-state the problem that we are trying to solve in this issue.
Android - Profile - Zip code field is auto populated with invalid format when adding address
What is the root cause of that problem?
We are only allowing outward and inward code together in the regex here https://github.com/Expensify/App/blob/17cae112dd45a4cb80b8dbbab020102f70ba7407/src/CONST.ts#L3761-L3764 but in this case it only provided the outward code, hence, the error.
What changes do you think we should make in order to solve the problem?
The outward code is 2-4 char length code before the space and the inward code is 3 character length after the space so we should update the regex to allow for allowing omitting of the inward code. We do that by making the inward code(the regex part after the space as a whole optional with ?)
We will also need to add a sample without an inward code to inform the user that omitting it is possible.
The other problem I noticed in the regex regarding inward code is inward code are three char length with the first part digit followed by the second part of two letters but the letters cannot include the letters CIKMOV according to here. But the CIKMOV in our regex is doing nothing right now so we should update that part too to exclude these letters by updating to character group of [ABD-HJLNP-UW-Z]
GB: {
regex:/^[A-Z]{1,2}[0-9R][0-9A-Z]?\s*([0-9][ABD-HJLNP-UW-Z]{2})?$/,
samples: 'LA102UX, BL2F8FX, BD1S9LU, WR4G 6LH, W1U',
},
Note that if we change the inward code part as [0-9]?[A-Z-CIKMOV]{0,2}, as suggested above, it will not enforce the inward code to be length of 3 and will generally lose the correct inward code regex rule already setup.
What alternative solutions did you explore? (Optional)
Triggered auto assignment to @mjasikowski, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@mjasikowski quick bump on this
let's go with @FitseTLT's proposal!
π£ @FitseTLT π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
@JmillsExpensify @mananjadhav @mjasikowski @FitseTLT this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
Pinged @FitseTLT on Slack to get an update on his progress.
PR will be ready today π
PR will be posted soon and I'll try to finish the review over the weekend.
Reviewing label has been removed, please complete the "BugZero Checklist".
The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.67-9 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
- https://github.com/Expensify/App/pull/52987
If no regressions arise, payment will be issued on 2024-12-05. :confetti_ball:
For reference, here are some details about the assignees on this issue:
- @mananjadhav requires payment through NewDot Manual Requests
- @FitseTLT requires payment automatic offer (Contributor)
@mananjadhav @JmillsExpensify @mananjadhav The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
BugZero Checklist:
- [x] [Contributor] Classify the bug:
Source of bug:
- [x] 1a. Result of the original design (eg. a case wasn't considered)
- [ ] 1b. Mistake during implementation
- [ ] 1c. Backend bug
- [ ] 1z. Other:
Where bug was reported:
- [x] 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
- [ ] 2b. Reported on staging (eg. found during regression or PR testing)
- [ ] 2d. Reported on a PR
- [ ] 2z. Other:
Who reported the bug:
- [ ] 3a. Expensify user
- [ ] 3b. Expensify employee
- [ ] 3c. Contributor
- [x] 3d. QA
- [ ] 3z. Other:
-
[x] [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to comment: NA
-
[x] [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: NA
-
[x] [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal Template.
I don't think we need a separate regression test for this one.
@JmillsExpensify Can you please post the payout summary so that I can raise the request?
Payment summary:
- Contributor: $250 @FitseTLT via Upwork
- Reviewer: $250 @mananjadhav via New Expensify
As for the regression test, why would we not add a regression test for international addressees? That seems to be the main issue, and one that we should test in the future to ensure it doesn't happen again.
Contributor paid via Upwork.
Version Number: 9.0.59-0 Reproducible in staging?: Y Reproducible in production?: Y If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: > https://expensify.testrail.io/index.php?/tests/view/5196117&group_by=cases:section_id&group_order=asc&group_id=22906
Because I thought it's already a part of the regression test? If it isn't then we'll need to add.
Ah, perfect, thanks for confirming. Ok, closing this issue out then, as your payment happens via New Expensify.
$250 approved for @mananjadhav