[$250] IOU - Unable to hold request as requestee

[kbecciv]

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.4.65-3
Reproducible in staging?: y
Reproducible in production?: y
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. [User A] Submit two expenses to User B.
3. [User B] Go to transaction thread of one of the requests.
4. [User B] Click 3-dot menu.
5. [User B] Click Hold request.

Expected Result:

The requestee should be able to hold the request.

Actual Result:

The requestee is unable to hold the request.

Workaround:

n/a

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

Add any screenshot/video evidence

Bug6460441_1713974311860.20240424_235550.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0105f7d7fccafab4d0
• Upwork Job ID: 1783534892479332352
• Last Price Increase: 2024-04-25

[melvin-bot]

Triggered auto assignment to @adelekennedy (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.

[kbecciv]

We think that this bug might be related to #wave-collect - Release 1

[kbecciv]

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

[adelekennedy]

This is reproducible for me - moving to wave collect for Hold Requests

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~0105f7d7fccafab4d0

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @jayeshmangwani (External)

[tienifr]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The requestee is unable to hold the request.

What is the root cause of that problem?

In here, we'll early return if there's no policy.type. In the case of 1-1 money request, there's no policy, and the hold expense feature is never meant to be used for 1-1 money request, so in this case when clicking Hold expense, it will just do nothing.

What changes do you think we should make in order to solve the problem?

In here, add condition to check policy?.type is available in order to show the "Hold expense" menu item. If there's no policy?.type, do not show "Hold expense" menu item, which is consistent with the behavior when we click on "Hold expense"

if (!isOnHold && (isRequestIOU || canModifyStatus) && policy?.type) {

Optionally, in HoldReasonPage, we can add full page not found view if policy?.type is not available, to make sure to show not found page in case the user deeplink to it from 1-1 money request.

Besides checking policy?.type, we can additionally check that policy?.type is not personal.

We can do the same here for already-hold case.

What alternative solutions did you explore? (Optional)

If for some reasons we want to allow holding request for 1-1 money request, we should:

• Remove this check
• In here, fallback to personal by default if the policy.type is not available.
• In here and here, add condition to check that the expense is a 1-1 expense (eg. can check via policy of that report), if yes then still allow putting on hold/off hold (even though the canEditMoneyRequest might be false)

[allgandalf]

Should be fixed by #40319, we can close this one