Next 10 Link erroneously available at the end of holdings in OPAC, intermittent

Bug #1274999 reported by Erica Rohlfs
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned

Bug Description

Evergreen versions 2.4.1, 2.4.3, and 2.5.2

OK, I’ve tried to articulate what I’m seeing a few different ways now. Let’s see how effective I can lay it out here :)

I’m starting to notice this more in the holdings statements of bibliographic records. It should also be noted that this is intermittent and not occurring for all records.

For some records, on the next set of holdings results (click on the "Next 10" link option for records with more than 10 holdings results), there is a "Next 10" and "Previous 10" link. However, once the user hits the last set of results, the "Next 10" link is still available. Clicking this link will then take the user into a screen with no holdings summary listed (and no “Previous 10” link). Normally, Evergreen will stop on the last page of holdings and only make the “Previous 10” link available, signifying to the users that they have reached the last page of holdings to navigate through.

There are two workarounds. Users can use the Go Back button in the instances of a Previous 10 link not available. There is also the Show More Copies link.

No Javascript error to report.

I will be providing 2 screen casts.

First Screen Cast
No_Previous_Link Attachment:
In the first screen cast, I used a record where I am seeing the error. Once I reach the end of the holdings, no more holdings show and the Previous 10 link is not available. It's as though the screen just keeps going one more time after there are no more holdings to list.

Revision history for this message
Erica Rohlfs (erohlfs) wrote :
Revision history for this message
Erica Rohlfs (erohlfs) wrote :

Second Screen Cast
Record_that_has_the_Previous_link Attachment:
In the second screen cast, I used a record that displays as expected when I navigate through the holdings. Once I reach the end of the list of holdings, Evergreen does not continue with another Next 10 link. It only displays the Previous 10 link, which is expected.

Revision history for this message
Ben Shum (bshum) wrote :

I wonder if this is another potential side effect of bug 1155769 where some copies disappeared from view in TPAC due to strange ordering issues...

Revision history for this message
Ben Shum (bshum) wrote :

Marking incomplete pending further tests.

Changed in evergreen:
status: New → Incomplete
Revision history for this message
Jim Keenan (jkeenan) wrote :

I can get this to happen in my catalog consistently. Here is an example search:

http://bark.cwmars.org/eg/opac/record/2084863?query=loeb%20livy;qtype=keyword;fg%3Aformat_filters=;locg=152

There are only 10 copies but the "Next 10 >>" link appears. If you click "Next 10 >>", it displays the record but no copies.

If you click "Show more copies", "Next 10 >>" goes away but only the 10 copies display.

If you click "Show fewer copies", "Next 10 >>" reappears.

Changed in evergreen:
status: Incomplete → Confirmed
Revision history for this message
Robert J Jackson (rjackson-deactivatedaccount) wrote :

Just received report from library that issue described by Jim Keenan is still a problem in 2.11.

Revision history for this message
Jason Boyer (jboyer) wrote :

The total number of copies was never consulted, only the number currently being displayed. This branch looks at the total number of copies at the current depth to display (or not) the Next link:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1274999_next_link

tags: added: pullrequest tpac
Changed in evergreen:
milestone: none → 2.next
Revision history for this message
Mike Rylander (mrylander) wrote :

Jason,

I've modified the TT syntax used in your branch. Please see if this both makes sense, and accomplishes the same goal as your original.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1274999_next_link

Revision history for this message
Jason Boyer (jboyer) wrote :

Absolutely, Mike. As much as I dislike sigils I'm not sure why they crept into my TT usage, heh. Also, .last is handy and I was unaware. Looks 100% to me.

My branch has been force-updated to include those changes and actually get the logic the right way 'round so once this has a testing signoff it'll be ready to go. Oops.

Revision history for this message
Jason Boyer (jboyer) wrote :

I seem to have skinned a knee on an edge case. :/ This branch doesn't work if you have the "Show Results from All Libraries" box checked, then you only get the first 10 and no Next link. I'll try to get this figured out.

Revision history for this message
Jason Boyer (jboyer) wrote :

My branch has been force-updated with a corrected version that pays attention to the copy_depth and depth query parameters, and if neither if defined, just assumes the greatest depth returned in ctx.copy_summary. Much better.

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Revision history for this message
Jason Etheridge (phasefx) wrote :

Thanks Jason! Pushed to master.

I tested this with the Concerto test data, stepping through

http://localhost/eg/opac/record/217?query=fiction;qtype=subject;locg=1;detail_record_view=0

and

http://localhost/eg/opac/record/217?query=fiction;qtype=subject;locg=4;detail_record_view=0

You can tack experiments like ;copy_limit=2 onto such URL's to further play around.

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Jason Etheridge (phasefx) → nobody
Changed in evergreen:
milestone: 3.next → 3.0-alpha
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.