Skip to content

[Due for payment 2025-03-21] [$250] Tags-In approver section, green checkmark while select user is not visible before leaving page #57514

Closed

Description

@mitarachim

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: V9.1.7-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: N
Email or phone of affected tester (no customers): N
Issue reported by: Applause Internal Team
Device used: Redminote 10s android 13
App Component: Workspace Settings

Action Performed:

Pre-condition: Have a control workspace with rules enabled and tag created

  1. Launch app
  2. Tap categories -Advertising -approver
  3. Select user displayed in dropdown
  4. Note after selected green checkmark is visible before leaving the page
  5. Again tap approver
  6. Unselect the user and now note the green checkmark is removed before leaving the page
  7. Go to workspace settings - tags
  8. Tap on a tag - approver
  9. Select user in dropdown
  10. Note after selected green checkmark is not visible before leaving the page
  11. Unselect the user and now note the green checkmark removed is not visible before leaving the page

Expected Result:

In categories&tags-approver section :

  1. Green checkmark must be visible before leaving the page while select approver .
  2. Green checkmark must not visible before leaving the page while unselect approver .

Actual Result:

In tags-approver section,

  1. Green checkmark not visible before leaving the page while select approver .
  2. Green checkmark visible before leaving the page while unselect approver .

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6755777_1740624578918.Screenrecorder-2025-02-27-08-04-44-521.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~021897737213539397584
  • Upwork Job ID: 1897737213539397584
  • Last Price Increase: 2025-03-06
  • Automatic offers:
    • QichenZhu | Reviewer | 106473930
Issue OwnerCurrent Issue Owner: @abekkala

Activity

  1. added
    BugSomething is broken. Auto assigns a BugZero manager.
    on Feb 27, 2025
  2. melvin-bot commented on Feb 27, 2025

    @melvin-bot

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

  3. bernhardoj commented on Feb 27, 2025

    @bernhardoj
    Contributor

    Proposal

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

    In tag approver selection, when selecting the approver, the green checkmark doesn't show before leaving the page like on the category approver page. It also doesn't disappear when unselecting.

    What is the root cause of that problem?

    The checkmark shows based on the selected approver data.

    selectedApprover={tagApprover ?? ''}

    However, on the tag page, the selected approver data isn't updated dynamically. That's because even when the policy is updated, the re-calculation of the selected approver isn't happening because we only use policyID.

    const tagApprover = PolicyUtils.getTagApproverRule(policyID, tagName)?.approver;

    If we compare it to the category approver page, we use the policy object itself, so it's updated dynamically

    const policy = usePolicy(policyID);
    const selectedApprover = CategoryUtils.getCategoryApproverRule(policy?.rules?.approvalRules ?? [], categoryName)?.approver ?? '';

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

    If the expectation is to show the checkmark while the page is closing, then we need to do the same thing on the category approver page.

    const policy = usePolicy(policyID);
    
    const tagApprover = PolicyUtils.getTagApproverRule(policy, tagName)?.approver;
    

    If we don't want the checkmark to show/disappear while the page is closing, we can remove the usage of setNavigationActionToMicrotaskQueue so the page is closed immediately after selecting the item, reducing the chance for the user to notice the checkmark, but I don't see the reason we want to do this though, there is nothing wrong to let the user see their updated selection.

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

    N/A, it's a visual issue

  4. melvin-bot commented on Mar 4, 2025

    @melvin-bot

    @abekkala Eep! 4 days overdue now. Issues have feelings too...

  5. melvin-bot commented on Mar 6, 2025

    @melvin-bot

    @abekkala Still overdue 6 days?! Let's take care of this!

  6. added
    ExternalAdded to denote the issue can be worked on by a contributor
    on Mar 6, 2025
  7. changed the title [-]Tags-In approver section, green checkmark while select user is not visible before leaving page[/-] [+][$250] Tags-In approver section, green checkmark while select user is not visible before leaving page[/+] on Mar 6, 2025
  8. melvin-bot commented on Mar 6, 2025

    @melvin-bot
  9. added
    Help WantedApply this label when an issue is open to proposals by contributors
    on Mar 6, 2025
  10. melvin-bot commented on Mar 6, 2025

    @melvin-bot

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

  11. 22 remaining items

  12. changed the title [-][$250] Tags-In approver section, green checkmark while select user is not visible before leaving page[/-] [+][Due for payment 2025-03-21] [$250] Tags-In approver section, green checkmark while select user is not visible before leaving page[/+] on Mar 14, 2025
  13. melvin-bot commented on Mar 14, 2025

    @melvin-bot

    Reviewing label has been removed, please complete the "BugZero Checklist".

  14. melvin-bot commented on Mar 14, 2025

    @melvin-bot

    The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.12-7 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

    If no regressions arise, payment will be issued on 2025-03-21. 🎊

    For reference, here are some details about the assignees on this issue:

  15. melvin-bot commented on Mar 14, 2025

    @melvin-bot

    @QichenZhu @abekkala @QichenZhu The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

  16. abekkala commented on Mar 17, 2025

    @abekkala
    Contributor

    PAYMENT SUMMARY FOR MAR 21

    • Fix: @bernhardoj [$250, if no regressions] payment via NewDot
    • PR Review: @QichenZhu [$250, if no regressions] OFFER - please complete checklist
  17. QichenZhu commented on Mar 19, 2025

    @QichenZhu
    Contributor

    BugZero Checklist:

    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:
    • @QichenZhu 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: https://github.com/Expensify/App/pull/48325/files#r2004446579

    • @QichenZhu 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: N/A

    • @QichenZhu 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 a regression test since this is a matter of visual preference. If needed, the proposed steps are below.

    • @abekkala Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

      Link to issue: https://github.com/Expensify/Expensify/issues/482839

    Regression Test Proposal

    Precondition:

    • Log in to an account that has a control workspace with rules enabled and at lease one tag created.

    Test:

    1. Go to Settings > Workspaces and select a workspace that meets the precondition
    2. Press Tags > any tag > Approver
    3. Select a user
    4. Verify that a green checkmark appears before leaving the page
    5. Press Approver
    6. Deselect the user
    7. Verify that the green checkmark disappears before leaving the page

    Do we agree 👍 or 👎

  18. abekkala commented on Mar 20, 2025

    @abekkala
    Contributor

    PAYMENT SUMMARY FOR MAR 21

  19. bernhardoj commented on Mar 21, 2025

    @bernhardoj
    Contributor

    Requested in ND.

  20. abekkala commented on Mar 21, 2025

    @abekkala
    Contributor

    @QichenZhu payment sent and contract ended - thank you! 🎉

  21. JmillsExpensify commented on Mar 24, 2025

    @JmillsExpensify
    Contributor

    $250 approved for @bernhardoj

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

Metadata

Metadata

Labels

Awaiting PaymentAuto-added when associated PR is deployed to productionBugSomething is broken. Auto assigns a BugZero manager.DailyKSv2ExternalAdded to denote the issue can be worked on by a contributor

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions