Preferred library Located URI's are not sorting to the top

Bug #1335147 reported by Kathy Lussier
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned

Bug Description

Evergreen version 2.6+

With the new Located URI visibility options in 2.6, users are more likely to come across records for electronic resources with multiple URL's listed.

According to the release notes, the URI's should use the same sorting algorithm as is used for copies. In further conversation with Mike Rylander, this means that on the record detail page:

"you should see the search-context-owned located URIs first, then pref_ou-owned located URIs listed second, then prox-ordered ones. that's the same way copies (well, actually, volumes) sort on the record detail page. they use the same logic. Here's the thing, though ... the located URI has to be owned by /exactly/ the prefered OU. if they are owned by the system and your pref and search OU are a branch, they'll sort by proximity."

In testing on a master system, the community demo system (2.6.0), and a 2.5 system patched with this feature, the preferred search library's URI are not sorting to the top on either the search results or record detail page.

tags: added: opac
Revision history for this message
Michele Morgan (mmorgan) wrote :

Marking Confirmed in TPAC. Still an issue in 3.6. URIs always sort by org unit alphabetically.

Given a search context ou that begins with "S" and a preferred ou that begins with "B", the "B" will display before the "S".

Changed in evergreen:
status: New → Confirmed
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.