[HOLD for payment 2023-09-27] [$1000] After deleting a mobile contact from a WorkSpace, it starts showing up in contacts as @expensify.sms

[izarutskaya]

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

---

Action Performed:

1. Open https://staging.new.expensify.com/
2. Log in with any of your logins
3. Create a new workspace or open an existing one
4. Open the workspace & click on "Members"
5. Click on 'Invite' button
6. Search for an invalid phone number (+2523234211)
7. Select the user > click on "Next" > click on "Invite"
8. Select the user & click on the "Remove" button
9. Click on 'Invite' button

Expected Result:

The previously added contact should appear as a phone number, without the @expensify.sms termination

Actual Result:

A previously added contact is displayed as a phone number with @expensify.sms at the end

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [ ] Android / native
• [ ] Android / Chrome
• [ ] iOS / native
• [ ] iOS / Safari
• [x] MacOS / Chrome / Safari
• [x] MacOS / Desktop

Version Number: v1.3.58-0

Reproducible in staging?: Y

Reproducible in production?: Y

If this was caught during regression testing, add the test name, ID and link from TestRail:

Email or phone of affected tester (no customers):

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

https://github.com/Expensify/App/assets/115492554/4fc01bef-7aa5-451c-82a0-60e30e1ca24f

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~014b0b1a782b2526c6
• Upwork Job ID: 1696345977519468544
• Last Price Increase: 2023-08-29
• Automatic offers:
• mollfpr | Reviewer | 26454047
• pradeepmdk | Contributor | 26454050

[melvin-bot[bot]]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot[bot]]

Bug0 Triage Checklist (Main S/O)

• [x] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• [x] This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• [x] This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• [x] This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• [x] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[c3024]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After deleting a phone contact from WS, it starts showing up in contacts as @expensify.sms in the invite page.

What is the root cause of that problem?

We are not formatting the @expensify.sms text anywhere for invite page.

What changes do you think we should make in order to solve the problem?

We can remove the sms domain in CheckboxListItem with formatPhoneNumber of LocalePhoneNumber by importing like this

import * as LocalePhoneNumber from '../../libs/LocalePhoneNumber';

and update this

{LocalePhoneNumber.formatPhoneNumber(item.text)}

at https://github.com/Expensify/App/blob/d42967aa5f472df24d1150f40490fe99d1716572/src/components/SelectionList/CheckboxListItem.js#L69

We can wrap the alternate text as well with this similar to the getParticipantsOptions of the OptionLisUtils if we want to avoid it in cases for alternate text as well just to be safe but presently alternateText has no @expensify.sms portion to be removed. https://github.com/Expensify/App/blob/d42967aa5f472df24d1150f40490fe99d1716572/src/components/SelectionList/CheckboxListItem.js#L76

{LocalePhoneNumber.formatPhoneNumber(item.alternateText)}

What alternative solutions did you explore? (Optional)

Solution 1 We can instead format the text directly in the OptionListUtils function formatMemberForList here https://github.com/Expensify/App/blob/a5ab459e731badcce4faea56fbce074a54f8495b/src/libs/OptionsListUtils.js#L1047 with LocalePhoneNumber.formatPhoneNumber and do it similarly for alternateText, name in Avatar if necessary. This formatMemberForList function is used only for invite page and presently we are not showing any tooltip for CheckboxItem so this solution and the primary solution has no difference. But if we like to show tooltip later, then we need to remove .sms from the name of the tooltip as well. If and when tooltip is implemented, the text there need to be formatted again if we implement the first solution. This solution is also preferable because the function is meant to format and the phone number formatting logic also is better to be implemented in this.

Solution 2 (too big a refactor for this bug) Use the getParticipantOptions (because this function has already proper phone number formatting logic) of OptionListUtils to get participant details in workspace members and invite pages instead of individually formatting in the page itself (as done in members page) or each with formatMemberForList (in contacts page) and use the regular logic of using icons object with MultipleAvatars component to show Avatar and tooltips as earlier in CheckboxListItem.

[jliexpensify]

Confirmed that we shouldn't show @expensify.sms anywhere

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~014b0b1a782b2526c6

[melvin-bot[bot]]

Current assignee @jliexpensify is eligible for the External assigner, not assigning anyone new.

