[Due for payment 2026-06-17] [Due for payment 2026-06-16] Categories - GL code, Approver and Enabled column are misaligned

[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.4.0-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: #92270
Email or phone of affected tester (no customers): sdsonjodjsodjos@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• User A invites User B to workspace as auditor.
• Add GL code and approver to any category.
• Perform steps below as auditor (User B).

1. Go to staging.new.expensify.com
2. Go to workspace settings > Categories.

Expected Result:

GL code, Approver and Enabled column will be aligned correctly.

Actual Result:

GL code, Approver and Enabled column are misaligned.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7172884

[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/66473db4114690c4c1abca26c6aede2b90bf33f2d82b113b40f85b28f890c8bc

[melvin-bot]

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

[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

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

On a control workspace with rules enabled, when an auditor (read-only scoped role) opens Workspace settings > Categories, the GL code, Approver, and Enabled column headers no longer line up with the values rendered in the rows below them. This is a regression introduced by #92270 (read-only access for auditors), which is why it only reproduces for read-only roles and not for admins.

What is the root cause of that problem?

#92270 added a separate read-only branch to getCustomListHeader() in WorkspaceCategoriesPage.tsx. When the user can't write (canSelectMultiple/canWriteCategories are false), the header is built differently from the data rows:

• The Enabled column drops its right margin: canWriteCategories && styles.mr5. That mr5 (20px) reserves space for the right caret. But the caret is always rendered — shouldShowRightCaret is hard-coded true, so read-only rows still navigate to the detail RHP and still show the caret. Removing the margin shifts the Enabled header ~20px out of alignment with the switch column beneath it.
• The left padding is dropped and the header is re-wrapped in a different padding container for the read-only case (pl3 → baseListHeaderWrapperStyle, which applies ph9 = 36px horizontal padding). Because the Name/GL code/Approver columns are flex1 and share width via justifyContentBetween, this padding swap moves their start positions away from the row content, cascading into the GL code and Approver misalignment as well.

Net effect: the read-only header's paddings/margins don't match the actual TableListItem row layout (which still renders the right caret and the same rightElement column widths), so all three columns drift.

Why it only affects auditors

For admins, canSelectMultiple is true, so the header takes the original path (pl3 + mr5, no wrapper) which already matches the row layout that includes the select checkbox column. Only the new read-only path is misaligned. The columns themselves (GL code / Approver) only appear on a wide-layout control policy with rules enabled — matching the issue's preconditions (auditor + GL code + approver added).

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

Make the read-only header reserve the same right-caret space and horizontal padding as the data rows in getCustomListHeader():

1. Keep the Enabled column's right margin in the read-only case too, since the caret is still rendered for read-only rows — i.e. don't gate styles.mr5 on canWriteCategories (the caret/mr5 spacing is independent of write access).
2. Make the read-only header's horizontal padding line up with the TableListItem row content (the baseListHeaderWrapperStyle ph9 wrapper vs. the row's actual padding). The columns should be verified visually so the read-only header matches the rows exactly.

Because the exact pixel offsets depend on the list item's padding, the fix should be verified in the browser as an auditor on a control policy with rules enabled, a GL code, and a category approver.

What alternative solutions did you explore? (Optional)

Revert #92270 if a clean targeted fix isn't quick — it's a deploy blocker and the PR is large. But the regression is isolated to this one header function, so a scoped fix is preferable.

---

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

[ShridharGoel]

Fixed here

CC: @Pujan92