Re: [OPEN-ILS-DEV] (Patch) Restore typo to Circulate.pm
On Tue, Mar 2, 2010 at 1:03 PM, Mike Rylander mrylan...@gmail.com wrote: Applied to 1.6.0 in prep for 1.6.0.3. Thanks, Warren! Great - thanks! I forgot to add that it might also need to be applied to rel_1_6, too. Cheers, Warren
[OPEN-ILS-DEV] (Patch) Double-quotes in call numbers or copy locations
I'm sure most people use Dewey- or LCC-based call numbers and so won't hit this problem but... We have a number of call numbers that include double-quotes (such as 'GSC A Series (...)' for some of our maps). For these items, the Copy Details and Browse Call Numbers links don't work on the rdetail page. I'm not sure this will be generally useful, but I put together a minor fix to escape double-quotes for these links. Thanks! Warren Layton NRCan Library / Bibliothèque RNCan rdetail_double_quotes.patch Description: Binary data
Re: [OPEN-ILS-DEV] (Patch) Double-quotes in call numbers or copy locations
On Thu, Feb 18, 2010 at 10:38 AM, Mike Rylander mrylan...@gmail.com wrote: This is great. Thanks, Warren. Would you mind sending a DCO-attached version? (Sorry ...) Here you go -- sorry about that! Thanks, Warren Layton NRCan Library / Bibliothèque RNCan 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: Warren A. Layton warren dot layton at googlemail rdetail_double_quotes.patch Description: Binary data
[OPEN-ILS-DEV] Add sfr class to fm_IDL.xml ?
Hello again, I'm trying to run through the MFHD test dataset located in trunk: http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/tests/datasets/README The first step, importing serials_marc21.xml, works fine. However, when I try to import serials_mfhd.xml, I get the following error: Couldn't process record: Can't locate object method new via package Fieldmapper::serial::full_rec (perhaps you forgot to load Fieldmapper::serial::full_rec?) at /openils/lib/perl5//OpenILS/Application/Ingest.pm line 1222. Looking through fm_IDL.xml, I notice that there are classes full_rec classes for metabib and authority records (mfr and afr, respectively), but not serials: class id=mfr controller=open-ils.cstore oils_obj:fieldmapper=metabib::full_rec oils_persist:tablename=metabib.full_rec reporter:label=Flattened MARC Fields class id=afr controller=open-ils.cstore oils_obj:fieldmapper=authority::full_rec oils_persist:tablename=authority.full_rec reporter:label=Full Authority Record Should there be an sfr class, too? Or does something else (in Ingest.pm?) need to be changed? Cheers, Warren
Re: [OPEN-ILS-DEV] direct_ingest.pl, biblio_fingerprint.js and Unicode chars
On Sun, Dec 13, 2009 at 8:50 PM, Dan Scott d...@coffeecode.net wrote: That issue notwithstanding, I would be in favour of applying this patch to trunk at this time, and with a little more testing and confirmation of the fingerprinting goals, I would like to see it backported to the 1.6 series. Thanks for testing this patch, Dan, and suggesting it for trunk. (And I, too, am curious about the goals of fingerprinting and whether non-ASCII is acceptable.) Cheers, Warren
Re: [OPEN-ILS-DEV] direct_ingest.pl, biblio_fingerprint.js and Unicode chars
On Tue, Dec 1, 2009 at 10:45 AM, Dan Scott d...@coffeecode.net wrote: If not, and if rolling the try/catch blocks of the script into the Perl Ingest function is fine, I can go ahead with that and post a patch here soon. I'd love to see that patch. Hello again (and sorry for the delay). I'm attaching my patch to include the biblio_fingerprint code directly in Ingest.pm. As suggested by Dan, I've included a legacy_script_support option in opensrf.xml that lets you run the old biblio_fingerprint.js script instead. A few notes: * The Perl code is structured very similarly to the JavaScript code (lots of try/catch blocks). There may be a better way to write it... * For the quality value, I left most of the increments in (length of datafields, matching certain values of the 039 field, etc). The exception is the quality bump for language. For some reason that I didn't understand, the old script incremented the quality value for English records only. If that's still needed, it can be added to the Perl code. * The other script called by Ingest.pm, biblio_descriptor.js, will still be called, regardless of the legacy_script_support setting. This is my first stab at this. It has solved the problems I was having with direct_ingest.pl for our records but comments and feedback are definitely welcome. Thanks! Warren Layton NRCan Library / Bibliothèque RNCan biblio_fingerprint.patch.gz Description: GNU Zip compressed data
[OPEN-ILS-DEV] (Patch) Remove translation for Org Units
Attached is a 1-liner to fix a bug reported in LaunchPad: https://bugs.launchpad.net/evergreen/+bug/494224 (Removing a translation for an org unit name didn't work.) I attached it to the LaunchPad report but I thought I'd send it to this list, too, just in case. Cheers, Warren delete_dojo_translation_fix.patch Description: Binary data
Re: [OPEN-ILS-DEV] direct_ingest.pl, biblio_fingerprint.js and Unicode chars
On Mon, Nov 30, 2009 at 7:25 PM, Dan Scott d...@coffeecode.net wrote: I suppose the next logical step would be to rewrite the OpenILS::Application::Ingest fingerprint methods to avoid the ScriptRunner server-side JavaScript biblio_fingerprint.js fun and see if that resolves the problem. Hi Dan, Thanks for all of your messages about this issue -- I wasn't quite sure what to try next. I've now done a very basic rewrite of the OpenILS::Application::Ingest::biblio_fingerprint function so that it doesn't use the server-side JavaScript. So far, it looks like it works with double-wide character codes. My fix is not yet as complete as the biblio_fingerprint.js script, though, so I'll wait until it's in a better state before submitting it. And that's if replacing biblio_fingerprint.js with a Perl solution is acceptable. I'm worried that there's an advantage to having it run as an external script that I'm missing and that I might be throwing the baby out with the bath water. While the biblio_fingerprint.js script doesn't seem to be called from outside of Application::Ingest, I keep asking myself if there's a good reason for it to be separate that I have overlooked. If not, and if rolling the try/catch blocks of the script into the Perl Ingest function is fine, I can go ahead with that and post a patch here soon. Thanks! Warren
[OPEN-ILS-DEV] Developer IRC Meeting: Wednesday December 2nd, 2009, 14:00
From the responses to the poll, it looks like Wednesday afternoon is the best time to have the Developer IRC meeting. So the details are as follows: Date: Wednesday December 2nd, 2009 Time: 2:00 PM Eastern The agenda is located on the wiki at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2009-12 Please feel free to add and amend items to make sure that it addresses the immediate concerns of the project. Some things can also be done in advance to help the meeting run more smoothly. For instance, Action items from the past meeting listed in the agenda can be crossed out they have already been addressed. As a reminder, this is a public meeting for Evergreen developers that will be held on the #evergreen channel on the Freenode IRC network (http://open-ils.org/irc.php). All members of the community with an interest in contributing to the development of Evergreen are welcome to attend - and if you are unable to attend at the designated time, please feel free to submit comments for any of the agenda items in advance to the Evergreen development mailing list. Thanks! Warren
[OPEN-ILS-DEV] direct_ingest.pl, biblio_fingerprint.js and Unicode chars
I'm trying to import a number of bib records with special characters in the MARC fields. I've gotten as far running direct_ingest.pl but I'm noticing that biblio_fingerprint.js chokes on a few of them. Looking a bit closer, I noticed that biblio_fingerprint.js chops character codes down to two least significant hex digits. For example, biblio_fingerprint.js turns #x10C; (Č) into #x0c (form feed), which causes the direct_ingest.pl to skip the record and output the following error: Couldn't process record: invalid character encountered while parsing JSON string Attached is a sample record that causes this problem for me (the tarball includes both the original MARCXML and the BRE file generated from it by marc2bre.pl). Any help would be appreciated! I can open a bug on Launchpad, too, if needed. Cheers, Warren iii_prob_record.tar.gz Description: GNU Zip compressed data
Re: [OPEN-ILS-DEV] Next developer IRC meeting?
Just a reminder that the next IRC developer meeting is coming up next week. It's not too late to vote on the date and time, but be sure to do so before the end of this week: http://www.doodle.com/9p9xzpx3fivxzity There's also a page on the wiki for the agenda: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2009-12 It is currently pretty bare, so feel free to add items that you think need to be discussed during the meeting. Cheers, Warren
Re: [OPEN-ILS-DEV] Next developer IRC meeting?
On Thu, Nov 12, 2009 at 11:16 PM, Dan Scott d...@coffeecode.net wrote: With the 1.4.0.7 and 1.6.0.0 releases tarred up and the finishing touches being put on the download page and release notes, it's probably a good time to touch base again. Here's a Doodle Poll to help decide the time and date for the meeting: http://www.doodle.com/9p9xzpx3fivxzity Available days are Nov. 30 - Dec. 4, and the possible times are: 10am / 2pm / 3pm / 4pm / 9pm. All times are Eastern Standard Time. Cheers, Warren
Re: [OPEN-ILS-DEV] (Patch) Make group permission setup a bit easier to decipher
On Wed, Nov 11, 2009 at 10:48 PM, Dan Scott d...@coffeecode.net wrote: On Wed, 2009-11-11 at 22:00 -0500, Warren Layton wrote: I don't know what you think of this patch. I think it's a great patch. Thanks! In my opinion, the only thing that we would want is a DCO. Darn - I _always_ forget to append that! Here it is: 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: Warren A. Layton warren.lay...@googlemail.com
[OPEN-ILS-DEV] (Patch) Make group permission setup a bit easier to decipher
I don't know what you think of this patch. I wrote it up after
noticing the following comment in the
Open-ILS/src/sql/Pg/950.data.seed-values.sql file:
-- XXX Incomplete base permission setup. A patch would be appreciated.
Now, I have no idea what the base permission setup should look like
for the average library. However, figuring out what permissions are
currently being applied is difficult with lines such as:
INSERT INTO permission.grp_perm_map VALUES (57, 2, 15, 0, false);
...when it could be rewritten as:
-- Add basic patron permissions to the Patrons group
INSERT INTO permission.grp_perm_map (grp, perm, depth, grantable)
VALUES (2, (SELECT id FROM permission.perm_list WHERE code =
'RENEW_CIRC'), 0, false);
To me, this patch makes it very clear which permissions are assigned
to which groups (the permissions for the Acquisition groups are
currently set in this way, too). This added clarity may help when
someone more knowledgeable than me tries to figure out what the base
permission setup should be for each group.
The only possible problems are:
1) The id in permission.grp_perm_map is not explicitly set with these
changes (e.g., in the first INSERT statement, above, the id is
explicitly set to 57). This didn't seem like a problem to me, but I
could be wrong.
2) I noticed that just before the Acquisitions group permissions, the
following line is present:
SELECT SETVAL('permission.grp_perm_map_id_seq'::TEXT, (SELECT
MAX(id) FROM permission.grp_perm_map));
I'm not sure if I should have included it at the the start of the
block that I changed (given that I'm not explicitly setting the id
value).
Let me know what you think and feel free to kick it back to me if
changes are needed.
Thanks!
Warren Layton
NRCan Library / Bibliothèque RNCan
Index: Open-ILS/src/sql/Pg/950.data.seed-values.sql
===
--- Open-ILS/src/sql/Pg/950.data.seed-values.sql (revision 14877)
+++ Open-ILS/src/sql/Pg/950.data.seed-values.sql (working copy)
@@ -902,6 +902,7 @@
(21, 'CREATE_VOLUME', oils_i18n_gettext(21, 'Allow a user to create a volume', 'ppl', 'description')),
(22, 'UPDATE_VOLUME', oils_i18n_gettext(22, 'Allow a user to edit volumes - needed for merging records. This is a duplicate of VOLUME_UPDATE, user must have both permissions at appropriate level to merge records.', 'ppl', 'description')),
(23, 'DELETE_VOLUME', oils_i18n_gettext(23, 'Allow a user to delete a volume', 'ppl', 'description')),
+(24, 'CREATE_COPY', oils_i18n_gettext(24, 'Allow a user to create a new copy object', 'ppl', 'description')),
(25, 'UPDATE_COPY', oils_i18n_gettext(25, 'Allow a user to edit a copy', 'ppl', 'description')),
(26, 'DELETE_COPY', oils_i18n_gettext(26, 'Allow a user to delete a copy', 'ppl', 'description')),
(27, 'RENEW_HOLD_OVERRIDE', oils_i18n_gettext(27, 'Allow a user to continue to renew an item even if it is required for a hold', 'ppl', 'description')),
@@ -918,13 +919,12 @@
(38, 'SET_CIRC_MISSING', oils_i18n_gettext(38, 'Allow a user to mark an item as ''missing''', 'ppl', 'description')),
(39, 'SET_CIRC_CLAIMS_RETURNED', oils_i18n_gettext(39, 'Allow a user to mark an item as ''claims returned''', 'ppl', 'description')),
(41, 'CREATE_TRANSACTION', oils_i18n_gettext(41, 'Allow a user to create a new billable transaction', 'ppl', 'description')),
+(42, 'VIEW_TRANSACTION', oils_i18n_gettext(42, 'Allow a user may view another user''s transactions', 'ppl', 'description')),
(43, 'CREATE_BILL', oils_i18n_gettext(43, 'Allow a user to create a new bill on a transaction', 'ppl', 'description')),
(44, 'VIEW_CONTAINER', oils_i18n_gettext(44, 'Allow a user to view another user''s containers (buckets)', 'ppl', 'description')),
(45, 'CREATE_CONTAINER', oils_i18n_gettext(45, 'Allow a user to create a new container for another user', 'ppl', 'description')),
-(24, 'CREATE_COPY', oils_i18n_gettext(24, 'Allow a user to create a new copy object', 'ppl', 'description')),
(47, 'UPDATE_ORG_UNIT', oils_i18n_gettext(47, 'Allow a user to change the settings for an organization unit', 'ppl', 'description')),
(48, 'VIEW_CIRCULATIONS', oils_i18n_gettext(48, 'Allow a user to see what another user has checked out', 'ppl', 'description')),
-(42, 'VIEW_TRANSACTION', oils_i18n_gettext(42, 'Allow a user may view another user''s transactions', 'ppl', 'description')),
(49, 'DELETE_CONTAINER', oils_i18n_gettext(49, 'Allow a user to delete another user''s container', 'ppl', 'description')),
(50, 'CREATE_CONTAINER_ITEM', oils_i18n_gettext(50, 'Allow a user to create a container item for another user', 'ppl', 'description')),
(51, 'CREATE_USER_GROUP_LINK', oils_i18n_gettext(51, 'Allow a user to add other users to permission groups', 'ppl', 'description')),
@@ -964,8 +964,8 @@
(85, 'VIEW_COPY_NOTES', oils_i18n_gettext(85, 'Allow a user to view all notes attached to a copy', 'ppl
[OPEN-ILS-DEV] UPDATE_RECORD permission in 1.4.x and 1.6.x
A staff member was having trouble undeleting a record. I have a taken a quick look and may have found a small issue: Using the staff client in version 1.4.0.6, it looks like open-ils.cat.biblio.record_entry.undelete is called (from Application/Cat.pm), which then checks if the user has the permission UPDATE_RECORD. However, the UPDATE_RECORD permission doesn't appear to be present in version 1.4.0.6. UPDATE_RECORD does, however, appear to be in version 1.6.0.0 (it gets added in Open-ILS/src/sql/Pg/950.data.seed-values.sql), but not in the 1.4.0.5-1.6.0.0-upgrade-db.sql upgrade script. Cheers, Warren Layton
Re: [OPEN-ILS-DEV] Preliminary Conify (Org. Units) Patch
On Fri, Oct 23, 2009 at 12:32 AM, Warren Layton warren.lay...@gmail.com wrote: Deleting is the one function that is still causing me a bit of trouble. I'll keep plugging away but if anyone has a spare minute, I'd appreciate some fresh eyes to look over the attached patch (against tags/rel_1_6_0_0). Newly-created items are easily deleted, but deleting items which were recently updated with new hours of operation or addresses doesn't always work. Perhaps I'm doing something unwholesome with Dojo's ItemWriteStore... Never mind! Looking at it again after a few hours of sleep helped me track down the problem. Attached is the new patch for review/testing (against tags/rel_1_6_0_0). DCO is below, just in case. Cheers, Warren Layton NRCan Library / Bibliothèque RNCan = 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: Warren A. Layton = conify_aou_rel_1_6.patch Description: Binary data
Re: [OPEN-ILS-DEV] ***SPAM*** Re: Preliminary Conify (Org. Units) Patch
On Fri, Oct 23, 2009 at 12:22 PM, Mike Rylander mrylan...@gmail.com wrote: Heh ... I was busily reviewing your first version and missed the next two. Take a look at the attached patch against org_unit.js (against stock version), which I believe changes things in the way you want, but with less cut-n-paste for each address. The only question I have is about setting ischanged on the hoo and aua objects when your fetch them in the load_...() functions. I've retained that from your earlier patch, but I'm not sure of the purpose. Sorry -- yes, those ischanged( 1 ) lines can be removed. Thanks for pointing that out -- it was masking a change that needed to be made in org_unit.html to set ischanged when the values were to be written out. If your cross-review looks good, I'll commit your HTML and my JS, eh? I think the attached patch for the HTML and your JS patch (minus ischanged stuff) should do it. Thanks for reviewing! Cheers, Warren Layton NRCan Library / Bibliothèque RNCan fix-org_unit-conify-html.patch Description: Binary data
[OPEN-ILS-DEV] Preliminary Conify (Org. Units) Patch
During last week's IRC development meeting[1], I volunteered to have a
look at hooking up the address fields in Conify's org. unit interface
(Admin-Server Administration-Organizational Units). Thanks to Mike
Rylander, isnew/ischanged/isdeleted fields were fixed recently for
org. unit objects which has helped me simplify the code quite a bit.
Of the CRUD functions, Creating, Retrieving and Updating seems to work
for the org. units, their hours of operation, and their addresses.
Deleting is the one function that is still causing me a bit of
trouble. I'll keep plugging away but if anyone has a spare minute, I'd
appreciate some fresh eyes to look over the attached patch (against
tags/rel_1_6_0_0). Newly-created items are easily deleted, but
deleting items which were recently updated with new hours of operation
or addresses doesn't always work. Perhaps I'm doing something
unwholesome with Dojo's ItemWriteStore...
Cheers,
Warren Layton
NRCan Library / Bibliothèque RNCan
[1] October 2009, see http://open-ils.org/dokuwiki/doku.php?id=dev:meetings
Index: Open-ILS/web/conify/global/actor/org_unit.js
===
--- Open-ILS/web/conify/global/actor/org_unit.js (revision 14571)
+++ Open-ILS/web/conify/global/actor/org_unit.js (working copy)
@@ -40,10 +40,9 @@
var cgi = new CGI();
var cookieManager = new HTTP.Cookies();
var ses = cookieManager.read('ses') || cgi.param('ses');
-var pCRUD = new OpenSRF.ClientSession('open-ils.pcrud');
var pcrud = new openils.PermaCrud({ authtoken : ses });
-var current_ou, current_ou_hoo, ou_list_store, hoo_id;
+var current_ou, current_ou_hoo, ou_list_store;
var dirtyStore = [];
var virgin_ou_id = -1;
@@ -64,9 +63,9 @@
delete_ou_button.disabled = false;
var modified_ou = new aou().fromStoreItem( current_ou );
- modified_ou.ischanged( 1 );
+modified_ou.ischanged ( 1 );
- pcrud.update( modified_ou, {
+ pcrud.apply( modified_ou, {
timeout : 10, // makes it synchronous
onerror : function (r) {
highlighter.editor_pane.red.play();
@@ -90,19 +89,25 @@
function hoo_load () {
save_hoo_button.disabled = false;
- hoo_id = pcrud.search( 'aouhoo',{id:ou_list_store.getValue( current_ou, 'id' )});
- if (hoo_id.length == 0) {
- current_ou_hoo = new aouhoo().fromHash({id:ou_list_store.getValue( current_ou, 'id' )});
+ if (pcrud.search( 'aouhoo',{id:ou_list_store.getValue( current_ou, 'id' )}).length) {
+ pcrud.retrieve( 'aouhoo', ou_list_store.getValue( current_ou, 'id' ), {
+ onerror : function (r) {
+throw dojo.string.substitute(aou_strings.ERROR_FETCHING_HOURS,[ou_list_store.getValue( current_ou, 'name' )]);
+ },
+oncomplete : function (r) {
+current_ou_hoo = r.recv().content();
+current_ou_hoo.ischanged( 1 );
+}
+ });
+ } else {
+ current_ou_hoo = new aouhoo().fromHash({
+isnew : 1,
+id : ou_list_store.getValue( current_ou, 'id' )
+});
for (var i = 0; i 7; i++) {
current_ou_hoo['dow_' + i + '_open']('09:00:00');
current_ou_hoo['dow_' + i + '_close']('17:00:00');
}
- } else {
- current_ou_hoo = pcrud.retrieve( 'aouhoo', ou_list_store.getValue( current_ou, 'id' ), {
- onerror : function (r) {
-throw dojo.string.substitute(aou_strings.ERROR_FETCHING_HOURS,[ou_list_store.getValue( current_ou, 'name' )]);
- }
- });
}
for (var i = 0; i 7; i++) {
@@ -117,134 +122,91 @@
highlighter.hoo_pane.green.play();
}
+
function addr_load () {
- // empty result not coming through ...
save_ill_address.disabled = false;
save_holds_address.disabled = false;
save_mailing_address.disabled = false;
save_billing_address.disabled = false;
- if (ou_list_store.getValue( current_ou, 'billing_address' )) {
- pCRUD.request({
- method : 'open-ils.pcrud.retrieve.aoa',
- params : [ ses, ou_list_store.getValue( current_ou, 'billing_address' ) ],
- onerror : function (r) {
-throw dojo.string.substitute(aou_strings.ERROR_FETCHING_PHYSICAL, [ou_list_store.getValue( current_ou, 'name' )]);
- },
- oncomplete : function (r) {
-current_billing_address = null;
-
-var res = r.recv();
-if (res) {
- if (res.content()) current_billing_address = res.content();
-}
-
-if (!current_billing_address) {
- current_billing_address = new aoa().fromHash({org_unit:ou_list_store.getValue( current_ou, 'id' )});
- current_billing_address.isnew(1);
-}
-
-set_addr_inputs('billing');
-highlighter.addresses_pane.green.play();
- }
- }).send();
- } else {
- current_billing_address = new aoa().fromHash({org_unit:ou_list_store.getValue( current_ou, 'id' )});
- current_billing_address.isnew(1);
- set_addr_inputs('billing');
+ if (pcrud.search( 'aoa',{id:ou_list_store.getValue( current_ou, 'billing_address')}).length) {
+ pcrud.retrieve( 'aoa', ou_list_store.getValue( current_ou, 'billing_address'), {
+ onerror : function (r) {
+ throw dojo.string.substitute
Re: [OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Re: Export to RefWorks in Evergreen
On Sat, Oct 17, 2009 at 2:46 PM, Dan Scott d...@coffeecode.net wrote: I'm embarrassed at how long it has taken to do this, but happy to report that I have tested your patch successfully and applied it against trunk and the rel_1_6 branch, with just one minor change: as with the Export to RefWorks for an individual record, I have set the default behaviour to not display the link. Sites that want to enable this functionality will need to adjust /openils/var/web/opac/skin/default/js/myopac.js accordingly. Thanks for applying the patch, Dan! (And thanks for changing the default behaviour to match that in rdetail -- I should've thought to copy the default behaviour from rdetail). Cheers, Warren
Re: [OPEN-ILS-DEV] (Patch) List Z39.50 Targets in Alphabetical Order
Sorry - previous patch didn't include the full path info. This time, I
ran svn diff from the ILS/trunk directory.
Cheers,
Warren
On Thu, Sep 3, 2009 at 8:39 PM, Warren Laytonwarren.lay...@gmail.com wrote:
The attached patch presents the Z39.50 targets in the Staff Client in
alphabetical order - a problem for us because we're starting to have
quite a few configured.
I'm not sure if this is the most elegant solution so feedback is
definitely welcome.
Cheers,
Warren
Index: Open-ILS/xul/staff_client/server/cat/z3950.js
===
--- Open-ILS/xul/staff_client/server/cat/z3950.js (revision 13937)
+++ Open-ILS/xul/staff_client/server/cat/z3950.js (working copy)
@@ -345,18 +345,28 @@
if (typeof robj.ilsevent != 'undefined') throw(robj);
obj.services = robj;
var x = document.getElementById('service_rows');
- for (var i in obj.services) {
+
+var services = new Array();
+for (var i in obj.services) {
+var label;
+if (obj.services[i].label) {
+label = obj.services[i].label;
+} else if (obj.services[i].name) {
+label = obj.services[i].name;
+} else {
+label = i;
+}
+var j = [label, i];
+services.push(j);
+}
+services.sort();
+for (var j=0; j services.length; j++) {
+var i = services[j][1];
try {
if (i == 'native-evergreen-catalog') continue;
var r = document.createElement('row'); x.appendChild(r);
var cb = document.createElement('checkbox');
-if (obj.services[i].label) {
-cb.setAttribute('label',obj.services[i].label);
-} else if (obj.services[i].name) {
-cb.setAttribute('label',obj.services[i].name);
-} else {
-cb.setAttribute('label',i);
-}
+cb.setAttribute('label',services[j][0]);
cb.setAttribute('tooltiptext',i + ' : ' + obj.services[i].db + '@' + obj.services[i].host + ':' + obj.services[i].port);
cb.setAttribute('mytype','service_class'); cb.setAttribute('service',i);
cb.setAttribute('id',i+'_service'); r.appendChild(cb);
[OPEN-ILS-DEV] (Patch) List Z39.50 Targets in Alphabetical Order
The attached patch presents the Z39.50 targets in the Staff Client in
alphabetical order - a problem for us because we're starting to have
quite a few configured.
I'm not sure if this is the most elegant solution so feedback is
definitely welcome.
Cheers,
Warren
Index: z3950.js
===
--- z3950.js (revision 13937)
+++ z3950.js (working copy)
@@ -345,18 +345,28 @@
if (typeof robj.ilsevent != 'undefined') throw(robj);
obj.services = robj;
var x = document.getElementById('service_rows');
- for (var i in obj.services) {
+
+var services = new Array();
+for (var i in obj.services) {
+var label;
+if (obj.services[i].label) {
+label = obj.services[i].label;
+} else if (obj.services[i].name) {
+label = obj.services[i].name;
+} else {
+label = i;
+}
+var j = [label, i];
+services.push(j);
+}
+services.sort();
+for (var j=0; j services.length; j++) {
+var i = services[j][1];
try {
if (i == 'native-evergreen-catalog') continue;
var r = document.createElement('row'); x.appendChild(r);
var cb = document.createElement('checkbox');
-if (obj.services[i].label) {
-cb.setAttribute('label',obj.services[i].label);
-} else if (obj.services[i].name) {
-cb.setAttribute('label',obj.services[i].name);
-} else {
-cb.setAttribute('label',i);
-}
+cb.setAttribute('label',services[j][0]);
cb.setAttribute('tooltiptext',i + ' : ' + obj.services[i].db + '@' + obj.services[i].host + ':' + obj.services[i].port);
cb.setAttribute('mytype','service_class'); cb.setAttribute('service',i);
cb.setAttribute('id',i+'_service'); r.appendChild(cb);
[OPEN-ILS-DEV] ***SPAM*** Conify Hours of Operation (Patch)
There was some discussion on IRC a while ago about problems editing
hours of operation, and (in my case, at least), I found that adding
and deleting org units was a problem, too. Attached is a patch for the
Conify interface in trunk that appears to fix these issues for me.
This is my first foray into pcrud (not to mention Dojo...), so feel
free to kick this back for further development if there are any
problems. I'm a bit unsure of the code under the onerror and
oncomplete conditions, which I have pretty much left intact. I have
also used the Dojo openils.PermaCrud instead of the OpenSRF
open-ils.pcrud, which may or may not be the correct way to go.
Feedback is definitely welcome, and I'd be willing to have a look at
the code for addresses (mailing, ILL, etc) once I'm sure I'm on the
right track with this current patch.
Cheers,
Warren Layton
NRCan Library
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: Warren Layton warren.lay...@googlemail.com
Index: Open-ILS/web/conify/global/actor/org_unit.js
===
--- Open-ILS/web/conify/global/actor/org_unit.js (revision 13797)
+++ Open-ILS/web/conify/global/actor/org_unit.js (working copy)
@@ -42,7 +42,7 @@
var pCRUD = new OpenSRF.ClientSession('open-ils.pcrud');
var pcrud = new openils.PermaCrud({ authtoken : ses });
-var current_ou, current_ou_hoo, ou_list_store
+var current_ou, current_ou_hoo, ou_list_store, hoo_id;
var dirtyStore = [];
var virgin_ou_id = -1;
@@ -65,7 +65,7 @@
var modified_ou = new aou().fromStoreItem( current_ou );
modified_ou.ischanged( 1 );
-pcrud.apply( modified_ou, {
+ pcrud.update( modified_ou, {
timeout : 10, // makes it synchronous
onerror : function (r) {
highlighter.editor_pane.red.play();
@@ -87,46 +87,33 @@
}
function hoo_load () {
- // empty result not coming through ...
- current_ou_hoo = new aouhoo().fromHash({id:ou_list_store.getValue( current_ou, 'id' )});
- current_ou_hoo.isnew(1);
+ save_hoo_button.disabled = false;
- pCRUD.request({
- method : 'open-ils.pcrud.retrieve.aouhoo',
- params : [ ses, ou_list_store.getValue( current_ou, 'id' ) ],
- onerror : function (r) {
- throw dojo.string.substitute(aou_strings.ERROR_FETCHING_HOURS, [ou_list_store.getValue( current_ou, 'name' )]);
- },
- oncomplete : function (r) {
- current_ou_hoo = null;
-
- var res = r.recv();
- if (res) {
-if (res.content()) current_ou_hoo = res.content();
+ hoo_id = pcrud.search( 'aouhoo',{id:ou_list_store.getValue( current_ou, 'id' )});
+ if (hoo_id.length == 0) {
+ current_ou_hoo = new aouhoo().fromHash({id:ou_list_store.getValue( current_ou, 'id' )});
+ for (var i = 0; i 7; i++) {
+ current_ou_hoo['dow_' + i + '_open']('09:00:00');
+ current_ou_hoo['dow_' + i + '_close']('17:00:00');
+ }
+ } else {
+ current_ou_hoo = pcrud.retrieve( 'aouhoo', ou_list_store.getValue( current_ou, 'id' ), {
+ onerror : function (r) {
+throw dojo.string.substitute(aou_strings.ERROR_FETCHING_HOURS,[ou_list_store.getValue( current_ou, 'name' )]);
}
+ });
+ }
- if (!current_ou_hoo) {
-current_ou_hoo = new aouhoo().fromHash({id:ou_list_store.getValue( current_ou, 'id' )});
-current_ou_hoo.isnew(1);
-for (var i = 0; i 7; i++) {
- current_ou_hoo['dow_' + i + '_open']('09:00:00');
- current_ou_hoo['dow_' + i + '_close']('17:00:00');
-}
- }
+ for (var i = 0; i 7; i++) {
+ window['dow_' + i + '_open'].setValue(
+ dojo.date.stamp.fromISOString( 'T' + current_ou_hoo['dow_' + i + '_open']() )
+ );
+ window['dow_' + i + '_close'].setValue(
+ dojo.date.stamp.fromISOString( 'T' + current_ou_hoo['dow_' + i + '_close']() )
+ );
+ }
- for (var i = 0; i 7; i++) {
-window['dow_' + i + '_open'].setValue(
- dojo.date.stamp.fromISOString( 'T' + current_ou_hoo['dow_' + i + '_open']() )
-);
-window['dow_' + i
Re: [OPEN-ILS-DEV] OpenSRF and Ubuntu 9.04
On Tue, Jul 28, 2009 at 5:20 PM, Jason Stephensonjstephen...@mvlc.org wrote: We had to downgrade the Ejabberd by a version on our test box here. Unfortunately, my assistant who has the details is out on vacation this week. He figured out which version of Ejabberd had the issue and which one to downgrade to. The problem exists for versions of ejabberd 2.0.3 and higher (Ubuntu 9.04 ships with 2.0.3). I downgraded the previous Ubuntu version from 8.10 (2.0.1-2) and it worked fine (and downgrading was very easy - no dependency problems to resolve, IIRC). Cheers, Warren
[OPEN-ILS-DEV] RIS SuperCat Feed
I've put together another SuperCat feed, this type for the RIS format. This can be used with most bibliographic citation software, such as Reference Manager and Endnote. Combined with the previous MARC text feed for RefWorks, most software should be covered. I have only included the changes to add the feed and the XSLT file. The patch (against trunk) doesn't include any changes to the OPAC, but I'm willing to put something together if needed. The MARC21slim2RIS.xsl transform makes a few assumptions: * Any authors listed in 100, 110, or 111 fields are considered primary authors (A1) * Any individuals listed in 700 fields are considered primary authors (A1) if their last name is found in the statement of responsibility (245c). Otherwise, they are considered secondary authors (A2). It's not 100% accurate, but it's certainly a step up from just turning all 700-level authors into A2s. * Corporate authors listed in 710 fields are always considered secondary authors (A2). * Meetings in 711 fields are always converted into Title Series (T3) (i.e., a talk at a conference would have the conference name listed as the Title Series, with the title of the talk listed as T1, primary title). * Apart from field 520 (used for Abstracts, N2), no 5xx fields are used * Subfields in the 650 and 651 fields are used as keywords (KW) Let me know any changes need to be made, or if you have any suggestions on my approach to converting MARC to RIS. Cheers! Warren Layton Index: Open-ILS/xsl/MARC21slim2RIS.xsl === --- Open-ILS/xsl/MARC21slim2RIS.xsl (revision 0) +++ Open-ILS/xsl/MARC21slim2RIS.xsl (revision 0) @@ -0,0 +1,284 @@ +?xml version=1.0 encoding=UTF-8? +xsl:stylesheet version=1.0 xmlns:marc=http://www.loc.gov/MARC21/slim; xmlns:xsl=http://www.w3.org/1999/XSL/Transform; exclude-result-prefixes=marc +xsl:include href=MARC21slimUtils.xsl/ +xsl:output method=text/ + +xsl:template match=marc:record +xsl:variable name=leader select=marc:leader / +xsl:variable name=leader6 select=substring($leader,7,1) / +xsl:variable name=leader7 select=substring($leader,8,1) / + +xsl:text#10;TY - /xsl:text + +xsl:variable name=field008 select=marc:controlfie...@tag=008]/ + +xsl:choose +xsl:when test=$leader6='a' or $leader6='t' +xsl:choose +xsl:when test=$leader6='a' and $leader7='b' or $leader7='i' or $leader7='s' +!-- Continuing Resource -- +xsl:variable name=field008-21 select=substring($field008,22,1)/ +xsl:choose +xsl:when test=$field008-21='p'JOUR/xsl:when +xsl:when test=$field008-21='n'NEWS/xsl:when +xsl:when test=$field008-21='m'SER/xsl:when + +!-- Default to Journal -- +xsl:otherwiseJOUR/xsl:otherwise +/xsl:choose +/xsl:when +xsl:otherwise +!-- If not a CR, then a book (or book-type) item -- +xsl:variable name=field008-24-27 select=substring($field008,25,4)/ +xsl:variable name=field008-29 select=substring($field008,30,1)/ + +xsl:choose +xsl:when test=$leader6='a' and $leader7='m'BOOK/xsl:when +xsl:when test=$leader6='a' and $leader7='a'CHAP/xsl:when +xsl:when test=$field008-29='1'CONF/xsl:when +xsl:when test=$field008-24-27='m'THES/xsl:when +xsl:when test=$field008-24-27='a'ABST/xsl:when +xsl:when test=$field008-24-27='j'PAT/xsl:when +xsl:when test=$field008-24-27='v'CASE/xsl:when +xsl:when test=$field008-24-27='l'STAT/xsl:when +xsl:when test=$field008-24-27='t'RPRT/xsl:when +xsl:when test=$field008-24-27='c'CTLG/xsl:when + +!-- Default to BOOK -- +xsl:otherwiseBOOK/xsl:otherwise +/xsl:choose +/xsl:otherwise +/xsl:choose +/xsl:when + +xsl:when test=$leader6='e' or $leader6='f'MAP/xsl:when +xsl:when test=$leader6='i' or $leader6='j'SOUND/xsl:when +xsl:when test=$leader6='c' or $leader6='d'MUSIC/xsl:when + +xsl:when test=$leader6='g' +xsl:variable name=field008-33 select=substring($field008,34,1)/ +xsl:choose +xsl:when test=$field008-33='m' or $field008-33='f'MPCT/xsl:when +xsl:when test=$field008-33='v'VIDEO/xsl:when +xsl:when test=$field008-33
Re: [OPEN-ILS-DEV] Export to RefWorks in Evergreen
On Fri, Jun 19, 2009 at 5:28 PM, Mike Rylander mrylan...@gmail.com wrote: Now ... it's committed. Thanks a ton, Warren. Very nice work. I'm not going to backport this from trunk to 1.6 just yet so we can have some discussion on the ability to turn it on or off, and what the default should be. Thanks for including it -- and thanks for keeping it in trunk only. As you and David Fiander have noted, it probably needs a bit more thought to make sure that it will work for other types of RefWorks users. One possible option would be to include the SuperCat feed in 1.6 (if the feed is deemed stable, of course) but leave out the changes to rdetail.js and page_rdetail.xml until a good solution is found for the default settings. Thanks again! Warren
Re: [OPEN-ILS-DEV] Export to RefWorks in Evergreen
On Wed, Jun 17, 2009 at 11:50 PM, Mike Rylander mrylan...@gmail.com wrote:
Hrm ... is the purpose of VENDOR to tell RefWorks what sort of
system the data is coming from, or to tell them which of their clients
is using the service?
I believe it's the latter (for instance, see the link to RefWorks at
http://mirlyn2-beta.lib.umich.edu/Record/001376273 ).
I've attached a slightly modified patch that doesn't append +Evergreen to
VENDOR and just uses the org's fullname (with spaces replaced with '+'
chars). That is likely more appropriate, at least from RefWorks' point of
view.
Cheers,
Warren
Index: Open-ILS/web/opac/skin/default/js/rdetail.js
===
--- Open-ILS/web/opac/skin/default/js/rdetail.js (revision 13399)
+++ Open-ILS/web/opac/skin/default/js/rdetail.js (working copy)
@@ -368,6 +368,21 @@
$('rdetail_place_hold').setAttribute(
'href','javascript:holdsDrawEditor({record:'+record.doc_id()+',type:T});');
+var here = (findOrgUnit(getLocation())).name();
+var org_name = here.replace( , +);
+var cgi = new CGI();
+
+ $('rdetail_exp_refworks').setAttribute(
+'href',
+'http://www.refworks.com/express/expressimport.asp?vendor='
++org_name
++'filter=MARC+Formatdatabase=All+MARC+Formatsencoding=65001url=http%3A%2F%2F'
++cgi.server_name+'/opac/extras/supercat/marctxt/record/'
++record.doc_id());
+
+ $('rdetail_exp_refworks').setAttribute(
+'target', 'RefWorksMain');
+
$('rdetail_img_link').setAttribute('href', buildISBNSrc(cleanISBN(record.isbn()), 'large'));
G.ui.rdetail.image.setAttribute(src, buildISBNSrc(cleanISBN(record.isbn(;
runEvt(rdetail, recordDrawn);
Re: [OPEN-ILS-DEV] Export to RefWorks in Evergreen
On Tue, Jun 16, 2009 at 11:18 PM, Warren Layton warren.lay...@gmail.comwrote:
Also, I'm including a sample patch against the 1.4 OPAC
(refworks_opac_1_4.diff), and is only provided as a demonstration of
how this feature could be enabled (for instance, the VENDOR and
HOSTNAME tags in the callback URL need to be replaced with proper
values for each specific site). See [1] and [2] for more
info.http://www.refworks.com/DirectExport.htm#DECallback
Hello again,
Attached is a patch against trunk that automatically generates the VENDOR
and HOSTNAME for the RefWorks link.
Essentially, VENDOR is set to the library's shortname, and HOSTNAME is
taken from a CGI object's cgi.server_name attribute. If there's a better way
to get these two bits of information, please let me know!
Cheers,
Warren
Index: Open-ILS/web/opac/skin/default/js/rdetail.js
===
--- Open-ILS/web/opac/skin/default/js/rdetail.js (revision 13399)
+++ Open-ILS/web/opac/skin/default/js/rdetail.js (working copy)
@@ -368,6 +368,20 @@
$('rdetail_place_hold').setAttribute(
'href','javascript:holdsDrawEditor({record:'+record.doc_id()+',type:T});');
+var here = findOrgUnit(getLocation());
+var cgi = new CGI();
+
+ $('rdetail_exp_refworks').setAttribute(
+'href',
+'http://www.refworks.com/express/expressimport.asp?vendor='
++here.shortname()
++'+Evergreenfilter=MARC+Formatdatabase=All+MARC+Formatsencoding=65001url=http%3A%2F%2F'
++cgi.server_name+'/opac/extras/supercat/marctxt/record/'
++record.doc_id());
+
+ $('rdetail_exp_refworks').setAttribute(
+'target', 'RefWorksMain');
+
$('rdetail_img_link').setAttribute('href', buildISBNSrc(cleanISBN(record.isbn()), 'large'));
G.ui.rdetail.image.setAttribute(src, buildISBNSrc(cleanISBN(record.isbn(;
runEvt(rdetail, recordDrawn);
Re: [OPEN-ILS-DEV] [patch] Selecting many Z39.50 targets
On Thu, Jun 11, 2009 at 10:10 PM, Jason Etheridgeja...@esilibrary.com wrote: Warren, I like this, thanks! Grant and I were experimenting with scrollbars, hiding the information altogether, etc., but I think this strikes a good balance of less clutter versus useful information. I tweaked things a bit so that the per-service summaries still exist, but as a tooltip Ah, great idea! I felt kind of bad taking the information about the services out. A tooltip seems like the best approach. Cheers, Warren
[OPEN-ILS-DEV] Display 856 $z in OPAC (1-line patch)
Hello all,
We have some records with MARC 856 fields with $z subfields.
Currently, it appears that Evergreen's OPAC should display $z
following the link in the Online Resources row of rdetail but the
information is not displayed. The attached 1-line patch fixes the
problem.
Cheers,
Warren Layton
NRCan Library
Index: trunk/Open-ILS/web/opac/skin/default/js/rdetail.js
===
--- trunk/Open-ILS/web/opac/skin/default/js/rdetail.js (revision 13256)
+++ trunk/Open-ILS/web/opac/skin/default/js/rdetail.js (working copy)
@@ -340,7 +340,7 @@
}
}
$('rdetail_online').appendChild(elem('a', {href:href,'class':'classic_link'}, displayLabel));
- if (!note note != displayLabel) {
+ if (note note != displayLabel) {
$('rdetail_online').appendChild(elem('span', {'class':'url_note'}, ' - ' + note));
}
$('rdetail_online').appendChild(elem('br'));
Re: [OPEN-ILS-DEV] Z39.50 Server off by one
On Fri, May 15, 2009 at 10:38 AM, Dan Scott deni...@gmail.com wrote: I'm happy to say that this patch solved our off-by-one problem quite nicely. And I'm honestly happy to just have a working Z39.50 server, with the ability to scope searches by org_unit and surface holdings in a way that makes VDX happy, without worrying too much about whether the cause of the off-by-one lies in the Evergreen code or the Simple2ZOOM code. I'm now pretty sure that the problem is Simple2Zoom. So it looks like this patch fixes the cause, and not just the symptom. We should update the SRU/Z39.50 section of the wiki to reflect the status of the server, it has come a long way in the last month! I added a few notes today on the DokuWiki and updated the sample dgo.conf included in the same page (while I mostly stole from you - thanks!). Cheers, Warren
[OPEN-ILS-DEV] Z39.50 Server off by one
I've managed to set up Evergreen as a Z39.50 server using Simple2Zoom. However, I noticed that when I would find N results, I could only retrieve N-1 of those results. It sounds like others may be having this problem. I poked around a bit in Simple2Zoom and made a quick 1-line fix (attached). It seems to have solved this issue for me on my simple Evergreen setup but I haven't tested it very much yet. I was wondering if anyone had narrowed this problem down to being an Evergreen issue or a Simple2Zoom issue. If it's a Simple2Zoom issue, then this patch might be helpful. Cheers, Warren simple2zoom_patch.diff.gz Description: GNU Zip compressed data
[OPEN-ILS-DEV] Holdings and Holds in SVN trunk
I know SVN trunk is a moving target but I've been having the same two problems over the past few days: Problem 1: I can install Evergreen and then update the structure of my demo Consortium with Conify. I then log out of the staff client, re-run /openils/bin/autogen.sh -c /openils/conf/opensrf_core.xml -u (and even osrf_ctl.sh -l -a restart_all) After doing so, I import a bib record without trouble. However, when I go into Holdings Maintenance, I get a pop-up error, the drop-down list to select the system/branch/sub-library is missing, and the pane below it (usually containing an expandable org tree). Even if I re-run autogen.sh, osrf_ctl.sh to restart the services, and rm -rf ~/.openils. Oddly, when I reboot my system, the problem is resolved and I can go in and add volumes/copies. Is there a less drastic step than rebooting that I could perform? Say, a cache file of the org structure that I could delete? Problem 2: I can't place holds on items, neither as the admin user in the staff client, nor as a regular patron in the OPAC. I always get a message saying that the item isn't available for hold when I know it should be. Cheers, Warren
[OPEN-ILS-DEV] Evergreen Driver for VuFind
(I just sent the following message to the vufind-tech list, but thought I'd also post it here.) At NRCan, we're looking at the possibility of using VuFind with Evergreen. Towards that end, I have taken a first stab at an Evergreen driver. It is not yet complete - getMyFines, getMyHolds, and placeHold are the major functions that are still need to be implemented (another patch adding these will be submitted ASAP). However, most of the other functions that apply to Evergreen work (holdings/status info is displayed when viewing a record, users can view the items they have checked out, and their personal data from the ILS). I'm also including a patch for web/sys/User.php which adds an ILS login function, which I have been using to login to VuFind using my Evergreen login/password. This new function can be used by setting [Authentication][method] in web/conf/config.ini to ILS. Currently, it's very specific to Evergreen and may need to be generalized if it is going to be used with other ILSs. These patches are against the SVN repository but have also been tested with 1.0-RC1. Let me know if there's anything that should be changed or fixed. Cheers, Warren Layton, NRCan vufind_eg.diff.gz Description: GNU Zip compressed data vufind_sys_user.diff.gz Description: GNU Zip compressed data
[OPEN-ILS-DEV] New fr-CA translations
Attached is a patch (from svn/ILS/trunk) for the new Evergreen fr-CA translation strings. Most files are now complete although there are a handful of strings for which I'll need to consult a proper translator. Warren (on behalf of NRCan) 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: Warren Layton [EMAIL PROTECTED] eg_fr-CA.diff.gz Description: GNU Zip compressed data
Re: [OPEN-ILS-DEV] Issues with direct_ingest.pl
On Mon, Nov 17, 2008 at 9:46 PM, Warren Layton [EMAIL PROTECTED] wrote: What I suspect is happening is that direct_ingest.pl rejects records that have an accented character between square brackets ([ and ]) in a field. For example, a record with the following 260 subfield will be rejected: subfield code=\b\[Bibliothe#x300;que nationale du Canada],/subfield However, if I remove _either_ the square brackets _or_ the #x300;, the record will be successfully processed. Just a quick follow-up to this problem. It also occurs in two other scenarios: 1) The openening and closing square brackets can be spread over multiple subfields. 2) The problem also occurs if the accented character/diacritic is placedbetween two escaped double-quotes (\). For example, a record containing the following subfield will produce the same error: subfield code=\b\\Syste#x300;mes solaires\, /subfield I have traced the execution of the script through /openils/lib/perl5/OpenILS/Application/Ingest.pm and the script is dying in sub biblio_fingerprint (API name: open-ils.ingest.fingerprint.xml). Specifically, biblio_fingerprint.js seems to be where the problem is occurring. I'm suspecting that some regular expression is getting tripped up somewhere. Cheers, Warren
[OPEN-ILS-DEV] Issues with direct_ingest.pl
I recently imported nearly 300,000 Unicorn records into Evergreen, many with accented characters (we have a lot of French and bilingual English-French material). However, 17 records got rejected by direct_ingest.pl. A handful of these rejects are our fault. However, I think I'm hitting some sort of corner case for most of the others. What I suspect is happening is that direct_ingest.pl rejects records that have an accented character between square brackets ([ and ]) in a field. For example, a record with the following 260 subfield will be rejected: subfield code=\b\[Bibliothe#x300;que nationale du Canada],/subfield However, if I remove _either_ the square brackets _or_ the #x300;, the record will be successfully processed. My first guess was that the square brackets ([ and ]) would need to be escaped for JSON but since all of these tags are in a string, the only character that needs to be escaped are double-quotes (). I should also note that other records with accented characters (e.g., e#x300;) and/or square brackets were processed just fine, but I think those with accented characters _between_ square brackets, as above, are all in the reject pile (not 100% sure, but I'll be verifying this ASAP). I'm attaching a single problem record that's already been passed through marc2bre.pl in case anyone wants to try reproducing the problem. Field 260, subfield b contains the problem. I can provide others if necessary. I'll continue debugging but I would appreciate any insights! Cheers, Warren eg_sample.bre.gz Description: GNU Zip compressed data
Re: [OPEN-ILS-DEV] Two minor issues to report
On Fri, Nov 7, 2008 at 6:34 AM, Dan Scott [EMAIL PROTECTED] wrote: 2008/11/6 Warren Layton [EMAIL PROTECTED]: * Under Advanced Search, the MARC Expert Search doesn't return any results, even when I know it should. For example, I have some records that contain the value B in field 991, subfield a. However, no records are returned when I perform a MARC Expert Search with these terms. MARC Expert Search in the OPAC only returns results for records that have copies attached - transcendant records are not retrieved. You can see the OpenSRF method that is called in the gateway log: open-ils.search.biblio.marc MARC Expert Search in the staff client returns results for all records, whether there are copies attached or not. You can see that a different OpenSRF method is called in the gateway log: open-ils.search.biblio.marc.staff I suspect this explains what you're seeing. Try attaching a copy to one of those records, and you should be able to use the MARC Expert Search to retrieve it. Thanks Dan! I think that's exactly what happened. I had previously added some copies but I blew my data away and re-imported (without adding copies) when I moved to trunk. Cheers, Warren * I have imported a number of MARC bib records. I never thought to look into the top-level SQL file (in my case, iii_full.sql, which pulls in iii_full.*.sql). It was brought to my attention that the final line, COMMIT, is commented out and that, without removing the -- at the beginning of the line, the data should not be successfully imported because it would be rolled back. However, even with this line commented out, my bib data gets imported without any problems. Is anyone else able to do this, or do I just have spectacular computer karma? I haven't done an import for a while now; are there any other COMMIT statements that have been introduced into the set of SQL statements generated by parallel_pg_loader.pl? Both systems are running Ubuntu 8.04 LTS. We are running 1.4rc1 on Ubuntu Server at work and I'm running SVN trunk on Ubuntu Desktop. -- Dan Scott Laurentian University
[OPEN-ILS-DEV] Two minor issues to report
Hello all, I have been running both Evergreen 1.4rc1 and the trunk build from the Subversion repository. There are two issues that I have run into on each build. I know that I have discussed these previously on the IRC channel but I thought I'd post them here, too. * Under Advanced Search, the MARC Expert Search doesn't return any results, even when I know it should. For example, I have some records that contain the value B in field 991, subfield a. However, no records are returned when I perform a MARC Expert Search with these terms. * I have imported a number of MARC bib records. I never thought to look into the top-level SQL file (in my case, iii_full.sql, which pulls in iii_full.*.sql). It was brought to my attention that the final line, COMMIT, is commented out and that, without removing the -- at the beginning of the line, the data should not be successfully imported because it would be rolled back. However, even with this line commented out, my bib data gets imported without any problems. Is anyone else able to do this, or do I just have spectacular computer karma? Both systems are running Ubuntu 8.04 LTS. We are running 1.4rc1 on Ubuntu Server at work and I'm running SVN trunk on Ubuntu Desktop. Cheers, Warren
[OPEN-ILS-DEV] Installing 1.4RC1 on Ubuntu 8.04 Server
I recently installed Evergreen 1.4 RC1 on a fresh install of Ubuntu 8.04 Server. Following the instructions on the DokuWiki[1], I ran into two minor issues: 1) Running the Makefile.install attempts to install syslog-ng. This itself isn't a problem but it causes the package manager to warn the user that syslogd, ksyslogd and ubuntu-minimal will be uninstalled, which the package manager doesn't seem to like. I did and apt-get install syslog-ng before running the Makefile.install and it made things a bit less confusing. (I don't think this is specific to Ubuntu Server - I seem to remember the same thing happening when I installed on Desktop). 2) After attempting to compile Evergreen in step 5, the configure script failed because it couldn't find the libdbi libraries and installed by the Makefile.install, including the associated pgsql driver (Step 5(I)). The solution was to skip ahead to Step 20 and add the /etc/ld.so.conf/eg.conf file and run ldconfig before doing the configure; make; make install commands in Step 5 (thanks to the friendly people on the Evergreen IRC channel for their help!). This certainly wasn't an issue when I had previously installed Evergreen on Ubuntu 8.04 desktop. With these two changes to the install procedure, everything was up and running in record time. If these two changes are sane, I'd be happy to update the instructions on the DokuWiki. Cheers, Warren [1]: 1.4 RC1 Installation Instructions on the DokuWiki: http://evergreen-ils.org/dokuwiki/doku.php?id=server:1.4.0.0:ubuntu804:install
[OPEN-ILS-DEV] 1.4RC1 - DB passwords in opensrf.xml
When installing 1.4 RC1, I noticed that the opensrf.xml file is automatically populated with my DB settings! However, I did hit one minor bug. If a DB password contains a '' character, the DB password in the XML should have each '' replaced by amp;. Currently, it's replaced with \amp;, which will cause problems (settings-tester.pl gives some good hints about the cause). This caused problems with /openils/bin/autogen and the srfsh login. I went through an manually removed the offending '\' chars and now things seems to work. Cheers, Warren
[OPEN-ILS-DEV] Re: 1.4RC1 - DB passwords in opensrf.xml
Oops - please ignore. This was my own fault. In step 6 of the install instructions, I put my password in double-quotes _and_ escaped the '' char with a backslash; only the latter was necessary). Cheers, Warren On Tue, Oct 21, 2008 at 9:39 PM, Warren Layton [EMAIL PROTECTED] wrote: When installing 1.4 RC1, I noticed that the opensrf.xml file is automatically populated with my DB settings! However, I did hit one minor bug. If a DB password contains a '' character, the DB password in the XML should have each '' replaced by amp;. Currently, it's replaced with \amp;, which will cause problems (settings-tester.pl gives some good hints about the cause). This caused problems with /openils/bin/autogen and the srfsh login. I went through an manually removed the offending '\' chars and now things seems to work. Cheers, Warren
Re: [OPEN-ILS-DEV] Help regarding srfsh
On Thu, Sep 25, 2008 at 9:55 AM, Dan Scott [EMAIL PROTECTED] wrote: 2008/9/25 Warren Layton [EMAIL PROTECTED]: That's odd. I seem to recall having problems doing a login admin open-ils from srfsh until I removed --enable-libdbi from the Makefile.install (I would just get a ???). I was sure it was this that was causing the problem but perhaps I had fixed something else. I'll try to reproduce it tonight. When I run the packaged version of settings-tester.pl, it complains about the lack of linking to libdbi, but login admin open-ils works perfectly. I stand corrected. I can log in regardless of what settings-tester.pl says about libdbi-drivers. Cheers, Warren
