TPAC unable to link to specific organization by shortname

Bug #1020625 reported by Michael Peters
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Unassigned

Bug Description

Evergreen 2.2 tomaster

In JSPAC, libraries are able to link to their own internal catalog by using the ?ol= suffix on the OPAC URL:

* http://evergreen.lib.in.us/opac/en-US/skin/default/xml/index.xml?ol=hmmpl
* http://evergreen.lib.in.us/opac/en-US/skin/default/xml/index.xml?ol=4

I've discovered that there is no way to use the shortname to perform this action in TPAC. I'm requesting that this feature be reinstated. Libraries generally know their shortname, but rarely know their org_unit.id value.

Working: http://dev.evergreen.lib.in.us/eg/opac/home?locg=2
Not Working: http://dev.evergreen.lib.in.us/eg/opac/home?locg=BR-2

Changed in evergreen:
importance: Undecided → Medium
Revision history for this message
Lebbeous Fogle-Weekley (lebbeous) wrote :

After some testing, this seems to work for me: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/senator/locg-ou-name (for master anyway).

It wants more testing from someone else. The parts of the TPAC code affected by this are murky, where we have loc and locg and pref_lib and physical_loc and some cookies and HTTP headers too. A single, easy-to-find design or document of intent about the correct interplay of all these inputs would facilitate confident development in this area.

tags: added: pullrequest
Revision history for this message
Michael Peters (mrpeters) wrote :

Works in 2.2, but with one caveat. locg is case sensitive, so isli is bad but ISLI is good. Can we remove that case sensitivity?

Changed in evergreen:
status: New → Confirmed
Revision history for this message
Lebbeous Fogle-Weekley (lebbeous) wrote :

Sure thing Mike. I force-pushed a revised commit to the same branch that does that. Here's an explanation from the revised commit message:

    Now case insensitive per recommendation by Michael Peters. In the
    event that you have org units with names that are the same except
    for case (probably a bad practice), the locg parameter will simply
    fail to set your context, rather than try to guess which org unit
    you meant.

Revision history for this message
Michael Peters (mrpeters) wrote :

Big thanks, Lebbeous!

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

Marking as new feature for 2.4.

Changed in evergreen:
importance: Medium → Wishlist
milestone: none → 2.4.0-alpha
Revision history for this message
Pasi Kallinen (paxed) wrote :
tags: added: signedoff
Ben Shum (bshum)
Changed in evergreen:
milestone: 2.4.0-alpha1 → 2.4.0-beta
Ben Shum (bshum)
Changed in evergreen:
milestone: 2.4.0-beta → 2.4.0-rc
Ben Shum (bshum)
Changed in evergreen:
milestone: 2.4.0-rc → 2.5.0-alpha
Revision history for this message
Dan Scott (denials) wrote :

I had to resolve a merge conflict, but testing showed that using locg=4 was the same as locg=BR1 and locg=Br1, so that worked for me. Pushed to master. And thanks!

Changed in evergreen:
status: Confirmed → Fix Committed
Revision history for this message
Michael Peters (mrpeters) wrote :

Thanks Pasi / Dan

Ben Shum (bshum)
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.