Evergreen

URI $9 displayes too many links in TPAC

Bug #1353643 reported by Liam Whalen
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
New
Wishlist
Mike Rylander
Evergreen 3.next

Bug Description

When using the new YAOUS opac.luri_acts_as_copy, too many 856 $u links are returned in both the search results and the record detail pages. A record with 50+ 856 $u values displays too much information to be useful to the users. As well, when URIs are coded to specific OUs, this forces the users to hunt for their URI within the search results and record details pages.

After an email discussion on the dev list:

July: http://libmail.georgialibraries.org/pipermail/open-ils-dev/2014-July/009588.html
August: http://libmail.georgialibraries.org/pipermail/open-ils-dev/2014-August/009644.html

plans for changes to the unapi and query_parser_fts code were decided upon.

In short, new YAOUSs will be created that help unapi prune the URIs that are returned to the TPAC, so that only URIs within a defined ancestor and descendant scoping fence are returned to the TPAC for display.

As well, another YAUOS will be created to allow the TPAC to limit the number of URIs displayed on the search results page.

Evergreen 2.6
OpenSRF 2.3.0
PostgreSQL 9.1
Ubuntu 12.04

Liam

Tags: opac
Revision history for this message
Liam Whalen (whalen-ld) wrote :

I have a commit for master ready to be tested.

It can be found here:

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

Liam

Liam Whalen (whalen-ld)
tags: added: pullrequest
Jeff Davis (jdavis-sitka)
Changed in evergreen:
milestone: none → 2.next
Revision history for this message
Jason Stephenson (jstephenson) wrote :

Liam,

Just from looking at the code I have two suggestions.

It would be better if all of the upgrade scripts were squashed into one. The statements should all be inside one transaction.

It would also be useful if comments were added to give an indication of what the new database functions are meant to do and what the arguments mean/are for.

The changes do look interesting.

Cheers,
Jason

Jeff Davis (jdavis-sitka)
Changed in evergreen:
milestone: 2.next → 2.9-alpha
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

Added a minor fix (order of creation of functions) on top of Liam's commit in this branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1353643-fix-create-function-order-upstream

Jason Stephenson (jstephenson)
Changed in evergreen:
milestone: 2.9-alpha → 2.9-beta
Jason Stephenson (jstephenson)
Changed in evergreen:
importance: Undecided → Wishlist
Revision history for this message
Liam Whalen (whalen-ld) wrote :

I have modified the SQL upgrades to include all changes in a single file. I have also added comments and release notes.

Revision history for this message
Liam Whalen (whalen-ld) wrote :

It helps to add the link to the new working branch:

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

Liam Whalen (whalen-ld)
Changed in evergreen:
milestone: 2.9-beta → 2.next
Revision history for this message
Mike Rylander (mrylander) wrote :

I'll be getting back to looking at this, but since it touches search, and there's both been a bit of drift in search and there is upcoming work to change it further, this will probably need to be recast a little bit. Assigning it to myself to keep it in front of me while looking at search stuff in the future...

Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Revision history for this message
Mike Rylander (mrylander) wrote :

This bug is going to have to wait for one of two events: inclusion of bug 1698206 (Eliminate Staged Search); or the decision to not include it. There's just too much overlap and if ESS gets in it will need a significant overhaul. Which, I'll commit to doing, if ESS goes in. But that very likely won't happen before 3.0. I'll leave this assigned to myself to signify that.

Dan Wells (dbw2)
Changed in evergreen:
milestone: 3.next → 3.1-beta
Revision history for this message
Dan Wells (dbw2) wrote :

In light of Mike's comments and bug #1698206 being released, I am going to assume this needs some major reworking, and adjust the bug status accordingly.

tags: removed: pullrequest
Changed in evergreen:
milestone: 3.1-beta → 3.next
Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

Actually I had this working with only minor changes in 3.0.2, but the fix for bug 1743650 appears to have broken it again in 3.0.3. It's too late for 3.1, I think, but it's not as big a task as it seems.

Jane Sandberg (sandbergja)
tags: added: opac
Revision history for this message
Derek C. Zoladz (derekz) wrote :

Is this fundamentally a duplicate bug 1582720?

https://bugs.launchpad.net/bugs/1582720

Revision history for this message
Jeff Davis (jdavis-sitka) wrote :

As noted in the other bug, this is not a duplicate, although both bugs touch on display of multiple URIs.

Our 3.1 environment seems to have some version of the fix for this bug. I'll see if I can reverse-engineer an updated branch.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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