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

Proposal

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

Filter icon is not responsive.

What is the root cause of that problem?

We are using normal navigate here

Search page is open on top of workspaceInitiaPage so canAccessRoute is incorrectly computed

And we get dismiss all RHP modal in this useEffect

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

When workspace init is the only route in the navigator state. We can use navigate with a type of 'UP'

    onPress={() => Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(currentUserPolicyExpenseChat?.reportID ?? '-1'), 'UP')}

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)

We can use function closeAndNavigate here

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.

Proposal

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

The issue involves [specific problem, e.g., "inconsistent form behavior causing incorrect submissions"], affecting [impact, e.g., "data reliability and user experience"].

What is the root cause of that problem?

Triggered by [root cause, e.g., "a race condition in asynchronous state management"].

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

1. Refactor state management to handle async operations correctly.
2. Add validation checks at client/server levels.
3. Enhance error handling for better feedback and logging.
4. Update outdated dependencies.

Suggested Fix for the Filter Icon Handler

function onFilterIconPress() {
    if (isExecuting) {
        return; // Prevent multiple executions.
    }

    singleExecution(() => {
        // Logic to show filter options
        Navigation.navigate(ROUTES.SEARCH_FILTER); // Adjust as per your route setup.
    })();
}

Add Accessibility and Clickability Checks

<TouchableOpacity
    onPress={onFilterIconPress}
    accessible={true}
    accessibilityLabel={translate('search.filter')}
    style={styles.filterIconContainer}
>
    <Expensicons.Filter />
</TouchableOpacity>

What alternative solutions did you explore? (Optional)

1. Rewrite module (time-intensive).
2. Adopt a new state library (steep learning curve).
3. Implementing targeted fixes and robust tests will resolve the issue and prevent recurrence.

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

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

Proposal

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

The filter button is "unresponsive"

What is the root cause of that problem?

In WorkspaceInitialPage, we check to see if the active route of the sub-page of the workspace settings page is accessible.

If not, then we dismiss any RHP. For example, if the user opens a workspace as a member and tries to open the workspace categories setting, then the categories setting RHP will be dismissed and the not found page will show from the workspace categories list page.

In our case, we open the workspace's initial page. The active route becomes Workspace_Initial. However, the current canAccessRoute logic only checks for the sub-page route. So, when it compares the active route with itself, it fails because menuItems doesn't contain Workspace_Initial.

We actually have the logic to run it only once.

But when we open the search page, all routes are "hidden".

So, the wasRendered logic in WorkspaceInitialPage won't work. And when we try to open the filter page, the previously "hidden" routes are added again to the stack and canAccessRoute becomes false which dismiss any RHP.

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

We can update canAccessRoute to cover the case of the workspace's initial page itself.

const canAccessRoute = activeRoute && (menuItems.some((item) => item.routeName === activeRoute) || activeRoute === SCREENS.WORKSPACE.INITIAL);

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

N/A

Proposal

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

Filter icon is not responsive when navigating to Search via WS chat in WS settings.

What is the root cause of that problem?

When we open the workspace's initial page, the active route becomes Workspace_Initial. However, the current canAccessRoute logic only checks for the sub-page route - therefore when it compares the active route with itself, it fails because menuItems doesn't contain Workspace_Initial.

We actually have the logic to only run it once here, but when we open the search page, all routes are "hidden" as explained here. Because of this, the wasRendered logic in WorkspaceInitialPage won't work as expected -> when we try to open the filter page, the previously "hidden" routes are added back to the stack and canAccessRoute becomes false which will dismiss any RHP that we try to open (Filters).

Credits to bernhardoj for the RCA.

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

We had a similar issue which I reviewed recently here where we navigated away from WorkspaceProfileSharePage to a report without dismissing the currently opened modal which caused a weird UI bug in the QR Code because the same modal would be opened twice.

A practical solution for this kind of issue which wouldn't break any other functionality is to simply replace the way we navigate away from WS to the report here:

to use Navigation.dismissModal instead:

onPress={() => Navigation.dismissModal(currentUserPolicyExpenseChat?.reportID ?? '-1')}

Why dismissing the modal first fixes our issue ?
Because as explained in RCA, on narrow layout devices (native / mWeb) screens displayed in RHP act as a modal and by dismissing it when navigating to the report, all the conditions which lead to the Filters RHP to being able to open when clicked on in our case, will now work as expected.

Result video (before / after)

cc @rayane-djouah

@kadiealexander, @rayane-djouah Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Will review today

@bernhardoj's proposal looks good to me. It comprehensively explains the root cause and fixes the bug at its root.

🎀👀🎀 C reviewed

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

📣 @rayane-djouah 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

PR is ready

cc: @rayane-djouah

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

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

• Fix can't open filter page if coming from workspace page #53807

If no regressions arise, payment will be issued on 2024-12-25. 🎊

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

• @bernhardoj requires payment through NewDot Manual Requests
• @rayane-djouah requires payment automatic offer (Reviewer)

@rayane-djouah @kadiealexander @rayane-djouah 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]

BugZero Checklist:

• 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
  • 2b. Reported on staging (deploy blocker)
  • 2c. Reported on a PR
  • 2z. Other:

  Who reported the bug:

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

• 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/41665/files#r1898131293

• 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

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

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

  Link to issue:

Regression Test Proposal

#### Precondition:

- N/A

#### Test:

1. Go to Workspace Settings.
2. Tap the workspace chat under "Submit expenses using your workspace chat below".
3. Tap the search icon in the top-right corner.
4. Enter any text and search.
5. On the Search page, tap the Filters button.
6. Verify that the Filters button is responsive and the search filters modal is displayed.

Do we agree 👍 or 👎

Payment summary:

@rayane-djouah due $250 for C work, paid via Upwork ✅
@bernhardoj due $250 for contributor work via NewDot manual request

Requested in ND.