[$250] Workspace - Category and Tag "Required" switch is enabled and locked evenif all tags are disable

[lanitochka17]

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.87-0
Reproducible in staging?: Y
Reproducible in production?: Y
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): [email protected]
Issue reported by: Applause - Internal Team
Component: Workspace Settings

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Create WS and enable Tag
3. Add some tags and enable "Members must tag all expenses" toggle
4. Navigate to Category and enable "Members must categorize all expenses" toggle
5. Select all Category and disable all category.
6. Navigate to setting and note that the toggle is is disabled and locked
7. Go back and navigate again and note that the toggle is enabled and locked
8. Navigate to Tag and Select all tags.
9. Disable all tags and navigate to setting and note that the toggle is enabled and locked

Expected Result:

The toggle is disabled and locked when all tags and categories are disabled

Actual Result:

The toggle is enabled and locked when all tags and categories are disabled

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

Bug6717031_1737140837036.bandicam_2025-01-17_21-46-17-653.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @s77rt

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021896598139956436446
• Upwork Job ID: 1896598139956436446
• Last Price Increase: 2025-03-03

[melvin-bot]

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

[Themoonalsofall]

Template proposal

Proposal

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

Workspace - Category and Tag "Required" switch is enabled and locked evenif all tags are disable

What is the root cause of that problem?

we define the toggle logic active

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

Line 108 in 72723ab

isActive={policy?.requiresCategory ?? false}

in case we have turned it on before, the toggle will still be on and locked even though all categories are disabled

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

We should turn off the active state of that toggle by update logic to

         isActive={(policy?.requiresCategory && hasEnabledOptions) ?? false}

and do the same with the Tag page

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

NA

What alternative solutions did you explore? (Optional)

Or we can add new useEffect to set policy.requiresCategory to false when all categories are disabled

    useEffect(()=>(
        if (!hasEnabledOptions) {
            updateWorkspaceRequiresCategory(false);
        }
    ),[hasEnabledOptions]);

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[gijoe0295]

The second OpenPolicyCategoriesPage call when we dismiss the RHP returns policy's requiresCategory as true which is not correct, while the first same call returns false. This is BE related.

[Shahidullah-Muffakir]

The second OpenPolicyCategoriesPage call when we dismiss the RHP returns policy's requiresCategory as true which is not correct, while the first same call returns false. This is BE related.

But if the user enables some categories again, the toggle should turn on. If the backend sets requiresCategory to false after all categories are disabled, then after enabling some categories, the toggle will stay off.

[allgandalf]

@alexpensify this is a BE issue, please use Internal label

[melvin-bot]

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

[alexpensify]

I'm adding Hot Pick, but I'm still reviewing which wave to associate with this one to get more attention.

[alexpensify]

Update: Hot Pick

[melvin-bot]

@alexpensify 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!

[alexpensify]

Hot Pick!

[alexpensify]

Weird, I thought this one was associated with a Project but updated it for more visibility.

[alexpensify]

Weekly Update: Hot Pick

[trjExpensify]

We implement the warning banner that I originally proposed
For admins, we show a RBR for the workspace that points them to the category or tag page so they have some kind of way of knowing about the problem and how to fix it

Oh, cool idea! I think we could get away with just doing the RBR error message. We'll show it right away If they disable all of the category values and have categoriesRequired.

Maybe the empty state is the way to go (but only for workspaces who have no categories enabled but ALSO have members must categorize expenses ticked on).

Totally, I agree it should only be for when Categories are required on the workspace. Else, we hide the category selector like we are today. 👍

[shawnborton]

Hmm but even if a category is required, what point does the empty state serve to the employee? I really think we should solve this at the admin level, as Tim is suggesting above.

So I still think we should just prevent the admin from disabling all categories when they have categories required. Back to Tom's point here:

so efficiently for admins they bulk select > disable all > enable the relevant expense accounts.

Is it that hard for them to bulk select all, but then go back and unselect one (or more) of the categories they don't want to disable?

[dannymcclain]

Or to Tim's point, let them select all and disable all of them, but then leave the first category enabled and show the RBR message.

[shawnborton]

Yeah... I don't love that though, because the user thinks they are taking a certain action but we actually intervene and do something slightly different for them. I think I would rather let them know up front why they can't actually complete that action, and what they need to do to actually move forward.

[dannymcclain]

Totally fair, and when you put it that way, I agree with you.

[trjExpensify]

Hmm but even if a category is required, what point does the empty state serve to the employee?

An explanation as to why there's a violation they can't fix on the expense I guess, really.

Is it that hard for them to bulk select all, but then go back and unselect one (or more) of the categories they don't want to disable?

Mhm, maybe? It's a little more convoluted to explain: "You can't disable all categories when categories are required on the workspace. Unselect at least one, and try again."

