[OPEN-ILS-DEV] ***SPAM*** Fix for shutdown problems
I just committed a fix to OSRF trunk for a shutdown bug. Every once in a while when I shut down OSRF (using the command osrf_ctl.sh -l -a stop_all), the script would fail when shutting down the C services, and I would have to kill the remaining processes by other means. After some head-scratching I came up with a theory for what was going wrong, and a fix for it. It's hard to be sure whether it will really fix the problem because the problem was intermittent and unpredictable. However the new design at least seems to be no worse than the old. -- If you don't care about the technical details you can skip this section, The osrf_ctl.sh script had been using ps + grep to capture the process ID (PID) of the opensrf-c daemon so that it could send a SIGINT signal to it later to shut it down. However the script was also capturing the PIDs of the daemon's child processes (i.e. the listener processes), which hadn't yet changed to application-specific names. [Explanation: the ps command reports the command line used to invoke each process. Both the opensrf-c daemon and the listeners that it spawns change this command line by overwriting their argv arrays, in order to change what ps reports.] As a result, when shutting down, the listener processes would receive signals from two different sources: from the opensrf-c daemon and from the surrounding shell script. If the signal from opensrf-c got there first, the kill from the script would fail, and the script would abort, even though the process had already been successfully killed. The solution is for opensrf-c to write the daemon's PID directly to a file, instead of relying on ps + grep to capture it. The file name is specified by an additional command line parameter, which (for upward compatibility) is currently optional. If you install or reinstall OSRF from scratch, this change will be included automatically. If you are updating an existing instance of OSRF, then pay attention to the following paragraphs: Because this change involves a change to the osrf_ctl.sh script, it will be necessary to run configure before the usual make and make install. If you are using the usual configuration, run the following from within the OSRF trunk directory: ./configure --prefix=/openils --sysconfdir=/openils/conf If course if you are using some custom configuration, change the above command accordingly. If you don't run configure, the old osrf_ctl.sh script will continue to work as it has in the past, and you won't get the benefit of the change. Scott McKellar
Re: [OPEN-ILS-DEV] MFHD Commit to Serials Branch
Hi, On May 3, 2010, at 11:35 AM, Dan Wells wrote: I should also note that this module now requires a new, not-yet released version of Marc::Record for the *field methods to work properly. You can get the updated code from Source Forge repository: http://sourceforge.net/projects/marcpm/develop I uploaded MARC::Record 2.0.1 to CPAN over the weekend, although it looks like I'll have to release a 2.0.2 (no functionality changes) soon to pick a nit so that the Debian folks will package it. Regards, Galen -- Galen Charlton VP, Data Services Equinox Software, Inc. / Your Library's Guide to Open Source email: g...@esilibrary.com direct: +1 352-215-7548 skype: gmcharlt web:http://www.esilibrary.com/
[OPEN-ILS-DEV] ***SPAM*** Patch: holds go home feature idea
I've been testing some code for the situation where an item gets stuck
circulating at a non-owning library. A number of people at the recent
hackfest expressed interest in various ways to get an item to fill holds
at it's home library depending on some setting, so I thought others
might be interested, and wondered if anyone else was working on this.
The idea is to compare a library setting, which is a time interval such
as '6 weeks', to the time interval since the item was checked in at its
home library. If the library setting has been exceeded, the system will
search for holds relative to the item's home library rather than the
current check in library. In effect, the item will go home if holds
exist there, if not the item may at least start moving toward its home
library depending on what other holds exist and the layout of the
library system.
The code adds one storage call to compare the library setting(pulled via
item circ_lib), and if the setting is exceeded, calls the existing
nearest_hold sub
with the item circ_lib rather than check in lib. You'll need to add an
UPDATE_ORG_UNIT_SETTING.circ.hold_go_home permission if you want to try
it out. The diff is against svn rel_1_6_0.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by:
Doug Kyle
dk...@grpl.org
Index: src/perlmods/OpenILS/Const.pm
===
--- src/perlmods/OpenILS/Const.pm (revision 16362)
+++ src/perlmods/OpenILS/Const.pm (working copy)
@@ -77,6 +77,7 @@
econst OILS_SETTING_ORG_BOUNCED_EMAIL = 'org.bounced_emails';
econst OILS_SETTING_CHARGE_LOST_ON_ZERO = 'circ.charge_lost_on_zero';
econst OILS_SETTING_VOID_OVERDUE_ON_LOST = 'circ.void_overdue_on_lost';
+econst OILS_SETTING_HOLD_GO_HOME = 'circ.hold_go_home';
econst OILS_SETTING_HOLD_SOFT_STALL = 'circ.hold_stalling.soft';
econst OILS_SETTING_HOLD_HARD_STALL = 'circ.hold_stalling.hard';
econst OILS_SETTING_HOLD_SOFT_BOUNDARY = 'circ.hold_boundary.soft';
Index: src/perlmods/OpenILS/Application/Circ/Holds.pm
===
--- src/perlmods/OpenILS/Application/Circ/Holds.pm (revision 16362)
+++ src/perlmods/OpenILS/Application/Circ/Holds.pm (working copy)
@@ -1571,14 +1571,31 @@
my $hold_stall_interval = $U-ou_ancestor_setting_value($user-ws_ou, OILS_SETTING_HOLD_SOFT_STALL);
+ my $hold_go_home_interval = $U-ou_ancestor_setting_value($copy-circ_lib-id, OILS_SETTING_HOLD_GO_HOME) || 0; #doug
+ my $homer;
+if ($hold_go_home_interval) {
+$homer = $U-storagereq(
+open-ils.storage.action.hold_go_home_interval_test,
+$hold_go_home_interval, $copy-id, $copy-circ_lib-id );
+}
+
$logger-info(circulator: searching for best hold at org .$user-ws_ou.
and copy $bc with a hold stalling interval of . ($hold_stall_interval || (none)));
# search for what should be the best holds for this copy to fulfill
- my $best_holds = $U-storagereq(
- open-ils.storage.action.hold_request.nearest_hold.atomic,
- $user-ws_ou, $copy-id, 10, $hold_stall_interval );
+ my $best_holds;
+ if ($homer) {
+$best_holds = $U-storagereq(
+open-ils.storage.action.hold_request.nearest_hold.atomic,
+$copy-circ_lib-id, $copy-id, 10, $hold_stall_interval );
+ } else {
+ $best_holds = $U-storagereq(
+open-ils.storage.action.hold_request.nearest_hold.atomic,
+$user-ws_ou, $copy-id, 10, $hold_stall_interval );
+ }
+
unless(@$best_holds) {
if( my $hold = $$old_holds[0] ) {
Index: src/perlmods/OpenILS/Application/Storage/Publisher/action.pm
===
--- src/perlmods/OpenILS/Application/Storage/Publisher/action.pm (revision 16362)
+++
[OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** ***SPAM*** Re: MFHD Commit to Serials Branch
On Mon, May 3, 2010 at 6:59 PM, Dan Wells d...@calvin.edu wrote: Hello Bill, 1. I'd recommend keeping the seials-integration [sic] branch up to date with trunk. It will make the final merge much simpler. I've used svnmerge [1] in the past with success. Sounds good, I'll do my best to keep up. 2. I'd like to offer our assistance getting the serials schema defined in the wiki [2] into trunk. (FWIW, I'm suggesting trunk instead of the integration branch for several reasons. Dealing with upgrade scripts in a branch won't be fun, trunk already has a serials schema in progress, the integration branch can absorb the changes (via svnmerge), and there are other features related to serials and ACQ that are pending the integration of the serials schema). I agree with this as well. What outstanding changes need to be made to the schema before it's brought in? I've been tinkering with the schema quite a bit since our pre-conference conversation, and testing it against various scenarios. I definitely understand better now the need to have multiple shelving_units per call_number, but also think we cannot give up supporting multiple copies per shelving unit. It is important for us to know relationally if two copies represent the same shelving_unit (that is, the same content). So it would appear that shelving_unit is a corollary to neither call_number nor copy, but truly exists at some meta-level which falls in between. For purposes of easier integration and backwards compatibility, I say we keep it there. With that in mind, we really have two options: 1) a separate linking table to map copies to shelving units in a many-to-one relation 2) a new 'serial.copy' table which inherits from asset.copy, but adds a reference to shelving_unit If we need to support multiple shelving_unit's per call_number (honestly, I missed the crux of the debate), then this approach seems reasonable to me. The mapping table makes sense, since we are, as you indicated, representing another dimension to the relationships between these objects. I think these are really two ways to do about the same thing, but since I do not have much experience with inherited tables, the wiki page has been updated to reflect the more traditional approach (#1). I could rally behind either approach (or still another), though, so more thoughts here are certainly welcome. * I recall some discussion of dropping the unique constraint on serial.shelving_unit.call_number. This has been dropped, per above. * Do we need a serials.distribution.owning_lib column to cover the scenario where serial.record_entry is owned by the root org unit? I think this sounds like a reasonable requirement. It has been added. * I'm inclined to leave serial.claim out until we know how acq.claim might affect things. Sounds fine. Similarly, dropping serial.issuance.has_claims, since that will likely be a derived value, based on the existence of claim data. * What else? I have made a few other changes. Notably, first, I replaced all DATE columns with TIMESTAMP... columns, as DATEs were not playing nice in a few places. Second I replaced 'is_expected' and 'is_received' with copies_expected and copies_received, as I believe this supports more use cases without adding much complexity to cases where the change would not be needed. There are a few other similarly minor changes sprinkled throughout. I intend to eventually add note tables for Shelving Units and Distributions (the Issuance note table is now there), but just haven't gotten around to it. They should be straightforward. copies_expected and copies_received is a count? I wonder if we'll need more copy-level details like recv_date for individual copies, etc. Something not quite as straightforward, though, is the idea of having a 'copy template' of some sort. I have added at least some comments pertaining to the idea of using the copy_transparency table, but as I understand it, that is not quite what was in mind when that table was created. Still, it or something like it would work and is desirable. This, in conjunction with my question above, creates some disturbing similarities to how acq.lineitem_detail's are used ;) It's basically a proto-copy with some values populated manually and/or from org_unit settings, and some auto-generated at real copy creation time. Integrating the ACQ code at that level could very well be massive overkill for serials, though. All that said, I think getting this into trunk even more-or-less as-is would be a big step in the right direction. I have updated the wiki page ( http://www.open-ils.org/dokuwiki/doku.php?id=acq:serials:basic_predicting_and_receiving) to reflect the schema as it currently exists on my development instance (apologies in advance for any typos!). As the week progresses, I fully expect to get the bulk of our current serials code into the branch.
[OPEN-ILS-DEV] ***SPAM*** RE: ***SPAM*** Re: ***SPAM*** Looking at BibTemplate
Hi Jason,
I was doing some simple experimenting this morning with BibTemplate and was
able to create a very basic Call number display on our test server. Here is
what we did to set this up:
1) In the default skin folder, edit js/result_common.js and add the line:
dojo.require('openils.BibTemplate');
to the top of that file.
Then, add
//instantiate bibtemplate
var here = findOrgUnit(getLocation());
new openils.BibTemplate({ root: r, record : rec.doc_id(), org_unit :
here.shortname() }).render();
to the resultDisplayRecord(rec, pos, is_mr) function of the same file.
I stole this code directly from Conifer's Evergreen contribution repository at:
http://svn.open-ils.org/trac/ILS-Contrib/browser/conifer/branches/rel_1_6_0/web/opac/skin/btresult/js/result_common.js
-check out that file for specifics.
2) Add this line to the xml/result/result_table.xml file:
span type='opac/slot-data' query='datafield[tag=050]'
id='rresult_cn'/spanbr /
This simply pulls the 050 call number marc field into the page.
I placed this just above the title link line:
a title=result.table.keyword; name='item_title' class='title_link'
The results can be seen at:
http://libdog.mohawkcollege.ca/opac/en-CA/skin/default/xml/rresult.xml?t=%20Koreatp=keywordd=0rt=keyword
Now, I emphasize that this is a simplistic starting point for testing purposes
just to get started. Sometimes I like to start with the simplest example and go
from there.
Conifer is working on a much more useful and sophisticated results page which
will pull in copy level information. The possibilities of the BibTemplate being
used in the results page are incredible.
Thank you Dan Scott for your presentation at Evergreen and Thank you Kevin
Beswick for your work on the results page! And thank you to all the developers
for the BibTemplate tool!
Regards,
Robert
From: open-ils-dev-boun...@list.georgialibraries.org
[open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Jason Boyer
[jas...@myjclibrary.org]
Sent: May 3, 2010 2:48 PM
To: Evergreen Development Discussion List
Subject: [OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Looking at BibTemplate
I'm working on getting a VM setup at work so I can spend more time with it,
when I was having trouble getting results with other tags I was using my home
laptop with a version of trunk that's got some age on it. All I've tried to do
there was add fields to the record display, nothing terribly fancy. That's
working out ok, I just wanted to see if it was a local issue (looks that way)
or if I was misunderstanding the scope of BibTemplate's abilities.
Word of someone working on a results page with call numbers is what has me
working on this in the first place. I got a lot out of your EG2010 conference
presentation, and one of the complaints I've heard from staff ever since we
migrated was that they wanted to see call numbers in search results instead of
loading every record individually. I didn't know that there was a working
example of a results page though, that will be a big help.
Thanks for the pointers.
Jason
--
Jason Boyer, IT Specialist
Jackson County Public Library
303 W Second St
Seymour, IN 47274
jas...@myjclibrary.orgmailto:jas...@myjclibrary.org
On Sun, May 2, 2010 at 8:23 PM, Dan Scott
d...@coffeecode.netmailto:d...@coffeecode.net wrote:
On 2 May 2010 11:19, Jason Boyer
jas...@myjclibrary.orgmailto:jas...@myjclibrary.org wrote:
I'm looking a little at BibTemplate in 1.6 and have a couple quick
questions.
One, I've been having some trouble getting any tags but td to work with
the type and query attributes. I've seen examples using spans, but I
couldn't get them to do anything.
On our 1.6.0.4 system, I just tried adding:
p type='opac/slot-data' query='datafield[tag=245]'/p
to the top of our rdetails/rdetail_summary.xml file, above the table
that normally displays the elements. And... it showed the contents of
the 245 field as you would expect. Maybe you want to share an example
of what you were trying to do?
Second, is BibTemplate enabled on the search results page, or only record
details? If it's not on the results page, how difficult would it be to add,
and is that already planned for a later release?
There's not much to do to enable BibTemplate; Dojo is already active
on the search results page, so you just need to clone the
dojo.addOnLoad() section of rdetails/rdetail_summary.xml that contains
the dojo.require('openils.BibTemplate') call and adjust the request to
reflect the bib ID of each record.
My colleague Kevin Beswick has an initial draft of a results page that
uses BibTemplate running at
http://laurentian-test.concat.ca/opac/en-CA/skin/btresult/xml/rresult.xml?t=androidtp=titlel=105d=1rt=title
- there's still some work he needs to do, but it's the direction we're
heading. And in general, yes, I think BibTemplate on the default skin
for search results and more use of it on the record details page are
