Open izarutskaya opened 8 months ago
Triggered auto assignment to @isabelastisser (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
:wave: Friendly reminder that deploy blockers are time-sensitive β± issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
Triggered auto assignment to @grgia (Engineering
), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.
@grgia 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.
I believe this is happening with manual requests too
When Split bill
is used with a receipt, the split amount is lost in the split bill details page.
Here, when we split the bill with a receipt, it was thought to be done via the scan tab where we do not enter the amount. In such a case, the flow starts with a split bill request and is completed later. However, as done in this issue, it is also possible to split the bill via Manual
request with an added receipt
. Currently, this goes through the default startSplit
flow. This is the root cause.
I do not think this is a regression.
We can support split bill request for manual request type with receipt by making use of the splitBill
here and splitBillAndOpenReport
here.
1) First, we need to avoid going through the startSplitBill
flow by additionally checking for a valid amount like this here
if (iouType === CONST.IOU.TYPE.SPLIT && receiptFile && transaction.amount === 0) {
2) Now, the flow with either go through splitBill
here or splitBillAndOpenReport
here. Here, let us pass the receiptFile
into splitBill
and splitBillAndOpenReport
as it is done here.
3) Inside the createSplitsAndOnyxData
here, generate the receiptObject
like it is done here and add this to the transaction here and iou report action here. Further, we need to add the receipt
to one-to-one iou report actions and transactions too here. Also, failure data can consider receipt error using getReceiptError
like here
However, this would also need BE support as SplitBill
API need to send back receipt
in response.
Alternatively, if we want to do this via startSplitBill
flow, we can include amount
in the flow. Here, I think even BE needs to ensure that transaction contains the amount
. Happy to explore more on this if we want to go through this approach.
FYI, this is likely fixed by this revert. Will have QA re-test once it is CP'd.
Looks like that revert ^ didn't fix the issue. So we still need to figure out what is going on here @grgia.
Another regression from https://github.com/Expensify/App/pull/33482 Not able to reproduce after reverting that PR locally
@situchan if you revert that PR you will not be able to split with a single user, which is why you can't reproduce this. I think this is not a regression as @rojiphil mentioned. Confirming shortly.
ok, if this bug happens on production when split bill with workspace (not single user), not blocker.
if this bug happens on production when split bill with workspace (not single user)
have you tested this?
checking
we can't test that scenario in prod, because the PR that fixes detecting 'Split' from the route is only in staging. Notice how the request never becomes a split.
https://github.com/Expensify/App/assets/9680864/6affccc1-f255-4aab-a167-e18e7a5a8f8a
@bernhardoj I think this is an edge case we missed, do you mind taking a look?
we can't test that scenario in prod, because the PR that fixes detecting 'Split' from the route is only in staging. Notice how the request never becomes a split.
π
I think demoting is fine here.
Checking
As the OP mentions, I think the issue is that the request changes from a manual
split with receipt to a scan
split. This results in a startSplitBill
flow which does not seem right. And this problem can also be reproduced in production as shown in the test video below. Further, the code referencing this issue has not changed for quite some time as is evident in the proposal. So, I still think this is not a regression.
What do you think?
cc @grgia @youssef-lr @bernhardoj @situchan
https://github.com/Expensify/App/assets/3004659/8e1efba9-ec16-4d89-8ba9-e1f05d2ada85
Ok, I agree with @rojiphil too that this is not a regression. The PR has been deployed to prod, so I tested on an older branch and can reproduce this when splitting with multiple users.
https://github.com/Expensify/App/assets/50919443/1dea60dd-8fe1-4e32-9fee-81e42169866e
Agree this can be treated as separate issue, not regression
@grgia grabbing this one if you don't mind!
β οΈ Could not update price automatically because there is no linked Upwork Job ID. The BZ team member will need to update the price manually in Upwork.
Job added to Upwork: https://www.upwork.com/jobs/~01e554328af9becb46
Triggered auto assignment to Contributor-plus team member for initial proposal review - @shubham1206agra (External
)
π£ @shubham1206agra π An offer has been automatically sent to your Upwork account for the Reviewer role π Thanks for contributing to the Expensify app!
π£ @rojiphil π 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 π
However, this would also need BE support as
SplitBill
API need to send backreceipt
in response.
@youssef-lr Thanks for assigning me here. This issue also needs BE support as mentioned above Once the BE is ready I will raise the PR in FE.
@shubham1206agra Welcome to the party π here.
@youssef-lr Another issue here related to distance requests also needs BE support so that SplitBill
API sends back receipt
for distance requests. Since this is also related, not sure if you want to pick that up too for BE changes.
Thanks for bringing that up @rojiphil, I will take a look on Monday.
Still planning to get to this today.
@rojiphil this will indeed to be held on backend changes, the manual split bill backend should support adding receipts, currently only startSplitBill
supports it. I'm not sure if I can get to this this week, most likely next one I'll be able to.
@youssef-lr Bump for the update here.
I still haven't had time for this yet. Will work on the backend PR next week.
Hi @youssef-lr, any updates?
I haven't had time to get to this yet, I was OOO sick when you mentioned me @isabelastisser, last week I have been prioritizing a wave issue and a vip-split design doc
@youssef-lr Bump on this one.
Hey @youssef-lr, any updates? Thanks!
@youssef-lr Bump on this.
I haven't been able to switch focus to this one. Uneven splits is almost done, I'll be able to get back to this this week.
Any progress @youssef-lr ? Thanks!
No progress yet sadly, I haven't been able to get to this yet as I'm focusing on higher priority issues.
@JmillsExpensify this issue is about allowing to add a receipt to manual splits, I remember you mentioned we'll have a new pattern for this, do you think we should wait for that?
Bump @JmillsExpensify
@youssef-lr Blast from the past. At one point this was going to be an option row in the Details
page for the report, though we never ended up adding it. Further, we kept the add receipt option in the three dot overflow menu. Then additionally, we ended up deciding to show an empty receipt state for all expense
transactions.
@Expensify/design I'm curious for your take on this one? Should add an Add receipt
option in the details page for manual splits? I'm not super convinced we should go the receipt empty state route for consumers, as that feels like it's promoting receipts to best practice when they are completely optional.
Honestly I don't know that I feel super duper strongly. I could definitely see Receipt
just being a push input like Description, Merchant, etc. So we're not really super calling attention to it (like the empty state does) but we're still giving people the option.
Yeah the overflow isn't ideal here is it π I don't haaate the UI though for if they manage to add it, but for the empty state if would definitely take precedence. Might just be me, but I'd love to find a consistent version that works for both split and manual even if it means that the receipt empty state on manual gets scaled down quite a bit. Is that too spicy?
Haha not necessarily. I'm not too passionate either. Split is still pretty aspirational, so I could potentially get down with just leaning into the empty state for now.
I like the idea of the push row for Receipt to de-emphasize it quite a bit.
I like the idea of the push row for Receipt to de-emphasize it quite a bit.
It's definitely not the first time it's come up, and I do feel like it could easily work for both split and manual without being too in the way. π€·ββοΈ
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: v1.4.45-0 Reproducible in staging?: Y Reproducible in production?: N Email or phone of affected tester (no customers): natnael.expensify+3@gmail.com Logs: https://stackoverflow.com/c/expensify/questions/4856 Issue reported by: Applause-Internal Team
Action Performed:
Expected Result:
Entered amount shouldn't be lost, and request shouldn't change to scan request
Actual Result:
Entered amount is lost and request is changed to a scan request
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
https://github.com/Expensify/App/assets/115492554/316ac613-a1bf-4035-972d-c2ae29b23716
View all open jobs on GitHub
Upwork Automation - Do Not Edit