[$250] WS settings - Enabling People must categorize expenses in OD disables Categories in ND

@c3024

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.1.89-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2219752/test-runs/TR-77/folder/13176928/41237641/822775146
Email or phone of affected tester (no customers): biruknew45+11vvbbg0@gmail.com
Issue reported by: Applause Internal Team
Device used: Web, mweb, android
App Component: Workspace Settings

Action Performed:

Go to https://staging.new.expensify.com
Create a Workspace
Go to Categories > More > disable "Members must categorize all expenses"
Go to More Features then disable Categories
Go to OD (https://staging.expensify.com/) then reload the page
Go to Workspace > Categories then enable all categories
Go back to ND, verify that Categories feature is enabled
Go to OD, enable People must categorize expenses
Go back to ND

Expected Result:

After enabling "People must categorize expenses" in OD, the Categories feature in ND should remain enabled.

Actual Result:

After enabling "People must categorize expenses" in OD, the Categories feature in ND becomes disabled.

Workaround:

Unknown

Platforms:

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021953484130624407223
Upwork Job ID: 1953484130624407223
Last Price Increase: 2025-09-18

Issue Owner

Current Issue Owner: @c3024

@abekkala

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

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

@c3024

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

🚨 Edited by proposal-police: This proposal was edited at 2025-08-07 23:03:18 UTC.

Proposal

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

In ND, the Categories feature appears disabled after enabling “People must categorize expenses” in OD.

What is the root cause of that problem?

Root cause is OD is not async as ND. Let me explain the flow you performed:

You disable Categories from More features page which makes areCategoriesEnabled disabled for ND in backend
You navigate to OD, and refresh the page with areCategoriesEnabled: false
You enable all categories from checkbox which makes areCategoriesEnabled: true on BACKEND (thus, ND front is updated thanks to socket). But post request to update "People must categorize..." is NOT UPDATED, i.e, areCategoriesEnabled leaves false
You disable "People must categorize..." and it gives the the false areCategoriesEnabled in return which makes Categories on ND disabled.

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

So I guess, backend fix will be more straightforward, but we can fix the issue on front itself by taking into enabled categories account in src/pages/workspace/WorkspaceMoreFeaturesPage.tsx.

L109

 const hasEnabledCategories = hasEnabledOptions(policyCategories ?? {});

L129

 isActive: (policy?.areCategoriesEnabled ?? false) || hasEnabledCategories,

And we need to make sure to update all instances where areCategoriesEnabled comes

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

Backend sets areCategoriesEnabled = true when requiresCategory = true.

@c3024

@c3024 Eep! 4 days overdue now. Issues have feelings too...

@c3024

as far as I understand, the hasEnabledOptions check is meant for cases where categories (or another feature) are enabled in More Features

I believe it's for checking if we have any enabled WS category rather than options in "More Features" OR to check any enabled tag.

App/src/libs/OptionsListUtils/index.ts

Lines 1049 to 1054 in 2a1cebd

    
           /** 
        
            * Verifies that there is at least one enabled option 
        
            */ 
        
           function hasEnabledOptions(options: PolicyCategories | PolicyTag[]): boolean { 
        
               return Object.values(options).some((option: PolicyTag | PolicyCategory) => option.enabled && option.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE); 
        
           }

So that means, if we have at least one enabled category from OD, Categories should be enabled. This is 100% promising?! cc @c3024

Let me share more examples from latest main:

App/src/components/MoneyRequestConfirmationList.tsx

Lines 319 to 321 in 79fc314

    
           // A flag for showing the categories field 
        
           const shouldShowCategories = (isPolicyExpenseChat || isTypeInvoice) && (!!iouCategory || hasEnabledOptions(Object.values(policyCategories ?? {})));

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 265 to 269 in 79fc314

    
           // Flags for showing categories and tags 
        
           // transactionCategory can be an empty string 
        
           // eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing 
        
           const shouldShowCategory = shouldShowPolicySpecificFields && (categoryForDisplay || hasEnabledOptions(policyCategories ?? {})); 
        
           // transactionTag can be an empty string

And yes, BE also should fix this

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

@c3024

@c3024 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

changed the labels as this requires an internal back-end fix.

@c3024

@c3024 Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

Navigation Menu

Repository navigation

[$250] WS settings - Enabling People must categorize expenses in OD disables Categories in ND #67928

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

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

What is the root cause of that problem?

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

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

31 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	/**
	* Verifies that there is at least one enabled option
	*/
	function hasEnabledOptions(options: PolicyCategories \| PolicyTag[]): boolean {
	return Object.values(options).some((option: PolicyTag \| PolicyCategory) => option.enabled && option.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);
	}

	// A flag for showing the categories field
	const shouldShowCategories = (isPolicyExpenseChat \|\| isTypeInvoice) && (!!iouCategory \|\| hasEnabledOptions(Object.values(policyCategories ?? {})));

	// Flags for showing categories and tags
	// transactionCategory can be an empty string
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const shouldShowCategory = shouldShowPolicySpecificFields && (categoryForDisplay \|\| hasEnabledOptions(policyCategories ?? {}));
	// transactionTag can be an empty string

[$250] WS settings - Enabling People must categorize expenses in OD disables Categories in ND #67928

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on Aug 5, 2025

melvin-bot commented on Aug 7, 2025

melvin-bot commented on Aug 7, 2025

mukhrr commented on Aug 7, 2025

Proposal

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

What is the root cause of that problem?

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

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

melvin-bot commented on Aug 12, 2025

31 remaining items

mukhrr commented on Sep 15, 2025

melvin-bot commented on Sep 18, 2025

melvin-bot commented on Sep 22, 2025

abekkala commented on Sep 23, 2025

melvin-bot commented on Sep 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions