dbs [Mon, 15 Nov 2010 22:36:25 +0000 (22:36 +0000)]
asset.uri needs a seed entry for queries of its ID values
To fix a problem with ingesting URIs, Ingest.pm was changed to reflect
the maximum asset.uri.id value rather than the asset.call_number.id
value. However, with no entries in asset.uri, the query returned a
NULL object which broke ingest entirely. Adding a seed entry avoids
this problem.
gmc [Wed, 10 Nov 2010 13:31:09 +0000 (13:31 +0000)]
do not use TRUNCATE when refreshing reporter.materialized_simple_record
Previous behavior would break Slony replication after doing a
bib load. Since a deletion is slower than a truncate, if you're
not using Slony replication, you may prefer to truncate rmsr
prior to calling reporter.enable_materialized_simple_record_trigger.
gmc [Thu, 28 Oct 2010 16:12:51 +0000 (16:12 +0000)]
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.
dbs [Thu, 28 Oct 2010 15:23:34 +0000 (15:23 +0000)]
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.
dbs [Wed, 27 Oct 2010 02:26:18 +0000 (02:26 +0000)]
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.
gmc [Thu, 21 Oct 2010 14:55:58 +0000 (14:55 +0000)]
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
gmc [Tue, 19 Oct 2010 23:47:25 +0000 (23:47 +0000)]
backport r13981 and r17493
* (Bill Erickson) don't call ingest from within bib create/overlay code
before the changes would have been comitted
* (Dan Scott) make selecting the bib source during Vandelay imports
work
dbs [Fri, 8 Oct 2010 03:28:05 +0000 (03:28 +0000)]
Avoid scary SSL / HTTPS errors in Apache configuration
When port 443 is the last listener port, Apache generates lots
of "unknown protocol speaking not SSL to HTTPS port!?" errors in
the logs - which are scary, but harmless. Putting port 80 last
avoids those errors entirely, per http://wiki.apache.org/httpd/InternalDummyConnection
phasefx [Mon, 4 Oct 2010 17:31:45 +0000 (17:31 +0000)]
prevent repeat renderings of opac sidebar (relevant subjects, authors, etc.) in Firefox. What's happening is that the rresultHandleMods is not firing immediately with each record retrieve, and so we get a flurry at the end where resultPageIsDone() returns true for all of them, triggering the allRecordsReceived event more than once. So now at the end of the first allRecordsReceived event chain, we set a global variable, and have these render functions check to see if it has been set.
* all potential capturable copies are now checked (up to the first
one that is permitted for the request), instead of a small random
subset of them
* don't do redundant permission checks
Patch from Steve Callendar, via James Fournie, via launchpad:
When the patron.password.use_phone is set, new patrons are created with their password set to the last 4 digits of their phone number, HOWEVER, when a patron's password is reset, it does not work properly. Although the little underlined summary shows the proper 4 digits, the password box displays 9-ish digits, and is not the last 4 digits of the password.
The attached patch was created by Steve Callender and is confirmed working on 1.6.0
This patch will not work on 2.0 as that has a new user editor, but it would presumably be worthwhile to verify this functionality works in that editor as well.
Update version stamp for Evergreen service, adopting branch convention from trunk
http://hostname/gateway?service=open-ils.actor&method=opensrf.open-ils.system.ils_version
was returning "1-5" for a number of systems we checked; in trunk, we have adopted the
"x-y" convention for branches, so in the 1.6 branches we will follow the "x-y-z"
approach for a little more clarity.
dbs [Thu, 12 Aug 2010 18:22:12 +0000 (18:22 +0000)]
Show the "Active?" checkbox as part of the required (minimal) set of fields
As we're registering users, it's probably a good idea to ensure that staff
can set the user to active at the same time that they enter the minimal
patron information.
dbs [Thu, 12 Aug 2010 17:50:56 +0000 (17:50 +0000)]
Enable "Delete address" button to work in rel_1_6
In some ways the inverse of r17023, the else clause that enabled
the delete button to be enabled was never being reached because
the preceding clauses caught all cases.
Moving it outside of the foreach() loop entirely seems to resolve the problem.
dbs [Thu, 12 Aug 2010 07:46:01 +0000 (07:46 +0000)]
Remove broken old JavaScript in Google Book preview code
I /think/ this was supposed to change the title of the "Preview" link to
"Read this online" or the like in the case that the full text is available,
but it was relying on a function that didn't exist (setText) and trying
to reference an ID that didn't exists. So it broke in those rare cases
where Google Books did provide the full text.
gmc [Tue, 10 Aug 2010 21:22:44 +0000 (21:22 +0000)]
bug 592777: allow authoritative version of open-ils.circ.retrieve
Part of a fix to avoid race condition that can occur
when patron renews an item in the OPAC in a database
that uses pgpool and replication, which sometimes
results in an erroneous 'action_circulation_not_found' error.
dbs [Mon, 9 Aug 2010 13:15:56 +0000 (13:15 +0000)]
Patch from Ben Ostrowsky <ben@esilibrary.com> to specify "staff account" in proxied pages
This change will make it a bit more clear that we're not looking for a
patron barcode/PIN in the Selfcheck Login screen (and make the wording
consistent across similar login pages).
gmc [Fri, 6 Aug 2010 20:35:57 +0000 (20:35 +0000)]
bug 532217: work around caching issue resulting doubled title display
Quick hack shamelessly borrowed from Dan Scott to fix problem
of title being displayed twice on bib details page when back
button is used in OPAC or staff client.
This is a temporary fix in lieu of rewriting the bib details
display to use BibTemplate exclusively.
gmc [Fri, 6 Aug 2010 01:22:56 +0000 (01:22 +0000)]
bug 614150: bail out on ACTOR_USER_NOT_FOUND
This fixes a bug where uploading an offline checkout
that refers to a missing patron returns an INTERNAL_SERVER_ERROR
instead of ACTOR_USER_NOT_FOUND. More generally, this avoids
an exception in case case where a circ operation is made
without checking the existence of the patron record beforehand.
dbs [Fri, 18 Jun 2010 04:48:03 +0000 (04:48 +0000)]
Backport security fix r16747 from trunk
1. Disable fleshing for PCRUD. Otherwise fleshing would provide a
back door whereby a user could see stuff he has no permission to see.
2. For the id_list method: strip out the "flesh_fields" entry, not
the "flesh_columns" entry (which doesn't exist). This actually makes
no difference, but if we're going to do something useless, we might
as well do it right.
erickson [Mon, 14 Jun 2010 15:43:05 +0000 (15:43 +0000)]
removed unused method retrieved from method_lookup. apart from being unused, the call was attempting to fetch a nonexistent method ('auth' vs. 'authority') and hilarity ensued
erickson [Fri, 11 Jun 2010 13:49:45 +0000 (13:49 +0000)]
added a number of info messages to the action/trigger runner and server code. the messages provide summary data about what event defs / hooks are being processed and when/if they complete or timeout.
miker [Thu, 10 Jun 2010 19:16:27 +0000 (19:16 +0000)]
Patch from James Fournie of SITKA:
There was some discussion about problems with holds fulfillment at the
holds roundtable at EG2010. I am pleased to share this patch with the
community which has been thoroughly tested by the folks at
Thompson-Nicola Regional District Library. (thanks guys!)
Background:
Evergreen's default out-of-the-box behaviour for holds fulfillment is
a gas-saving method. Holds are fulfilled by proximity. In a
multibranch library, holds are fulfilled at the local branch first.
Many libraries, particularly single branch libraries may be ok with
this, but it may be problematic for other libraries.
Imagine a scenario where you have a large central branch and a small
rural branch of the same library system. At the large branch, there
are many copies of Popular New DVD with lots of holds. There are no
copies at the rural branch. Patrons at the small rural branch who
want to pick up Popular New DVD at their home branch may never get
their hold fulfilled because the copies will stay at the large branch
as long as there are holds for pickup there.
This patch adds an org unit setting that changes the opportunistic
check-in so that items checked in will be assigned to holds by request
date first, rather than proximity. This setting can be applied to
any level of the org tree, so in some situations you may even want to
activate FIFO for large libraries, but leave the original setting for
smaller libraries with less traffic who want to keep their copies more
local.
Also credit to Jeff Godin who thought of the same patch and
contributed the setting name "holds FIFO" for the setting
[ NOTE: Implications of mixed FIFO and non-FIFO environments that are
not sufficiently segregated by the use of Hard Boundaries for Holds
present a potenial for user confusion. Beware that mixing FIFO and
non-FIFO settings within a resource-sharing group will likely result in
severe imbalance of hold fulfillment, though further configuration,
development, tuning and testing may be able to mitigate these issues.
--miker ]
erickson [Thu, 10 Jun 2010 18:49:14 +0000 (18:49 +0000)]
updated report param editor to handle join types embedded in the field name. this bug caused sporadic failed rendering of the report editor params widgets
erickson [Tue, 8 Jun 2010 19:14:27 +0000 (19:14 +0000)]
back-porting: protect against empty results from bib searches caused by search timeouts. This allows the API call to log the error and return reasonable results
erickson [Mon, 3 May 2010 15:37:24 +0000 (15:37 +0000)]
backporting 16376: fixed bug where updating the email address resulted in updating the username instead of the email address on the local copy of the user object in the opac. this bug likely affected nothing.
Backporting r16204: Patch from Galen Charlton. This patch adds additional calls to escape_xml to handle cases where patron or library data could contain ampersand or other characters that need to be converted to entities. Issue discovered by Bibliomation; patch includes contributions by Ben Ostrowsky.
miker [Sat, 27 Mar 2010 17:35:48 +0000 (17:35 +0000)]
Patch from Dan Wells which allows restriction of renewal when the item in question is needed to fulfill a hold.
There was concern initially about whether a patrons own holds should be ignored, but that is not the case in scripted circ rules, so the behavior, as implemented by Dan, is correct.
phasefx [Fri, 26 Mar 2010 16:02:24 +0000 (16:02 +0000)]
textbox support for oils_persist (to fix stickiness in the label interface). trunk already has this but is so drastically different that I'm afraid to backport
phasefx [Tue, 16 Mar 2010 19:56:27 +0000 (19:56 +0000)]
make batch renewal use synchronous calls again to better handle exceptions. The original push for synchronous calls here was for performance, so we may need to revisit