[$250] 1:1 Submit expense - The receiving end of the IOU should not be asked to fill out information if the scan failed
If you havenβt already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: 9.0.54 Reproducible in staging?: Y Reproducible in production?: Y If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5121232&group_by=cases:section_id&group_order=asc&group_id=294998 Issue reported by: Applause - Internal Team
Action Performed:
- Start the Submit expense flow in a 1:1 conversation with a user you have access to
- Select the scan option
- Upload a picture that will fail the scan process
- Wait for the scan to fail
- Log in as the other account
- Navigate to the IOU that failed the scan
- Verify the receiver is not asked to fill out the missing information
Expected Result:
The receiving end of the IOU should not be asked to fill out information if the scan failed
Actual Result:
The receiving end of the IOU is asked to fill out information if the scan failed but can't
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- [ ] Android: Standalone
- [ ] Android: HybridApp
- [ ] Android: mWeb Chrome
- [ ] iOS: Standalone
- [ ] iOS: HybridApp
- [ ] iOS: mWeb Safari
- [x] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
Add any screenshot/video evidence
https://github.com/user-attachments/assets/7317ab19-6b6a-4337-91c2-e925dd5af6f4
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021854642765194540226
- Upwork Job ID: 1854642765194540226
- Last Price Increase: 2024-11-14
- Automatic offers:
- FitseTLT | Contributor | 105019830
Triggered auto assignment to @alexpensify (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.
@alexpensify 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
Proposal
Please re-state the problem that we are trying to solve in this issue.
1:1 Submit expense - Scan failure should not ask receiver to enter information
What is the root cause of that problem?
We are displaying the same Enter an amount text for both side of the users
https://github.com/Expensify/App/blob/c3dde46202d2f48934ef7aa617d69c8b4c0b5ff6/src/components/ReportActionItem/MoneyRequestView.tsx#L272
What changes do you think we should make in order to solve the problem?
We should display this copy only if the user canEditAmount and add another appropriate copy (like No amount set yet) and display it when the user can't modify the amount
translationPath: canEditAmount ? 'common.error.enterAmount' : 'common.error.noAmount',
We should do the same enterDate and enterMerchant
What alternative solutions did you explore? (Optional)
Optionally we can also avoid displaying the error for the receiving end
Adding to my testing list, I'll review this one soon.
No update yet
Job added to Upwork: https://www.upwork.com/jobs/~021854642765194540226
Triggered auto assignment to Contributor-plus team member for initial proposal review - @getusha (External)
@getusha - can you please confirm if this proposal will fix this issue?
Heads up, I will be offline until Tuesday, November 12, 2024, and will not actively watch over this GitHub during that period.
If this GitHub requires an urgent update, please ask for help in the #expensify-open-source Slack Room. If it can wait, I'll continue the review process when I return online. Thanks!
@alexpensify The title of the issue should be updated according to the expected result
Expected Result: The receiving end of the IOU should not be asked to fill out information if the scan failed
Done! Thanks for the feedback.
@alexpensify @getusha this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
@alexpensify, @getusha Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@getusha any update regarding the review here? Thanks!
@alexpensify, @getusha Huh... This is 4 days overdue. Who can take care of this?
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
@alexpensify, @getusha 6 days overdue. This is scarier than being forced to listen to Vogon poetry!
@getusha if you are unable to review. I'll start the process of reassigning on Monday.
Reviewing, apologies for the delay!
@FitseTLT's proposal looks good to me. I think not displaying an error message to the receiving account sounds better to me. π π π C+ Reviewed!
Triggered auto assignment to @mountiny, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
What is the correct behaviour here, I am not 100% sure
The receiving end of the IOU should not be asked to fill out information if the scan failed
- Don't show any kind of error on the receiving end. or
- Show a different error message for the receiving end.
I think the expected behavior should be the first option. I think it doesn't make sense to keep an error message with RBR for the receiving end.
wdyt?
Yeah I think its a bit weird to show the RBR if you cannot edit the expense. Curious for @trjExpensify throughts
Do we actually RBR the DM for the receiver? π I agree we shouldn't do that.
As for the field error, I agree it doesn't make sense to the receiver to see "Enter an amount" when they can't. That said, I think we need to bring back that system message in the expense thread, to communicate why this is $0.00.
CC: @JmillsExpensify
That said, I think we need to bring back that system message in the expense thread, to communicate why this is $0.00.
do we have an issue for bringing that back?
I believe it was going to come with Mills' sys message doc, is that right Jason?
Yeah, that's right.
Alright so for the purposes of this issue, we should make sure no error is shown on the side that cannot edit it.
@getusha can you please choose the proposal according to that expectation? thanks!
@FitseTLT's alternative solution states that https://github.com/Expensify/App/issues/51574#issuecomment-2442777973, we can assign them. I Don't think a code snippet is really necessary since i think it's as straight forward as adding additional check to isError
π£ @FitseTLT π 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 π