Closed kbecciv closed 1 year ago
Triggered auto assignment to @joekaufmanexpensify (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
Platforms
in OP are β
)Old Profile picture still shows avatar on a new split money page
The cause is we get payeePersonalDetails
from participants
that is converted to optionSelector from personalDetails
with format here
https://github.com/Expensify/App/blob/9fa12f3cd6bc422d2b9723ac98d575c7ce48f05d/src/libs/OptionsListUtils.js#L216-L230
https://github.com/Expensify/App/blob/9fa12f3cd6bc422d2b9723ac98d575c7ce48f05d/src/pages/iou/SplitBillDetailsPage.js#L69
While getIOUConfirmationOptionsFromPayeePersonalDetail
fuction get data from fields that follow personalDetailsPropType
. https://github.com/Expensify/App/blob/9fa12f3cd6bc422d2b9723ac98d575c7ce48f05d/src/libs/OptionsListUtils.js#L804
Because personalDetail.avatar
and personalDetail.displayname
is undefined
, text
is email or phone number instead of display name
https://github.com/Expensify/App/blob/9fa12f3cd6bc422d2b9723ac98d575c7ce48f05d/src/libs/OptionsListUtils.js#L806
and avatar is default avatar instead of current avatar
https://github.com/Expensify/App/blob/9fa12f3cd6bc422d2b9723ac98d575c7ce48f05d/src/libs/OptionsListUtils.js#L810
We have two solution to fix payee issue
SpliBillDetailPage
, we get payeePersonalDetails
from personalDetails
instead of participants
https://github.com/Expensify/App/blob/9fa12f3cd6bc422d2b9723ac98d575c7ce48f05d/src/pages/iou/SplitBillDetailsPage.js#L69getIOUConfirmationOptionsFromPayeePersonalDetail
function, we only need return personalDetail
and other fields that we need because personalDetail
now was converted to option
return {
...personalDetail
descriptiveText: amountText,
};
In this issue, we can notice that when we open the Split Bill Details Page, the payee's avatar is not shown correctly.
The root cause behind this issue is that the default avatar URL is passed to the avatar component instead of the user avatar.
This happens because to get the payee's user details, we use the OptionsListUtils.getIOUConfirmationOptionsFromPayeePersonalDetail
function. This uses the personalDetails.avatar
to get the user's avatar. This is not correct because the payee's details in this.props.payeePersonalDetails
are of the format:
{
"icons": [
{
"source": "https://d1wpcgnaa73g0y.cloudfront.net/0fb18190762aaf5fa9f5f91acd2b54a0bbc520f1_128.jpeg",
"name": "...",
"type": "avatar"
}
],
"payPalMeAddress": "",
"phoneNumber": ""
}
If there is no props.payeePersonalDetails
, it fallbacks to this.props.currentUserPersonalDetails
, which has the personalDetails.avatar
property. A good way to fix this issue would be to use ternary operators to check if the property avatar
exists on the personalDetails
object, then use that property else look for icons[0].source
or vice versa and pass that to the UserUtils.getAvatar
accordingly.
Alternatively, we can modify the personal details prop to use avatar instead of the icons array. https://github.com/Expensify/App/blob/245364fd417e1e00ce2dc6996d0c0f030d4687a4/src/pages/iou/SplitBillDetailsPage.js#L69
I can reproduce this. Interestingly, the profile image in the LHN and in the settings tab is also not updating right away after changing it. Although both do update after refreshing the session. Whereas the image on the bill split detailed page does not.
Job added to Upwork: https://www.upwork.com/jobs/~015e350d1e95099cb9
Current assignee @joekaufmanexpensify is eligible for the External assigner, not assigning anyone new.
Triggered auto assignment to Contributor-plus team member for initial proposal review - @parasharrajat (External
)
Triggered auto assignment to @flodnv (External
), see https://stackoverflow.com/c/expensify/questions/7972 for more details.
Reviewing...
Sounds good, thanks @parasharrajat !
@parasharrajat are we good to proceed with either of these proposals?
Bumped proposals in slack here
Solution 1 from @dukenv0307 's proposal looks good to me. It seems a simple mistake that we get the payee's personal details from the participants. We do need an option structure for the payee to render but we have a function to convert the personal details to option type. As we fallback to current user personal details, it is clear that payeePersonalDetails should be some type of currentuserpersonalDetails and https://github.com/Expensify/App/blob/9fa12f3cd6bc422d2b9723ac98d575c7ce48f05d/src/components/MoneyRequestConfirmationList.js#L178 should return the same type.
cc: @flodnv
:ribbon: :eyes: :ribbon: C+ reviewed
Sharing my opinion:
I think @dukenv0307 2nd proposal looks better. Filtering personalDetails (especially in HT account) doesn't sounds good.
personalDetails
are indexed based on login so IMO, it is O(1) to get the details when we have a login. Also, OptionsListUtils.getPersonalDetailsForLogins
can be used for this purpose.
Am I missing something?
@parasharrajat As @bernhardoj mentioned above we are using filter function to get payeeDetails now and he thinks is not good. So shoud we get payeePersonalDetails
by personalDetails[reportAction.actorEmail]
instead of using filter function.
_.filter(participants, (participant) => participant.login === reportAction.actorEmail)[0];
Ah, you're right. I totally forgot about that π€¦
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
@flodnv thoughts on proceeding with this proposal?
Option 1 from @dukenv0307's proposal looks good to me, and
So shoud we get payeePersonalDetails by personalDetails[reportAction.actorEmail] instead of using filter function.
Yes
π£ @dukenv0307 You have been assigned to this job by @flodnv! Please apply to this job in Upwork 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 π
@flodnv @parasharrajat The PR is ready to review.
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 π
@flodnv, @parasharrajat, @joekaufmanexpensify, @dukenv0307 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
Hm, not overdue. PR is waiting to be deployed to prod.
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.29-11 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-06-28. :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.
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:
This one did not qualify for speed bonus, so we need to issue the following payments:
@dukenv0307 offer sent for $1,000!
@parasharrajat offer sent for $1,000!
@avi-shek-jha offer sent for $250!
@parasharrajat Could you please complete your portion of the BZ checklist when you have a chance? Thanks!
@joekaufmanexpensify I think this issue should have speed bonus because while reviewing the PR, we have another PR of the internal team for migrating from email-based indexing to account Ids here https://github.com/Expensify/App/pull/20473 and we need to wait for this PR to be merged to complete the PR of this issue.
Can you check again and correct me if I'm wrong?
Hm, were we waiting for that PR though? I see this PR was being reviewed concurrently to the one you referenced. And one comment about it, but it didn't seem to me like we were holding on it. Unless I am not understanding correctly.
And it seems like we were still actively working on this PR when the other one you referenced got merged, rather than this one being done, and just waiting for the other one to merge. So I'd still say no speed bonus here. But LMK if you're thinking about this differently!
As soon as the bug-zero checklist is complete here, we'll be all set to issue payment tomorrow!
[@parasharrajat] The PR that introduced the bug has been identified. Link to the PR:https://github.com/Expensify/App/pull/19390 [@parasharrajat] 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:https://github.com/Expensify/App/pull/19390/files#r1244341085 [@parasharrajat] 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: Not required! it was a simple mistake and proper testing and code review should have caught it. [@parasharrajat] Determine if we should create a regression test for this bug. Yes [@parasharrajat] 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. https://github.com/Expensify/App/issues/20118#issuecomment-1610200034
Verify that no errors appear in the JS console
Do you agree π or π ?
@joekaufmanexpensify Please hold my payment for now. I will ping you soon with further details.
Sounds good, thanks! I will create the regression test issue tomorrow.
I think the regression test sounds good as long as QA agrees it's not too niche... π
Sounds good. Added regression test issue above. BZ checklist is now complete!
All set to issue payment here! @parasharrajat I know your payment is held right now, but going to issue the others.
@dukenv0307 $1,000 sent and contract ended!
@avi-shek-jha $250 sent and contract ended!
Leaving this open until we are all set to pay @parasharrajat
Held pending being able to pay rajat.
Not overdue. Pending being able to issue payment here.
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:
Profile picture should be updated on a new split money page
Actual Result:
Profile picture still shows avatar on a new split money page
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: 1.3.22.0
Reproducible in staging?: n/a
Reproducible in production?: n/a
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/93399543/af62a462-2350-4325-a493-57f36d5ef618
Expensify/Expensify Issue URL:
Issue reported by: @avi-shek-jha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1685417843739759
View all open jobs on GitHub
Upwork Automation - Do Not Edit