Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[$250] Filter mismatch on "Save Search" , Filters page shows the currency selected, but the results do not match the filter. #53880

Open
1 of 8 tasks
m-natarajan opened this issue Dec 10, 2024 · 8 comments
Assignees
Labels
Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 External Added to denote the issue can be worked on by a contributor Help Wanted Apply this label when an issue is open to proposals by contributors

Comments

@m-natarajan
Copy link

m-natarajan commented Dec 10, 2024

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.73-6
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @jayeshmangwani
Slack conversation (hyperlinked to channel name): expensify_bugs

Action Performed:

  1. Navigate to the Search tab.
  2. Press Filters from the header and select a currency (e.g., AED).
  3. Save the search, We navigated to the search screen, and the results correctly reflect the selected filter.
  4. Go back to Filters and press Reset Filters from the header.
  5. Press View Results, We navigated to the search results screen, and no filters are applied (all expenses are visible).
  6. Again, press Filters from the header and reselect the same currency as in Step 2.
  7. Save the search.

Expected Result:

Either the currency filter on the Filters screen should not be preselected, OR The search results should display expenses filtered by the active saved filter.

Actual Result:

After saving the search, no filters are applied to the results on the search screen, However, returning to the Filters page shows the currency filter is still selected.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

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
filter-bug.mov
Recording.839.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~021867704716594549077
  • Upwork Job ID: 1867704716594549077
  • Last Price Increase: 2024-12-13
Issue OwnerCurrent Issue Owner: @eh2077
@m-natarajan m-natarajan added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Dec 10, 2024
Copy link

melvin-bot bot commented Dec 10, 2024

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

@FitseTLT
Copy link
Contributor

FitseTLT commented Dec 10, 2024

Edited by proposal-police: This proposal was edited at 2024-12-10 18:38:30 UTC.

Proposal

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

Filter mismatch on "Save Search" , Filters page shows the currency selected, but the results do not match the filter.

What is the root cause of that problem?

When the current search already exists we dismiss modal and return early on save search here

if (!queryJSON || (savedSearches && savedSearchKeys.includes(String(queryJSON.hash)))) {
// If the search is already saved, return early to prevent unnecessary API calls
Navigation.dismissModal();
return;

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

We should apply filter and navigate instead of dismiss modal so that the user can see the search result without saving the search as it already exists 👍

 if (!queryJSON || (savedSearches && savedSearchKeys.includes(String(queryJSON.hash)))) {
            // If the search is already saved, return early to prevent unnecessary API calls
            applyFiltersAndNavigate();
            return;

_Note: we don't need to separately handle the !queryJSON case in onSaveSearch because the save button is only rendered in the first place if the queryJSON exists

const displaySearchButton = queryJSON && !SearchQueryUtils.isCannedSearchQuery(queryJSON);

so we can remove it from the condition

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

We can write an appropriate test for AdvancedSearchFilters aligned with the solution we will go with by populating the appropriate savedSearches and then searching with a search hash that is already saved and then asserting that we are navigated to the correspoding search route if we go with the first option or asserting the filters are cleared if we go with my alternative solution

What alternative solutions did you explore? (Optional)

Optionally we can clear the filters before dismiss Modal

if (!queryJSON || (savedSearches && savedSearchKeys.includes(String(queryJSON.hash)))) {
            // If the search is already saved, return early to prevent unnecessary API calls
            SearchActions.clearAllFilters();
            Navigation.dismissModal();
            return;

@ChavdaSachin
Copy link
Contributor

ChavdaSachin commented Dec 10, 2024

Edited by proposal-police: This proposal was edited at 2024-12-10 19:45:08 UTC.

Proposal

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

Search results are not updated when clicking save search button for already saved search query.

What is the root cause of that problem?

When handling the case of already already saved query, we just dismiss the modal rather than calling applyFiltersAndNavigate() function here.

if (!queryJSON || (savedSearches && savedSearchKeys.includes(String(queryJSON.hash)))) {
// If the search is already saved, return early to prevent unnecessary API calls
Navigation.dismissModal();
return;
}

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

Rather than dismissing the modal, We should navigate to search result.
and handle !queryJSON case separately to make the code futureproof, and avoid making extra API calls in case queryJSON is undefined.

        if (!queryJSON){
            // If search query is empty, do not save the search result.
            Navigation.dismissModal();
            return;
        }
        if(savedSearches && savedSearchKeys.includes(String(queryJSON.hash))) {
            // If the search is already saved, navigate to results without saving the query.
            applyFiltersAndNavigate();
            return;
        }

Or else keep this case dependent on save button visibility and completely remove the !queryJSON case(save button is only visible when queryJSON is Truthy value, so no need to check it again here)

        if(savedSearches && savedSearchKeys.includes(String(queryJSON.hash))) {
            // If the search is already saved, navigate to results without saving the query.
            applyFiltersAndNavigate();
            return;
        }

if (!queryJSON || (savedSearches && savedSearchKeys.includes(String(queryJSON.hash)))) {
// If the search is already saved, return early to prevent unnecessary API calls
Navigation.dismissModal();
return;
}

Optionally we could add a specific case if current query is same as the query to be saved, in that case just dismiss the modal and avoid any additional API calls.

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

Mostly it doesn't need any automated tests.
But if needed a test could be added to make sure no extra API calls are made when saving already saved query.

What alternative solutions did you explore? (Optional)

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.

@FitseTLT
Copy link
Contributor

Added Note why we don't need to handle !queryJSON case separately

@ChavdaSachin
Copy link
Contributor

Updated proposal
added precise justification and an additional option

@FitseTLT
Copy link
Contributor

Note: when I stated

Note: we don't need to separately handle the !queryJSON case in onSaveSearch because the save button is only rendered in the first place if the queryJSON exists

App/src/pages/Search/AdvancedSearchFilters.tsx

Line 516 in 219dabf

const displaySearchButton = queryJSON && !SearchQueryUtils.isCannedSearchQuery(queryJSON);

so we can remove it from the condition

I obivously meant removing the !queryJSON from onSaveSearch (not from displaySearchButton) as it can clearly be inferred from the context I was building my logic from 👍 Noting this to avoid possible misunderstanding.

@melvin-bot melvin-bot bot added the Overdue label Dec 13, 2024
@johncschuster johncschuster added the External Added to denote the issue can be worked on by a contributor label Dec 13, 2024
@melvin-bot melvin-bot bot changed the title Filter mismatch on "Save Search" , Filters page shows the currency selected, but the results do not match the filter. [$250] Filter mismatch on "Save Search" , Filters page shows the currency selected, but the results do not match the filter. Dec 13, 2024
Copy link

melvin-bot bot commented Dec 13, 2024

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

@melvin-bot melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Dec 13, 2024
Copy link

melvin-bot bot commented Dec 13, 2024

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

@melvin-bot melvin-bot bot removed the Overdue label Dec 13, 2024
@johncschuster johncschuster moved this to Bugs and Follow Up Issues in [#whatsnext] #expense Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 External Added to denote the issue can be worked on by a contributor Help Wanted Apply this label when an issue is open to proposals by contributors
Projects
Status: Bugs and Follow Up Issues
Development

No branches or pull requests

5 participants