Closed izarutskaya closed 1 year ago
Triggered auto assignment to @jliexpensify (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
Platforms
in OP are β
)After deleting a phone contact from WS, it starts showing up in contacts as @expensify.sms in the invite page.
We are not formatting the @expensify.sms text anywhere for invite page.
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)}
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)}
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
.
Job added to Upwork: https://www.upwork.com/jobs/~014b0b1a782b2526c6
Current assignee @jliexpensify is eligible for the External assigner, not assigning anyone new.
Triggered auto assignment to Contributor-plus team member for initial proposal review - @mollfpr (External
)
After deleting a mobile contact from a WorkSpace, it starts showing up in contacts as @expensify.sms
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
we need remove OptionsListUtils.addSMSDomainIfPhoneNumber
here and add it into
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
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
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.
@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
@mollfpr Is there a duplicate for the number 0878-... in the personal details or in the invite options in your screen?
@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.
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
@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!
Triggered auto assignment to @Li357, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@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
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
@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.
@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?
@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.
How about not showing the personal details with errors at all in the invite page?
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.
@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
@pradeepmdk So, regardless of the fix on the optimistic data, do we need to format the option list to fix the existing data?
@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.
@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.
@mollfpr Sorry for the delay here. I agree that @pradeepmdk included more in the RCA. I'm going to assign them to this
π£ @mollfpr π An offer has been automatically sent to your Upwork account for the Reviewer role π Thanks for contributing to the Expensify app!
π£ @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 π
@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
@pradeepmdk I think it's okay, to raise the PR now and get it approved.
@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
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?
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
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.
@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
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.
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?
so can you help to get the bonuses as well?
Sorry, what do you mean by this?
@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
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.
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).
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
@mollfpr @jliexpensify for on your eye. https://github.com/Expensify/App/issues/25704#issuecomment-1706961089 https://expensify.slack.com/archives/C01GTK53T8Q/p1693932139950359
@pradeepmdk To be honest, I still have no idea if it is a bonus speed or not π
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.
Based on my calculations, the pull request did not get merged within 3 working days of assignment. Please, check out my computations here:
On to the next one π
Reviewing
label has been removed, please complete the "BugZero Checklist".
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:
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.
For reference, here are some details about the assignees on this issue:
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
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 Pr is ready
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:
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?
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