[melvin-bot[bot]]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mollfpr (External)

[pradeepmdk]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After deleting a mobile contact from a WorkSpace, it starts showing up in contacts as @expensify.sms

What is the root cause of that problem?

Root cause is when we invite displayName stored in with domainName@expensify.sms in optimisticData when we invite https://github.com/Expensify/App/blob/a5ab459e731badcce4faea56fbce074a54f8495b/src/libs/actions/Policy.js#L331

we are creating OptionsListUtils.addSMSDomainIfPhoneNumber for storing the optimisticData https://github.com/Expensify/App/blob/fd755ee94ee9aed354e528abc0b62d19a90802c2/src/libs/PersonalDetailsUtils.js#L118

What changes do you think we should make in order to solve the problem?

1) https://github.com/Expensify/App/blob/a5ab459e731badcce4faea56fbce074a54f8495b/src/libs/actions/Policy.js#L331

we need remove OptionsListUtils.addSMSDomainIfPhoneNumber here and add it into

https://github.com/Expensify/App/blob/fd755ee94ee9aed354e528abc0b62d19a90802c2/src/libs/PersonalDetailsUtils.js#L115

and https://github.com/Expensify/App/blob/a5ab459e731badcce4faea56fbce074a54f8495b/src/libs/actions/Policy.js#L398

so only we have this addSMSDomainIfPhoneNumber for login not for the displayName

2) or just formatting the displayName: LocalePhoneNumber.formatPhoneNumber(login), https://github.com/Expensify/App/blob/fd755ee94ee9aed354e528abc0b62d19a90802c2/src/libs/PersonalDetailsUtils.js#L118

Addional fix Needed same issue for other places

we need fix some other place too 1) RequestMoney api optimisticData data https://github.com/Expensify/App/blob/fd755ee94ee9aed354e528abc0b62d19a90802c2/src/libs/actions/IOU.js#L447 here participant.login is without domain so we need switch payerEmail to login 2) split api above solution needed here https://github.com/Expensify/App/blob/fd755ee94ee9aed354e528abc0b62d19a90802c2/src/libs/actions/IOU.js#L837

[mollfpr]

Thanks for the proposals!

@c3024 @pradeepmdk Why does it only happen on the failing phone number deleted? The other phone number that is valid also has the domain in their displayName and login, but it displays just fine.

[pradeepmdk]

@mollfpr because when api falling onyxData empty but we stored in the optimisticData with OptionsListUtils.addSMSDomainIfPhoneNumber so that its happening. so that in my proposal remove the addSMSDomainIfPhoneNumber on display name

https://github.com/Expensify/App/blob/a5ab459e731badcce4faea56fbce074a54f8495b/src/libs/actions/Policy.js#L346

[c3024]

@mollfpr Is there a duplicate for the number 0878-... in the personal details or in the invite options in your screen?

[mollfpr]

@pradeepmdk Sorry, I don't understand your point. In the above image, the valid phone number also has the domain, but it displays fine; why is that?

@c3024 Nope, it just added.

[c3024]

If display name has expensify.sms then I think it should show expensify.sms because we are not stripping it anywhere. Just for clarification, there are no two options or personal details one with +62878732837@expensify.sms and another with 0 878-732-837 on your screen, right? @mollfpr

[mollfpr]

@c3024 Thanks, I understand now the issue is. Your alternative solution 1, looks good. We format the text and alternate text on the WorkspaceMembersPage, so I think we need to do the same for the invite page.

I think we don't have anything wrong with the API action and the optimistic data, so I prefer to keep it that way.

Let's go with @c3024 alternative solution 1 in their proposal. For note, I think we just need to format the text and alternateText, no need for the avatar.

🎀 👀 🎀 C+ reviewed!

[melvin-bot[bot]]

Triggered auto assignment to @Li357, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[pradeepmdk]

@mollfpr This issue was when we storing optimisticData in Onyx whenever API falling. https://github.com/Expensify/App/blob/a5ab459e731badcce4faea56fbce074a54f8495b/src/libs/actions/Policy.js#L331

https://github.com/Expensify/App/blob/a5ab459e731badcce4faea56fbce074a54f8495b/src/libs/actions/Policy.js#L346

