[HOLD App #28021] Scan - Unable to delete receipt after replacing it unless merchant name is entered

[lanitochka17]

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: 1.3.85-0

Reproducible in staging?: Yes

Reproducible in production?: Yes

If this was caught during regression testing, add the test name, ID and link from TestRail:

Email or phone of affected tester (no customers):

Logs: https://stackoverflow.com/c/expensify/questions/4856

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

Issue found when executing PR #29617

Action Performed:

1. Go to staging.new.expensify.com
2. Go to + > Request money > Scan
3. Complete the scan request
4. Open Scan request details page
5. Click on the receipt > 3-dot menu > Replace
6. Upload a photo
7. Click on the receipt - 3-dot menu > Delete receipt > Delete
8. Enter merchant name
9. Click on the receipt - 3-dot menu > Delete receipt > Delete

Expected Result:

In Step 7, if the receipt cannot be deleted for some reason, there should be an error message or the delete action button should be hidden
In Step 9, if the empty fields must be filled before the receipt can be deleted, the app should only allow the deletion of receipt after both Amount and Merchant values are entered

Actual Result:

In Step 7, after deleting the receipt, it disappears and then reappears
In Step 9, the receipt can only be deleted after Merchant name is entered, while the amount field is still empty

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Bug6240231_1697535759614.bandicam_2023-10-17_15-18-36-579.mp4

MacOS: Desktop

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[paultsimura]

If we want to maintain the current behavior and just allow removing the receipt, the changes should be made on the BE side, as the DetachReceipt API request returns the following:

{
    "jsonCode": 405,
    "message": "405 Cannot detach receipt from partial transaction",
    "onyxData": [],
    "requestID": "8179546a49d234ee-WAW"
}

I suppose the receipt state should be taken into consideration on the BE: if it's not scanning – then allow detaching.
Otherwise, it'd be better to clarify the expected behavior: hide the delete button, update the merchant automatically on the receipt replacement, etc.

[trjExpensify]

@Gonals @luacmartins can you look at this one please?

I'm not 100% sure it'll be fixed in @joekaufmanexpensify issue.

[melvin-bot]

@trjExpensify Huh... This is 4 days overdue. Who can take care of this?

[trjExpensify]

Bump @Gonals @luacmartins on the above! #29766 (comment)

[luacmartins]

I agree with @paultsimura, this seems to be an internal issue

[melvin-bot]

@trjExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[trjExpensify]

Okay, but that wasn't really my question. 😅 The issue linked to has a similar root cause in that you are able to replace a receipt while it's still scanning. After which, you can run into these downstream "bugs" as side effects; 1) you can't delete the receipt 2) other participants can't see the replaced receipt

So just like we hide the ability to detach a receipt while it's still scanning, we should hide the ability to replace a receipt while it's still scanning. That avoids both of these issues. So my question is if that's going to be implemented in #28021? If so, can this issue go on hold until a PR is merged for that as we don't need to do anything in addition whether that be on the BE or FE.

[luacmartins]

Ah got it. It seems like we're leaning towards hiding the replace option while scan is in progress, but we still don't have a proposal for #28021. That being said, I agree that we can put this issue on hold until we have a PR for that issue. Thanks for raising this!

[trjExpensify]

Cool, cool. Dropping to weekly while it's on hold.

[trjExpensify]

Samesies.

[trjExpensify]

Still held.

[trjExpensify]

Same spot.

[trjExpensify]

Still held. Waiting on @Gonals to provide a secondary review of the proposal in: #28021 (comment)

[trjExpensify]

Still held, PR is in review.

[trjExpensify]

PR hit staging yesterday, and I can see you can't run into this issue anymore because the ability to replace a receipt while it's still scanning has been removed. Closing!