Closed lanitochka17 closed 1 month ago
Triggered auto assignment to @slafortune (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.
@slafortune FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors
"To" field displays Hidden instead of invoice receiver
When we calculate participants in case of invoice room here we do not pass accountID
so at confirmation step participantAccountID
will be equal to -1 and display hidden user here
We need to pass accountID
when we calculate participants
participants = [
{reportID: chatReport?.reportID, selected: true, accountID: chatReport?.invoiceReceiver?.accountID},
{
policyID: chatReport?.policyID,
isSender: true,
selected: false,
},
];
https://github.com/Expensify/App/assets/171708823/96e67610-bbd0-4b46-b3e5-b5235d4e0b37
Job added to Upwork: https://www.upwork.com/jobs/~013c79d3cbeca420a5
Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External
)
Hidden user is shown in the To section of send invoice from a chat.
On the confirmation page, the participant is mapped from the transaction participant data. https://github.com/Expensify/App/blob/904d49d0101b78bccc3fdb2c26e361ff94b61585/src/pages/iou/request/step/IOURequestStepConfirmation.tsx#L139-L149
If the participant has an accountID, we map it with getParticipantsOption
, otherwise we map it with getReportOption
. If we initiate the send invoice from the room/chat, the participant will contain a reportID
, but not accountID
.
https://github.com/Expensify/App/blob/904d49d0101b78bccc3fdb2c26e361ff94b61585/src/libs/actions/IOU.ts#L6651-L6659
With this information, we expect the participant to be mapped with getReportOption
, however, this PR defaults the accountID to -1 (we previously defaulted it to 0).
https://github.com/Expensify/App/blob/904d49d0101b78bccc3fdb2c26e361ff94b61585/src/pages/iou/request/step/IOURequestStepConfirmation.tsx#L142
So, this condition thinks that the participant is a user. https://github.com/Expensify/App/blob/904d49d0101b78bccc3fdb2c26e361ff94b61585/src/pages/iou/request/step/IOURequestStepConfirmation.tsx#L147
We have 2 options:
return participantAccountID > 0 ? OptionsListUtils.getParticipantsOption(participant, personalDetails) : OptionsListUtils.getReportOption(participant);
@bernhardoj's proposal looks good to me!
๐ ๐ ๐ C+ reviewed
Triggered auto assignment to @Gonals, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@slafortune, @Gonals, @thesahindia Eep! 4 days overdue now. Issues have feelings too...
๐ฃ @bernhardoj ๐ 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 ๐
PR is ready
cc: @thesahindia
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.5-13 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 2024-07-17. :confetti_ball:
For reference, here are some details about the assignees on this 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:
I'll request in ND once payment is due.
Thanks for the heads up @bernhardoj - I closed the contract for this GH with Upworks
It was caused by the migration PR . It was a huge PR, so it's easy to miss such cases.
We don't need a specific test case here.
The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.6-8 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 2024-07-22. :confetti_ball:
For reference, here are some details about the assignees on this 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:
The payment should be due tomorrow (07-17)
Requested in ND.
@bernhardoj is due $250 for the Contributor role via NewDot @thesahindia is due $250 for the C+ role via NewDot
$250 approved for @bernhardoj
$250 approved for @thesahindia
If you havenโt already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Version Number: 1.4.85-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: N/A Issue reported by: Applause - Internal Team
Action Performed:
Expected Result:
"To" field will display the invoice receiver
Actual Result:
"To" field displays Hidden instead of invoice receiver
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/78819774/9d4ec46a-e9eb-4775-9325-58e9be241c18
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @slafortune