VBA - Error message for manually entered address in the field in company info and unable to proceed

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Issue was found when executing #5771

Action Performed:

1. Launch the app and login
2. Create a workspace
3. Click the workspace in the settings
4. Click Connect Bank account
5. Continue with VBA flow

Expected Result:

After entering address manually in company info page user should be able to proceed to personal info page

Actual Result:

Error message displayed as "Please enter a valid street address that is not a PO Box" in company address field and unable to proceed

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number: v1.1.7-12
Reproducible in staging?: Yes
Reproducible in production?: Credentials will not work in production
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Expensify/Expensify Issue URL:
Issue reported by: Applause
Slack conversation:

View all open jobs on GitHub

[OSBotify]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Triggered auto assignment to @robertjchen (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[kevinksullivan]

closing out as this is not a valid address and working correctly. We could handle the message more descriptively, but let's kick that to polish.

[isagoico]

@kevinksullivan this is reproducible with valid addresses and each time the user decides to don't use the address picker (enter the address manually)

[kevinksullivan]

Removing as a deploy blocker, but definitely an issue we need to resolve. Also discussing longer term plans here, so perhaps we hold on a larger discussion @trjExpensify @JmillsExpensify ?

https://expensify.slack.com/archives/C020EPP9B9A/p1634274922234500

[robertjchen]

Switching to Weekly pending additional discussion

[trjExpensify]

Yeah, I think the main enhancement for the address field is to be able to modify the content. I'm open to an additional unit/apt: field, but I wonder if it's required if the ability to edit is supported.

@aldo-expensify had some thoughts on that here.

[aldo-expensify]

@kevinksullivan this is reproducible with valid addresses and each time the user decides to don't use the address picker (enter the address manually)

Yep, it is not obvious at all that the user MUST select a result from the picker

[aldo-expensify]

There are three things that I think we should improve

Selecting a result from the autocomplete is mandatory and is not obvious

One possible solution could be to clear the field on blur if the user doesn't select anything to make it more obvious that he has to select something

Results that are not an "address", but a "route"

In some cases we offer results in the autocomplete that don't have enough information. I.e, search for "25220 Quail Ridge Road, Escondido, CA 97027" and click the result: "Quail Ridge Road, Escondido, CA, USA".

I would be ideal to avoid showing results that we reject, the PR mentioned below doesn't do that, it just rejects the address with missing parts after it has been selected.

Related GH issue: #5840
Related PR: #5854

Results that are an "address", but are missing something

We found that some results in NY are missing the "locality" field, which we use as the city. This has been fixed in the PR below by using the field "sublocality" when "locality" is missing. This may be fixed, but is hard to know if other weird cases could appear. We are going to be logging when the user chooses an incomplete address result.

Related GH issue: #5867
Related PR: #5950

[trjExpensify]

Selecting a result from the autocomplete is mandatory and is not obvious
One possible solution could be to clear the field on blur if the user doesn't select anything to make it more obvious that he has to select something

Why is it mandatory? Isn't the other solution here to allow for manual input or modifying a search result returned? e.g adding in an apt/unit number etc.

It would be ideal to avoid showing results that we reject

I agree with this sentiment. Showing results we reject isn't helpful.

In some cases we offer results in the autocomplete that don't have enough information. I.e, search for "25220 Quail Ridge Road, Escondido, CA 97027" and click the result: "Quail Ridge Road, Escondido, CA, USA".

In this example, why aren't we returning 25220 Quail Ridge Road, Escondido, CA 97027 in the results? Or is this to say that we are, but a user has selected a different result i.e Quail Ridge Road, Escondido, CA, USA?

We are going to be logging when the user chooses an incomplete address result.

This is a great idea to keep 👀 on it!

[aldo-expensify]

Selecting a result from the autocomplete is mandatory and is not obvious
One possible solution could be to clear the field on blur if the user doesn't select anything to make it more obvious that he has to select something

Why is it mandatory? Isn't the other solution here to allow for manual input or modifying a search result returned? e.g adding in an apt/unit number etc.

After a result is selected, we take 4 information pieces from it: city, address (street name + number), zipCode and state. I think allowing manual input is an option when google isn't giving us the right address, but I think it has not been considered yet because, after fixing this, we don't know if that case exists.

If we want the user to be able to input manually, we will have to put back the 4 mentioned fields.

In some cases we offer results in the autocomplete that don't have enough information. I.e, search for "25220 Quail Ridge Road, Escondido, CA 97027" and click the result: "Quail Ridge Road, Escondido, CA, USA".

In this example, why aren't we returning 25220 Quail Ridge Road, Escondido, CA 97027 in the results?

We are returning it

Or is this to say that we are, but a user has selected a different result i.e Quail Ridge Road, Escondido, CA, USA?

Yes

If you search "25220 Quail Ridge Road, Escondido, CA 97027", we show these results (and some others):

• Quail Ridge Road, Escondido, CA, USA (appears first)
• 25220 Quail Ridge Road, Escondido, CA 97027

If the user clicks "Quail Ridge Road, Escondido, CA, USA", we give a validation error when he clicks "Save & Continue"

[mvtglobally]

Issue reproducible during KI retests.

[robertjchen]

Is the suggested fix here to be more specific with the error message? Otherwise, it's working as intended since it's preventing us from continuing with an invalid address.

[kevinksullivan]

Hmm this feels pretty rough still. Additionally, this means it's impossible to enter an apartment number if not shown, right? I believe @MitchExpensify ran into this problem as well. I think address lookup works really well for most cases, but it completely blocks users from going forward as well. I wonder if we pursue an alternative solution that auto-fills information but still lets a user manually edit it? Because address lookup is realistically too strict for individuals who often times will have a unit number that doesn't populate.

[aldo-expensify]

Hmm this feels pretty rough still. Additionally, this means it's impossible to enter an apartment number if not shown, right? I believe @MitchExpensify ran into this problem as well. I think address lookup works really well for most cases, but it completely blocks users from going forward as well. I wonder if we pursue an alternative solution that auto-fills information but still lets a user manually edit it? Because address lookup is realistically too strict for individuals who often times will have a unit number that doesn't populate.

Yep, it is impossible to enter an apartment number. I agree with that we should offer an alternative where the user can enter / modify things manually. I could work on that if we define how it should work :)

