"Sort results by barcode" does not sort properly

Description

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:

  1. Log into some Juniper Bugfest

  2. Go to the Requests app

  3. Filter by request status "Closed - Cancelled"

  4. 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:

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Attachments

4
  • 04 Nov 2021, 05:04 PM
  • 04 Nov 2021, 05:04 PM
  • 04 Nov 2021, 05:04 PM
  • 04 Nov 2021, 05:04 PM

Checklist

hide

TestRail: Results

Activity

Show:

Brooks Travis December 2, 2021 at 4:54 PM
Edited

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 PM
Edited

 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 PM
Edited

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.

Won't Do

Assignee

Unassigned

Reporter

Priority

Development Team

Prokopovych

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created November 4, 2021 at 5:04 PM
Updated December 21, 2021 at 5:37 PM
Resolved December 21, 2021 at 5:37 PM
TestRail: Cases
TestRail: Runs

Flag notifications