Skip to content

[$500] IOU - A disabled category in IOU does not deselect when you click on it #35553

Closed

Description

@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: 1.4.35-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4257599
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:

Preconditions:
Configure the OldDot administrator account, include a maximum of 7 categories and invite the employee to the policy https://sites.google.com/applausemail.com/applause-expensifyproject/wiki-guides/newdot-categories?authuser=0
Steps:

  1. Open https://staging.new.expensify.com/
  2. Log in with the account of the employee added to the policy
  3. Navigate to the group policy chat room
  4. Create a manual request with any category and send it to the WS room
  5. Open https://staging.expensify.com/
  6. Under the administrator account, disable the category from step 4
  7. In NewDot, under the employee's account, go to IOU details
  8. Click on the category field
  9. Click on the selected category with a green check mark

Expected Result:

When you click on a disabled category, it should deselect itself

Actual Result:

A disabled category in IOU does not deselect when you click on it

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

Add any screenshot/video evidence

Bug6363552_1706788366027.Recording__1245.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~01faafade61edc83ca
  • Upwork Job ID: 1753056687790592000
  • Last Price Increase: 2024-02-01
  • Automatic offers:
    • DylanDylann | Reviewer | 28142211
    • tienifr | Contributor | 28142212

Activity

  1. added
    ExternalAdded to denote the issue can be worked on by a contributor
    BugSomething is broken. Auto assigns a BugZero manager.
    on Feb 1, 2024
  2. changed the title [-] IOU - A disabled category in IOU does not deselect when you click on it[/-] [+][$500] IOU - A disabled category in IOU does not deselect when you click on it[/+] on Feb 1, 2024
  3. melvin-bot commented on Feb 1, 2024

    @melvin-bot
  4. added
    Help WantedApply this label when an issue is open to proposals by contributors
    on Feb 1, 2024
  5. melvin-bot commented on Feb 1, 2024

    @melvin-bot

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

  6. melvin-bot commented on Feb 1, 2024

    @melvin-bot

    Triggered auto assignment to @laurenreidexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

  7. lanitochka17 commented on Feb 1, 2024

    @lanitochka17
    Author

    We think that this bug might be related to #wave6
    CC @greg-schroeder

  8. tienifr commented on Feb 1, 2024

    @tienifr
    Contributor

    Proposal

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

    A disabled category in IOU does not deselect when you click on it

    What is the root cause of that problem?

    When the number of categories is small, this block will run, and we'll be getting the category option tree based on the enabledAndSelectedCategories, but in enabledAndSelectedCategories, the selected category currently has enabled false, because it was disabled in Admin side, so it shows as disabled in the list.

    If there're a lot of categories (equal or more than CATEGORY_LIST_THRESHOLD), this issue won't happen because in that case we already set the enabled: true for the selected category, regardless of its enabled status, as can be seen here.

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

    When constructing the enabledAndSelectedCategories list here, push the selected categories in, all with enabled: true first, then push the remaining enabled categories. This is the same as we're already doing for list of a lot of categories (equal or more than CATEGORY_LIST_THRESHOLD). Also a bonus is that the selected category now will come as the first item in the list, consistent with the a-lot-of-categories UX.

    const enabledAndSelectedCategories = [...selectedOptions, ...sortedCategories.filter((category) => category.enabled && !selectedOptionNames.includes(category.name))];
    

    What alternative solutions did you explore? (Optional)

    If instead we want to keep the ordering of the selected category amongst the categories as currently, we can look for the selected category in the current enabledAndSelectedCategories and set its enabled to true.

    Another approach is:
    Pass an array of selected categories as a 3rd param of getCategoryOptionTree, and when checking isDisabled, make sure that category is not currently selected before setting isDisabled as true.

    In here we should apply similar logic as well.

    Not related to this issue but in this line if both parent and child are categories, like Advertising and Advertising: Social Media: Facebook, the Advertising seems to be disabled incorrectly. We might want to check and fix it separately.

  9. tienifr commented on Feb 1, 2024

    @tienifr
    Contributor

    Proposal updated to add example code change.

  10. DylanDylann commented on Feb 2, 2024

    @DylanDylann
    Contributor

    The main solution in @tienifr's proposal looks good to me
    🎀 👀 🎀 C+ reviewed

  11. 12 remaining items

  12. aimane-chnaif commented on Feb 21, 2024

    @aimane-chnaif
    Contributor

    This caused regression. Restored this bug back.

  13. Julesssss commented on Feb 21, 2024

    @Julesssss
    Contributor

    @tienifr could you please raise a follow-up? There's a good suggested fix here in the linked issue

  14. tienifr commented on Feb 23, 2024

    @tienifr
    Contributor

    Sure.

  15. tienifr commented on Feb 23, 2024

    @tienifr
    Contributor

    @DylanDylann Regression fix PR is ready for review #37127.

  16. DylanDylann commented on Feb 28, 2024

    @DylanDylann
    Contributor

    @laurenreidexpensify Please help to move forward with this issue, the PR is deployed to production and there are no regression as confirmed here

  17. tienifr commented on Mar 1, 2024

    @tienifr
    Contributor

    @laurenreidexpensify Please help move forward this issue or add Hold for payment label.

  18. laurenreidexpensify commented on Mar 4, 2024

    @laurenreidexpensify
    Contributor

    Payment Summary:

    Contributor $500 paid in Upwork @tienifr
    C+ $500 paid in Upwork @DylanDylann

  19. laurenreidexpensify commented on Mar 4, 2024

    @laurenreidexpensify
    Contributor

    @DylanDylann pls add checklist and regression step suggestions thank you

  20. DylanDylann commented on Mar 4, 2024

    @DylanDylann
  21. Julesssss commented on Mar 4, 2024

    @Julesssss
    Contributor

    I'm not sure we need this very specific regression test to be honest. If none already exist maybe we could create a generic one to test the list component with a disabled item to cover many cases

  22. laurenreidexpensify commented on Mar 6, 2024

    @laurenreidexpensify
    Contributor

    @DylanDylann @Julesssss do you have a suggestion for how that could look? Just tryna visualise what the many cases could be. Thanks!

  23. Julesssss commented on Mar 6, 2024

    @Julesssss
    Contributor

    I found one here. So no need for any new cases

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

BugSomething is broken. Auto assigns a BugZero manager.DailyKSv2ExternalAdded to denote the issue can be worked on by a contributorReviewingHas a PR in review

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions