Items repeated in tpac display, others not visible

[Michele Morgan]

Evergreen 2.2.3, 2.3.3 using TPAC

In cases where there are multiple items attached to the same call number on a bib record, the catalog display can show some attached items twice and others not at all. This can be reproduced in the following catalogs:

http://catalog.noblenet.org
http://bark.cwmars.org
http://catalog.mvlc.org
http://acorn.biblio.org

The display bug happens when multiple copies, attached to the same call number record, display on multiple pages. A sample record is:

http://catalog.noblenet.org/eg/opac/record/3205462

in which nine items belonging to Beverly Main library are displayed across 2 pages. The total number of items displayed is correct across the pages, but two items from the first page are repeated on the second, so details on two items are not displayed at all.

The attached Word document includes screenshots that illustrate the problem.

It was fairly easy to find examples of this. Just look for bestsellers where libraries have multiple copies and page through until you see a single call number's copies span pages.

[Ben Shum (bshum)]

I wonder if the ordering of items showing is changing due to activity, like checking in/out the copies which would alter the status and perhaps push up or down results until one navigated back or forth. So far I haven't been able to replicate this misbehavior in my catalog.

Marking bug status as incomplete pending more investigation.

[Michele Morgan (mmorgan)]

The repeated items do seem to change from day to day - probably due to activity - but seem fairly consistent within a session. Attached is a document with screenshots highlighting duplicate items in the following record:

http://acorn.biblio.org/eg/opac/record/2897144

[Kyle Tomita (tomitakyle)]

Fix on working repo branch, user/ktomita/lp1155679-items_repeated_tpac_display

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=refs/heads/user/ktomita/lp1155769-items_repeated_tpac_display

[Ben Shum (bshum)]

I still haven't been able to clearly replicate this problem consistently on my systems, but I assume that's the nature of a random ordering process.

One note on the change here, going strictly by barcode instead of copy_number might not be the best thing for folks who actually make regular use of the copy_number field. While I know we do not (so it won't affect us), someone may be using them and expecting that copy 1 go before copy 2, etc.

I mentioned this in IRC and kmlussier wondered if we were to order by copy_number, and then barcode. My only question to test is what would happen in a case where you have a mix of items that have the same org unit, call number sortkey, but some had copy_number applied and others were NULL. Would it put the NULLs ahead of the ones with copy_number or after them?

More testing required to understand and work through this.

Thanks for getting the ball rolling again Kyle!

[Ben Shum (bshum)]

Verified that adding "barcode" as an additional order by field helps to eliminate the random ordering issue that caused some items to "disappear" from view.

Kyle, if you can confirm my results and submit a revised branch, I'll be happy to sign off on it to get it into master.

[Kyle Tomita (tomitakyle)]

Hi Ben,

I added the order by barcode to a new branch, http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=refs/heads/user/ktomita/lp1155769-items_repeated_tpac_display-additional.

[Ben Shum (bshum)]

Thanks Kyle! Picked your commit to master and then backported to rel_2_5. When I tried to backport it to rel_2_4, it didn't pick cleanly and there seem to be differences in how sort worked previously in 2.4. Specifically, that the label_sortkey wasn't being employed and also that copy_number wasn't being used either.

Going to leave that 2.4 stuff alone for now. Maybe can look at it more closely later.