Category - Selected item is no longer selected after renaming the category

[lanitochka17]

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.0.78-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): applausetester+909608@applause.expensifail.com
Issue reported by: Applause - Internal Team
Component Workspace Settings

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace settings > Categories
3. Click Select all checkbox
4. Click on any selected category
5. Click Name
6. Edit the name and save it
7. Note that the renamed category is now unselected
8. Go to Taxes
9. Click Select all checkbox
10. Click on the selected rate
11. Click Name
12. Rename and save it
13. Note that the renamed tag remains selected

Expected Result:

There should be consistency in the item selection after renaming category and tax rate while they are selected

Actual Result:

In Step 7, after renaming the selected category, it is unselected
In Step 9, after renaming the selected tag, it remains selected

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6701534_1734996446867.20241224_072205.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @neil-marcellini (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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.

[BhuvaneshPatil]

Proposal

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

When we select category, and edit the name. Category is not selected anymore.

What is the root cause of that problem?

We use name as key for list and to check if that item is selected using the name. So when we update the name of category, key changes, thus the category is un-selected.

App/src/pages/workspace/categories/WorkspaceCategoriesPage.tsx

Lines 108 to 115 in 8b7096f

	return {
	text: value.name,
	keyForList: value.name,
	isSelected: !!selectedCategories[value.name] && canSelectMultiple,
	isDisabled,
	pendingAction: value.pendingAction,
	errors: value.errors ?? undefined,
	rightElement: <ListItemRightCaretWithLabel labelText={value.enabled ? translate('workspace.common.enabled') : translate('workspace.common.disabled')} />,

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

We should have an id field for category that can be used for key. This field is non-changing and hence it will work.
Similar thing is done on tax rates page.

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

What alternative solutions did you explore? (Optional)

[truph01]

Edited by proposal-police: This proposal was edited at 2024-12-24 02:38:54 UTC.

Proposal

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

• In Step 7, after renaming the selected category, it is unselected
• In Step 9, after renaming the selected tag, it remains selected

What is the root cause of that problem?

• Categories are identified solely by their names. When editing a category, we effectively delete the old category and create a new one:

App/src/libs/actions/Policy/Category.ts

Line 589 in 8b7096f

[policyCategory.oldName]: null,

This results in a scenario where, when a user selects category A and subsequently updates it to B, the workspace A is no longer marked as selected.

• This behavior is expected because selecting A indicates a desire to use A specifically. Updating it to B implies the removal of A and the creation of a new category, B. Consequently, marking B as selected is unnecessary in this case.

• The only issue is that, the dropdown button still counting A as selected, which leads to an inaccurate display of the number of selected options. We need to address it.

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

• We can create a hook which will auto-update the selected options once the options change:

import {useEffect} from 'react';
import type {PolicyCategories} from '@src/types/onyx';

const useAutoUpdateSelectedOptions = (
    listItem: PolicyCategories,
    selectedOptions: Record<string, boolean>,
    setSelectedOptions: React.Dispatch<React.SetStateAction<Record<string, boolean>>>,
) => {
    useEffect(() => {
        const availableOptions = Object.values(listItem ?? {})
            .filter((o) => o.pendingAction !== 'delete')
            .map((o) => o.name);
        const originalSelectedOptions = Object.keys(selectedOptions);
        const newSelectedOptions = originalSelectedOptions.filter((o) => availableOptions.includes(o));
        setSelectedOptions(
            newSelectedOptions.reduce((acc, key) => {
                acc[key] = true;
                return acc;
            }, {}),
        );
    }, [listItem]);
};
export default useAutoUpdateSelectedOptions;

• And use it in here:

    useAutoUpdateSelectedOptions(policyCategories ?? {}, selectedCategories, setSelectedCategories);

• We can use the hook above on other pages like workspace tax page, workspace tag page, etc.

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

• We can create a test function that simulate the update of policyCategories data and see whether the number of selected options is updated properly.

What alternative solutions did you explore? (Optional)

[truph01]

@neil-marcellini The bug mentioned in OP is "when a user selects category A and subsequently updates it to B, the workspace A is no longer marked as selected."

IMO, this behavior is expected because selecting category A reflects the user's intent to use A specifically. When they update it to B, it signifies not just a change in category but the creation of a new category, B, and the removal of A. Marking B as selected would lead to confusion, as it misrepresents the user's intention.

What do you think?