[Due for payment 2026-03-18][$250] Report -“Changed approver” system message show in ND for reports created and autopaid in OD

[nlemma]

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: v9.3.30-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-7269/folder/13176702/41236801/1223430640?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 10 / Chrome
App Component: Chat Report View

Action Performed:

Setup

1. Create a Control policy, on Instant submit, with Submit & Approve enabled
2. In OldDot - in the workspace Workflows tab, set Manually approve all expenses over: to $0.01
3. In ND, go to WS Workflows tab in "Make or track payments" section > Enable Auto-pay option to Reports above $100.00 are not reimbursed unless manually initiated.
4. Add a withdrawal-ready bank account for the workspace - Full verified BAV
5. In Wallet, create a Personal Bank Account - Use the Manual deposit bank account

Steps

1. In OldDot - as the workspace owner, create a report & add an expense of $1, then approve the report
2. In NewDot, open the report
3. Verify you see the "paid with bank account xxx via workspace rules" system message copy.
   Result: Extra “Changed approver [owner name]” system message displayed in NewDot
4. In NewDot, Submit and approve another expense.
5. Verify that report also gets auto-reimbursed & shows the same system message copy as above.
   Result: "paid with bank account xxx via workspace rules" (expected)

Expected Result:

When a report is created and approved in OldDot, and then viewed in NewDot, only the system message “automatically paid $amount with Expensify via workspace rules” should be displayed.

Actual Result:

When the report is created and approved in OldDot, then opened in NewDot, an additional system message appears: “changed approver to [owner name]”, followed by the expected “automatically paid $amount with Expensify via workspace rules” message.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7093885_1772644609769.bandicam_2026-03-04_12-01-27-795.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @linhvovan29546

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029576213193694823
• Upwork Job ID: 2029576213193694823
• Last Price Increase: 2026-03-05

[melvin-bot]

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

[MelvinBot]

Proposal

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

When a report is created and approved in OldDot with auto-pay enabled (Control policy, approve threshold, auto-reimburse), NewDot displays an extra "Changed approver [owner name]" system message that shouldn't be there. Only the "automatically paid $amount with Expensify via workspace rules" message should appear.

What is the root cause of that problem?

OldDot's auto-pay workflow internally creates a TAKECONTROL report action as a side effect of reassigning the report's manager during auto-reimbursement. NewDot unconditionally renders this action as a visible "changed the approver to [owner name]" system message.

Specifically, the rendering path is:

1. shouldReportActionBeVisible (ReportActionsUtils.ts:1105) has no special handling for TAKE_CONTROL — it passes all visibility filters because it's in supportedActionTypes, is not deprecated, and isDeletedAction returns false (the action has a non-empty message).

2. PureReportActionItem.tsx at line 1746 catches TAKE_CONTROL and renders it via getChangedApproverActionMessage.

3. getChangedApproverActionMessage (ReportActionsUtils.ts:4087) tries to read mentionedAccountIDs from originalMessage. OldDot TAKE_CONTROL actions have an empty originalMessage (no mentionedAccountIDs), so the function falls back to actorAccountID at line 4100, producing "changed the approver to [owner name]".

Notably, buildOptimisticChangeApproverReportAction (ReportUtils.ts:8273) sets shouldShow: false for NewDot-originated change approver actions, but shouldReportActionBeVisible never checks shouldShow for TAKE_CONTROL/REROUTE actions — it only checks it for ReportPreview actions via isVisiblePreviewOrMoneyRequest at line 1417.

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

Filter out OldDot TAKE_CONTROL actions that lack mentionedAccountIDs in shouldReportActionBeVisible. OldDot TAKE_CONTROL actions have originalMessage: {} (no mentionedAccountIDs), while NewDot-originated change approver actions always include mentionedAccountIDs. This distinguishes OldDot auto-pay side effects from intentional NewDot approver changes.

In shouldReportActionBeVisible in ReportActionsUtils.ts, add a check: if the action is TAKE_CONTROL and originalMessage does not contain mentionedAccountIDs, return false.

This approach is minimal and targeted — it hides only the OldDot-originated TAKE_CONTROL actions that produce the confusing "changed approver to [self]" messages, while preserving the rendering of NewDot TAKE_CONTROL/REROUTE actions which always have proper mentionedAccountIDs.

What alternative solutions did you explore? (Optional)

1. Add TAKE_CONTROL to isOldDotReportAction list — This would route it through getMessageOfOldDotReportAction which shows "took control" (line 2102). However, this only changes the message text rather than hiding the unwanted action entirely.

2. Respect shouldShow property for TAKE_CONTROL/REROUTE — The optimistic builder already sets shouldShow: false, so extending isVisiblePreviewOrMoneyRequest (or adding a separate check) to hide actions with shouldShow === false would work for NewDot actions. However, OldDot TAKE_CONTROL actions don't have shouldShow set at all (it's undefined), so this alone wouldn't fix the OldDot auto-pay scenario.

3. Backend fix in Auth — Have OldDot not create TAKECONTROL during auto-pay, or add an automaticAction flag. This would be the most correct fix but requires a backend change outside the App repo.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[allgandalf]

IGNORE

[allgandalf]

sorry i was testing something with the bot, please ignore my message , @twilight2294 not sure why you deleted your proposal 😅 , sorry I was just trying to feed the bot your and melvins proposal for testing and it posted the same via API , apologies

[imgyf]

Proposal

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

When a report is created and auto-paid in OldDot, NewDot displays a spurious "changed approver to [owner name]" system message alongside the expected "paid with bank account via workspace rules" message.

What is the root cause of that problem?

The root cause is in getChangedApproverActionMessage (src/libs/ReportActionsUtils.ts:4091). When OldDot's auto-pay workflow creates a TAKE_CONTROL action as a side effect of reassigning the report's manager during auto-reimbursement, this action has an empty originalMessage — no mentionedAccountIDs array.

The function's fallback logic at line 4100 treats missing mentionedAccountIDs as acceptable and substitutes actorAccountID to produce a "changed the approver to [actor]" message. This fallback is incorrect — a TAKE_CONTROL action without mentionedAccountIDs is an OldDot auto-pay side effect, not an intentional approver change, and should not produce a user-facing message at all.

The renderer in PureReportActionItem.tsx:1749 then unconditionally displays whatever getChangedApproverActionMessage returns, with no guard against empty or invalid content.

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

1. In getChangedApproverActionMessage (src/libs/ReportActionsUtils.ts), remove the actorAccountID fallback. When mentionedAccountIDs is missing or empty, return an empty string instead of fabricating a message from the actor. OldDot TAKE_CONTROL actions lack this field and should not generate an approver-change message.

2. In PureReportActionItem.tsx, in the TAKE_CONTROL/REROUTE rendering branch (line 1749), add a guard: if getChangedApproverActionMessage returns an empty string, return null (don't render the action). This prevents empty system messages from appearing as blank bubbles.

NewDot-originated TAKE_CONTROL actions always include mentionedAccountIDs (set by buildOptimisticChangeApproverReportAction at ReportUtils.ts:8392), so they will continue to render correctly.

What alternative solutions did you explore? (Optional)

Filtering TAKE_CONTROL actions in shouldReportActionBeVisible based on mentionedAccountIDs presence would also work, but the fix is better placed in the message generation function itself — getChangedApproverActionMessage should not fabricate messages from insufficient data. Fixing the source of the bad message is more robust than adding a visibility filter downstream.