[$250] [Held requests][HIGH] Hold button on expense preview appears only if open the expense first

[IuliiaHerets]

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: 9.0.19-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4845380&group_by=cases:section_id&group_order=asc&group_id=309128
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

Precondition:

1. Login as the owner of the workspace> Create a workspace
2. Invite the approver and employee
3. Enable "workflows"> On the "Workflow" editor - enable "Add Approvals"> Set the Approver account as the Approver

Steps:

1. Log in as the employee and submit 2 expenses to the workspace
2. Log in as the Approver> Navigate to the employee workspace chat with expenses
3. Right click on expenses to open the menu

Expected Result:

There should be Hold option when approver open the right click menu from expense

Actual Result:

Hold button on expense preview appears only if open the transaction thread page first

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6569910_1723470417784.Recording__3689.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021902104887608709904
• Upwork Job ID: 1902104887608709904
• Last Price Increase: 2025-04-15

Issue Owner

Current Issue Owner: @robertjchen

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @francoisl (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[IuliiaHerets]

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

[github-actions]

👋 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:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[cdOut]

This is definitely related to the changes I've made in the hold cleanup PR, please assign me so I can look into fixing this issue.

[parasharrajat]

I don't this this is a regression but a new case to be handled.

[francoisl]

Sounds good, assigned to @cdOut and going to demote to non-blocker.

[trjExpensify]

I have a feeling this is related to some other issues in this list and OpenReport. CC: @robertjchen

[robertjchen]

It looks like this is still a strictly frontend issue? The hold option should be available in the menu without having to open the expense first

[melvin-bot]

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

[mountiny]

@robertjchen Feel free to export the issue for the community next time!

[mountiny]

https://expensify.slack.com/archives/C01GTK53T8Q/p1742332226593539 posted for visibility here

[ntdiary]

Yes, this was deployed back Oct 2024, there should be two new fields in the parent report summary childCanHold and childCanUnhold

Eh, I didn't find these two fields in the response. 😅

I think childCanHold and childCanUnhold were added in the wrong place. They should be on individual transaction actions (where action.actionName === 'iou'), rather than on the parent report action.

Some child data isn't loaded when opening the report for the first time (forgot whether it's the child report, report action or transaction), which should be why they added two child fields to the parent report. A similar issue also exists with the delete option, and they can also be reproduced by logging in again.

[CyberAndrii]

Eh, I didn't find these two fields in the response. 😅

They're on the REPORTPREVIEW action

Image

But we also need them on IOU actions

Image

And it should be null or false on REPORTPREVIEW actions that contain multiple expenses. #47241 (comment)

[melvin-bot]

@ntdiary Eep! 4 days overdue now. Issues have feelings too...

[ntdiary]

But we also need them on IOU actions

And it should be null or false on REPORTPREVIEW actions that contain multiple expenses. #47241 (comment)

Yeah, we still need to optimize the BE logic for these two fields, and then FE can create a PR to use them to fix this issue.
BTW, @CyberAndrii, would you be interested in submitting a FE proposal? :)

cc @robertjchen @mountiny

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[abzokhattab]

Proposal

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

The "Hold" button on the expense preview appears only if the expense is opened first.

What is the root cause of that problem?

The "Hold" button on the expense preview does not appear because the necessary child data to determine if an expense can be held is only available after fully opening the expense, rather than being included in the preview action.

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

• Inside the canHoldUnholdReportAction , we should add a check to see if the parent report action is a preview and if it contains the newly added parameters:

if (isReportPreviewAction(parentReportAction) && parentReportAction.childCanHold !== undefined && parentReportAction.childCanUnhold !== undefined) {
        return {
            canHoldRequest: parentReportAction.childCanHold,
            canUnholdRequest: parentReportAction.childCanUnhold,
        };
    }

• We also need to update the condition here to pass the reportAction as a fallback to canHoldUnholdReportAction when the moneyRequestAction is undefined. This can be done here and here as follows:

type === CONST.CONTEXT_MENU_TYPES.REPORT_ACTION && areHoldRequirementsMet && canHoldUnholdReportAction(moneyRequestAction ?? reportAction).canUnholdRequest,
...
type === CONST.CONTEXT_MENU_TYPES.REPORT_ACTION && areHoldRequirementsMet && canHoldUnholdReportAction(moneyRequestAction ?? reportAction).canHoldRequest,

• Also, update the areHoldRequirementsMet function to return true if moneyRequestAction is undefined and reportAction exists, as this is the only case where the condition will be true:

const areHoldRequirementsMet =
        (!isInvoiceReport &&
            isMoneyRequestOrReport &&
            !isArchivedNonExpenseReport(transactionThreadReportID ? childReport : parentReport, transactionThreadReportID ? childReportNameValuePairs : parentReportNameValuePairs)) ||
        (!!reportAction && !moneyRequestAction);

Result:

Untitled.mov

also i notice a problem where the backend doenst update the childCanHold and childCanUnhold whenever the request is changed to held or unheld

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

NA

[ntdiary]

• We also need to update the condition here to pass the reportAction as a fallback to canHoldUnholdReportAction when the moneyRequestAction is undefined.

@abzokhattab, that's a good point. It reminds me that when a reportAction is an IOU action, it's essentially identical to the moneyRequestAction. In this case, we wouldn't need to rely on the new childCanHold field.
As for other changes, I think we should first figure out those related concepts to prevent the conditions from becoming overly complex and fragile.
e.g., for a preview action, if childCanHold can serve as the single source of truth, we could potentially eliminate the need for moneyRequestAction. Rather than adding a sub-condition like !!reportAction && !moneyRequestAction, I'd prefer to first figure out whether we can improve the potentially problematic isMoneyRequestOrReport variable. Finally, it would be great to add some unit tests. :)

[melvin-bot]

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

[jliexpensify]

👋 Hi, how are we going with this issue @ntdiary ?

[ntdiary]

@jliexpensify, we need the backend to confirm and fix a few points:

1. For REPORTPREVIEW action, confirm whether childCanHold/childCanUnhold can serve as the single source of truth .
2. When opening a REPORTPREVIEW action with multiple transactions, If the backend guarantees all transactions data exists, then for its IOU actions, we won’t need childCanHold/childCanUnhold. Otherwise, IOU actions still need these fields. ( Note: just based on my test, its transactions always exist, but I can't be 100% certain that is always right)
3. If a REPORTPREVIEW contains multiple transactions, childCanHold/childCanUnhold should be falsy.
4. If a transaction is held by the admin, childCanHold/childCanUnhold should be falsy for the submitter (looks like this data isn't being sent to the submitter, but it won't block this issue).
5. @abzokhattab notices a problem where the backend doesn't update the childCanHold/childCanUnhold whenever the request is changed to held or unheld.

With these clarifications, the FE should be able to propose a more robust solution.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[jliexpensify]

Got it, thanks for the update! cc @robertjchen for this comment

[melvin-bot]

@ntdiary Eep! 4 days overdue now. Issues have feelings too...

[robertjchen]

reviewing

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@ntdiary Still overdue 6 days?! Let's take care of this!

[robertjchen]

this week

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