(Assuming connected to accounting above, so they can't actually disable categoriesRequired).

[dubielzyk-expensify]

An explanation as to why there's a violation they can't fix on the expense I guess, really.

Catching up here. It's a tricky one. I've quickly prototyped up the last suggestion (unless I missed something):

CleanShot.2025-02-26.at.13.14.17.mp4

To me this feels more natural than the other suggestions cause I don't like the idea of an admin being able to change something that overrides the rules of the workspace and then can be left in a broken state which ultimately is likely to lead to more errors and cases we need to account for.

I think as long as we leave the selection there after they've gotten the warning, that seems fine with me.

[dubielzyk-expensify]

Sorry missed one bit which is adding the lock at the end which then re-triggers the modal:

CleanShot.2025-02-26.at.13.20.36.mp4

[dannymcclain]

Dang honestly that feels pretty slick to me. Maintaining the selection like that makes it still feel like we're telling them why they can't do the action and how to proceed (without actually doing something they haven't explicitly tried to do).

To me this feels more natural than the other suggestions cause I don't like the idea of an admin being able to change something that overrides the rules of the workspace and then can be left in a broken state which ultimately is likely to lead to more errors and cases we need to account for.

I think as long as we leave the selection there after they've gotten the warning, that seems fine with me.

Large agree with this.

[tgolen]

I really like that prototype @dubielzyk-expensify. I think we should go with that

[trjExpensify]

Let's do it!

[shawnborton]

Yup, that's exactly what I had in mind Jon - thanks for bringing it to life!

[dannymcclain]

:send-it:

[tgolen]

@twilight2294 Can you give a proposal for this prototype?

[twilight2294]

Hey @tgolen apoligies, It's pretty late for me now to update the full proposal, but i read the whole conversation and understood the requirement, i quickly made code changes to show you the functionality:

Screen.Recording.2025-02-27.at.1.27.16.AM.mov

This is the basic idea which is required. I will update the proposal if needed first thing tomorrow, but if we want to move quickly on this one then you can assign me here and i can start working tomorrow, thanks for the patience, if you still need updated proposal i will update it tomorrow morning !

[tgolen]

OK, thank you! I don't think there is any rush to this. Tomorrow is fine!

…

On Wed, Feb 26, 2025 at 12:59 PM Rutika Pawar ***@***.***> wrote: Hey @tgolen <https://github.com/tgolen> apoligies, It's pretty late for me now to update the full proposal, but i read the whole conversation and understood the requirement, i quickly made code changes to show you the functionality: https://github.com/user-attachments/assets/cb7a4779-2a2b-409b-8d88-37b4d523ebfe This is the basic idea which is required. I will update the proposal if needed first thing tomorrow, but if we want to move quickly on this one then you can assign me here and i can start working tomorrow, thanks for the patience, if you still need updated proposal i will update it tomorrow morning ! — Reply to this email directly, view it on GitHub <#55431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJMABYB2E2RV3QSPEKO5D32RYMLDAVCNFSM6AAAAABVMSQCPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBWGA3DCOJRGU> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: twilight2294]*twilight2294* left a comment (Expensify/App#55431) <#55431 (comment)> Hey @tgolen <https://github.com/tgolen> apoligies, It's pretty late for me now to update the full proposal, but i read the whole conversation and understood the requirement, i quickly made code changes to show you the functionality: https://github.com/user-attachments/assets/cb7a4779-2a2b-409b-8d88-37b4d523ebfe This is the basic idea which is required. I will update the proposal if needed first thing tomorrow, but if we want to move quickly on this one then you can assign me here and i can start working tomorrow, thanks for the patience, if you still need updated proposal i will update it tomorrow morning ! — Reply to this email directly, view it on GitHub <#55431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJMABYB2E2RV3QSPEKO5D32RYMLDAVCNFSM6AAAAABVMSQCPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBWGA3DCOJRGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[twilight2294]

Updated proposal

Screen.Recording.2025-02-27.at.10.54.11.AM.mov

[twilight2294]

@tgolen any feedback, also label external and assign me to the issue? thanks

[melvin-bot]

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

[melvin-bot]

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

[tgolen]

@s77rt Can you please check this proposal and make sure you are OK with it?

I think this part:

If Tags/Categories are required, but all tags/categories have been disabled, display a clear warning at the top of the Tags/Categories page that lets the workspace admin know that's not an ideal situation.

Can be removed. It was a hold-over from the previous proposal and we are actively preventing this situation from happening now.

[s77rt]

@twilight2294 Thanks for the proposal. Overall the suggested changes look good to me.

🎀 👀 🎀 C+ reviewed
Link to proposal

[melvin-bot]

Current assignee @tgolen is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.