(FSE Dry run 1) "keyword" index is not used in query when searching users by Keyword

Description

Steps to reproduce:

  1. Log into https://crs-sandbox2.int.aws.folio.org/

  2. Go to "Users" app

  3. Open browser DevTools

  4. Fill search input field with any value (f.e. “adm“)

  5. Click on “Seach” button

Expected result:

 In DevTools, GET request "/users?limit=100...""query" parameter contains the payload with “query“:

"keywords="<searched term>*" sortby personal.lastName personal.firstName" value

Actual result:

 In DevTools, GET request "/users?limit=100...""query" parameter contains the payload with “query“:

((username="adm*" or personal.firstName="adm*" or personal.preferredFirstName="adm*" or personal.lastName="adm*" or personal.middleName="adm*" or personal.email="adm*" or barcode="adm*" or id="adm*" or externalSystemId="adm*" or customFields="adm*")) sortby personal.lastName personal.firstName

Additional information:

  • See example:

 

Environment

None

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Estimation Notes and Assumptions

None

RCA Group Details

None

Attachments

1

Checklist

hide

Activity

Show:

Yauhen Viazau October 1, 2024 at 5:21 PM

This is NOT reproducible on Eureka snapshot (https://folio-etesting-snapshot-diku.ci.folio.org/). Closed the issue as “Won’t do“

Craig McNally October 1, 2024 at 4:58 PM

I don’t think there is any work required here, so we can probably close it. My guess is that if this is still an issue in Ramsons it will be caught as part of Ramsons testing. I personally think it makes sense to leave this open for now, and test this against a snapshot environment built from HEAD/master. I believe it should be resolved. If the issue is not reproducible there, we can close this with some level of confidence that it should also be addressed in Ramsons.

Craig McNally October 1, 2024 at 4:53 PM

Here’s the situation…

For QCSP4 deployed for LoC we’re still using a resolution which points to a eureka-specific branch of ui-users. was not ported to this branch, which explains why we see this behavior in the dryrun env. We’ve recently merged our branch into the mainline (see ), but that was essentially for ramsons, not quesnelia. Given that patrons will not be loaded until phase 2 (Ramsons), the number of users is pretty low and therefore is unlikely to even make in impact. We could try to backport this to Eureka-specific quesnelia branch, but it doesn’t seem worth it. My suggestion is to just wait until Ramsons where a release of ui-users which includes and .

Yauhen Viazau October 1, 2024 at 2:26 PM

- not sure about the impact. But this was implemented in , and is a part of Q CSP4. In the ticket description, there is an assumption that this update will make search faster:

The /users API has a new CQL search index keywords that significantly speeds up the search:

Craig McNally October 1, 2024 at 2:25 PM

See

Won't Do

Details

Assignee

Reporter

Development Team

Eureka

RCA Group

Environmental/deployment issue

Priority

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created October 1, 2024 at 10:52 AM
Updated October 1, 2024 at 5:21 PM
Resolved October 1, 2024 at 5:20 PM
TestRail: Cases
TestRail: Runs