need more flexibility in sorting by org unit in TPAC

[Chris Sharp]

In JSPAC, the default behavior in the detailed record view is to sort by library system (level 1 in the org unit heirarchy), then by branch (level 2). This presumes a three-tiered hierarchy (in keeping with the original design for PINES) of consortium (0), system (1), and branch (2). TPAC sorts by branch only, without regard for grouping by parent organizational unit, which may work for other organizations, but does not work for what I'll call the "traditional" organizational setup of PINES.

(It's worth mentioning that the organizational unit selector *is* grouped by system, so it appears inconsistent to me).

My suggestion is to have TPAC allow for the JSPAC-style grouping in the copy table. Consider this a late entry to the "JSPAC features that need re-implementation in TPAC" list.

[Chris Sharp (chrissharp123)]

FWIW, PINES is running:

Evergreen version 2.3.4
Ubuntu 12.04 LTS
PostgreSQL 9.1

[Michael Peters (mrpeters)]

Thanks to some guidance by Thomas Berzansky and Chris Sharp I've got some code that helps solve this.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=1f06a21537f87371fa2e0c8bcc2b96a841588b5c

Warning -- the code is very ugly. I'm not a perl developer so the whitespace is poor, but it is working code in my master server. Example: http://egdev.emeralddata.net/eg/opac/record/2?query=Concerto;qtype=keyword;locg=1;copy_offset=0;copy_limit=50

I'm told "working" code trumps "ugly" code so I was encouraged to share anyways. As I learn more Perl I'll be glad to go back and clean up the whitespace. Sorry, for now!

[Terran McCanna (tmccanna)]

I don't think that this behavior has changed, but looking at Concerto data it looks like it is listing all of the branch level holdings alphabetically by branch and then listing Sub-branch level holdings after that. Screenshot attached (in this example, Example Bookmobile 1 is a sub-branch of Example Branch 3).