Expensify / App

Welcome to New Expensify: a complete re-imagination of financial collaboration, centered around chat. Help us build the next generation of Expensify by sharing feedback and contributing to the code.
https://new.expensify.com
MIT License
3.5k stars 2.85k forks source link

IOU - All the cancelled request preview shows loading spinner for reopened accounts - reported by @Tushu17 #7420

Closed kavimuru closed 1 year ago

kavimuru commented 2 years ago

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

  1. Launch the app
  2. Login with reopened account credentials
  3. Open Direct message with account who I canceled request money.

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

stitesExpensify commented 2 years ago

No update.

stitesExpensify commented 2 years ago

No update, still not a priority

stitesExpensify commented 1 year ago

No update

melvin-bot[bot] commented 1 year ago

Triggered auto assignment to @puneetlath (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

puneetlath commented 1 year ago

@stitesExpensify I removed and re-added the Bug label to get a BZ team member assigned (me haha) to help move this forward.

JmillsExpensify commented 1 year ago

We should float this one in #engineering-chat to try and get alternative internal volunteers.

melvin-bot[bot] commented 1 year ago

Triggered auto assignment to @marcaaron (Demolition), see https://stackoverflow.com/c/expensify/questions/8099 for more details.

marcaaron commented 1 year ago

Can someone summarize what needs to be done here?

marcaaron commented 1 year ago

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?

stitesExpensify commented 1 year ago

Cancel and then close the account, although I would guess that other cases also exist

marcaaron commented 1 year ago

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.

marcaaron commented 1 year ago

Maybe I'm not getting how this feature works. I can't ever remember.

marcaaron commented 1 year ago

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 🤔

marcaaron commented 1 year ago

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:

marcaaron commented 1 year ago

actually, that solution appears to break all new IOU transactions. 😕

marcaaron commented 1 year ago

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:

2022-11-04_09-10-47

Creating a new request as the user who did not close their account works

2022-11-04_09-11-00

But will lead to them seeing two report actions

2022-11-04_09-11-22

What's also weird is that the previous action "Details" says that the other user paid (but they didn't)

2022-11-04_09-17-40

And the new preview for the new transaction looks OK

2022-11-04_09-17-57

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.

puneetlath commented 1 year ago

If we canceled the IOU request before unsharing the report, would that solve it?

marcaaron commented 1 year ago

ah sorry, can you clarify what you think that would solve? I'm not sure what the "it" in your question refers to.

puneetlath commented 1 year ago

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.

marcaaron commented 1 year ago

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.

marcaaron commented 1 year ago

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...

  1. If the IOUReport shared has a non-zero total then rejact all the transactions on behalf of the user.
  2. Do not "reject" the report or change the state or status of the IOU report (that should now have a zero total).
  3. Re-share the IOU report with the user when they reopen their account (so we don't have to create a new one)
marcaaron commented 1 year ago

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

puneetlath commented 1 year ago

Nice!

marcaaron commented 1 year ago

Still working on this, but it's not a daily priority for me since closing accounts is an edge case.

JmillsExpensify commented 1 year ago

+1. I think weekly is appropriate.

marcaaron commented 1 year ago

Related Auth PR has been merged. Wrote some integration tests for the Web-E PR (still on HOLD waiting for Auth deploy).

JmillsExpensify commented 1 year ago

Not sure why I'm subscribed to this issue haha, but just noticed we need to create an Upwork job for the reporting bonus.

puneetlath commented 1 year ago

@Tushu17 can you please apply here for the reporting bonus: https://www.upwork.com/jobs/~0102f107207d43a2df

Tushu17 commented 1 year ago

@puneetlath Ok applied, Thanks.

puneetlath commented 1 year ago

Great, paid!

puneetlath commented 1 year ago

Looks like we're done here!