[HOLD #26538] [$500] Settings - Using deep link, admin can request money to user workspace chat even though its not allowed

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Open the app
2. Open settings->workspaces->any workspace-> members->invite any member
3. Open the new chat created between workspace and user added in step 2
4. Click plus and observe that request money is not present as we are admin
5. In the URL, replace '/r/' with '/request/new/' and observe that it allows to open request money page
6. Complete the process and observe that app raises a request

Expected Result:

App should display 'Hmm its not here' page for request money by deep link by admin in workspace chat as request money option is not available for admin

Actual Result:

App allows to request money by deep link by admin in workspace chat even though request money option is not available for admin

Workaround:

Unknown

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: v1.3.61-3

Reproducible in staging?: Y

Reproducible in production?: Y

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

Notes/Photos/Videos: Any additional supporting documentation

request.money.for.admin.is.available.by.deep.link.mp4

Bandicam.2023-09-01.23-21-57-558.mp4

Expensify/Expensify Issue URL:

Issue reported by: @dhanashree-sawant

Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1692943365255729

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01fea0f36079525f3d
• Upwork Job ID: 1698569709503803392
• Last Price Increase: 2023-10-19

Issue Owner

Current Issue Owner: @sophiepintoraetz

[GItGudRatio]

Proposal

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

Using deep link, admin can request money to user workspace chat even though its not allowed

What is the root cause of that problem?

On the MoneyRequestSelectorPage, we do not have any validation based on the report type if the user should be allowed to create an IOU.

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

We need to add a validation to show the "Not found" page if the user is not allowed to perform IOU in a specific chat.

We need to add a new condition here !ReportUtils.canRequestMoney(ReportUtils.getReport(reportID)):

App/src/pages/iou/MoneyRequestSelectorPage.js

Line 68 in f5fa30b

<FullPageNotFoundView shouldShow={!IOUUtils.isValidMoneyRequestType(iouType)}>

What alternative solutions did you explore? (Optional)

To determine if the Request Money menu item should be shown in a chat, we use the function ReportUtils.getMoneyRequestOptions. All the validation is present here that tells if the user should be able to request money. What we need to do is create a function to have all this validation. We could also update the existing canRequestMoney method. The exact implementation can be discussed in the PR.

The places where Request Money should be disabled are:

• If the report is a thread.
• If the report is a task.
• If the report is a recorded expensify account id.
• If the report is not own policy expense chat and the number of members is zero.
• If the report is a money request report.
• If the report is a policy expense chat and is own policy expense chat.
• If the report is a chat room.
• If the report has multiple participants and is not policy expense chat.
• If the report is control policy expense chat.

The places where Split Bill should be disabled are:

• If the report is a chat room.
• If the report has multiple participants and is not policy expense chat.
• If the report is control policy expense chat.

[namhihi237]

Proposal

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

App should display 'Hmm its not here' page for request money by deep link by admin in workspace chat as request money option is not available for admin

What is the root cause of that problem?

We have not checked whether the report is allowed to open modal request money when opened by deep link or not at MoneyRequestSelectorPage like in composer here

Therefore, when we open a deeplink, we can open the money request modal in any report.

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

We should check the same as in the composer and add condition here

    const report = reportID && ReportUtils.getReport(reportID);
    const isRequestMoney = _.isEmpty(report) || ReportUtils.getMoneyRequestOptions(report, lodashGet(report, "participantAccountIDs", []), props.betas).includes(CONST.IOU.MONEY_REQUEST_TYPE.REQUEST);

<FullPageNotFoundView shouldShow={!IOUUtils.isValidMoneyRequestType(iouType) || !isRequestMoney}>

App/src/pages/iou/MoneyRequestSelectorPage.js

Line 68 in 5db2445

<FullPageNotFoundView shouldShow={!IOUUtils.isValidMoneyRequestType(iouType)}>

What alternative solutions did you explore? (Optional)

N/A

[esh-g]

Proposal

Please re-state the issue

The request money deep link has no checks to ensure that the action is allowed or not.

What is the root cause of this issue?

The request money page MoneyRequestSelectorPage has no logic to check if the requesting action is allowed for the particular report.

What changes should be made in order to fix this?

We already have a method called ReportUtils.getMoneyRequestOptions() which returns the valid money request options for a particular report that we are using in the + button in the composer to display valid options.

App/src/libs/ReportUtils.js

Lines 2977 to 2996 in c169952

	function getMoneyRequestOptions(report, reportParticipants, betas) {
	// In any thread or task report, we do not allow any new money requests yet
	if (isChatThread(report) || isTaskReport(report)) {
	return [];
	}
	const participants = _.filter(reportParticipants, (accountID) => currentUserPersonalDetails.accountID !== accountID);
	const hasExcludedIOUAccountIDs = lodashIntersection(reportParticipants, CONST.EXPENSIFY_ACCOUNT_IDS).length > 0;
	const hasSingleParticipantInReport = participants.length === 1;
	const hasMultipleParticipants = participants.length > 1;
	if (hasExcludedIOUAccountIDs || (participants.length === 0 && !report.isOwnPolicyExpenseChat)) {
	return [];
	}
	// Additional requests should be blocked for money request reports
	if (isMoneyRequestReport(report)) {
	return [];
	}

We should use this function in MoneyRequestSelectorPage as well. Since, we are already using FullScreenNotFoundView in the page already:

App/src/pages/iou/MoneyRequestSelectorPage.js

Line 90 in c169952

<FullPageNotFoundView shouldShow={!IOUUtils.isValidMoneyRequestType(iouType)}>

1. We need to check if the passed iouType is allowed for the current report. Therefore, we should modify the condition to the following:

const isInvalid = !IOUUtils.isValidMoneyRequestType(iouType) || (props.report && !_.includes(ReportUtils.getMoneyRequestOptions(props.report, reportParticipantIDs, props.betas), iouType));
...
<FullPageNotFoundView shouldShow={isInvalid}> 

2. We also need to pass the reportParticipantIDs so we can add that to the body of the component as a memo:

const reportParticipantIDs = useMemo(
    () => _.without(lodashGet(props.report, 'participantAccountIDs', []), props.currentUserPersonalDetails.accountID),
    [props.session.accountID, props.report],
);

3. To get the relevant parameters for getMoneyRequestOptions(), we can modify the HOCs and add some properties to the withOnyx HOC as well as add the withCurrentUserPersonalDetails HOC, like this:

export default withOnyx({
    selectedTab: {
        key: `${ONYXKEYS.SELECTED_TAB}_${CONST.TAB.RECEIPT_TAB_ID}`,
    },
    report: {
        key: ({route}) => `${ONYXKEYS.COLLECTION.REPORT}${route.params.reportID}`,
    },
    betas: {
        key: ONYXKEYS.BETAS,
    },
    session: {
        key: ONYXKEYS.SESSION
    }
})(MoneyRequestSelectorPage);

[melvin-bot]

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

[sophiepintoraetz]

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01fea0f36079525f3d

[melvin-bot]

Current assignee @sophiepintoraetz is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[ntdiary]

@sophiepintoraetz , hmm, curious if there are other normal flows that would cause a user to hit this issue? 😂
The conditions for allowing money request seem a bit complex, so I'm not exactly sure if it's necessary to fix right now.
Also it looks like the backend allows this request - if we really want to fix this issue, we may need to disable it there as well.

[esh-g]

@ntdiary I think a combination of backend and frontend are required. This is how we handled the issue of accessing things like workspace settings for non-admins. Like in this issue: #22013

[sophiepintoraetz]

if there are other normal flows that would cause a user to hit this issue?

I appreciate it's not a normal flow but given the world of finance, these are the sort of back doors you want to shore up, so let's fix it. If it is on the back end as well, I'll assign the internal label.

[melvin-bot]

Current assignee @ntdiary is eligible for the Internal assigner, not assigning anyone new.

[ntdiary]

@sophiepintoraetz, can you please also add a internal engineer?

We need to prohibit such creating requests on the backend (return error code), just like deleting these requests:

test.mp4

[ntdiary]

@GItGudRatio, the MoneyRequestSelectorPage component already has a report prop, so I think we can replace ReportUtils.getReport(reportID) with props.report.

[GItGudRatio]

@ntdiary Yeah sure, we can do the optimizations in the PR itself. I believe we need to decide upon the logic only for now, that's why I focused on the flow.

[esh-g]

@ntdiary From the proposals in this issue, please recognise that proposals from @GItGudRatio and @namhihi237 don't cover the case for split bills. If you see my proposal, it uses the iouType prop to validate to it will also be able to protect against unwanted split bill requests.

[ntdiary]

@ntdiary Yeah sure, we can do the optimizations in the PR itself. I believe we need to decide upon the logic only for now, that's why I focused on the flow.

@GItGudRatio, yeah, this is just a small kindly reminder, it would not make me reject your proposal, it's just that if you pay attention to this, it will make me feel you have a good understanding of the flow. : )

[ntdiary]

@ntdiary From the proposals in this issue, please recognise that proposals from @GItGudRatio and @namhihi237 don't cover the case for split bills. If you see my proposal, it uses the iouType prop to validate to it will also be able to protect against unwanted split bill requests.gg

@esh-g, don't worry, I'm still reviewing these proposals, no final decision yet. Also, @GItGudRatio mentioned logic related to split bill in the alternative solutions.

[techievivek]

Coming from here: #29367 (comment) we also want to prevent send money in group chat or other flows except global create and DM 1:1.

[pecanoro]

@ntdiary I think Tim closed the discussion here with a good proposal to move forward, do you think we could apply to this problem as well?

[ntdiary]

@ntdiary I think Tim closed the discussion here with a good proposal to move forward, do you think we could apply to this problem as well?

@pecanoro, I think it's good, and just left a comment in that thread, if there are no other updates within 24 hours, let's move forward with that approach. 🚀

[melvin-bot]

Current assignee @ntdiary is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[ntdiary]

@pecanoro, there is a small change: as I noted in this comment, we'll be refactoring the money request flow, so I think we can put this issue on hold too? Please feel free to let me know if you have different thoughts. 🤔

[pecanoro]

Ahh got it, I will put in on hold as well/

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[pecanoro]

I see that requesting money seems to be available now for admins both ways (using the + and the link), so should it actually be allowed? I am confused about what's the desired behavior. @sophiepintoraetz Can you maybe bring it up in Slack? It seems admins can request money just fine like anyone else.

[sophiepintoraetz]

Ah, I missed this before heading OOO - let me catch up where the discussion is and come back to this.

[sophiepintoraetz]

Yes, I am going to close this issue out - Admins will be able to request money as a part of the invoicing/bill pay flow we are building.