Closed kavimuru closed 1 year ago
No update.
No update, still not a priority
No update
Triggered auto assignment to @puneetlath (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
@stitesExpensify I removed and re-added the Bug label to get a BZ team member assigned (me haha) to help move this forward.
We should float this one in #engineering-chat to try and get alternative internal volunteers.
Triggered auto assignment to @marcaaron (Demolition
), see https://stackoverflow.com/c/expensify/questions/8099 for more details.
Can someone summarize what needs to be done here?
I'm also confused about the bug...
Precondition: Closed an account then reopen again Launch the app Login with reopened account credentials Open Direct message with account who I canceled request money.
Are we canceling the money request and then closing the account or closing an account that has active requests?
Cancel and then close the account, although I would guess that other cases also exist
Here's what I am seeing so far...
The IOUPreview component tries to fetch the report in the URL or from the action but the API returns 666 "no longer exists". The other participant has no issues viewing the UI (assuming they retain access to the report, but the other user who closed their account does not).
Maybe dumb question... but can we just reshare these IOU reports when someone reopens their account?
Thinking we can just find all IOU reports where they are the accountID
or managerID
and re-share them. Then they will have access to the retracted report? Retracting the report seems fine is the lack of access to it that messes up the UI.
Maybe I'm not getting how this feature works. I can't ever remember.
Oh actually it would just be if they are the managerID
I think. Since if the report has your accountID
then you would be able to access it still 🤔
cc @Julesssss @mountiny as I think you guys are probably pretty familiar with the IOU flows and can please tell me if you see any obvious issues with this approach?
Problem:
Solution:
actually, that solution appears to break all new IOU transactions. 😕
Just noting that if you do not cancel the request but close and reopen you will still get a loading spinner as the payer though the requester will see that they are owed:
Creating a new request as the user who did not close their account works
But will lead to them seeing two report actions
What's also weird is that the previous action "Details" says that the other user paid (but they didn't)
And the new preview for the new transaction looks OK
This feature seems very broken when an account gets closed - did we just not think about what would happen at all? This might be too big of an issue for me to focus on at the moment, but will wait for input from others in case I am wrong and there's an obvious solution.
If we canceled the IOU request before unsharing the report, would that solve it?
ah sorry, can you clarify what you think that would solve? I'm not sure what the "it" in your question refers to.
Sorry, what I meant was that if we cancel the IOU request before closing the account, then theoretically there is nothing that needs to be reshared when the account is re-opened since the IOU no longer exists. Perhaps that is overly simplified though.
Got it, the loading spinners will still happen even if you manually cancel the request before closing your account. We could cancel the IOU transaction automatically when someone closes their account - but they would still lose access to the IOU report itself (so the UI will keep showing the loading spinner in both scenarios).
I still can't really think of why someone would need to have an IOU report unshared from them when they close their account.
Looks like when someone closes their account the "active" IOU report's state and status go from:
state = 1
status = 1
to
state = 0
status = 0
AFAICT iou reports should not ever have a state of 0 and are always either SUBMITTED
or MANUALREIMBURSED
.
It is getting rejected like @stitesExpensify found above.
Ok so, alternative idea...
Tested the above solution out and it works pretty good here are some drafts:
https://github.com/Expensify/Web-Expensify/pull/35453 https://github.com/Expensify/Auth/pull/7228
Nice!
Still working on this, but it's not a daily priority for me since closing accounts is an edge case.
+1. I think weekly is appropriate.
Related Auth PR has been merged. Wrote some integration tests for the Web-E PR (still on HOLD waiting for Auth deploy).
Not sure why I'm subscribed to this issue haha, but just noticed we need to create an Upwork job for the reporting bonus.
@Tushu17 can you please apply here for the reporting bonus: https://www.upwork.com/jobs/~0102f107207d43a2df
@puneetlath Ok applied, Thanks.
Great, paid!
Looks like we're done 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:
Precondition: Closed an account then reopen again
Expected Result:
All canceled request money should appear without any issues
Actual Result:
All canceled request money shows spinner.
Workaround:
Unknown
Platform:
Where is this issue occurring?
Version Number: 1.1.33-2 Reproducible in staging?: Yes Reproducible in production?: Yes Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/151190208-15448c72-dbbc-4a8a-8925-f78b3d760c7b.mp4
Expensify/Expensify Issue URL: Issue reported by: Slack conversation:
View all open jobs on GitHub