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
Edit multiple option unavailable when selecting draft (open) expense #101754
Version Number: 9.4.90-1 Reproducible in staging?: Yes Reproducible in production?: Yes If this was caught during regression testing, add the test name, ID and link from BrowserStack:#101090 Email or phone of affected tester (no customers): Logs:https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: Applause Internal Team Slack conversation (hyperlinked to channel name):
Action Performed:
Navigate to staging.new.expensify.com
Join as new user selecting Track and budget expenses (business expense) intent
Open the workspace chat.
Create 2 expenses as 2 separate reports.
Mark one of the two expenses as done.
Go to Spend, select only the expense that is still open, and look for Edit multiple option
Expected Result:
Edit multiple option should be available when selecting open expense
Actual Result:
Edit multiple option unavailable when selecting draft (open) expense
Workaround:
Unknown
Platforms:
Select the officially supported platforms where the issue was reproduced:
TL;DR — this is not a product bug. The test step is wrong.Edit multiple requires 2 or more selected expenses by design. Step 6 selects one. I reproduced all three selection states on web: a single expense never offers Edit multiple, whether it is Draft or Done.
Selection on Spend › Expenses
Actions offered
Edit multiple?
Draft (open) expense only
Export, Merge, Split, More → (Duplicate expense, Delete)
❌
Done expense only
Export, Duplicate expense
❌
Both expenses
Edit multiple, Export, Duplicate expenses
✅
So the "Expected Result" in this issue does not match the intended behaviour, and the Draft status is not what hides the option.
What is the root cause of that problem?
canEditMultipleTransactions returns false before it looks at report status at all, whenever fewer than two transactions are selected:
Nothing in that function treats an open report as non-editable — "Mark as done" leaves the report at status CLOSED, which is neither approved nor settled, so both expenses pass the editability checks once two are selected. That is why the option appears at step 7 of Expensify/App#101090 (select both) and not at step 6 (select one).
What changes do you think we should make in order to solve the problem?
Select two open (Draft) expenses → open Edit multiple → confirm Reimbursable is enabled.
Swap one selection for the Done expense → open Edit multiple → confirm Reimbursable is disabled.
Then close this issue as invalid.
If the product genuinely wants single-expense bulk editing, that is a new feature request, not a regression — it contradicts the guard, its unit test, and the Edit multiple copy. Extend admin bulk edit to expenses on approved and paid reports is the right place to raise it.
Reproduction evidence (dev NewDot, web)
Onboarded a fresh user with the Track expenses for my business intent, created two expenses in the workspace chat as two separate reports, and marked one report as done.
Spend › Expenses renders one row per transaction (not per report), so isExpenseReportSearch is false and the areReportsSelected early return is not involved:
Draft only — no Edit multiple (the More overflow contains only Duplicate expense and Delete, so it is not merely hidden behind the overflow):
Done only — also no Edit multiple. This is the key data point: the issue's premise implies the Done expense behaves differently, and it does not.
Both selected — Edit multiple appears:
Why the open report is not the blocker: the onboarding user is policy admin, so canEditMoneyRequest short-circuits to true, and non-restricted fields (Category, Tag, Description) return true at ReportUtils.ts:5406-5408.
History: both the < 2 guard and the areReportsSelected parameter shipped in the original Reapply "Reapply "Feat: bulk edit multiple"" (merged 2026-03-30). Neither was introduced by a recent change, so there is no regression window here.
Alternative explanations I ruled out:
Transactions on draft reports not hydrated in the Search snapshot, shrinking the list below 2 — ruled out: selectionBuilders.ts:286-321 stores the full item as transaction: item. Only empty-report rows lack it.
Spend using the expenseReport data type, tripping the areReportsSelected guard — ruled out: the Spend tab lands on type:expense per getSearchTabRoute.ts:37-38, confirmed by the transaction rows above.
Missing reportAction making every field non-editable — a real latent failure mode at ReportUtils.ts:5266-5268, but not reached here because the < 2 guard returns first.
Two unrelated smells found along the way (worth separate issues, not fixes here)
areReportsSelected is misnamed and over-broad. Every caller passes a search data type flag, not a selection fact — see useSearchBulkActions.ts:2357. On Spend › Reports, Edit multiple is suppressed wholesale even when the selection is entirely transactions.
Stale-snapshot flicker. The lastNonEmptySearchResultsRef fallback at useSearchBulkActions.ts:579 can keep an expenseReport snapshot alive while switching Reports → Expenses, transiently hiding Edit multiple until the new results land.
Next Steps for Contributor+ team: To accept:@MelvinBot implement [this](https://github.com/Expensify/App/issues/101754) to create a draft PR. To refine:@MelvinBot <your feedback> To reject: Explain why you are rejecting Melvin's proposal.
This issue is not a bug because selection mode and batch editing options are only available when selecting two or more items. The test steps in the PR incorrectly specify selecting only a single expense. Therefore, I think we can close this one and update test step on PR
I don't have permission to close this issue. @grgia, can you close it as not planned?
suneox confirmed this is expected behavior: selection mode and bulk edit options only appear when you select two or more expenses. The earlier test steps selected a single expense.
Activity
MelvinBot commentedon Sep 21, 2026
Proposal
TL;DR — this is not a product bug. The test step is wrong.
Edit multiplerequires 2 or more selected expenses by design. Step 6 selects one. I reproduced all three selection states on web: a single expense never offersEdit multiple, whether it is Draft or Done.Edit multiple?So the "Expected Result" in this issue does not match the intended behaviour, and the Draft status is not what hides the option.
What is the root cause of that problem?
canEditMultipleTransactionsreturnsfalsebefore it looks at report status at all, whenever fewer than two transactions are selected:src/libs/ReportUtils.ts:5256-5258Step 6 selects exactly one row, so the guard fires and
useSearchBulkActions.ts:2361-2380never pushes the option into the menu. This is deliberate and pinned by a unit test:tests/unit/canEditMultipleTransactionsTest.ts:129-134assertsfalse"when fewer than two transactions are selected".Nothing in that function treats an open report as non-editable — "Mark as done" leaves the report at status
CLOSED, which is neither approved nor settled, so both expenses pass the editability checks once two are selected. That is why the option appears at step 7 ofExpensify/App#101090(select both) and not at step 6 (select one).What changes do you think we should make in order to solve the problem?
No App code change. Fix the QA steps on Disable Reimbursable in Edit multiple when a selected expense is locked so they select two expenses, which is what that PR actually needed verified:
Edit multiple→ confirm Reimbursable is enabled.Edit multiple→ confirm Reimbursable is disabled.Then close this issue as invalid.
If the product genuinely wants single-expense bulk editing, that is a new feature request, not a regression — it contradicts the guard, its unit test, and the
Edit multiplecopy. Extend admin bulk edit to expenses on approved and paid reports is the right place to raise it.Reproduction evidence (dev NewDot, web)
Onboarded a fresh user with the Track expenses for my business intent, created two expenses in the workspace chat as two separate reports, and marked one report as done.
Spend › Expenses renders one row per transaction (not per report), so
isExpenseReportSearchisfalseand theareReportsSelectedearly return is not involved:Draft only — no
Edit multiple(theMoreoverflow contains only Duplicate expense and Delete, so it is not merely hidden behind the overflow):Done only — also no
Edit multiple. This is the key data point: the issue's premise implies the Done expense behaves differently, and it does not.Both selected —
Edit multipleappears:Why the open report is not the blocker: the onboarding user is policy admin, so
canEditMoneyRequestshort-circuits totrue, and non-restricted fields (Category, Tag, Description) returntrueatReportUtils.ts:5406-5408.History: both the
< 2guard and theareReportsSelectedparameter shipped in the original Reapply "Reapply "Feat: bulk edit multiple"" (merged 2026-03-30). Neither was introduced by a recent change, so there is no regression window here.Alternative explanations I ruled out:
selectionBuilders.ts:286-321stores the full item astransaction: item. Only empty-report rows lack it.expenseReportdata type, tripping theareReportsSelectedguard — ruled out: the Spend tab lands ontype:expensepergetSearchTabRoute.ts:37-38, confirmed by the transaction rows above.reportActionmaking every field non-editable — a real latent failure mode atReportUtils.ts:5266-5268, but not reached here because the< 2guard returns first.Two unrelated smells found along the way (worth separate issues, not fixes here)
areReportsSelectedis misnamed and over-broad. Every caller passes a search data type flag, not a selection fact — seeuseSearchBulkActions.ts:2357. On Spend › Reports,Edit multipleis suppressed wholesale even when the selection is entirely transactions.lastNonEmptySearchResultsReffallback atuseSearchBulkActions.ts:579can keep anexpenseReportsnapshot alive while switching Reports → Expenses, transiently hidingEdit multipleuntil the new results land.Related issues
Edit multiplesurface, different cause.Expensify/App#101090addressed.Next Steps for Contributor+ team:
To accept:
@MelvinBot implement [this](https://github.com/Expensify/App/issues/101754)to create a draft PR.To refine:
@MelvinBot <your feedback>To reject: Explain why you are rejecting Melvin's proposal.
view run · view recording
melvin-bot commentedon Sep 21, 2026
Triggered auto assignment to Contributor-plus team member for initial proposal review - @abzokhattab (
External)melvin-bot commentedon Sep 21, 2026
Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.
abzokhattab commentedon Sep 21, 2026
this is related to this PR #101090 can you please check this out @suneox @tylerkaraszewski
melvin-bot commentedon Sep 24, 2026
@abzokhattab Whoops! This issue is 2 days overdue. Let's get this updated quick!
suneox commentedon Sep 25, 2026
This issue is not a bug because selection mode and batch editing options are only available when selecting two or more items. The test steps in the PR incorrectly specify selecting only a single expense. Therefore, I think we can close this one and update test step on PR
🎀 👀 🎀 C+ reviewedmelvin-bot commentedon Sep 25, 2026
Triggered auto assignment to @grgia, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
abzokhattab commentedon Sep 25, 2026
@izarutskaya could u please recheck
suneox commentedon Sep 25, 2026
This is already handled by the initial implementation
abzokhattab commentedon Sep 28, 2026
@MelvinBot can you close the ticket ... the bug is not valid
MelvinBot commentedon Sep 28, 2026
I don't have permission to close this issue. @grgia, can you close it as not planned?
suneoxconfirmed this is expected behavior: selection mode and bulk edit options only appear when you select two or more expenses. The earlier test steps selected a single expense.view run
melvin-bot commentedon Sep 28, 2026
@grgia Whoops! This issue is 2 days overdue. Let's get this updated quick!
grgia commentedon Sep 29, 2026
Closing, thanks @abzokhattab