evergreen:tags/rel_2_3_8

Last commit made on 2013-06-19
Get this branch:
git clone -b tags/rel_2_3_8 https://git.launchpad.net/evergreen

Branch merges

Branch information

Name:
tags/rel_2_3_8
Repository:
lp:evergreen

Recent commits

1d42261... by Bill Erickson on 2013-06-19

2.3.8 stub upgrade script

Signed-off-by: Bill Erickson <email address hidden>

3ae7ed9... by Bill Erickson on 2013-06-19

Bumping version numbers, adding Upgrade Script and Changelog

Signed-off-by: Bill Erickson <email address hidden>

39f895e... by Bill Erickson on 2013-06-19

Bumping OpenILS Version to 2.0308

Signed-off-by: Bill Erickson <email address hidden>

82f8d09... by Bill Erickson on 2013-06-19

2.3.8 Translations Import

Signed-off-by: Bill Erickson <email address hidden>

9b3b78b... by Kathy Lussier on 2013-06-14

Fixes to MARC batch import docs

Added needed subheadings to the MARC batch update docs. Also shortened
line lengths and modified intro that focused on 2.2 new features.

Signed-off-by: Kathy Lussier <email address hidden>

77231ce... by Bill Erickson on 2012-08-27

Repair fine generator memory leak

Calling "next" from within a "try" block results in a memory leak,
presumably because "try" is a tangled nest of subs and evals.
Replacing the "try" with a good ol' "eval" avoids the leak.

This can be reproduced with the following:

---------
use Error qw/:try/;

foreach (0..200000) {
    try {
        next;
    } catch Error with {
    };
}
---------

This particular leak in the fine generator is onerous when the fine
generator is run often (e.g. every 15 mins), which means circs that
have already been processed for the day are re-analzyed over and over,
causing the code to continue early (next) to the next loop iteration
for large numbers of circs. It also happens when a circs are skipped
because they have no fine interval, rate, or max fine.

You know this is happening because you will see something like this in
the storage stderr log:

Exiting eval via next at
/usr/local/share/perl/5.10.1/OpenILS/Application/Storage/Publisher/action.pm
line 820.

Exiting subroutine via next at
/usr/local/share/perl/5.10.1/OpenILS/Application/Storage/Publisher/action.pm
line 820.

This patch does not avoid the "exiting eval via next" warning, since
we're still next'ing out of the eval. It just avoids the memory leak
(and the "Exiting subroutine" warning). More extensive refactoring is
needed to to completely remove the second warning.

Signed-off-by: Bill Erickson <email address hidden>
Signed-off-by: Mike Rylander <email address hidden>

89898e7... by Mike Rylander on 2013-04-30

Search clicked /and/ preceding sf values

When looking for authority records to control a bib field, we currently
search using exactly, and only, the subfield that was clicked. This
commit changes that so that the full field up to and including the clicked
subfield is used in the simple authority heading search we perform to find
the best-match (pivot) authority record.

Signed-off-by: Mike Rylander <email address hidden>
Signed-off-by: Lebbeous Fogle-Weekley <email address hidden>

b8e64db... by Thomas Berezansky on 2012-07-26

Make Force/Recall holds always return as nearest

Without even running the hold rules.

Signed-off-by: Thomas Berezansky <email address hidden>
Signed-off-by: Mike Rylander <email address hidden>

Conflicts:
 Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Holds.pm

(Just whitespace conflicts on tab vs space -- repaired by hand.)

feaf67e... by Ben Shum on 2013-03-02

TPAC - set autofocus to user input when placing holds in staff client

When placing holds in TPAC via the staff client, the focus had been on the
basic search field above. Change this to have autofocus on the input field
for the hold user by default.

This can potentially save staff from having to perform an extra click to
select the input field. Now they can immediately begin entering the barcode
of the user they plan to create a hold on behalf of.

Signed-off-by: Ben Shum <email address hidden>

Conflicts:
 Open-ILS/src/templates/opac/parts/place_hold.tt2

Signed-off-by: Mike Rylander <email address hidden>

33b4964... by Lebbeous Fogle-Weekley <email address hidden> on 2013-04-15

Acq: Be fuzzy about case when retrieving EDI documents

The edi_fetcher relies on a routine in OpenILS::Acq::EDI to, among
other things, try to avoid fetching the same EDI document multiple times
when many rows in acq.edi_account refer to the same host and login
credentials.

Since in practice most vendors seem to run FTP servers for EDI on
Windows, not UNIX, and pathnames are therefore case-insensitive, that
test for other occurrences ought also to be case-insensitive.

If I were to look at this as a purist, I could argue that vendor servers
might sometimes by run on UNIX, and that for some reason it is possible
that different vendor-to-buyer EDI documents (order responses or
invoices) could have pathnames that differ only in the case of some
characters. But that seems wildly unlikely. If anyone does take this
possibility seriously, perhaps acq.edi_account needs a Boolean column to
indicate the remote host's case [in]sensitivity.

Signed-off-by: Lebbeous Fogle-Weekley <email address hidden>
Signed-off-by: Ben Shum <email address hidden>