we need to fix the root case for avoiding the displayName store as @expensify.sms

OptionsListUtils.js this will not solve all the places it will work only this place.

If you want check this exactly when api failed case phone number when we go to create task assignee means same like this format only it will displayed, same for moneyrequest, split bill as well

[pradeepmdk]

@mollfpr @Li357

I think we don't have anything wrong with the API action and the optimistic data, so I prefer to keep it that way.

this is wrong right? the display name with @expensify.sms.This happened only from optimisticData but API give correct response without @expensify.sms

If the AddMembersToWorkspace api is sucess means personalDetailsList displayname come with without @expensify.sms:

if we fix the displayname. all the place working correctly.

[Li357]

@pradeepmdk Seems like you're right. I would prefer to fix the optimistic data generated, can you demonstrate this fix working everywhere we currently show @expensify.sms?

[mollfpr]

@pradeepmdk You have a good point on the optimistic data, but fixing the optimistic data is not enough. We also need to format the option list too. Otherwise, the issue still persists for the wrong existing data.

I also suspect that this issue is a regression from https://github.com/Expensify/App/pull/22904.

[c3024]

How about not showing the personal details with errors at all in the invite page?

[mollfpr]

In other PR https://github.com/Expensify/App/pull/23157, we have optimistic with displayName formatted.

The error personal details should be removed in #22904, but the failure data setup is removed in https://github.com/Expensify/App/pull/23947

Edit: It seems intended so we can still see the RBR in the workspace members page.

[pradeepmdk]

@mollfpr @Li357 but we can format only displayname right? displayName: LocalePhoneNumber.formatPhoneNumber(login), This will solve other places too.

its working fine for me https://drive.google.com/file/d/1t-FM8J5xXghkqffkZb8VVLH2g8JRo9oP/view?usp=sharing

this one seems refactoring the https://github.com/Expensify/App/pull/22904 optimisticData of personalDeatils only so you could find here the formatting one.

and this one https://github.com/Expensify/App/pull/23947 Due to refactoring they are removed formatting one https://github.com/Expensify/App/blob/ffab9162da0b10157290face92431271b306e639/src/libs/actions/Policy.js

https://github.com/Expensify/App/pull/23157, the formatting one was before refactoring so you could not find the getNewPersonalDetailsOnyxData method https://github.com/tienifr/App/blob/9eba1ddbe07aabf82f8b15f7bbc82dc44197ffcf/src/libs/actions/Policy.js#L353

fixing the optimistic data is not enough. We also need to format the option list too. Otherwise, the issue still persists for the wrong existing data.

since i also added same solution but displayname fix only changes reflected to other places as well like moneyrequest, splitbill etc. so that i removed that solution but here RCA is optimistic data only

[mollfpr]

@pradeepmdk So, regardless of the fix on the optimistic data, do we need to format the option list to fix the existing data?

[pradeepmdk]

@mollfpr we need fix the optimistic data. for existing data format only we can use optionList (formatMemberForList)but this will work only for workspace.. not for the split money, moneyrequest. when they logout and login existing data will removed because that is failed data only so not storing in the backend.

[mollfpr]

@Li357 What is your call here? I think @pradeepmdk got the RCA correct. I didn't get that at first until several looked up the history changes.

[Li357]

@mollfpr Sorry for the delay here. I agree that @pradeepmdk included more in the RCA. I'm going to assign them to this

[melvin-bot[bot]]

📣 @mollfpr 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job

[melvin-bot[bot]]

📣 @pradeepmdk 🎉 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 📖

[pradeepmdk]

@Li357 @mollfpr need to wait for merge freeze to complete or else can I raise the PR now? https://expensify.slack.com/archives/C01GTK53T8Q/p1693347701566439

[mollfpr]

@pradeepmdk I think it's okay, to raise the PR now and get it approved.

[pradeepmdk]

@mollfpr so is that eligible for getting the bonus as well? because they mentioned here https://expensify.slack.com/archives/C01GTK53T8Q/p1693407966629239?thread_ts=1693347701.566439&cid=C01GTK53T8Q

[mollfpr]

Usually, the bonus will be counted from when you got assigned until the C+ approves the PR.

@jliexpensify Could you confirm if the merge freeze will affect the speed bonus, or will no bonus be applied at this stage?