[mvtglobally]

Issue reproducible during KI retests.

[trjExpensify]

Yep, it is impossible to enter an apartment number. I agree with that we should offer an alternative where the user can enter / modify things manually. I could work on that if we define how it should work :)

So what are the decisions to make here?

1. Allow the user to simply modify the content of the field to append an apt number?
2. Add an adjacent field to enter the apt/unit:

Anything else?

[aldo-expensify]

@trjExpensify

The decided way to go was discussed here: https://expensify.slack.com/archives/C03TQ48KC/p1635812089454700

In summary:

• Always show all inputs for: city , state ,street + number + (apt number), zip code
• The input street + number will keep its autocomplete behaviour. If the user selects a result, we will populate other fields.
• The user will be allowed to manipulate any of the address components

[robertjchen]

That sounds good to me! @aldo-expensify looks like you're already working on PR for this? 🙏

[aldo-expensify]

That sounds good to me! @aldo-expensify looks like you're already working on PR for this? 🙏

Yep! this PR: #6200

[robertjchen]

Re-assigned to you! 😅 Let me know if I can help with anything 👍

[kevinksullivan]

I love the auto-fill / edit solution. Using this app Learn & Earn as an example, they had an awesome KYC experience overall, and the auto-fill allowed me to easily make any changes necessary or add an apt number with no issues.

[aldo-expensify]

Resolving conflicts in PR, after that it should be ready for review.

[aldo-expensify]

I love the auto-fill / edit solution. Using this app Learn & Earn as an example, they had an awesome KYC experience overall, and the auto-fill allowed me to easily make any changes necessary or add an apt number with no issues.

this looks good in my opinion, close to what we are doing in the PR, except for the Apt number field. For now, that will remain in the same field with the street name/number.

[aldo-expensify]

I'm closing this because with the current state of the address field, a user should be able to input an address manually if the google search results aren't useful:

Screen.Recording.2021-11-22.at.2.32.24.PM.mov

Remaining developments and comments on the address inputs will be in this GH issue / PR