57f9180...
by
gmc <gmc@dcc99617-32d9-48b4-a31d-7c20da2025e4>
adjust user tests that get done when retargeting holds
Fixes bug where a user having the maximum number of
active hold requests allowed to them by policy would
prevent items from being targeted to fill their requests.
1b3256d...
by
dbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Backport r18516: Ensure call numbers are returned to the holdings editor in ascending sorted order
James Fournie in https://bugs.launchpad.net/evergreen/+bug/635121 reported
that call numbers were being displayed in the order that they had been
added to the database, rather than in sorted call number label order.
Although I have been unable to reproduce this problem on two different
test systems, the patch he provided for 1.6.1 (which fixes the problem on their
test system) shouldn't hurt other systems.
7900914...
by
dbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Prevent ingest errors when asset.uri ID value outstrips asset.call_number
We were basing IDs in asset.uri on the max ID of asset.call_number,
which occasionally led to major ingest problems as attempts to insert
the next ID into asset.uri failed because that ID already existed. Using
the max ID from asset.uri for asset.uri inserts seems to make more sense
and does resolve that problem.
The bigger problem of not using the sequences that are already on these
tables to generate the IDs will not be an issue in 2.0, when we move to
in-database ingest and can use the normal lastval() approach to populate
asset.uri_call_number_map with the new values.
4537c21...
by
gmc <gmc@dcc99617-32d9-48b4-a31d-7c20da2025e4>
improve call number sorting
oils_text_as_bytea now does uppercasing in addition
to converting strings to bytea, working around
the limitation that json_query can't stack transforms