[jliexpensify]

Great question - so I would imagine that you could raise a PR but it won't be merged/deployed unless it's related to what Vit has outlined here.

For bonuses, I'm not 100% sure how it works with a freeze - let me check in with the team here!

EDIT: https://expensify.slack.com/archives/C01SKUP7QR0/p1693812853334999

[jliexpensify]

Looks like there are no urgency bonuses for anything not related to receipt scanning and distance requests.

Specifically Vit's comment:

i think to make this fair consider that if the PR is non-urgent ie non related to the above topics, you dont have to rush as it would most likely not be merged in the time for the urgency bonus.

[pradeepmdk]

@mollfpr Pr is ready for review @jliexpensify so after the merge freeze is complete we are getting eligible bouns? if this PR is raised after merge freeze

[jliexpensify]

My understanding is that no bonuses will be paid, since they won't be merged in time. The only scenario would maybe be you raising a PR as the merge freeze is ending, and it gets merged pretty soon after.

[pradeepmdk]

So here anyway this is not urgent and not going to merge until the merge freezes. @mollfpr @jliexpensify so can you help to get the bonuses as well?

[jliexpensify]

so can you help to get the bonuses as well?

Sorry, what do you mean by this?

[pradeepmdk]

@jliexpensify

The only scenario would maybe be you raising a PR as the merge freeze is ending, and it gets merged pretty soon after.

I thought if we raised pR after merge freeze chance to get bouns. but now I already raised PR. What should I do? this is a little bit confusing to me

[mollfpr]

The only scenario would maybe be you raising a PR as the merge freeze is ending, and it gets merged pretty soon after.

This doesn't make sense to me. There will be no difference in raising the PR now or later.

but now I already raised PR. What should I do? this is a little bit confusing to me

This is fine. I'll be relieved to get the job done as soon as possible.

[jliexpensify]

Hey sorry everyone, maybe I haven't communicated this clearly: my understanding from what Vit has posted is that bonuses won't be paid out during this merge freeze, since we're pausing on all non-essential PR's for the next week.

For my statement here:

The only scenario would maybe be you raising a PR as the merge freeze is ending, and it gets merged pretty soon after.

I was thinking that if you raised a PR pretty much the same time as we lifted the merge freeze, then you might qualify for a bonus (as the merge freeze would be lifted).

[mollfpr]

raised a PR

~@jliexpensify Do you mean merged?~ I understand now this may be considered the time for reviewing the PR, so makes sense to me.

The PR seems to be fixing the issue on the request money flow (manual and distance), so probably the PR still can be merged?

cc @Li357

[pradeepmdk]

@mollfpr @jliexpensify for on your eye. https://github.com/Expensify/App/issues/25704#issuecomment-1706961089 https://expensify.slack.com/archives/C01GTK53T8Q/p1693932139950359

[mollfpr]

@pradeepmdk To be honest, I still have no idea if it is a bonus speed or not 😅

[jliexpensify]

I think if the PR is related to either SmartScanning or distance requests, then it would very likely be prioritised, and you'd get the bonus. But this issue is around @expensify.sms showing up right? So it's not really related to either.

[melvin-bot[bot]]

Based on my calculations, the pull request did not get merged within 3 working days of assignment. Please, check out my computations here:

• when @pradeepmdk got assigned: 2023-09-01 15:49:35 Z
• when the PR got merged: 2023-09-11 14:41:24 UTC
• days elapsed: 5

On to the next one 🚀

[melvin-bot[bot]]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot[bot]]

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.3.68-17 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/26638

If no regressions arise, payment will be issued on 2023-09-20. :confetti_ball:

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• [ ] External issue reporter
• [ ] Contributor that fixed the issue
• [ ] Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @pradeepmdk requires payment offer (Contributor)
• @mollfpr requires payment offer (Reviewer)

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot[bot]]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [ ] [@mollfpr] The PR that introduced the bug has been identified. Link to the PR:
• [ ] [@mollfpr] 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:
• [ ] [@mollfpr] A discussion in #expensify-bugs 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:
• [ ] [@mollfpr] Determine if we should create a regression test for this bug.
• [ ] [@mollfpr] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [ ] [@jliexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[pradeepmdk]

@mollfpr Pr is ready