[$125] Categorize - Checkbox does not appear next to the categories in Categories RHP

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

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace settings > Categories
3. Disable all the categories
4. Go to self DM
5. Track a manual expense
6. Click Categorize it from the actionable whisper
7. Select the workspace with all the categories disabled

Expected Result:

Checkbox will appear next to the categories in Categories RHP so that user can bulk select all the categories

Actual Result:

Checkbox does not appear next to the categories in Categories RHP

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

Bug6656768_1730912358115.20241107_005550.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021854581870980912212
• Upwork Job ID: 1854581870980912212
• Last Price Increase: 2024-11-18
• Automatic offers:
• neonbhai | Contributor | 105008672

Issue Owner

Current Issue Owner: @mananjadhav

[melvin-bot]

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

[daledah]

Edited by proposal-police: This proposal was edited at 2024-11-06 18:38:37 UTC.

Proposal

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

Checkbox does not appear next to the categories in Categories RHP

What is the root cause of that problem?

We are not allowing multiple selection as it is a small screen and selectionMode is not enabled here

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

Line 87 in b3a2bcc

const canSelectMultiple = shouldUseNarrowLayout ? selectionMode?.isEnabled : true;

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

We should set canSelectMultiple= true for all case here

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

Line 87 in b3a2bcc

const canSelectMultiple = shouldUseNarrowLayout ? selectionMode?.isEnabled : true;

And we can apply this logic for all pages in workspace

What alternative solutions did you explore? (Optional)

[neonbhai]

Proposal

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

Checkbox does not appear next to the categories in Categories RHP

What is the root cause of that problem?

We don't allow selection mode to turn on when categories page is in the RHP as the check here is only for isSmallScreenWidth.

Hence selection is not possible.

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

We will use isInNarrowPaneModal from useResponsiveLayout to check if we are rendering in the RHP.

App/src/components/SelectionListWithModal/index.tsx

Line 32 in 580bf69

const {isSmallScreenWidth} = useResponsiveLayout();

Then add a prop allowSelectionModeInRHP to SelectionListWithModal here, to allow selectionMode in RHP.

App/src/components/SelectionListWithModal/index.tsx

Line 82 in 580bf69

if (!turnOnSelectionModeOnLongPress || !isSmallScreenWidth || item?.isDisabled || item?.isDisabledCheckbox || !isFocused) {

We will do other adjustments to logic as needed.

Alternatively

We can replace the isSmallScreenWidth with shouldUseNarrowLayout here if we want to allow selection Mode for all editable lists like these RHP. We will then not need to control this behavior with a prop.

[melvin-bot]

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

[melvin-bot]

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

[mananjadhav]

Will review the proposals.

[github-actions]

Your proposal. will be dismissed because you did not follow the proposal template.

[Jaeta01]

Proposal

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

Categorize - Checkbox does not appear next to the categories in Categories RHP

What is the root cause of that problem?

In this scenario, the shouldUseNarrowLayout condition is used to control the display of the checkbox. However, this can lead to issues in layout consistency, as the checkbox visibility is entirely dependent on this condition.

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

Update shouldUseNarrowLayout to isSmallScreenWidth

What alternative solutions did you explore? (Optional)

[isabelastisser]

@mananjadhav, can you please review the proposals and provide an update? Thanks!

[melvin-bot]

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

[mananjadhav]

Will provide an update in an hour.

[melvin-bot]

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

[isabelastisser]

Bump @mananjadhav for an update. Thanks!

[melvin-bot]

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

[mananjadhav]

I think it makes sense to use shouldUseNarrowLayout for all selection lists. But would confirm with the internal engineer.

🎀 👀 🎀 C+ reviewed.

[melvin-bot]

Triggered auto assignment to @MonilBhavsar, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[MonilBhavsar]

Okay pretty straightforward, but would be good to look into why we disallowed selection list initially for RHP. May be on purpose?

[mananjadhav]

@neonbhai Can you please share the ETA on the PR?

[neonbhai]

Working on the PR! raising by tonight

[mananjadhav]

PR will be raised soon and I'll review it then.

[neonbhai]

Looks like this will be the first time selection mode and long press UX will appear on web. Long pressing on an item is not a standard UX behavior for Web and maybe we should not introduce it 🤔

A similar list like Report Fields Values page shows checkbox instead of long press behavior in the RHP on web:

Report.Fields.Values.page.currently.mov

I think we should modify the categories page to mirror this behavior and also have checkboxes:

Screen.Recording.2024-12-02.at.5.45.23.AM.mov

Code changes

• Using isSmallScreenWidth here and here.

• passing isSmallScreenWidth here:

turnOnSelectionModeOnLongPress={isSmallScreenWidth}

cc: @mananjadhav @MonilBhavsar @shawnborton @dannymcclain

[melvin-bot]

@mananjadhav, @isabelastisser, @MonilBhavsar, @neonbhai Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[isabelastisser]

@mananjadhav, can you please provide an update? Thanks!

[dannymcclain]

Looks like this will be the first time selection mode and long press UX will appear on web. Long pressing on an item is not a standard UX behavior for Web and maybe we should not introduce it 🤔

Hmm, I agree. I don't think we should ever use long press on desktop. cc @Expensify/design for additional thoughts.

[shawnborton]

Totally agree with that

[mananjadhav]

Agree with design input and @neonbhai's suggestion.

[dubielzyk-expensify]

Agree with @Expensify/design team

[melvin-bot]

@mananjadhav @isabelastisser @MonilBhavsar @neonbhai this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[mananjadhav]

@neonbhai What's the ETA on the PR?

[neonbhai]

Facing issue with building on Android, finalizing soon!

[neonbhai]

The PR is ready for review!

cc: @mananjadhav

[isabelastisser]

@mananjadhav, please provide an update. Thanks!

[mananjadhav]

@isabelastisser The PR has been deployed to production 14 hours ago. I think the automation failed to update the status.

[mananjadhav]

@isabelastisser This is ready for payout.

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: NA. We didn't consider this case earlier.

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion:

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

I don't think we need regression test for this one.

[isabelastisser]

Payment summary:

Contributor: @neonbhai paid $125 via Upwork
Contributor+: @mananjadhav owed $125 via NewDot PENDING

[isabelastisser]

all set!

[garrettmknight]

$125 approved for @mananjadhav