Send FilterResults Parameter

by ADMIN 29 views

=====================================================

Problem Description


The search results have switched from being filtered to unfiltered, causing wildcard searches to stop working as expected. For example, an item search for ma??ingly should return 495 results but started to return 2,371. All 2,371 results were accessible via pagination (i.e., it wasn't just the search estimate). This unexpected behavior has caused issues with the search functionality, and it is essential to resolve this problem to ensure that the search results are accurate and filtered correctly.

Expected Behavior/Solution


The cause of this issue is that the backend added a filterResults parameter to its search endpoint, yet we didn't add that parameter to the middle tier's call to that endpoint. Since some of the parameters are optional, the backend started processing the middle tier's facetsSoon parameter value (false) as the filterResults parameter, thereby overriding the default of true. To resolve this issue, we need to update the middle tier's call to the backend's search endpoint to include the filterResults parameter.

Requirements


To resolve this issue, we need to complete the following tasks:

  1. Update the middle tier's call to the backend's search endpoint: We need to add the filterResults parameter to the middle tier's call to the backend's search endpoint. This will ensure that the search results are filtered correctly.
  2. Update the middle tier's call to the backend's relatedList endpoint: While not likely causing a problem, this endpoint also has the filterResults parameter. We should update the middle tier's call to this endpoint as well to ensure consistency.
  3. Review all middle tier calls to the backend: We should review all middle tier calls to the backend to see if we can find any other discrepancies. This will help us identify any other potential issues and ensure that our code is consistent and accurate.
  4. Consider making all backend parameters required or requiring a single parameter that's JSON: We should consider making all backend parameters required or requiring a single parameter that's JSON and going by property names versus parameter order. This will help us avoid similar issues in the future and make our code more maintainable.

Needed for Promotion


If an item on the list is not needed, it should be crossed off but not removed. This is an essential requirement for the promotion of the search functionality.

Tasks and Dependencies


The following tasks and dependencies are associated with this issue:

  • Wireframe/Mockup: Mike is responsible for creating a wireframe or mockup for this issue.
  • Committee discussions: Sarah is responsible for leading the committee discussions for this issue.
  • Feasibility/Team discussion: Sarah is responsible for leading the feasibility and team discussion for this issue.
  • Backend requirements: We need to consider the backend implications of this issue, including making all backend parameters required or requiring a single parameter that's JSON.
  • Frontend requirements: There are no frontend requirements for this issue.
  • Are new regression tests required for QA: Amy is responsible for determining whether new regression tests are required for QA.
  • Questions: We should document any questions or concerns related to this issue.

UAT/LUX Examples


The following UAT/LUX examples are relevant to this issue:

  • Simple search for ma??ingly objects: We should test the search functionality with a simple search for ma??ingly objects to ensure that it is working correctly.

Dependencies/Blocks


The following dependencies and blocks are associated with this issue:

  • Blocked By: There are no dependencies that block this issue.
  • Blocking: This issue is blocking the frontend from receiving filtered search results.

Related Github Issues


The following related Github issues are associated with this issue:

Related Links


There are no related links associated with this issue.

Wireframe/Mockup


There is no wireframe or mockup associated with this issue.

Solution


To resolve this issue, we need to update the middle tier's call to the backend's search endpoint to include the filterResults parameter. We should also update the middle tier's call to the backend's relatedList endpoint to ensure consistency. Additionally, we should review all middle tier calls to the backend to see if we can find any other discrepancies. Finally, we should consider making all backend parameters required or requiring a single parameter that's JSON to avoid similar issues in the future.

Code Changes


The following code changes are required to resolve this issue:

// Update the middle tier's call to the backend's search endpoint
public void search(String query) {
    // Add the filterResults parameter to the request
    Map<String, String> params = new HashMap<>();
    params.put("filterResults", "true");
    // Make the request to the backend
    Response response = makeRequest(query, params);
    // Process the response
}

// Update the middle tier's call to the backend's relatedList endpoint
public void getRelatedList(String query) {
    // Add the filterResults parameter to the request
    Map<String, String> params = new HashMap<>();
    params.put("filterResults", "true");
    // Make the request to the backend
    Response response = makeRequest(query, params);
    // Process the response
}

Testing


We should test the search functionality with a simple search for ma??ingly objects to ensure that it is working correctly. We should also test the relatedList endpoint to ensure that it is working correctly.

Conclusion


In conclusion, the search results have switched from being filtered to unfiltered, causing wildcard searches to stop working as expected. The cause of this issue is that the backend added a filterResults parameter to its search endpoint, yet we didn't add that parameter to the middle tier's call to that endpoint. To resolve this issue, we need to update the middle tier's call to the backend's search endpoint to include the filterResults parameter. We should also update the middle tier's call to the backend's relatedList endpoint to ensure consistency. Additionally, we should review all middle tier calls to the backend to see if we can find any other discrepancies. Finally, we should consider making all backend parameters required or requiring a single parameter that's JSON to avoid similar issues in the future.

=====================================

Q: What is the filterResults parameter?


A: The filterResults parameter is a parameter that is added to the backend's search endpoint to filter the search results. It is used to determine whether the search results should be filtered or not.

Q: Why is the filterResults parameter causing issues?


A: The filterResults parameter is causing issues because it is not being added to the middle tier's call to the backend's search endpoint. As a result, the backend is processing the middle tier's facetsSoon parameter value (false) as the filterResults parameter, thereby overriding the default of true.

Q: What are the requirements to resolve this issue?


A: The requirements to resolve this issue are:

  1. Update the middle tier's call to the backend's search endpoint: We need to add the filterResults parameter to the middle tier's call to the backend's search endpoint.
  2. Update the middle tier's call to the backend's relatedList endpoint: We should update the middle tier's call to the backend's relatedList endpoint to ensure consistency.
  3. Review all middle tier calls to the backend: We should review all middle tier calls to the backend to see if we can find any other discrepancies.
  4. Consider making all backend parameters required or requiring a single parameter that's JSON: We should consider making all backend parameters required or requiring a single parameter that's JSON to avoid similar issues in the future.

Q: What are the benefits of resolving this issue?


A: The benefits of resolving this issue are:

  • Improved search functionality: Resolving this issue will improve the search functionality by ensuring that the search results are filtered correctly.
  • Reduced errors: Resolving this issue will reduce errors caused by the filterResults parameter not being added to the middle tier's call to the backend's search endpoint.
  • Improved user experience: Resolving this issue will improve the user experience by providing accurate and filtered search results.

Q: What are the potential risks of not resolving this issue?


A: The potential risks of not resolving this issue are:

  • Continued errors: If the issue is not resolved, the errors caused by the filterResults parameter not being added to the middle tier's call to the backend's search endpoint will continue.
  • Decreased user satisfaction: If the issue is not resolved, the user satisfaction will decrease due to the inaccurate and unfiltered search results.
  • Increased maintenance costs: If the issue is not resolved, the maintenance costs will increase due to the need to constantly fix the errors caused by the filterResults parameter not being added to the middle tier's call to the backend's search endpoint.

Q: What are the next steps to resolve this issue?


A: The next steps to resolve this issue are:

  1. Update the middle tier's call to the backend's search endpoint: We need to add the filterResults parameter to the middle tier's call to the backend's search endpoint.
  2. Update the middle tier's call to the backend's relatedList endpoint: We should update the middle tier's to the backend's relatedList endpoint to ensure consistency.
  3. Review all middle tier calls to the backend: We should review all middle tier calls to the backend to see if we can find any other discrepancies.
  4. Consider making all backend parameters required or requiring a single parameter that's JSON: We should consider making all backend parameters required or requiring a single parameter that's JSON to avoid similar issues in the future.

Q: Who is responsible for resolving this issue?


A: The following individuals are responsible for resolving this issue:

  • Mike: Mike is responsible for creating a wireframe or mockup for this issue.
  • Sarah: Sarah is responsible for leading the committee discussions for this issue.
  • Amy: Amy is responsible for determining whether new regression tests are required for QA.

Q: What are the dependencies and blocks associated with this issue?


A: The following dependencies and blocks are associated with this issue:

  • Blocked By: There are no dependencies that block this issue.
  • Blocking: This issue is blocking the frontend from receiving filtered search results.

Q: What are the related Github issues associated with this issue?


A: The following related Github issues are associated with this issue:

Q: What are the related links associated with this issue?


A: There are no related links associated with this issue.