Restore IOUReportID fallback for IOU action report resolution#93881
Conversation
Temporary client-side fallback to originalMessage.IOUReportID when resolving the report an IOU action belongs to, restoring behavior removed in PR #87530. The backend does not reliably send reportID on IOU actions, so resolving purely from reportAction.reportID broke editability (admins/managers could not edit fields on submitted expense reports). Remove once the backend reliably includes reportID. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@ahmedGaber93 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
@carlosmiceli Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
🚧 @youssef-lr has triggered a test Expensify/App build. You can view the workflow run here. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a1a5abef67
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
trjExpensify
left a comment
There was a problem hiding this comment.
This is blocking admins from editing reports on NewDot. 👍
The moved-expense flow sets the new IOU action's reportID to the destination report but spreads the old originalMessage, leaving a stale IOUReportID pointing at the source report. Preferring IOUReportID would resolve the wrong report and deny editing to destination-workspace admins. Prefer reportAction.reportID and fall back to IOUReportID only when reportID is missing (the backend-omitted case). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This comment has been minimized.
This comment has been minimized.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
🚧 @youssef-lr has triggered a test Expensify/App build. You can view the workflow run here. |
This comment has been minimized.
This comment has been minimized.
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / Safari |
0db4bb2
|
🚧 @luacmartins has triggered a test Expensify/App build. You can view the workflow run here. |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
…_fallback Restore IOUReportID fallback for IOU action report resolution (cherry picked from commit e4244d9) (cherry-picked to staging by luacmartins)
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
🚀 Cherry-picked to staging by https://github.com/luacmartins in version: 9.4.10-3 🚀
Bundle Size Analysis (Sentry): |
|
🤖 No help site changes required. I reviewed the changes in this PR against the help site files under This is a temporary, internal client-side fix that restores the That expected behavior is already correctly documented on the help site:
Since the docs already reflect the correct (restored) behavior, no draft PR was created. |
…_fallback Restore IOUReportID fallback for IOU action report resolution (cherry picked from commit e4244d9) (cherry-picked to production by roryabraham)
|
🚀 Deployed to production by https://github.com/puneetlath in version: 9.4.11-0 🚀
Bundle Size Analysis (Sentry): |
|
🚀 Cherry-picked to staging by https://github.com/roryabraham in version: 9.4.12-0 🚀
Bundle Size Analysis (Sentry): |
|
Tested in the customer account on prod, and it's fixed. |
|
🚀 Cherry-picked to staging by https://github.com/roryabraham in version: 9.4.14-0 🚀
Bundle Size Analysis (Sentry): |
|
🚀 Deployed to production by https://github.com/puneetlath in version: 9.4.14-1 🚀
|
|
🚀 Cherry-picked to staging by https://github.com/roryabraham in version: 9.4.15-0 🚀
|
|
🤖 I reviewed the changes in this PR against the help site files under No help site changes are required. This PR is a purely internal bug fix. It restores the
The user-facing effect is a regression fix — it restores an admin's/manager's ability to edit coding fields (Category, Tag, Description, etc.) on expense reports submitted by other members. That is the already-intended behavior the help site documents (e.g. Edit Expenses); the docs do not describe the broken read-only state this PR repairs. There are no new features, settings, labels, buttons, or workflows introduced, so nothing in the help site needs to be added or revised. No draft docs PR was created. @youssef-lr, please confirm you agree no help site changes are needed here. If you believe a docs update is warranted, let me know what behavior should be documented and I'll create the draft PR. |
Explanation of Change
#87530 ("Remove usage of IOUReportID completely", shipped in v9.4.8) stopped resolving the report an
IOUaction belongs to via thegetOriginalMessage(reportAction)?.IOUReportID ?? reportAction?.reportIDfallback and switched to usingreportAction?.reportIDdirectly. The premise was that forCREATE/TRACKIOUactionsreportIDalways equals the IOU/expense report ID.That premise does not hold for backend-hydrated actions: the backend does not reliably include
reportIDonIOUactions, so the lookup resolves the wrong report (or none). When that happens,getPolicy()cannot find the policy, the admin/manager bypass incanEditMoneyRequest/canEditFieldOfMoneyRequestnever fires, and execution falls through to the requestor-only branch. The result is that an admin or manager viewing someone else's submitted expense report sees every field as read-only — and because the edit is blocked client-side, no request is ever sent to the API. The code already documents this divergence inuseGetIOUReportFromReportAction("For self-DM tracks and split bills, action.reportID resolves to a chat report, not an IOU/expense report").This PR restores the
originalMessage.IOUReportID ?? reportAction?.reportIDfallback in the report-resolution paths used for editability:canEditMoneyRequestcanEditFieldOfMoneyRequestcanEditReportActionuseGetIOUReportFromReportActionIt also re-adds the
IOUReportIDfield to theOriginalMessageIOUtype (it had been removed) so the fallback typechecks.This is a temporary client-side fallback. The real fix is on the backend, which must reliably include
reportIDonIOUactions; once that ships, the fallback (and theIOUReportIDfield) should be removed. Tracked in #93882.Fixed Issues
$ #93864
PROPOSAL:
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari