Workspace - Auditor can long press on per diem rate but nothing happens after tapping Select

[applause-bot]

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.3.91-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91305
Email or phone of affected tester (no customers): djoijnsdojsoijnsdoijnsij1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Workspace Settings

Action Performed:

Precondition:

• User A invites User B to workspace as auditor.
• Workspace has per diem rates.
• Perform steps below as auditor (User B).

1. Launch Expensify app.
2. Go to workspace settings > Per diem.
3. Long tap on any per diem rate.
4. Tap Select.

Expected Result:

Long tapping on per diem rate should not show Select option for auditor.

Actual Result:

Auditor can long press on per diem rate but nothing happens after tapping Select.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169335_1780383992699.Screen_Recording_20260602_144435_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7169335

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/c722df6136139bb316b530fb104d4516879d3268a7e61cfa4077b0d323117bca

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #91305

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a regression from #91305 (read-only workspace access for auditors). On the Per Diem page, the long-press "Select" entry point is enabled unconditionally, while the action it triggers is gated behind write access — so an auditor can open the menu but the action is a no-op.

In WorkspacePerDiemPage.tsx, turnOnSelectionModeOnLongPress is passed with no condition, whereas onTurnOnSelectionMode and canSelectMultiple are both gated on canWritePerDiem. Because the long-press flag is always on, the auditor's long press opens the "Select" modal; tapping Select then does nothing because the selection callback and multi-select UI are write-gated.

Every other page touched by the same PR correctly gates this flag on its write flag — Per Diem is the only one that missed it.

Evidence

The long-press modal is shown purely based on the flag in SelectionListWithModal handleLongPressRow:

if (!turnOnSelectionModeOnLongPress || !isSmallScreenWidth || item?.isDisabled || ...) {
    return;
}

Per Diem passes the flag unconditionally while gating everything else on canWritePerDiem:

• turnOnSelectionModeOnLongPress — no condition ← bug
• onTurnOnSelectionMode={(item) => canWritePerDiem && item && toggleSubRate(item)} — gated
• canSelectMultiple = canWritePerDiem && ... — gated

Sibling pages from the same PR, all correctly gated:

• WorkspaceTaxesPage.tsx:496 — turnOnSelectionModeOnLongPress={canWriteTaxes}
• PolicyDistanceRatesPage.tsx:563 — turnOnSelectionModeOnLongPress={canWriteDistanceRates}
• WorkspaceCategoriesPage.tsx:802 — turnOnSelectionModeOnLongPress={canWriteCategories && isSmallScreenWidth}
• WorkspaceTagsPage.tsx:965 — turnOnSelectionModeOnLongPress={canWriteTags && !hasDependentTags}

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

Gate the long-press flag on write access, matching the sibling pages: pass turnOnSelectionModeOnLongPress={canWritePerDiem} (line 512) instead of leaving it unconditional. With this, an auditor's long press no longer opens the "Select" modal, satisfying the expected result.

What alternative solutions did you explore? (Optional)

None needed — gating on canWritePerDiem is the established pattern used by every other workspace list page and is the minimal, consistent fix.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92328) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.