Repository navigation
[Due for payment 2025-06-02] [$250] Members are able to edit the title of approved reports. #57416
Description
Activity
- addedBugSomething is broken. Auto assigns a BugZero manager.Something is broken. Auto assigns a BugZero manager.DailyKSv2KSv2
on Feb 25, 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.🚨 Edited by proposal-police: This proposal was edited at 2025-02-25 18:00:43 UTC.
Proposal
Please re-state the problem that we are trying to solve in this issue.
The Title field is editable and an error message is displayed after committing the new Title. By going to the workspace chat and entering again to the expense details, the Title field has the new name for a little while and a message in the thread is displayed saying that the title has changed.
What is the root cause of that problem?
We always show
shouldShowRightIconandinteractiveastruehereApp/src/components/ReportActionItem/MoneyReportView.tsx
Lines 154 to 159 in cde1841
shouldShowRightIcon disabled={isFieldDisabled} wrapperStyle={[styles.pv2, styles.taskDescriptionMenuItem]} shouldGreyOutWhenDisabled={false} numberOfLinesTitle={0} interactive What changes do you think we should make in order to solve the problem?
-
We can pass
transactionThreadReportas props toMoneyReportView -
Create the condition like we did with
MoneyRequestViewhere. We should create a new variable likecanEditand pass it toshouldShowRightIconandinteractiveand we also add|| isAdminto the condition if we want the admin can edit report title field
const parentReportID = transactionThreadReport?.parentReportID; const [parentReportActions] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReportID ?? CONST.DEFAULT_NUMBER_ID}`, { canEvict: false, }); const [reportActions] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report?.reportID ?? CONST.DEFAULT_NUMBER_ID}`, { canEvict: false, }); const parentReportAction = transactionThreadReport?.parentReportActionID ? parentReportActions?.[transactionThreadReport.parentReportActionID] : Object.values(reportActions ?? {}).find((action) => action.actionName === CONST.REPORT.ACTIONS.TYPE.IOU); const linkedTransactionID = useMemo(() => { if (!parentReportAction) { return undefined; } const originalMessage = parentReportAction && isMoneyRequestAction(parentReportAction) ? getOriginalMessage(parentReportAction) : undefined; return originalMessage?.IOUTransactionID; }, [parentReportAction]); const [transaction] = useOnyx(`${ONYXKEYS.COLLECTION.TRANSACTION}${linkedTransactionID ?? CONST.DEFAULT_NUMBER_ID}`); const canUserPerformWriteAction = !!canUserPerformWriteActionReportUtils(transactionThreadReport ?? report); const isAdmin = policy?.role === CONST.POLICY.ROLE.ADMIN; const canEdit = (isMoneyRequestAction(parentReportAction) && canEditMoneyRequest(parentReportAction, transaction) && canUserPerformWriteAction) || isAdmin;App/src/pages/home/report/ReportActionItemContentCreated.tsx
Lines 154 to 161 in cba89eb
<MoneyReportView report={report} policy={policy} isCombinedReport pendingAction={action?.pendingAction} shouldShowTotal={transaction ? transactionCurrency !== report?.currency : false} shouldHideThreadDividerLine={shouldHideThreadDividerLine} /> What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
UI bug, don't need to create unit tests. If needed, we can render
MoneyReportViewwith mock data , and check if the user isn't admin, item will not interactive and right icon will not show.What alternative solutions did you explore? (Optional)
OR we can create the condition like we did with
MoneyRequestViewhereApp/src/components/ReportActionItem/MoneyRequestView.tsx
Lines 179 to 180 in cba89eb
const canUserPerformWriteAction = !!canUserPerformWriteActionReportUtils(report) && !readonly; const canEdit = isMoneyRequestAction(parentReportAction) && canEditMoneyRequest(parentReportAction, transaction) && canUserPerformWriteAction; Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.
-
Proposal
Please re-state the problem that we are trying to solve in this issue.
Error message when an employee changes the report name of an approved expense
What is the root cause of that problem?
We have always set the value of
shouldShowRightIconandinteractivewithout checking if that is allowed for approved report
App/src/components/ReportActionItem/MoneyReportView.tsx
Lines 146 to 159 in cde1841
<MenuItemWithTopDescription description={Str.UCFirst(reportField.name)} title={fieldValue} onPress={() => { Navigation.navigate( ROUTES.EDIT_REPORT_FIELD_REQUEST.getRoute(report?.reportID, report?.policyID, reportField.fieldID, Navigation.getReportRHPActiveRoute()), ); }} shouldShowRightIcon disabled={isFieldDisabled} wrapperStyle={[styles.pv2, styles.taskDescriptionMenuItem]} shouldGreyOutWhenDisabled={false} numberOfLinesTitle={0} interactive This causes the name to be editable on the
FEbut theBEthrows error and we see that error on the FE later, this is the RCA.What changes do you think we should make in order to solve the problem?
The fix would be to check if the field is indeed editable, we need to use
canUserPerformWriteActionfrom thereportUtils:Line 7876 in cba89eb
function canUserPerformWriteAction(report: OnyxEntry<Report>) { This would make sure to keep the item actionable only when it can be edited.
What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?
We will create a UI test here which will render the
MoneyReportViewcomponent with mock Onyx data, and we will set the report status to approved, then we will get the UI component and check if the item is not interactive and editable.What alternative solutions did you explore? (Optional)
N/A
As the submitter, I'm not running into the error when changing the report title after the report is in the
Approvedstate.
Though, I agree on OldDot we don't let submitters change the report title of
approvedreports:
So it's inconsistent here, and we have two options to consider:
- Update OldDot to allow submitters to edit report titles of
approvedreports. - Update NewDot to only let workspace admins update the report titles of
approvedreports.
I vote the 2nd option at this juncture, and makes more sense in-line with their overall edit capabilities of expense reports in this status. @JmillsExpensify @garrettmknight thoughts?
Reacted by Garrett Knight- Update OldDot to allow submitters to edit report titles of
Updated proposal
Agree on the second option
- changed the title
[-]Report - Error message when an employee changes the report name of an approved expense[/-][+]Members are able to edit the title of `approved` reports.[/+]on Mar 3, 2025 - addedExternalAdded to denote the issue can be worked on by a contributorAdded to denote the issue can be worked on by a contributor
on Mar 3, 2025 - changed the title
[-]Members are able to edit the title of `approved` reports.[/-][+][$250] Members are able to edit the title of `approved` reports.[/+]on Mar 3, 2025 99 remaining items
- addedAwaiting PaymentAuto-added when associated PR is deployed to productionAuto-added when associated PR is deployed to production
on May 26, 2025 - changed the title
[-][$250] Members are able to edit the title of `approved` reports.[/-][+][Due for payment 2025-06-02] [$250] Members are able to edit the title of `approved` reports.[/+]on May 26, 2025 Reviewinglabel has been removed, please complete the "BugZero Checklist".The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.51-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2025-06-02. 🎊
For reference, here are some details about the assignees on this issue:
- @s77rt requires payment through NewDot Manual Requests
- @Tony-MK requires payment automatic offer (Contributor)
@s77rt @trjExpensify @s77rt The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]
BugZero Checklist:
- [Contributor] Classify the bug:
Bug classification
Source of bug:
- 1a. Result of the original design (eg. a case wasn't considered)
- 1b. Mistake during implementation
- 1c. Backend bug
- 1z. Other:
Where bug was reported:
- 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
- 2b. Reported on staging (eg. found during regression or PR testing)
- 2d. Reported on a PR
- 2z. Other:
Who reported the bug:
- 3a. Expensify user
- 3b. Expensify employee
- 3c. Contributor
- 3d. QA
- 3z. Other:
-
[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: feat: Integrate report fields with backend #34483 (comment)
-
[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: n/a
-
[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.
Bug requires regression test: Yes
-
[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:
- Workspace with approval workflow and custom report fields
- An admin account
- An employee account
Test:
- As employee: Submit an expense to the WS
- As admin: Approve the expense
- As employee: Verify you cannot edit any custom report field
- As employee: Verify you cannot edit the report's title
Do we agree 👍 or 👎
Reacted by Tom Rhys Jones- moved this from Bugs and Follow Up Issues to Done in #expensify-bugs
on Jun 2, 2025 $250 approved for @s77rt
Reacted by Abdelhafidh Belalia
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Version Number: 9.1.5-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5650477
Email or phone of affected tester (no customers): agexptest+cw.employee@gmail.com
Issue reported by: Applause Internal Team
Device used: Windows 10/ Chrome, Samsung S23FE/ Android 14
App Component: Money Requests
Action Performed:
Preconditions:
Use a Control workspace with an admin and an employee.
In Workflows, the Delay submissions option is set to manually. The Add approvals toggle is enabled and the default workflow is set.
Rules feature enabled in the workspace.
Custom report names option is enabled and Custom name has any text.
Auto-approve compliant reports option is enabled and Auto-approve reports under option is set to any value.
Steps:
Expected Result:
Only workspace admins should be able to update the report titles of
approvedreports (like OldDot).Actual Result:
The report title field is editable by the member in the
approvedstate.Note: apparently there was an error message shown in the original bug report, but I can't repro that, though I can still edit the report title of the approved report as the member - but I shouldn't be allowed to.
Workaround:
Unknown
Platforms:
Screenshots/Videos
bug.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @trjExpensify