Categorizing - Inconsistent app behavior when all categories are deleted offline and online

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.7-4
Reproducible in staging?: y
Reproducible in production?: no different behavior
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):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: applause internal team
Slack conversation:

Action Performed:

Precondition:

• Workspace has categories.

1. Go to staging.new.expensify.com
2. Go offline.
3. Go to workspace settings > Categories.
4. Delete all the categories.
5. Go to self DM.
6. Track a manual expense.
7. Click Categorize it from the actionable whisper.
8. Click on the workspace from Step 3.
9. Note that user is able to create categories from the RHP.
10. Go online.
11. Go to Troubleshoot > Clear cache and restart > Refresh and restart.
12. Go back to self DM.
13. Click Categorize it.

Expected Result:

The behavior should be consistent when all categories of the workspace are deleted offline and online.

Actual Result:

When all categories of the workspace are deleted offline, user can add categories from the RHP.
After returning online, user is unable to add categories from the RHP.

Workaround:

unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6544072_1721142553064.20240716_230243.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

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

[roryabraham]

reproduction video isn't playing for me ... why GitHub, why? 😠

[roryabraham]

Ok, the video loaded and this bug report is very difficult to follow. The steps are pretty convoluted, and I'm not going to action it as-is.

The only thing that really seemed like a potentially legitimate issue in the video was that, when you went back offline after being online, all the deleted categories re-appeared in strikethrough form. To me, this suggests that the API command that was meant to delete the categories when you came back online after deleting them offline did not finish or succeed.

[roryabraham]

@m-natarajan can you please try these steps and see how it goes?

1. have a policy with categories enabled
2. Open the network console in chrome
3. Go offline
4. Delete the categories
5. come back online
6. Look in the network console for a DeleteWorkspaceCategories command, and see if it succeeds, fails, or just takes a really long time

[roryabraham]

In any event, I don't think this should be treated as a deploy blocker.

[nyomanjyotisa]

Proposal

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

Categorizing - Inconsistent app behavior when all categories are deleted offline and online

What is the root cause of that problem?

we add the reportOption to recentReportOptions if the getEnabledCategoriesCount result not equal to 0 here:

App/src/libs/OptionsListUtils.ts

Lines 2071 to 2073 in ac10c53

	if (getEnabledCategoriesCount(policyCategories) !== 0) {
	recentReportOptions.push(reportOption);
	}

On getEnabledCategoriesCount function we only filter by option.enabled, and not filtering out the option with pending action delete

App/src/libs/OptionsListUtils.ts

Lines 988 to 990 in ac10c53

	function getEnabledCategoriesCount(options: PolicyCategories): number {
	return Object.values(options).filter((option) => option.enabled).length;
	}

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

To make it consistent to not displaying the workspace on Categorize if all the category deleted both offline and online, we can update the getEnabledCategoriesCount to filter out the option with pending action delete

function getEnabledCategoriesCount(options: PolicyCategories): number {
    return Object.values(options).filter((option) => option.enabled && option.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE).length;
}

RESULT

New-Expensify.17.mp4

What alternative solutions did you explore? (Optional)

[CortneyOfstad]

Based on the comment here, going to have this retested, using the updated steps listed below:

1. have a policy with categories enabled
2. Open the network console in chrome
3. Go offline
4. Delete the categories
5. come back online
6. Look in the network console for a DeleteWorkspaceCategories command, and see if it succeeds, fails, or just takes a really long time

[melvin-bot]

@CortneyOfstad, @roryabraham Whoops! This issue is 2 days overdue. Let's get this updated quick!

[CortneyOfstad]

Not overdue — waiting for QA to retest using the updated steps here

[CortneyOfstad]

Still not overdue, as we're waiting for QA to retest!

[melvin-bot]

@CortneyOfstad, @roryabraham Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@CortneyOfstad @roryabraham this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

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

[CortneyOfstad]

Still not overdue, waiting for QA to retest.

@greg-schroeder I am heading OoO so reassigning to keep eyes on this. I did not apply a project, as I was waiting to see if QA was able to recreate using the updated steps here. Thanks!

[greg-schroeder]

Sounds good, will keep an eye out

[roryabraham]

bumped request for retest: https://expensify.slack.com/archives/C9YU7BX5M/p1722461538857739

[roryabraham]

sounds like this is fixed