You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2025-04-07] [$250] Reports - Expense can be submitted and approved when "Prevent self-approvals" is enabled #58210
Version Number: 9.1.11-1 Reproducible in staging?: Yes Reproducible in production?: Yes If this was caught during regression testing, add the test name, ID and link from TestRail: Exp Email or phone of affected tester (no customers):applausetester+110301kh@applause.expensifail.com Issue reported by: Applause Internal Team Device used: Mac 15.3 / Chrome App Component: Search
Action Performed:
Precondition:
Delayed submission is enabled.
Admin is the approver.
"Prevent self-approvals" is enabled.
Go to staging.new.expensify.com
Go to workspace chat.
Submit an expense.
Note that Submit button is disabled.
Go to Reports.
Click Submit button on the same expense in Step 3.
Click Approve button.
Expected Result:
Submit and Approve button should be disabled in Reports when "Prevent self-approvals" is enabled.
Actual Result:
Submit and Approve button are not disabled in Reports when "Prevent self-approvals" is enabled.
passing the policy from the search data but sometimes the data needed for the calculation might not be available like policy.areRulesEnabled so it will early return true here
What changes do you think we should make in order to solve the problem?
Reliable Solution can be given from BE by always populating all important props of the policy, for instance in this case we need preventSelfApproval and areRulesEnabled but otherwise from FE we can also rely on the onyx policy data and only fallback to the policy from search data if it doesn't exist.
What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
If needed we can add a test for getAction to assert it doesn't return submit action if self approval is prevented even if the policy data from search has missing information.
What alternative solutions did you explore? (Optional)
// We check for isAllowedToApproveExpenseReport because if the policy has preventSelfApprovals enabled, we disable the Submit action and in that case we want to show the View action instead
What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
Add tests to for ReportUtils.isAllowedToApproveExpenseReport function with different policies and reports which have randomized values for areRulesEnabled, preventSelfApproval and report?.ownerAccountID.
Also, add scenarios where the CONST.SEARCH.ACTION_TYPES needs to be the same as the report preview or money request page.
What alternative solutions did you explore? (Optional)
changed the title [-]Reports - Expense can be submitted and approved when "Prevent self-approvals" is enabled[/-][+][$250] Reports - Expense can be submitted and approved when "Prevent self-approvals" is enabled[/+]on Mar 11, 2025
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: No discussion was started because this could not have been identified earlier.
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal Template
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:
Regression Test Proposal
Precondition:
Delayed submission is enabled for workspace A.
Admin is the approver for this workspace.
Test:
Enable "Prevent self approvals" for workspace A.
Go to the workspace chat for this workspace.
Create an expense.
Confirm that the submit button is disabled.
Navigate to Reports.
Find the expense created in step 3.
Click on the review button for this expense.
Verify that the submit button is disabled.
Disable "Prevent self approvals" for this workspace.
Go to the expense preview created in step 3.
Verify that the submit button is enabled.
Repeat steps 5 to 7.
Verify that the submit button is enabled.
Submit the expense.
Enable "Prevent self approvals" for this workspace.
Verify that the Approve button is disabled in Report Preview and Reports Screen RHP for this expense.
Disable "Prevent self approvals" for this workspace.
Verify that the Approve button is enabled in Report Preview and Reports Screen RHP for this expense.
Activity
melvin-bot commentedon Mar 11, 2025
Triggered auto assignment to @trjExpensify (
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.FitseTLT commentedon Mar 11, 2025
Proposal
Please re-state the problem that we are trying to solve in this issue.
Open Reports - Expense can be submitted and approved when "Prevent self-approvals" is enabled
What is the root cause of that problem?
We call
isAllowedToApproveExpenseReportUtilshereApp/src/libs/SearchUIUtils.ts
Line 400 in 4c2b419
policy.areRulesEnabledso it will early return true hereApp/src/libs/ReportUtils.ts
Lines 8647 to 8649 in 4c2b419
What changes do you think we should make in order to solve the problem?
Reliable Solution can be given from BE by always populating all important props of the policy, for instance in this case we need
preventSelfApprovalandareRulesEnabledbut otherwise from FE we can also rely on the onyx policy data and only fallback to the policy from search data if it doesn't exist.App/src/libs/ReportUtils.ts
Line 8646 in 4c2b419
What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
If needed we can add a test for
getActionto assert it doesn't return submit action if self approval is prevented even if the policy data from search has missing information.What alternative solutions did you explore? (Optional)
Tony-MK commentedon Mar 11, 2025
Proposal
Please re-state the problem that we are trying to solve in this issue.
Reports - Expense can be submitted and approved when "Prevent self-approvals" is enabled
What is the root cause of that problem?
This PR introduced the root cause, where the
ReportUtils.isAllowedToApproveExpenseReportreturnstrueearly when the rules are not enabled.Hence, the
getActionfunction returns theCONST.SEARCH.ACTION_TYPES.SUBMITbecause of this.App/src/libs/SearchUIUtils.ts
Lines 400 to 408 in 05dd3dc
What changes do you think we should make in order to solve the problem?
Remove the condition below to stop returning
trueearly in theReportUtils.isAllowedToApproveExpenseReport, since it is necessary.App/src/libs/ReportUtils.ts
Lines 8655 to 8657 in 05dd3dc
What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
Add tests to for
ReportUtils.isAllowedToApproveExpenseReportfunction with different policies and reports which have randomized values forareRulesEnabled,preventSelfApprovalandreport?.ownerAccountID.Also, add scenarios where the
CONST.SEARCH.ACTION_TYPESneeds to be the same as the report preview or money request page.What alternative solutions did you explore? (Optional)
Improve the
ReportUtils.isAllowedToApproveExpenseReportfunction by returningfalseif the policy rules are disabled.trjExpensify commentedon Mar 11, 2025
CC: @mountiny for vis as you were involved in the PR.
[-]Reports - Expense can be submitted and approved when "Prevent self-approvals" is enabled[/-][+][$250] Reports - Expense can be submitted and approved when "Prevent self-approvals" is enabled[/+]melvin-bot commentedon Mar 11, 2025
Job added to Upwork: https://www.upwork.com/jobs/~021899604361654368613
melvin-bot commentedon Mar 11, 2025
Triggered auto assignment to Contributor-plus team member for initial proposal review - @c3024 (
External)34 remaining items
c3024 commentedon Apr 7, 2025
BugZero Checklist:
Bug classification
Source of bug:
Where bug was reported:
Who reported the bug:
[Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to comment: https://github.com/Expensify/App/pull/55386/files#r2031204014
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: No discussion was started because this could not have been identified earlier.
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal Template
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:
Regression Test Proposal
Precondition:
Test:
Do we agree 👍 or 👎
melvin-bot commentedon Apr 10, 2025
@trjExpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!
Tony-MK commentedon Apr 11, 2025
Hey @stitesExpensify,
Could you let someone know to help close this issue since @trjExpensify is OOO?
Thank you.
cc: @mallenexpensify
stitesExpensify commentedon Apr 11, 2025
Hey @Tony-MK sorry for the delay, at this point I think it's best that we just wait for Tom to come back on Monday
Tony-MK commentedon Apr 11, 2025
No problem. Thank you
trjExpensify commentedon Apr 12, 2025
Payment summary as follows:
I'll leave this issue open to check out the regression test when I return on Tues.
trjExpensify commentedon Apr 15, 2025
Alrighty, back. Regression test issue created. Closing, thanks!
JmillsExpensify commentedon Apr 25, 2025
$250 approved for @c3024