sorting of shelving locations in search filter

I'm have a hunch this is related to https://bugs.launchpad.net/evergreen/+bug/802700 which discusses the sort order of a few other interfaces but I'm not able to back that up 100%. I'm willing to bet this is ordering shelving locations in the order of "id" (asset.copy_location.id) rather than "name" (asset.copy_location.name). The suspicion on that comes from the fact that "Stacks" always appears first in the list.

A bit deeper digging, reveals that the "advLoadCopyLocations" function in adv_global.js is using "FETCH_COPY_LOCATIONS" which is a call to open-ils.circ.copy_location.retrieve.all.

Finally, we can trace that API call back to src/perlmods/lib/OpenILS/Application/Circ/CopyLocations.pm which doesn't appear to include any sort of ordering. One would think it likely retrieves the copy locations in order of the database id value because there is no explicit sort method.

The solution may be a bit beyond my skill set at this point but hopefully this leads one of the more experienced developers to the solution a bit quicker.

I think you're right about it being id-based by default. Something else to consider is that you're supposed to be able to explicitly determine the order of shelving locations (Admin->Local Administration->Copy Location Order, which uses table asset.copy_location_order). The search filter doesn't appear to be aware of this (which might should get a separate bug report).

I did some more digging at this today. Findings are frustrating!

For example, take "Indiana State Library - Indianapolis" in the Evergreen Indiana OPAC (http://evergreen.lib.in.us). The order of the Shelving Locations seems to have no rhyme or reason to the sorting.

The OPAC consistently returns the order:

Stacks
New Books
Preservation-bench
Talking Books Large Type

But, that's not ordered by id value, nor is there any discernible pattern to the sort! I tried the same advanced search in IE, Firefox and Chrome and the order ways always this same, but randomly sorted, order.

Some SQL from our database about these asset.copy_locations is below, along with a screenshot showing the consistent order in the fixed list.

evergreen=# SELECT id, name, owning_lib FROM asset.copy_location WHERE owning_lib IN (1, 73) ORDER BY id LIMIT 5;
  id | name | owning_lib
-------+------------------------+------------
     1 | Stacks | 1
 21055 | Assumed Lost | 73
 21056 | Authors' room | 73
 21057 | CHECKEDOUT | 73
 21058 | Cage Federal documents | 73
(5 rows)

evergreen=# SELECT id, name, owning_lib FROM asset.copy_location WHERE owning_lib IN (1, 73) AND name = 'New Books';
  id | name | owning_lib
-------+-----------+------------
 21299 | New Books | 73
(1 row)

evergreen=# SELECT id, name, owning_lib FROM asset.copy_location WHERE owning_lib IN (1, 73) AND name = 'Preservation-bench';
  id | name | owning_lib
-------+--------------------+------------
 21955 | Preservation-bench | 73
(1 row)

evergreen=# SELECT id, name, owning_lib FROM asset.copy_location WHERE owning_lib IN (1, 73) AND name = 'Talking Books Large Type';
  id | name | owning_lib
-------+--------------------------+------------
 21225 | Talking Books Large Type | 73
(1 row)

Hello Michael,

My quick testing shows that these results are simply coming out in "database order", which can be considered more or less undefined from our perspective.

Ignoring for now the more complicated (and apparently incomplete) "Copy Locations Order" feature, I would try adding:

$second_cstore_arg->{"order_by"} = {"acpl" => "name"};

just after:

my $second_cstore_arg = {"no_i18n" => scalar($no_i18n)};

in CopyLocations.pm.

If that works out for you, please feel free to push a branch to working, as I think it would be worth applying even if only as an interim solution.

Thanks,
Dan

Dan,

Thanks for the suggestion. It's working perfectly!

I've pushed it up to a Working repo for further evaluation.

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

Committed back through rel_2_0.