"Sort results by barcode" does not sort properly
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
Attachments
clones
is blocked by
relates to
Checklist
hideTestRail: Results
Activity

Brooks Travis December 2, 2021 at 4:54 PMEdited
They SIG is ok with the current prioritization (See 12/2/21 RA SIG meeting notes). We'll wait on the data synchronization solution, which should solve the underlying issue.

Brooks Travis November 29, 2021 at 7:34 PM
I haven't been able to get it onto the agenda yet. It got bumped from the 11/8 meeting and between my being out and the holiday, we haven't found a spot for it. I'll try to squeeze it in this Thursday when we talk about TLR.

Anya November 29, 2021 at 3:38 PM
Support : what was the outcome of your meeting with RA?

Brooks Travis November 4, 2021 at 5:12 PMEdited
For Support SIG, I've cloned this bug from CIRCSTORE-286. We exhausted the avenues for addressing this via a bugfix release. It's going to require new feature work (see FOLIO-2473 and the comments on CIRCSTORE-286). I'm going to update the test case and the release notes for Juniper to indicate that this is a known issue and link to this issue. I also dropped the priority from P2 to P4, since it will probably be a release or two before it can be addressed. Feel free to bump it back up if the SIG feels it should be. I was also going to ask RA on Monday (11/8). /cc

Brooks Travis November 4, 2021 at 5:06 PMEdited
This was cloned from CIRCSTORE-286 and relates to the work done there to diagnose the underlying issue. See the comments there for more details.
Overview:
When testing MCL sorting in the request app, testers encountered a situation when sorting by barcode where requests without a user barcode were not sorting correctly (interspersed with other request where a patron barcode value was present.
Steps to Reproduce:
Log into some Juniper Bugfest
Go to the Requests app
Filter by request status "Closed - Cancelled"
Attempt to sort the results descending by "Requester Barcode"
Expected Results:
Results are sorted, descending, by requester barcode, with empty values sorted appropriately.
Actual Results:
Records with empty requester barcode values are intermixed with records where a requester barcode is present.
Additional Information:
May be worth taking a look at the general sort accuracy, as well, just to make sure.
URL: https://bugfest-juniper.folio.ebsco.com/requests/view/a1e7d32a-2ac3-41b7-a1d0-fe85cf0cf427?filters=requestStatus.Open%20-%20Not%20yet%20filled%2CrequestStatus.Open%20-%20Awaiting%20pickup%2CrequestStatus.Closed%20-%20Cancelled&mode=duplicate&sort=-requesterBarcode%2CrequestDate
NOTE: Per discussion on CIRCSTORE-286, this is being caused by a mismatch in what the /circulation/requests endpoint returns and what /request-storage/requests returns and can query on. /circulation/requests takes the response from /request-storage/requests and augments it with current information from /users (in this case), but the record sorting is done by the storage module, which uses it's locally-stored copies of the data. Until data sync is developed for user data in requests, there is no way to resolve this issue.
Interested parties: