From Katrin.Fischer.83 at web.de Wed Jul 2 08:16:12 2014 From: Katrin.Fischer.83 at web.de (Katrin Fischer) Date: Wed, 02 Jul 2014 08:16:12 +0200 Subject: [Koha-devel] Reminder: Koha Developer IRC Meeting - July 2nd, 15:00 and 22:00 UTC Message-ID: <53B3A3AC.1040107@web.de> Hi all, Just a quick reminder that the Koha Developer IRC Meeting is on July 2nd at 15:00 and 22:00 UTC: http://wiki.koha-community.org/wiki/Development_IRC_meeting,_2_July_2014 See you there, Katrin From kyle.m.hall at gmail.com Wed Jul 2 20:39:04 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 2 Jul 2014 14:39:04 -0400 Subject: [Koha-devel] Replacement of C4::SQLHelper by DBIx::Class In-Reply-To: <53B16407.6010607@biblibre.com> References: <53B16407.6010607@biblibre.com> Message-ID: So far I think the patches are excellent. The use of DBIx::Class::ResultClass::HashRefInflator is a great way to move to using DBIx::Class in our modules without the need to rework all the calling code to make use of dbic objects. For long term goals I see the following steps leading us to the most efficient use of dbic: 1) Replace all DBI deletes with DBIC 2) Replace all DBI updates with DBIC 3) Replace all DBI selects with DBIC using HashRefInflator 4) Eliminate simple module subs that do CRUD, switch to using DBIC from scripts 5) Move logic out of our perl modules and into our Result classes, and create custom ResultSet classes for operations affecting multiple rows This course of action will lead to much more DRY code, and mean fewer bugs in the long run. Mandatory unit tests are also a given. In summary, keep up the good work Yohann! Feel free to contact me personally for any assistance I may provide you! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Mon, Jun 30, 2014 at 9:20 AM, Yohann Dufour wrote: > Hi, > > I'm currently replacing C4::SQLHelper by DBIx::Class in order to remove > the module C4::SQLHelper from Koha (see bug 11385 > ). > I've already posted two patchs with this in mind : bug 12482 > and bug > 12487 . > Before continuing, I would like to have a feedback from the community on > the method I used to do that. > > Thank's for your responses, > > Yohann > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Jul 2 20:41:16 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 2 Jul 2014 15:41:16 -0300 Subject: [Koha-devel] Replacement of C4::SQLHelper by DBIx::Class In-Reply-To: References: <53B16407.6010607@biblibre.com> Message-ID: +1000! On Wed, Jul 2, 2014 at 3:39 PM, Kyle Hall wrote: > So far I think the patches are excellent. The use of > DBIx::Class::ResultClass::HashRefInflator is a great way to move to using > DBIx::Class in our modules without the need to rework all the calling code > to make use of dbic objects. > > For long term goals I see the following steps leading us to the most > efficient use of dbic: > 1) Replace all DBI deletes with DBIC > 2) Replace all DBI updates with DBIC > 3) Replace all DBI selects with DBIC using HashRefInflator > 4) Eliminate simple module subs that do CRUD, switch to using DBIC from > scripts > 5) Move logic out of our perl modules and into our Result classes, and > create custom ResultSet classes for operations affecting multiple rows > > This course of action will lead to much more DRY code, and mean fewer bugs > in the long run. Mandatory unit tests are also a given. > > In summary, keep up the good work Yohann! Feel free to contact me > personally for any assistance I may provide you! > > Kyle > > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Mill Run Technology Solutions ( http://millruntech.com ) > > > On Mon, Jun 30, 2014 at 9:20 AM, Yohann Dufour > wrote: > >> Hi, >> >> I'm currently replacing C4::SQLHelper by DBIx::Class in order to remove >> the module C4::SQLHelper from Koha (see bug 11385 >> ). >> I've already posted two patchs with this in mind : bug 12482 >> and bug >> 12487 . >> Before continuing, I would like to have a feedback from the community on >> the method I used to do that. >> >> Thank's for your responses, >> >> Yohann >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuannguyen at icsc.vn Thu Jul 3 05:36:50 2014 From: tuannguyen at icsc.vn (Nguyen Anh Tuan) Date: Thu, 3 Jul 2014 10:36:50 +0700 Subject: [Koha-devel] Koha development environment setup Message-ID: Hi all, I don't know how to setup koha development environment to customize koha. Now I install koha on my ubuntu server. I just read doc in koha wiki but still understand clearly, please help me guide more clear. Thanks you! -- Nguyen Anh Tuan ? hp: +84 168-545-0338 ? email: tuannguyen at icsc.vn ______________________________ __ *ICSC CORPORATION* Hall 6A, Quang Trung Software City, District 12, HCMC, Vietnam Phone: +84 8 37 15 07 81 Fax: +84 8 37 15 07 80 Website: www.icsc.vn - www.openerpviet.com ------------------------------ This e-mail and attachments (if any) is intended only for the addressee(s) and is subject to copyright. This e-mail contains information which may be confidential or privileged. If you are not the intended recipient please advise the sender by return e-mail, do not use or disclose the contents and delete the message and any attachments from your system. Unless specifically stated, this e-mail does not constitute formal advice or commitment by the sender or ICSC or any of its subsidiaries. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lan.vu at dlcorp.com.vn Thu Jul 3 07:19:31 2014 From: lan.vu at dlcorp.com.vn (Lan Vu Duy) Date: Thu, 3 Jul 2014 12:19:31 +0700 Subject: [Koha-devel] Koha development environment setup In-Reply-To: References: Message-ID: Dear Anh Tuan, It's Vu Duy Lan from D&L Technology Integration and Consulting JSC ( www.dlcorp.com.vn, www.koha.vn) We have been doing Koha development and supporting Koha in Vietnam. Recently we have uploaded full Vietnamese translation for Koha 3.12 http://translate.koha-community.org/vi/312/ We would be happy to help you to go through the process and I will contact you directly for support. Thank you for your interest in Koha. Best regards, Vu Duy Lan 2014-07-03 10:36 GMT+07:00 Nguyen Anh Tuan : > Hi all, > > I don't know how to setup koha development environment to customize koha. > Now I install koha on my ubuntu server. > > I just read doc in koha wiki but still understand clearly, please help me > guide more clear. > > Thanks you! > > -- > Nguyen Anh Tuan > ? hp: +84 168-545-0338 ? email: tuannguyen at icsc.vn > ______________________________ > __ > *ICSC CORPORATION* > > Hall 6A, Quang Trung Software City, District 12, HCMC, Vietnam > Phone: +84 8 37 15 07 81 > Fax: +84 8 37 15 07 80 > Website: www.icsc.vn - www.openerpviet.com > > ------------------------------ > This e-mail and attachments (if any) is intended only for the addressee(s) > and is subject to copyright. This e-mail contains information which may be > confidential or privileged. If you are not the intended recipient please > advise the sender by return e-mail, do not use or disclose the contents and > delete the message and any attachments from your system. Unless > specifically stated, this e-mail does not constitute formal advice or > commitment by the sender or ICSC or any of its subsidiaries. > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Thu Jul 3 20:50:04 2014 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 3 Jul 2014 14:50:04 -0400 Subject: [Koha-devel] Removal of prog and CCSR themes: Help requested Message-ID: As I said in the developers meeting yesterday I have started to submit patches for the removal of prog and CCSR themes from the OPAC, starting with patches to remove system preferences specific to those themes. A patch to remove the theme files themselves is easily done, but then we're left with odds and ends in the code which I could use help tracking down. A search for references to "prog" in the code turns up several instances where the existence of prog is assumed or considered to be the default. Could I get one or more volunteers to look into that side of things? Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From tomascohen at gmail.com Thu Jul 3 20:56:03 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 3 Jul 2014 15:56:03 -0300 Subject: [Koha-devel] Removal of prog and CCSR themes: Help requested In-Reply-To: References: Message-ID: Count on me. On Thu, Jul 3, 2014 at 3:50 PM, Owen Leonard wrote: > As I said in the developers meeting yesterday I have started to submit > patches for the removal of prog and CCSR themes from the OPAC, > starting with patches to remove system preferences specific to those > themes. > > A patch to remove the theme files themselves is easily done, but then > we're left with odds and ends in the code which I could use help > tracking down. A search for references to "prog" in the code turns up > several instances where the existence of prog is assumed or considered > to be the default. > > Could I get one or more volunteers to look into that side of things? > > Thanks, > > Owen > > -- > Web Developer > Athens County Public Libraries > http://www.myacpl.org > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Fri Jul 4 01:52:37 2014 From: kohanews at gmail.com (Koha News) Date: Thu, 03 Jul 2014 16:52:37 -0700 Subject: [Koha-devel] Koha Community Newsletter: June 2014 Message-ID: <53B5ECC5.2040106@gmail.com> Fellow Koha users: The Koha Community Newsletter for May 2014 is here: http://koha-community.org/koha-community-newsletter-june-2014/ Many thanks to all the folks who submitted articles and news to this month's newsletter. Please feel free to email us with any corrections or suggestions. Thanks! Chad Roseburg Joanne Dillon Editors, Koha Community Newsletter From tomascohen at gmail.com Fri Jul 4 20:16:15 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 4 Jul 2014 15:16:15 -0300 Subject: [Koha-devel] Advise on DBIx Message-ID: Hi, I'm trying to write some code using our Koha::Schema::Result::* classes. The sample i picked was the most unfortunate: I want to pull data from Deletedbiblio and Deletedbibliotems which don't have a relation defined. The relevant bits of the code look like: my $resultset = $schema->resultset( 'Deletedbiblio' )->search( { Deletedbiblio.biblionumber => $biblionumber }, { join => [ qw/ Deletedbiblioitems Itemtypes / ] } ); it dies because "No such relationship Deletedbiblioitem on Deletedbiblio". How shuold we cope with that situation? (I understand introducing a relationship would mean a lot of trouble as the tables are intended for deleted / not hard-linked data). Any ideas? Plain SQL? Regards To+ P.S. Happy independence day for those that apply :-D -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Fri Jul 4 21:14:02 2014 From: gmc at esilibrary.com (Galen Charlton) Date: Fri, 4 Jul 2014 12:14:02 -0700 Subject: [Koha-devel] Advise on DBIx In-Reply-To: References: Message-ID: Hi On Fri, Jul 4, 2014 at 11:16 AM, Tomas Cohen Arazi wrote: > it dies because "No such relationship Deletedbiblioitem on Deletedbiblio". > How shuold we cope with that situation? (I understand introducing a > relationship would mean a lot of trouble as the tables are intended for > deleted / not hard-linked data). > > Any ideas? Plain SQL? Briefly, you can declare the relationship relationships in the DBIC class without there having to be a corresponding FK in the underlying SQL. That said, if this query is something that would be used frequently, adding a FK relationship would be fine, or at least an index. > P.S. Happy independence day for those that apply :-D Thanks! Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From kyle.m.hall at gmail.com Sun Jul 6 19:48:45 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Sun, 6 Jul 2014 13:48:45 -0400 Subject: [Koha-devel] Removal of prog and CCSR themes: Help requested In-Reply-To: References: Message-ID: I'll keep an eye out while digging though the code and submit patches for anything I catch! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Thu, Jul 3, 2014 at 2:56 PM, Tomas Cohen Arazi wrote: > Count on me. > > > On Thu, Jul 3, 2014 at 3:50 PM, Owen Leonard wrote: > >> As I said in the developers meeting yesterday I have started to submit >> patches for the removal of prog and CCSR themes from the OPAC, >> starting with patches to remove system preferences specific to those >> themes. >> >> A patch to remove the theme files themselves is easily done, but then >> we're left with odds and ends in the code which I could use help >> tracking down. A search for references to "prog" in the code turns up >> several instances where the existence of prog is assumed or considered >> to be the default. >> >> Could I get one or more volunteers to look into that side of things? >> >> Thanks, >> >> Owen >> >> -- >> Web Developer >> Athens County Public Libraries >> http://www.myacpl.org >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > > -- > Tom?s Cohen Arazi > Prosecretar?a de Inform?tica > Universidad Nacional de C?rdoba > ? +54 351 5353750 ext 13168 > GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yohann.dufour at biblibre.com Mon Jul 7 15:23:59 2014 From: yohann.dufour at biblibre.com (Yohann Dufour) Date: Mon, 07 Jul 2014 15:23:59 +0200 Subject: [Koha-devel] Replacement of C4::SQLHelper by DBIx::Class In-Reply-To: References: <53B16407.6010607@biblibre.com> Message-ID: <53BA9F6F.2010004@biblibre.com> Yes, I think the use of DBIx::Class::ResultClass::HashRefInflator is a good way for a smooth transition to DBIx::Class. However, my current working concerns only the replacement of the module SQLHelper by DBIx::Class, so I don't know if I could help the community to update all the koha code with DBIx::Class ... But, If I have some question about DBIx::Class, I wouldn't hesitate to ask you some help. Yohann Le 02/07/2014 20:39, Kyle Hall a ?crit : > So far I think the patches are excellent. The use of > DBIx::Class::ResultClass::HashRefInflator is a great way to move to > using DBIx::Class in our modules without the need to rework all the > calling code to make use of dbic objects. > > For long term goals I see the following steps leading us to the most > efficient use of dbic: > 1) Replace all DBI deletes with DBIC > 2) Replace all DBI updates with DBIC > 3) Replace all DBI selects with DBIC using HashRefInflator > 4) Eliminate simple module subs that do CRUD, switch to using DBIC > from scripts > 5) Move logic out of our perl modules and into our Result classes, and > create custom ResultSet classes for operations affecting multiple rows > > This course of action will lead to much more DRY code, and mean fewer > bugs in the long run. Mandatory unit tests are also a given. > > In summary, keep up the good work Yohann! Feel free to contact me > personally for any assistance I may provide you! > > Kyle > > http://www.kylehall.info > ByWater Solutions ( http://bywatersolutions.com ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Mill Run Technology Solutions ( http://millruntech.com ) > > > On Mon, Jun 30, 2014 at 9:20 AM, Yohann Dufour > > wrote: > > Hi, > > I'm currently replacing C4::SQLHelper by DBIx::Class in order to > remove the module C4::SQLHelper from Koha (see bug 11385 > ). > I've already posted two patchs with this in mind : bug 12482 > > and bug 12487 > . > Before continuing, I would like to have a feedback from the > community on the method I used to do that. > > Thank's for your responses, > > Yohann > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From yohann.dufour at biblibre.com Mon Jul 7 16:10:40 2014 From: yohann.dufour at biblibre.com (Yohann Dufour) Date: Mon, 07 Jul 2014 16:10:40 +0200 Subject: [Koha-devel] The schema of DBIx::Class is not up-to-date Message-ID: <53BAAA60.9070402@biblibre.com> Good afternoon, As you know, I'm working on DBIx::Class, and I realized that the DBIx::Class schema (in Koha/Schema/) is not up-to-date with the current database structure (installer/data/mysql/kohastructure.sql) which is really used by the modules. The last update of the DBIx::Class schema was the 2013-10-14, and some changes has been done since this day. Thus, it is problematic to use DBIx::Class if some differences exist. What do you think about updating the DBIx::Class in order to link it with the current database schema and trying to find a way to update automatically the DBIx::Class schema at each change in the database structure. I joined with this email the list of the differences between the DBIx::Class schema and the current database schema. Yohann -------------- section suivante -------------- diff -r /home/yohann/koha/Koha/Schema/Result/Accountline.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Accountline.pm < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/Aqbasket.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Aqbasket.pm < on_delete => "CASCADE", > on_delete => "RESTRICT", < { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" }, > { is_deferrable => 1, on_delete => "RESTRICT", on_update => "CASCADE" }, < on_delete => "CASCADE", > on_delete => "SET NULL", < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "RESTRICT", > on_update => "RESTRICT", diff -r /home/yohann/koha/Koha/Schema/Result/Aqinvoice.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Aqinvoice.pm < on_delete => "CASCADE", > on_delete => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/Aqorder.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Aqorder.pm < on_delete => "CASCADE", > on_delete => "SET NULL", < on_delete => "CASCADE", > on_delete => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/AqordersTransfer.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/AqordersTransfer.pm < on_delete => "CASCADE", > on_delete => "SET NULL", < on_delete => "CASCADE", > on_delete => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/AuthorisedValuesBranch.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/AuthorisedValuesBranch.pm < on_update => "CASCADE", > on_update => "RESTRICT", < on_update => "CASCADE", > on_update => "RESTRICT", diff -r /home/yohann/koha/Koha/Schema/Result/Biblio.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Biblio.pm < __PACKAGE__->belongs_to( < "biblioitem", < "Koha::Schema::Result::Biblioitem", < { "foreign.biblionumber" => "self.biblionumber" } < ); diff -r /home/yohann/koha/Koha/Schema/Result/BorrowerAttributeTypesBranch.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/BorrowerAttributeTypesBranch.pm < on_update => "CASCADE", > on_update => "RESTRICT", < on_update => "CASCADE", > on_update => "RESTRICT", diff -r /home/yohann/koha/Koha/Schema/Result/Borrower.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Borrower.pm < { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" }, > { is_deferrable => 1, on_delete => "RESTRICT", on_update => "RESTRICT" }, < { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" }, > { is_deferrable => 1, on_delete => "RESTRICT", on_update => "RESTRICT" }, diff -r /home/yohann/koha/Koha/Schema/Result/CategoriesBranch.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/CategoriesBranch.pm < on_update => "CASCADE", > on_update => "RESTRICT", < on_update => "CASCADE", > on_update => "RESTRICT", diff -r /home/yohann/koha/Koha/Schema/Result/ClassSource.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/ClassSource.pm < { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" }, > { is_deferrable => 1, on_delete => "RESTRICT", on_update => "RESTRICT" }, diff -r /home/yohann/koha/Koha/Schema/Result/CourseInstructor.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/CourseInstructor.pm < { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" }, > { is_deferrable => 1, on_delete => "RESTRICT", on_update => "RESTRICT" }, diff -r /home/yohann/koha/Koha/Schema/Result/CourseReserve.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/CourseReserve.pm < { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" }, > { is_deferrable => 1, on_delete => "RESTRICT", on_update => "RESTRICT" }, diff -r /home/yohann/koha/Koha/Schema/Result/CreatorBatch.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/CreatorBatch.pm < { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" }, > { is_deferrable => 1, on_delete => "CASCADE", on_update => "RESTRICT" }, < on_update => "CASCADE", > on_update => "RESTRICT", diff -r /home/yohann/koha/Koha/Schema/Result/ImportRecord.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/ImportRecord.pm < =head2 import_records_matches > =head2 import_record_matches < Related object: L > Related object: L < "import_records_matches", < "Koha::Schema::Result::ImportRecordMatches", > "import_record_matches", > "Koha::Schema::Result::ImportRecordMatch", diff -r /home/yohann/koha/Koha/Schema/Result/Issue.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Issue.pm < on_delete => "CASCADE", > on_delete => "RESTRICT", < on_delete => "CASCADE", > on_delete => "RESTRICT", < __PACKAGE__->belongs_to( < "borrower", < "Koha::Schema::Result::Borrower", < { borrowernumber => "borrowernumber" }, < { join_type => "LEFT", on_delete => "CASCADE", on_update => "CASCADE" }, < ); < < __PACKAGE__->belongs_to( < "item", < "Koha::Schema::Result::Item", < { itemnumber => "itemnumber" }, < { < is_deferrable => 1, < join_type => "LEFT", < on_delete => "CASCADE", < on_update => "CASCADE", < }, < ); < < __PACKAGE__->belongs_to( < "branch", < "Koha::Schema::Result::Branch", < { branchcode => "branchcode" }, < { < is_deferrable => 1, < join_type => "LEFT", < on_delete => "CASCADE", < on_update => "CASCADE", < }, < ); diff -r /home/yohann/koha/Koha/Schema/Result/Item.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Item.pm < on_delete => "CASCADE", > on_delete => "RESTRICT", < on_delete => "CASCADE", > on_delete => "RESTRICT", < __PACKAGE__->belongs_to( < "biblio", < "Koha::Schema::Result::Biblio", < { "foreign.biblionumber" => "self.biblionumber" } < ); < < __PACKAGE__->belongs_to( < "biblioitem", < "Koha::Schema::Result::Biblioitem", < { biblioitemnumber => "biblioitemnumber" }, < ); < < sub effective_itemtype { < my ( $self ) = @_; < < my $pref = $self->result_source->schema->resultset('Systempreference')->find('item-level_itypes'); < if ( $pref->value() ) { < return $self->itype(); < } else { < return $self->biblioitem()->itemtype(); < } < } diff -r /home/yohann/koha/Koha/Schema/Result/MessageQueue.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/MessageQueue.pm < { is_deferrable => 1, on_delete => "CASCADE", on_update => "CASCADE" }, > { is_deferrable => 1, on_delete => "RESTRICT", on_update => "CASCADE" }, diff -r /home/yohann/koha/Koha/Schema/Result/OldIssue.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/OldIssue.pm < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/OldReserve.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/OldReserve.pm < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/Reserve.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Reserve.pm < __PACKAGE__->belongs_to( < "item", < "Koha::Schema::Result::Item", < { itemnumber => "itemnumber" }, < { < is_deferrable => 1, < join_type => "LEFT", < on_delete => "CASCADE", < on_update => "CASCADE", < }, < ); < < __PACKAGE__->belongs_to( < "biblio", < "Koha::Schema::Result::Biblio", < { biblionumber => "biblionumber" }, < { < is_deferrable => 1, < join_type => "LEFT", < on_delete => "CASCADE", < on_update => "CASCADE", < }, < ); diff -r /home/yohann/koha/Koha/Schema/Result/Review.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Review.pm < on_delete => "CASCADE", > on_delete => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/Subscription.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Subscription.pm < on_delete => "CASCADE", > on_delete => "SET NULL", < on_delete => "CASCADE", > on_delete => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/Virtualshelfcontent.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Virtualshelfcontent.pm < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/Virtualshelfshare.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Virtualshelfshare.pm < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/Virtualshelve.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Virtualshelve.pm < on_delete => "CASCADE", < on_update => "CASCADE", > on_delete => "SET NULL", > on_update => "SET NULL", diff -r /home/yohann/koha/Koha/Schema/Result/Z3950server.pm /home/yohann/koha/misc/devel/Koha/Schema/Result/Z3950server.pm < extra: {list => ["primary","secondary"]} > extra: {list => ["primary","secondary",""]} < extra => { list => ["primary", "secondary"] }, > extra => { list => ["primary", "secondary", ""] }, From tomascohen at gmail.com Mon Jul 7 16:13:51 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 7 Jul 2014 11:13:51 -0300 Subject: [Koha-devel] The schema of DBIx::Class is not up-to-date In-Reply-To: <53BAAA60.9070402@biblibre.com> References: <53BAAA60.9070402@biblibre.com> Message-ID: I will take care of that DBIx schema upgrade each time I push a patch that changes the schema. Thanks for pointing this out Yohann, Regards To+ On Mon, Jul 7, 2014 at 11:10 AM, Yohann Dufour wrote: > Good afternoon, > > As you know, I'm working on DBIx::Class, and I realized that the > DBIx::Class schema (in Koha/Schema/) is not up-to-date with the current > database structure (installer/data/mysql/kohastructure.sql) which is > really used by the modules. The last update of the DBIx::Class schema was > the 2013-10-14, and some changes has been done since this day. > > Thus, it is problematic to use DBIx::Class if some differences exist. > What do you think about updating the DBIx::Class in order to link it with > the current database schema and trying to find a way to update > automatically the DBIx::Class schema at each change in the database > structure. > > I joined with this email the list of the differences between the > DBIx::Class schema and the current database schema. > > > Yohann > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at bywatersolutions.com Mon Jul 7 20:53:25 2014 From: info at bywatersolutions.com (Brendan Gallagher) Date: Mon, 7 Jul 2014 11:53:25 -0700 Subject: [Koha-devel] Ajax datatables. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11703 In-Reply-To: References: Message-ID: Thanks Jonathan - I see that you did do some testing on this. Excellent! Brendan On Wed, Jun 25, 2014 at 4:30 AM, Jonathan Druart < jonathan.druart at biblibre.com> wrote: > Hi Brendan, > > I will try to have a look at the last patches and see if no regression > is introduced. > Hopefully I will have the time soon... > > Cheers, > Jonathan > > 2014-06-24 18:22 GMT+02:00 Brendan Gallagher : > > Hello QA - > > > > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11703 > > > > We just had a few little follow up's on the QA and we've completed those > > about a month ago and need a little QA follow up. They do apply cleanly > > currently. Anything I can do to help encourage someone to look at those > > last 2 follows and passed them for QA? I'd love to get this into 3.16.1 > or > > 3.16.2 ASAP. > > > > Thanks, > > Brendan > > > > -- > > > --------------------------------------------------------------------------------------------------------------- > > Brendan A. Gallagher > > ByWater Solutions > > CEO > > > > > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : http://www.koha-community.org/ > > git : http://git.koha-community.org/ > > bugs : http://bugs.koha-community.org/ > -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info at bywatersolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Tue Jul 8 17:07:20 2014 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 8 Jul 2014 08:07:20 -0700 Subject: [Koha-devel] The schema of DBIx::Class is not up-to-date In-Reply-To: <53BAAA60.9070402@biblibre.com> References: <53BAAA60.9070402@biblibre.com> Message-ID: Hi, On Mon, Jul 7, 2014 at 7:10 AM, Yohann Dufour wrote: > I joined with this email the list of the differences between the DBIx::Class > schema and the current database schema. I believe that the difference in the generated schema classes can be accounted for by the fact that you're using a newer version of DBIx::Class::Schema::Loader. When I was RM for 3.16, I was using DBIC::Schema::Loader version v0.07025. Yesterday Tomas and I did some checking of classes generated using v0.07039. Among other changes, the newer versions now recognize "set null" as a FK action and default to "restrict" rather than "cascade" if the action is not explicitly specified. Those are both good changes, so I recommend that we require at least version v0.07039 of DBIC::Schema::Loader. Since that module is /not/ required for production use -- it's only needed for development -- requiring a hire version should not affect packaging signficantly. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From M.de.Rooy at rijksmuseum.nl Wed Jul 9 14:52:09 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 9 Jul 2014 12:52:09 +0000 Subject: [Koha-devel] Bug 9810 under UNIMARC Message-ID: <809BE39CD64BFD4EB9036172EBCCFA314236E917@S-MAIL-1B.rijksmuseum.intra> Hello all, Could a UNIMARC user (bonjour France) have a quick look at the small patches of bug 9810 ? Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Tue Jul 15 01:26:37 2014 From: kohanews at gmail.com (Koha News) Date: Mon, 14 Jul 2014 16:26:37 -0700 Subject: [Koha-devel] Call for news for July Newsletter Message-ID: <53C4672D.1090401@gmail.com> Fellow Koha users ~ We're collecting news for the July newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- * News items can be of any length. * Anything and everything Koha. * Submit by the 26th. If you are working on an interesting project or development related to Koha, please let us know and we'll include it in the development section. -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter From kohanews at gmail.com Tue Jul 15 01:27:34 2014 From: kohanews at gmail.com (Koha News) Date: Mon, 14 Jul 2014 16:27:34 -0700 Subject: [Koha-devel] Call for development news - July Newsletter Message-ID: <53C46766.8060400@gmail.com> Koha Development community ~ If you have any bugs or projects you'd like us to highlight or promote in the June newsletter, please let us know. Maybe it'll attract some additional eyes, testers and sign-offs. k o h a news AT gmail dot com Thank you! -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter From tomascohen at gmail.com Tue Jul 15 20:01:42 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 15 Jul 2014 15:01:42 -0300 Subject: [Koha-devel] RFC: Koha::Borrower::Pictures Message-ID: Hi, for bug 12578 [1] I was thinking of adding a 'timestamp' field to the 'patronimages' table. And got into the task of rewriting the CRUD methods for patron pictures into the Koha namespace, as an excercise for using DBIx in a real life example. Should I consider the use case where the library/user might want to attach more than one picture to a patron and choose a default? Even though I won't implement a UI for that, I can consider it in advance. Thanks in advance -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Tue Jul 15 21:39:13 2014 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 16 Jul 2014 07:39:13 +1200 Subject: [Koha-devel] RFC: Koha::Borrower::Pictures In-Reply-To: References: Message-ID: On 16/07/2014 6:02 am, "Tomas Cohen Arazi" wrote: > > Hi, for bug 12578 [1] I was thinking of adding a 'timestamp' field to the 'patronimages' table. And got into the task of rewriting the CRUD methods for patron pictures into the Koha namespace, as an excercise for using DBIx in a real life example. > > Should I consider the use case where the library/user might want to attach more than one picture to a patron and choose a default? Even though I won't implement a UI for that, I can consider it in advance. > Hi Tom?s, I think that building it so more than one can be saved (in the future) is a good idea. Chris > Thanks in advance > > -- > Cohen Arazi > Prosecretar?a de Inform?tica > Universidad Nacional de C?rdoba > ? +54 351 5353750 ext 13168 > GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.nighswonger at gmail.com Tue Jul 15 22:12:03 2014 From: chris.nighswonger at gmail.com (Christopher Nighswonger) Date: Tue, 15 Jul 2014 16:12:03 -0400 Subject: [Koha-devel] RFC: Koha::Borrower::Pictures In-Reply-To: References: Message-ID: On Jul 15, 2014 3:39 PM, "Chris Cormack" wrote: > > > I think that building it so more than one can be saved (in the future) is a good idea. > +1 Chris N -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtompset at hotmail.com Tue Jul 15 22:30:00 2014 From: mtompset at hotmail.com (Mark Tompsett) Date: Tue, 15 Jul 2014 16:30:00 -0400 Subject: [Koha-devel] RFC: Koha::Borrower::Pictures In-Reply-To: References: Message-ID: Greetings, > Should I consider the use case where the library/user > might want to attach more than one picture to a patron > and choose a default? Yes. This will allow for flexibility in the future. GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: From dora.mallikarjun at gmail.com Wed Jul 16 07:45:43 2014 From: dora.mallikarjun at gmail.com (mallikarjun dora) Date: Wed, 16 Jul 2014 11:15:43 +0530 Subject: [Koha-devel] British library z3950 target Message-ID: Dear All, Does anyone using the British library catalog, here search not throwing result from British library. Regards -- !~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~! Mallikarjun Dora Professional Assistant Vikram Sarabhai Library Indian Institute of Management, Ahmedabad mallikarjun at iimahd.ernet.in Mob: 9725608871 Google Scholar Profile -------------- next part -------------- An HTML attachment was scrubbed... URL: From maolins at gmail.com Wed Jul 16 09:23:29 2014 From: maolins at gmail.com (Anthony Mao) Date: Wed, 16 Jul 2014 15:23:29 +0800 Subject: [Koha-devel] British library z3950 target In-Reply-To: References: Message-ID: Hi Mallikarjun, I think you need password to access BL Z39.50 server. z3950cat.bl.uk:9909 2014-07-16 13:45 GMT+08:00 mallikarjun dora : > Dear All, > > Does anyone using the British library catalog, here search not throwing > result from British library. > > > Regards > > -- > !~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~! > Mallikarjun Dora > Professional Assistant > Vikram Sarabhai Library > Indian Institute of Management, Ahmedabad > mallikarjun at iimahd.ernet.in > Mob: 9725608871 > Google Scholar Profile > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Wishing you all the best. . . . Anthony Mao ??? ?886 2 29052334 (voice) + 886 2 29017405 (FAX) From martin.renvoize at ptfs-europe.com Wed Jul 16 18:28:41 2014 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Wed, 16 Jul 2014 17:28:41 +0100 Subject: [Koha-devel] RFC: Koha::Borrower::Pictures In-Reply-To: References: Message-ID: +1 from me to.. initially I couldn't see a reason for multiple pictures, but then it occured to me that a history could well be useful in some instances. Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com On 15 July 2014 21:30, Mark Tompsett wrote: > Greetings, > > > Should I consider the use case where the library/user > > might want to attach more than one picture to a patron > > and choose a default? > > Yes. This will allow for flexibility in the future. > > GPML, > Mark Tompsett > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Jul 16 18:46:37 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 16 Jul 2014 13:46:37 -0300 Subject: [Koha-devel] Jenkins tests update Message-ID: Yesterday I updated the master tasks script for launching unit tests. I did it so more tests are run (which were currently ommited). It looks like this: export TEST_QA=1 export JUNIT_OUTPUT_FILE='junit_output.xml' PERL5OPT='-MDevel::Cover' prove \ --timer --harness=TAP::Harness::JUnit \ t/ \ t/db_dependent/ \ t/db_dependent/Acquisition \ t/db_dependent/Circulation \ t/db_dependent/Holds \ t/db_dependent/Koha \ t/db_dependent/Labels \ t/db_dependent/Members \ t/db_dependent/Record \ t/db_dependent/Reports \ t/db_dependent/Search \ t/db_dependent/Serials \ xt/author/icondirectories.t \ xt/author/podcorrectness.t \ xt/author/translatable-templates.t \ xt/author/valid-templates.t \ xt/permissions.t \ xt/tt_valid.t \ xt/yaml_valid.t \ xt/single_quotes.t The difference with the previous is the addition of several (not all) t/db_dependent subdirectories. We cannot run prove recursively because not everything are unit tests. RMaints: If you agree with the change, I'll propagate (manually) this change to the stable branches tasks. Also, if anyone finds something still missing just let me know. For instance I haven't spent time on looking at t/ subdirectories. Thanks in advance To+ -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Thu Jul 17 09:43:15 2014 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Thu, 17 Jul 2014 09:43:15 +0200 Subject: [Koha-devel] Jenkins tests update In-Reply-To: References: Message-ID: <53C77E93.2080504@biblibre.com> Hie, Sounds great. +1 Le 16/07/2014 18:46, Tomas Cohen Arazi a ?crit : > Yesterday I updated the master tasks script for launching unit tests. I did > it so more tests are run (which were currently ommited). It looks like this: > > export TEST_QA=1 > export JUNIT_OUTPUT_FILE='junit_output.xml' > PERL5OPT='-MDevel::Cover' prove \ > --timer --harness=TAP::Harness::JUnit \ > t/ \ > t/db_dependent/ \ > t/db_dependent/Acquisition \ > t/db_dependent/Circulation \ > t/db_dependent/Holds \ > t/db_dependent/Koha \ > t/db_dependent/Labels \ > t/db_dependent/Members \ > t/db_dependent/Record \ > t/db_dependent/Reports \ > t/db_dependent/Search \ > t/db_dependent/Serials \ > xt/author/icondirectories.t \ > xt/author/podcorrectness.t \ > xt/author/translatable-templates.t \ > xt/author/valid-templates.t \ > xt/permissions.t \ > xt/tt_valid.t \ > xt/yaml_valid.t \ > xt/single_quotes.t > > The difference with the previous is the addition of several (not all) > t/db_dependent subdirectories. We cannot run prove recursively because not > everything are unit tests. > > RMaints: If you agree with the change, I'll propagate (manually) this > change to the stable branches tasks. > > Also, if anyone finds something still missing just let me know. For > instance I haven't spent time on looking at t/ subdirectories. > > Thanks in advance > To+ > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS Biblibre - P?les support et syst?me fridolin.somers at biblibre.com From Giuseppe.Angilella at ct.infn.it Thu Jul 17 11:31:24 2014 From: Giuseppe.Angilella at ct.infn.it (Giuseppe Angilella) Date: Thu, 17 Jul 2014 11:31:24 +0200 (CEST) Subject: [Koha-devel] unimarc to marc21 Message-ID: Hi, I wonder whether it is possible to filter unimarc records retrieved from a Z39.50 server, and convert them "on the fly" into marc21 (and vice versa). Record_transform, a metaproxy module, claims to be able to perform such a conversion, but I couldn't figure out how to use it in conjuction with Koha. Many thanks, Giuseppe. From M.de.Rooy at rijksmuseum.nl Thu Jul 17 11:37:55 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 17 Jul 2014 09:37:55 +0000 Subject: [Koha-devel] unimarc to marc21 In-Reply-To: References: Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3142376CBD@S-MAIL-1B.rijksmuseum.intra> I am working right now on bug 6536 (again). If you have an xslt file for unimarc-marc21 conversion, you could use it in the additional xslt option. Will submit the xslt patch probably today.. Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Giuseppe Angilella Verzonden: donderdag 17 juli 2014 11:31 Aan: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] unimarc to marc21 Hi, I wonder whether it is possible to filter unimarc records retrieved from a Z39.50 server, and convert them "on the fly" into marc21 (and vice versa). Record_transform, a metaproxy module, claims to be able to perform such a conversion, but I couldn't figure out how to use it in conjuction with Koha. Many thanks, Giuseppe. _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From z.tajoli at cineca.it Thu Jul 17 11:53:51 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Thu, 17 Jul 2014 11:53:51 +0200 Subject: [Koha-devel] unimarc to marc21 In-Reply-To: References: Message-ID: <53C79D2F.7010006@cineca.it> Hi to all, l 17/07/2014 11:31, Giuseppe Angilella ha scritto: > Record_transform, a metaproxy module, claims to be able to perform such > a conversion, but I couldn't figure out how to use it in conjuction with Record_transform uses a xslt stylesheet, but there are only MARC21->DC and MARC21->MAD/MODS conversions. If you build metaproxy from source you can insert USMARCON in metaproxy. With USMARCON is more easy to write an unimarc to marc21 conversion. For Koha bug 6536, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6536 is the best option available. I suggest you to: -- add your self in CC list for the bug -- help on sign-off when it will be possible. Bye Zeno Tajoli -- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From jonathan.druart at biblibre.com Thu Jul 17 12:06:19 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 17 Jul 2014 12:06:19 +0200 Subject: [Koha-devel] Jenkins tests update In-Reply-To: References: Message-ID: Hi, I would prefer something more generic. I sometimes add new sub-directories and it will be a pain to manually maintain the dir list. For instance, it seems the configuration you propose does not take into account the issuingRules sub-directory in t/db_dependent/Circulation. Is it possible to launch several prove commands? We could imagine something like find t -name "*.t" -exec /usr/bin/prove {} \; Otherwise, it should be possible to generate an exhaustive unit test file list present in the t directory and pass it to prove. Cheers, Jonathan 2014-07-16 18:46 GMT+02:00 Tomas Cohen Arazi : > Yesterday I updated the master tasks script for launching unit tests. I did > it so more tests are run (which were currently ommited). It looks like this: > > export TEST_QA=1 > export JUNIT_OUTPUT_FILE='junit_output.xml' > PERL5OPT='-MDevel::Cover' prove \ > --timer --harness=TAP::Harness::JUnit \ > t/ \ > t/db_dependent/ \ > t/db_dependent/Acquisition \ > t/db_dependent/Circulation \ > t/db_dependent/Holds \ > t/db_dependent/Koha \ > t/db_dependent/Labels \ > t/db_dependent/Members \ > t/db_dependent/Record \ > t/db_dependent/Reports \ > t/db_dependent/Search \ > t/db_dependent/Serials \ > xt/author/icondirectories.t \ > xt/author/podcorrectness.t \ > xt/author/translatable-templates.t \ > xt/author/valid-templates.t \ > xt/permissions.t \ > xt/tt_valid.t \ > xt/yaml_valid.t \ > xt/single_quotes.t > > The difference with the previous is the addition of several (not all) > t/db_dependent subdirectories. We cannot run prove recursively because not > everything are unit tests. > > RMaints: If you agree with the change, I'll propagate (manually) this change > to the stable branches tasks. > > Also, if anyone finds something still missing just let me know. For instance > I haven't spent time on looking at t/ subdirectories. > > Thanks in advance > To+ > > -- > Tom?s Cohen Arazi > Prosecretar?a de Inform?tica > Universidad Nacional de C?rdoba > ? +54 351 5353750 ext 13168 > GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From arun25jun at gmail.com Thu Jul 17 12:49:08 2014 From: arun25jun at gmail.com (Arun kumar) Date: Thu, 17 Jul 2014 16:19:08 +0530 Subject: [Koha-devel] Change of Workflow in the existing system of KOHA for Placing New Orders in Acquisition Message-ID: Hello, We are working on various development pointers in Acquisition module to customize it according to our workflow Placing orders in KOHA 3.12 is vague to our organisation its consuming procedure for placing orders which can be acheived with minimal workflow i have crafted the workflow to meet our requirements, which includes ordering form SUGGESTION MANAGEMENT itself with an hyperlink from Accepted tab and passing suggestionid and biblionumber directly to neworderempty.pl further modifying this file with a new form with vendor and basket details and creating a basket with basketno and bookseller id and other credentials passed on to addorder.pl my question is that how do we create a new basket at neworderempty.pl and passing its details to place an order in addorder.pl, i have studied the code for creation of basket in basketheader.pl, and followed the same i don't understand where i went wrong My Sincere Appreciation towards any pointers, thanks in advance Regards Arunkumar Project Assistant National Institute of Oceanography -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Thu Jul 17 14:42:38 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Thu, 17 Jul 2014 14:42:38 +0200 Subject: [Koha-devel] unimarc to marc21 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3142376CBD@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3142376CBD@S-MAIL-1B.rijksmuseum.intra> Message-ID: <53C7C4BE.4060402@cineca.it> Hi to all, Il 17/07/2014 11:37, Marcel de Rooy ha scritto: > I am working right now on bug 6536 (again). > If you have an xslt file for unimarc-marc21 conversion, you could use it in the additional xslt option. > Will submit the xslt patch probably today.. here there is a basic xslt for Unimarc -> MARC21 conversion: https://github.com/edsd/biblio-metadata/blob/master/UNIMARC2MARC21.xsl Probably it is not enough for a librarina, but it is a start. Bye Zeno Tajoli -- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From M.de.Rooy at rijksmuseum.nl Thu Jul 17 15:18:11 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 17 Jul 2014 13:18:11 +0000 Subject: [Koha-devel] Bugzilla fields: assignee and complexity Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3142376EA9@S-MAIL-1B.rijksmuseum.intra> Hi all, Some/many people do not really care about filling assignee or patch complexity when submitting patches to Koha. In the process of signoff or QA, it is helpful to see rightaway the author of the report and its supposed complexity (size). When glancing through the queues, I am inclined to favor patches with that information filled. If you agree, please enter that information too. Thanks! Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Thu Jul 17 15:56:20 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Thu, 17 Jul 2014 09:56:20 -0400 Subject: [Koha-devel] RFC: Koha::Borrower::Pictures In-Reply-To: References: Message-ID: Agreed, +1. I could see a situation where a library takes a new picture every year, and Koha just uses the newest one as the default. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Jul 16, 2014 at 12:28 PM, Renvoize, Martin < martin.renvoize at ptfs-europe.com> wrote: > +1 from me to.. initially I couldn't see a reason for multiple pictures, > but then it occured to me that a history could well be useful in some > instances. > > Martin Renvoize > Software Engineer, PTFS Europe Ltd > Content Management and Library Solutions > Skype: > Landline: 0203 286 8685 > Mobile: 07725985636 > > http://www.ptfs-europe.com > > > On 15 July 2014 21:30, Mark Tompsett wrote: > >> Greetings, >> >> > Should I consider the use case where the library/user >> > might want to attach more than one picture to a patron >> > and choose a default? >> >> Yes. This will allow for flexibility in the future. >> >> GPML, >> Mark Tompsett >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Thu Jul 17 16:33:31 2014 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 17 Jul 2014 10:33:31 -0400 Subject: [Koha-devel] Bugzilla fields: assignee and complexity In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3142376EA9@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3142376EA9@S-MAIL-1B.rijksmuseum.intra> Message-ID: > In the process of signoff or QA, it is helpful to see rightaway the author > of the report and its supposed complexity (size). It's much easier to remember to set the complexity setting if you use git-bz, so I recommend it! If anyone who submits patches doesn't use git-bz yet please give it a try and ask for help if you run into trouble. It's really worth the effort. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From bgkriegel at gmail.com Thu Jul 17 17:31:25 2014 From: bgkriegel at gmail.com (Bernardo Gonzalez Kriegel) Date: Thu, 17 Jul 2014 12:31:25 -0300 Subject: [Koha-devel] Bugzilla fields: assignee and complexity In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA3142376EA9@S-MAIL-1B.rijksmuseum.intra> Message-ID: > > > It's much easier to remember to set the complexity setting if you use > git-bz, so I recommend it! > > If anyone who submits patches doesn't use git-bz yet please give it a > try and ask for help if you run into trouble. It's really worth the > effort. > > Is there a complete list of options to git-bz? (other than -m or -s) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giuseppe.Angilella at ct.infn.it Fri Jul 18 06:56:16 2014 From: Giuseppe.Angilella at ct.infn.it (Giuseppe Angilella) Date: Fri, 18 Jul 2014 06:56:16 +0200 (CEST) Subject: [Koha-devel] unimarc to marc21 In-Reply-To: <53C79D2F.7010006@cineca.it> References: <53C79D2F.7010006@cineca.it> Message-ID: Hi, > For Koha bug 6536, > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6536 is the best > option available. I wasn't aware of that, which looks great indeed! :-) > I suggest you to: > -- add your self in CC list for the bug > -- help on sign-off when it will be possible. I am currently trying to signing it off on a sandbox at biblibre. The patch applied smoothly (it seems), and I can now specify a XSLT file for transforming results on a Z39.50 server I had entered previously (i.e., before applying the patch, while in "master" mode, in order to test that UNImarc fields were retrieved incorrectly into my USmarc database, as expected). I tried entering either unimarc2marc21.xsl or UNIMARC2MARC21.xsl, but I get the following error: Warning: XSLT error on search result 1 on trying to retrieve a record. How can I list the available XSLT files, or upload the desired one, as I have no shell access to the sandbox? Many thanks! Giuseppe. From bargioni at pusc.it Fri Jul 18 16:58:26 2014 From: bargioni at pusc.it (Stefano Bargioni) Date: Fri, 18 Jul 2014 16:58:26 +0200 Subject: [Koha-devel] British library z3950 target In-Reply-To: References: Message-ID: <565DAF5A-A77B-4BCB-BD7D-BEEF339909D0@pusc.it> You can contact them for a free access: http://www.bl.uk/bibliographic/data.html. Stefano On 16/lug/2014, at 09:23, Anthony Mao wrote: > Hi Mallikarjun, > > I think you need password to access BL Z39.50 server. > z3950cat.bl.uk:9909 > > > 2014-07-16 13:45 GMT+08:00 mallikarjun dora : >> Dear All, >> >> Does anyone using the British library catalog, here search not throwing >> result from British library. >> >> >> Regards >> >> -- >> !~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~!~! >> Mallikarjun Dora >> Professional Assistant >> Vikram Sarabhai Library >> Indian Institute of Management, Ahmedabad >> mallikarjun at iimahd.ernet.in >> Mob: 9725608871 >> Google Scholar Profile >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ > > > > -- > Wishing you all the best. . . . > > > Anthony Mao ??? > ?886 2 29052334 (voice) > + 886 2 29017405 (FAX) > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From yohann.dufour at biblibre.com Mon Jul 21 12:16:48 2014 From: yohann.dufour at biblibre.com (Yohann Dufour) Date: Mon, 21 Jul 2014 12:16:48 +0200 Subject: [Koha-devel] Presentation of TestBuilder Message-ID: <53CCE890.8000101@biblibre.com> Hi, With Jonathan Druart, we have been working on a Koha module in order to simplify the writing of tests. For example, when we want to test an order, we have to instantiate first a bookseller, a basket, a budget and a biblio. In the end, there are more lines which instantiate all the needed objects than lines of test. The concept of this module : /TestBuilder/ is to generate automatically the foreign keys of a specific entry in the database. You can choose the inserted values or let them be generated randomly. The bug report related to the /TestBuilder/ is bug 12603 . You can see examples of the use of /TestBuilder/ on existing files : bug 12604 , bug 12605 , bug 12606 , bug 12607 . Regards, Yohann -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From tomascohen at gmail.com Mon Jul 21 15:05:19 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 21 Jul 2014 10:05:19 -0300 Subject: [Koha-devel] GBSD 23-07: UTF-8 code cleanup Message-ID: Hi, last general meeting we set Wednesday 23rd, July as our next Global Bug Squashing Day. This time, GBSD targets a specific problem: UTF-8 handling problems in Koha, for which a bug has been filled (bug 11944 [1]) and Jonathan Druart (Joubu) has been working on. The idea is to test Jonathan's work, and find bugs (and hopefully fix them). The key ideas on how data must be handled so no encoding problems arise can be found on the wiki [2]. Please notice that Jonathan's work is currently on a branch in Biblibre's git repo [3]. Biblibre has also set sandboxes for testing [4]. Sandboxes 6 and 16 have been set for this specific bug (MARC21 and UNIMARC respectively). We hope you can join us! [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11944 [2] http://wiki.koha-community.org/wiki/Handling_UTF8_in_development [3] git remote add biblibre http://git.biblibre.com/biblibre/kohac.git ; \ git checkout biblibre/ft/bug_11944 [4] http://wiki.koha-community.org/wiki/Sandboxes -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Jul 21 15:27:10 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 21 Jul 2014 13:27:10 +0000 Subject: [Koha-devel] Force hold on item-level? Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31423788CE@S-MAIL-1B.rijksmuseum.intra> Hi all, Anyone working on /having ideas on the following: Would it be interesting to force Koha somehow on specific biblios (with multiple and not-identical items) to place holds only on item-level and not on biblio level ? This would be kind of opposite of OPACItemHolds that can block item level holds in general. I am not thinking of a syspref however, but of some way to mark this behavior on biblio level. Any feedback is welcome! Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nengard at gmail.com Mon Jul 21 15:56:06 2014 From: nengard at gmail.com (Nicole Engard) Date: Mon, 21 Jul 2014 09:56:06 -0400 Subject: [Koha-devel] Force hold on item-level? In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31423788CE@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA31423788CE@S-MAIL-1B.rijksmuseum.intra> Message-ID: If I understand you right, this has already been done: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7825 Nicole On Mon, Jul 21, 2014 at 9:27 AM, Marcel de Rooy wrote: > *Hi all,* > > > > *Anyone working on /having ideas on the following:* > > > > *Would it be interesting to force Koha somehow on specific biblios (with > multiple and not-identical items) to place holds only on item-level and not > on biblio level ? * > > *This would be kind of opposite of OPACItemHolds that can block item level > holds in general. * > > *I am not thinking of a syspref however, but of some way to mark this > behavior on biblio level. * > > > > *Any feedback is welcome!* > > > > *Thanks,* > > > > *Marcel* > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Mon Jul 21 17:32:07 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Mon, 21 Jul 2014 17:32:07 +0200 Subject: [Koha-devel] VAT/GST rewrite Message-ID: Hello, As promised, I have just finished to translate the spec for the VAT/GST rewrite. You can found them on the wiki: http://wiki.koha-community.org/wiki/GST_Rewrite_RFC Note that I am waiting for some feedbacks before starting the development. I really would like to know if the logic is good for all of you/your customers/use cases and if you agree on the values calculation. Regards, Jonathan From tomascohen at gmail.com Mon Jul 21 21:19:36 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 21 Jul 2014 16:19:36 -0300 Subject: [Koha-devel] RFC: /svc/ API Message-ID: Hi, on bug 12590 [1] we started a discussion on the current /svc API. Petter proposed extending the /svc/bib capabilities (which is great) but I noticed the current API does not respect the usual meaning of HTTP verbs for REST (specifically the meaning of POST). So I have a question: who is using the API and how difficult would be to adapt to using PUT instead of POST? Any thoughts? -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.blouin at inlibro.com Mon Jul 21 21:36:06 2014 From: philippe.blouin at inlibro.com (Philippe Blouin) Date: Mon, 21 Jul 2014 15:36:06 -0400 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: References: Message-ID: <53CD6BA6.7030007@inlibro.com> Hi, Changing the API would be quite simple. But not making it "retro-compatible" could be a nightmare to some installs. In our case, we "published" the addresses as call-backs. Correcting those in the remote systems _could_ be a drag, way more than the usual rebase/upgrade/fix involving code. Just a thought. Blou On 07/21/2014 03:19 PM, Tomas Cohen Arazi wrote: > Hi, on bug 12590 [1] we started a discussion on the current /svc API. > Petter proposed extending the /svc/bib capabilities (which is great) > but I noticed the current API does not respect the usual meaning of > HTTP verbs for REST (specifically the meaning of POST). > > So I have a question: who is using the API and how difficult would be > to adapt to using PUT instead of POST? > > Any thoughts? > > -- > Tom?s Cohen Arazi > Prosecretar?a de Inform?tica > Universidad Nacional de C?rdoba > ? +54 351 5353750 ext 13168 > GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Philippe Blouin, Responsable du d?veloppement informatique T?l. : (888) 604-2627 philippe.blouin at inLibro.com inLibro | pour esprit libre | www.inLibro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Mon Jul 21 21:46:58 2014 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 22 Jul 2014 07:46:58 +1200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <53CD6BA6.7030007@inlibro.com> References: <53CD6BA6.7030007@inlibro.com> Message-ID: <20140721194658.GW12153@rorohiko.wgtn.cat-it.co.nz> * Philippe Blouin (philippe.blouin at inlibro.com) wrote: > Hi, > Changing the API would be quite simple. But not making it "retro-compatible" > could be a nightmare to some installs. In our case, we "published" the > addresses as call-backs. Correcting those in the remote systems could be a > drag, way more than the usual rebase/upgrade/fix involving code. > > Just a thought. Hi All I think we you want to do something like this (change a published and in use API) then we should version it. So that the current in use version can be version one, we make a new version 2 of the API people can transition to it. At some point in the future (maybe) we get rid of version 1 Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From Katrin.Fischer.83 at web.de Mon Jul 21 23:08:36 2014 From: Katrin.Fischer.83 at web.de (Katrin Fischer) Date: Mon, 21 Jul 2014 23:08:36 +0200 Subject: [Koha-devel] Force hold on item-level? In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA31423788CE@S-MAIL-1B.rijksmuseum.intra> Message-ID: <53CD8154.8030703@web.de> Hi, I thought the idea of moving OPACItemHolds to the circulation matrix was promising in terms of more flexibility: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5787 And there is another patch implementing item level holds a bit different especially for serial records: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11157 I think there would definitely be interest in such a feature. Katrin Am 21.07.2014 15:56, schrieb Nicole Engard: > If I understand you right, this has already been done: > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7825 > > Nicole > > > On Mon, Jul 21, 2014 at 9:27 AM, Marcel de Rooy > > wrote: > > *Hi all,____* > > *__? __* > > *Anyone working on /having ideas on the following:____* > > *__? __* > > *Would it be interesting to force Koha somehow on specific biblios > (with multiple and not-identical items) to place holds only on > item-level and not on biblio level ? ____* > > *This would be kind of opposite of OPACItemHolds that can block item > level holds in general. ____* > > *I am not thinking of a syspref however, but of some way to mark > this behavior on biblio level. ____* > > *__? __* > > *Any feedback is welcome!____* > > *__? __* > > *Thanks,____* > > *__? __* > > *Marcel____* > > __? __ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > From indradg at gmail.com Tue Jul 22 02:42:35 2014 From: indradg at gmail.com (Indranil Das Gupta) Date: Tue, 22 Jul 2014 00:42:35 +0000 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <20140721194658.GW12153@rorohiko.wgtn.cat-it.co.nz> References: <53CD6BA6.7030007@inlibro.com> <20140721194658.GW12153@rorohiko.wgtn.cat-it.co.nz> Message-ID: On Mon, Jul 21, 2014 at 7:46 PM, Chris Cormack wrote: > * Philippe Blouin (philippe.blouin at inlibro.com) wrote: >> Hi, > I think we you want to do something like this (change a published and in use API) then > we should version it. > > So that the current in use version can be version one, we make a new version 2 of the API > people can transition to it. At some point in the future (maybe) we get rid of version 1 +1 Sounds reasonable. -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org From heupink at merit.unu.edu Tue Jul 22 17:27:01 2014 From: heupink at merit.unu.edu (mourik jan heupink - merit) Date: Tue, 22 Jul 2014 17:27:01 +0200 Subject: [Koha-devel] failover ldap servers Message-ID: <53CE82C5.4020404@merit.unu.edu> Hi, Is it possible to provide two (or more) hostnames for (identical) ldap servers in koha-conf.xml? That way you'd have failover if one ldap fails. Or perhaps define (separate) ldapserver id's (dc1, dc2) with identical content for the various DC's? Or..? Kind regards, Mourik Jan From Katrin.Fischer.83 at web.de Tue Jul 22 22:04:22 2014 From: Katrin.Fischer.83 at web.de (Katrin Fischer) Date: Tue, 22 Jul 2014 22:04:22 +0200 Subject: [Koha-devel] Reminder: Koha Developer IRC Meeting - July 23rd, 15:00 and 22:00 UTC Message-ID: <53CEC3C6.9080007@web.de> Hi all, just a quick reminder about the Koha Developer IRC Meeting on July 23rd at 15:00 and 22:00 UTC: http://wiki.koha-community.org/wiki/Development_IRC_meeting,_23_July_2014 See you there! Katrin From dcook at prosentient.com.au Wed Jul 23 02:11:13 2014 From: dcook at prosentient.com.au (David Cook) Date: Wed, 23 Jul 2014 10:11:13 +1000 Subject: [Koha-devel] RFC: /svc/ API Message-ID: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> +1 to a versioned API. I don't think that I use it for anything at the moment, but I'm not 100% sure about all our apps. I think we might have a third-party one that uses it. As for PUT vs POST, I suppose strictly speaking PUT would be more appropriate for /svc/bib. In terms of difficulty, it would be fairly trivial to update our apps. It's worth remembering that the OCLC Connexion daemon "./misc/bin/connexion_import_daemon.pl" uses "/cgi-bin/koha/svc/import_bib". This script should probably also use PUT, but I have no idea if OCLC Connexion supports that. Since there are an indeterminate number of third-party software systems using the existing API, I'd recommend versioning and using v2 to handle things more RESTfully. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- Date: Tue, 22 Jul 2014 00:42:35 +0000 From: Indranil Das Gupta To: "koha-devel at lists.koha-community.org" Subject: Re: [Koha-devel] RFC: /svc/ API Message-ID: Content-Type: text/plain; charset=UTF-8 On Mon, Jul 21, 2014 at 7:46 PM, Chris Cormack wrote: > * Philippe Blouin (philippe.blouin at inlibro.com) wrote: >> Hi, > I think we you want to do something like this (change a published and in use API) then > we should version it. > > So that the current in use version can be version one, we make a new version 2 of the API > people can transition to it. At some point in the future (maybe) we get rid of version 1 +1 Sounds reasonable. -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org ------------------------------ From petter.goksoyr.asen at kul.oslo.kommune.no Wed Jul 23 04:11:51 2014 From: petter.goksoyr.asen at kul.oslo.kommune.no (=?iso-8859-1?Q?Petter_Goks=F8yr_=C5sen?=) Date: Wed, 23 Jul 2014 04:11:51 +0200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> Message-ID: <13834160A6C2994D8650749DA5EC061B0160585EE5B2@CL122726.oslofelles.oslo.kommune.no> David Cook wrote: > Since there are an indeterminate number of third-party software systems > using the existing API, I'd recommend versioning and using v2 to handle > things more RESTfully. I agree. We should think twice before breaking existing integrations and workflows. I am also interested to hear peoples opinions about Koha's HTTP APIs in general: - do you want them expanded? for what use cases? - and more importantly: should Koha's templates make use of i'ts own APIs? My library certainly think this could be a fruitful direction for Koha to go, and want to help make it happen. But if there is no big interest in the community in this approach, we'll more likely to fork and/or contribute to Biblibre's koha-restful instead of patching the svc and ILS-DI APIs. Regards, Petter Goks?yr ?sen Deichmanske bibliotek / Oslo Public Library From dcook at prosentient.com.au Wed Jul 23 05:03:03 2014 From: dcook at prosentient.com.au (David Cook) Date: Wed, 23 Jul 2014 13:03:03 +1000 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <13834160A6C2994D8650749DA5EC061B0160585EE5B0@CL122726.oslofelles.oslo.kommune.no> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B0@CL122726.oslofelles.oslo.kommune.no> Message-ID: <02fd01cfa622$9e4e3c60$daeab520$@prosentient.com.au> I'm so glad that you've asked these questions, Petter! 1) I would very much like to see Koha's HTTP APIs expanded. Locally, I've added some services for check-in and check-out, as we have a desktop app that does some circulation on behalf of Koha. More generally, I would like to see a richer HTTP API, so that we could more loosely couple Koha to other systems, especially in terms of OPAC functionality. We work with a lot of special libraries, so it would be great if they could use an API to integrate search and holds into their own websites. It would also be useful for discovery software (like VuFind) for getting real-time item availability information. I know BibLibre integrate Koha and Drupal (which might be the reason for their koha-restful code?). As for the staff client, I think it would still be useful, as it opens up more third-party involvement with Koha. If there were more services, we could do more with our desktop app. I'm sure that others would find uses for it as well. I think that this also has the potential to increase separation of business and presentation layers. Of course, I think presentation is important, but if we focus on making sure that useful data is coming out, we're less likely to cheat and combine them when we probably shouldn't. 2) I'm not sure that I understand what you mean when you ask "should Koha's templates make use of its own APIs?". Do you mean using the API via Javascript on the template, or using the API via LWP in the Perl script? In either case, I'm starting to think so. I think there is already a growing trend in Koha for using APIs via AJAX. As for using the APIs serverside, I don't know what implications that would have. 3) I agree with your library, Petter. I think that this would be a fruitful direction for Koha to go. I think that I could contribute some time and energy to this as well. I only heard of BibLibre's "koha-restful" recently. I didn't thoroughly review the code, but it appears that it only uses IP-based authentication at the moment. I think it was missing all the functionality that I desired as well, so I decided not to use it. I hope other people express an interest as well, as I really would like to see Koha become more service-oriented. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- From: Petter Goks?yr ?sen [mailto:petter.goksoyr.asen at kul.oslo.kommune.no] Sent: Wednesday, 23 July 2014 12:11 PM To: David Cook Subject: SV: [Koha-devel] RFC: /svc/ API David Cook wrote: > Since there are an indeterminate number of third-party software > systems using the existing API, I'd recommend versioning and using v2 > to handle things more RESTfully. I agree. We should think twice before breaking existing integrations and workflows. I am also interested to hear peoples opinions about Koha's HTTP APIs in general: - do you want them expanded? for what use cases? - and more importantly: should Koha's templates make use of i'ts own APIs? My library certainly think this could be a fruitful direction for Koha to go, and want to help make it happen. But if there is no big interest in the community in this approach, we'll more likely to fork and/or contribute to Biblibre's koha-restful instead of patching the svc and ILS-DI APIs. Regards, Petter Goks?yr ?sen Deichmanske bibliotek / Oslo Public Library From jonathan.druart at biblibre.com Wed Jul 23 10:13:37 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 23 Jul 2014 10:13:37 +0200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <02fd01cfa622$9e4e3c60$daeab520$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B0@CL122726.oslofelles.oslo.kommune.no> <02fd01cfa622$9e4e3c60$daeab520$@prosentient.com.au> Message-ID: 2014-07-23 5:03 GMT+02:00 David Cook : Hi David, > I only heard of BibLibre's "koha-restful" recently. I didn't thoroughly > review the code, but it appears that it only uses IP-based authentication at > the moment. I think it was missing all the functionality that I desired as > well, so I decided not to use it. BibLibre wrote koha-restful to fix the lack of possibilities IDS-DI can provide. We are highly open-minded to contributions (merge request, patches, etc.), if you find some time :) If you want to add features, you can send us a patch at dev_patches AT biblibre DOT com You can find more information about it into README file and opac/rest.pl documentation on http://git.biblibre.com. Cheers, Jonathan > -----Original Message----- > From: Petter Goks?yr ?sen [mailto:petter.goksoyr.asen at kul.oslo.kommune.no] > Sent: Wednesday, 23 July 2014 12:11 PM > To: David Cook > Subject: SV: [Koha-devel] RFC: /svc/ API > > > David Cook wrote: >> Since there are an indeterminate number of third-party software >> systems using the existing API, I'd recommend versioning and using v2 >> to handle things more RESTfully. > > I agree. We should think twice before breaking existing integrations and > workflows. > > I am also interested to hear peoples opinions about Koha's HTTP APIs in > general: > - do you want them expanded? for what use cases? > - and more importantly: should Koha's templates make use of i'ts own APIs? > > My library certainly think this could be a fruitful direction for Koha to > go, and want to help make it happen. But if there is no big interest in the > community in this approach, we'll more likely to fork and/or contribute to > Biblibre's koha-restful instead of patching the svc and ILS-DI APIs. > > Regards, > Petter Goks?yr ?sen > Deichmanske bibliotek / Oslo Public Library > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From alex.sassmannshausen at gmail.com Wed Jul 23 11:15:18 2014 From: alex.sassmannshausen at gmail.com (Alex Sassmannshausen) Date: Wed, 23 Jul 2014 11:15:18 +0200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <13834160A6C2994D8650749DA5EC061B0160585EE5B2@CL122726.oslofelles.oslo.kommune.no> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B2@CL122726.oslofelles.oslo.kommune.no> Message-ID: <8761io77oq.fsf@yamato.home> Hello, Very interesting discussion! Petter Goks?yr ?sen writes: > David Cook wrote: >> Since there are an indeterminate number of third-party software systems >> using the existing API, I'd recommend versioning and using v2 to handle >> things more RESTfully. > > I agree. We should think twice before breaking existing integrations > and workflows. +1 > I am also interested to hear peoples opinions about Koha's HTTP APIs in general: > - do you want them expanded? for what use cases? We would definitely be interested in having expanded APIs. We at PTFS Europe have been working on a revised VuFind driver which uses the ILS-DI API to provide functionality currently only available through direct database connections (https://github.com/PTFS-Europe/vufind/compare/vufind-org:master...koha-driver). Parts of this driver unfortunately do not work yet due to limitations of the ILS-DI API, so we'd be keen to see it enhanced! > - and more importantly: should Koha's templates make use of i'ts own > APIs? I like this idea in principle, though am in no way capable of assessing the feasibility or practical implications in terms of relative performance and code complexity? Best wishes, Alex -- Sent with my mu4e From reed at typist.geek.nz Wed Jul 23 12:09:10 2014 From: reed at typist.geek.nz (Reed Wade) Date: Wed, 23 Jul 2014 22:09:10 +1200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <8761io77oq.fsf@yamato.home> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B2@CL122726.oslofelles.oslo.kommune.no> <8761io77oq.fsf@yamato.home> Message-ID: Just to add my bits regarding rest style APIs because I've been making a lot of those lately: - sticking with GET and POST may simplify things because they're just a lot more typical and you're less likely to run into odd problems with less well tested lib and proxy support - a great rule of thumb is POST for writes and GET for reads; this makes it intentionally harder to compose a url that accidentally writes anything - avoid emitting HTML, the cool kids are letting the browser do all the work now Some folks will not like the next bit of advice because it's not pure REST. I like to never return http error responses for API level exceptions. Instead I like to provide a "success" boolean value in the json response and a text explanation in a separate variable. -reed -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Wed Jul 23 13:34:04 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 23 Jul 2014 11:34:04 +0000 Subject: [Koha-devel] Force hold on item-level? In-Reply-To: <53CD8154.8030703@web.de> References: <809BE39CD64BFD4EB9036172EBCCFA31423788CE@S-MAIL-1B.rijksmuseum.intra> , <53CD8154.8030703@web.de> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA314238B2C3@S-MAIL-1B.rijksmuseum.intra> Thanks Nicole and Katrin. Bug 7825 indeed adds a force option! I would only want to extend it to "selective" where I could force it only for groups of records or even at record level somehow. Bug 5787 proposed to move OPACItemsHolds to the circulation matrix, but has been marked as a duplicate of 5786 that refers to AllowOnShelfHolds ("Does not apply"). The status of this dev is not so clear anymore. Bug 11157 is also interesting although marked as a "simple dirty hack" for serials.. Will still be thinking a little bit of an alternative approach? Marcel From gmc at esilibrary.com Wed Jul 23 17:22:20 2014 From: gmc at esilibrary.com (Galen Charlton) Date: Wed, 23 Jul 2014 08:22:20 -0700 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> Message-ID: Hi, On Tue, Jul 22, 2014 at 5:11 PM, David Cook wrote: > +1 to a versioned API. I don't think that I use it for anything at the > moment, but I'm not 100% sure about all our apps. I think we might have a > third-party one that uses it. Also +1 to a versioned API. > This script should probably also use PUT, but I have no idea if OCLC > Connexion supports that. I don't believe it matters as far as Connexion is concerned, as it only talks to connexion_import_daemon.pl via a raw socket. > Since there are an indeterminate number of third-party software systems > using the existing API, I'd recommend versioning and using v2 to handle > things more RESTfully. MarcEdit is one program I know that uses the current API to inject records into a Koha database. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From dcook at prosentient.com.au Thu Jul 24 02:15:58 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 24 Jul 2014 10:15:58 +1000 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B0@CL122726.oslofelles.oslo.kommune.no> <02fd01cfa622$9e4e3c60$daeab520$@prosentient.com.au> Message-ID: <036401cfa6d4$71cece90$556c6bb0$@prosentient.com.au> Hi Jonathan: Thanks. I'll keep that in mind. We might need to use it for a certain project, so that's good to know. I'm a bit wary of using third-party software for Koha that we don?t maintain ourselves though :/. Is there any chance that BibLibre might be looking to merge the code into the community codebase? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- From: druartjonathan at gmail.com [mailto:druartjonathan at gmail.com] On Behalf Of Jonathan Druart Sent: Wednesday, 23 July 2014 6:14 PM To: David Cook Cc: Petter Goks?yr ?sen; koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] RFC: /svc/ API 2014-07-23 5:03 GMT+02:00 David Cook : Hi David, > I only heard of BibLibre's "koha-restful" recently. I didn't > thoroughly review the code, but it appears that it only uses IP-based > authentication at the moment. I think it was missing all the > functionality that I desired as well, so I decided not to use it. BibLibre wrote koha-restful to fix the lack of possibilities IDS-DI can provide. We are highly open-minded to contributions (merge request, patches, etc.), if you find some time :) If you want to add features, you can send us a patch at dev_patches AT biblibre DOT com You can find more information about it into README file and opac/rest.pl documentation on http://git.biblibre.com. Cheers, Jonathan > -----Original Message----- > From: Petter Goks?yr ?sen > [mailto:petter.goksoyr.asen at kul.oslo.kommune.no] > Sent: Wednesday, 23 July 2014 12:11 PM > To: David Cook > Subject: SV: [Koha-devel] RFC: /svc/ API > > > David Cook wrote: >> Since there are an indeterminate number of third-party software >> systems using the existing API, I'd recommend versioning and using v2 >> to handle things more RESTfully. > > I agree. We should think twice before breaking existing integrations > and workflows. > > I am also interested to hear peoples opinions about Koha's HTTP APIs > in > general: > - do you want them expanded? for what use cases? > - and more importantly: should Koha's templates make use of i'ts own APIs? > > My library certainly think this could be a fruitful direction for Koha > to go, and want to help make it happen. But if there is no big > interest in the community in this approach, we'll more likely to fork > and/or contribute to Biblibre's koha-restful instead of patching the svc and ILS-DI APIs. > > Regards, > Petter Goks?yr ?sen > Deichmanske bibliotek / Oslo Public Library > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From dcook at prosentient.com.au Thu Jul 24 02:21:28 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 24 Jul 2014 10:21:28 +1000 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> Message-ID: <036501cfa6d5$367fbe20$a37f3a60$@prosentient.com.au> Ah, right you are, Galen. It does use a socket. Yeah, that should be trivial to update connexion_import_daemon.pl. None of our folks use OCLC, but that's good to know. Going back to my earlier email, MarcEdit would probably benefit from a richer Koha API as well. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- From: Galen Charlton [mailto:gmc at esilibrary.com] Sent: Thursday, 24 July 2014 1:22 AM To: David Cook Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] RFC: /svc/ API Hi, On Tue, Jul 22, 2014 at 5:11 PM, David Cook wrote: > +1 to a versioned API. I don't think that I use it for anything at the > moment, but I'm not 100% sure about all our apps. I think we might > have a third-party one that uses it. Also +1 to a versioned API. > This script should probably also use PUT, but I have no idea if OCLC > Connexion supports that. I don't believe it matters as far as Connexion is concerned, as it only talks to connexion_import_daemon.pl via a raw socket. > Since there are an indeterminate number of third-party software > systems using the existing API, I'd recommend versioning and using v2 > to handle things more RESTfully. MarcEdit is one program I know that uses the current API to inject records into a Koha database. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From tomascohen at gmail.com Thu Jul 24 02:30:14 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 23 Jul 2014 21:30:14 -0300 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <036501cfa6d5$367fbe20$a37f3a60$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <036501cfa6d5$367fbe20$a37f3a60$@prosentient.com.au> Message-ID: We should do as we usually do: set a new context for URIs (/rest/ ?) and implement a RESTfull API there, following all the standards, and versioned from the beggining. We could use CGI::Application::Dispatch, merge koha-restfull and work on top of that (it should be discussed whether we agree on the current API or not), or even do it with a framework, like Dancer [1]. And then have a clear deprecation path for the old API. Would be happy to work on that if more people were interested. [1] http://irc.koha-community.org/koha/2014-07-18#i_1538096 On Wed, Jul 23, 2014 at 9:21 PM, David Cook wrote: > Ah, right you are, Galen. It does use a socket. Yeah, that should be > trivial to update connexion_import_daemon.pl. > > None of our folks use OCLC, but that's good to know. > > Going back to my earlier email, MarcEdit would probably benefit from a > richer Koha API as well. > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St, Ultimo, NSW 2007 > > -----Original Message----- > From: Galen Charlton [mailto:gmc at esilibrary.com] > Sent: Thursday, 24 July 2014 1:22 AM > To: David Cook > Cc: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] RFC: /svc/ API > > Hi, > > On Tue, Jul 22, 2014 at 5:11 PM, David Cook > wrote: > > +1 to a versioned API. I don't think that I use it for anything at the > > moment, but I'm not 100% sure about all our apps. I think we might > > have a third-party one that uses it. > > Also +1 to a versioned API. > > > This script should probably also use PUT, but I have no idea if OCLC > > Connexion supports that. > > I don't believe it matters as far as Connexion is concerned, as it only > talks to connexion_import_daemon.pl via a raw socket. > > > Since there are an indeterminate number of third-party software > > systems using the existing API, I'd recommend versioning and using v2 > > to handle things more RESTfully. > > MarcEdit is one program I know that uses the current API to inject records > into a Koha database. > > Regards, > > Galen > -- > Galen Charlton > Manager of Implementation > Equinox Software, Inc. / The Open Source Experts > email: gmc at esilibrary.com > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web: http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Jul 24 04:26:39 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 24 Jul 2014 12:26:39 +1000 Subject: [Koha-devel] RFC: /svc/ API Message-ID: <037801cfa6e6$b30d0ea0$19272be0$@prosentient.com.au> I?d be happy enough with a ?/rest/v1? or something like that. Sure. I haven?t seen ?koha-restfull? in action, so I would probably want to test it quite a bit. As I pointed out before, I don?t think it does any authentication besides checking the ?REMOTE_ADDR? environmental variable, which is problematic. First, that won?t work when Koha sits behind a reverse proxy (or rather?it could have horrible consequences if you allow the ip address for your reverse proxy as it means that ?anyone? could access ?koha-restfull?). Second, it bypasses Koha?s permission authorization system. Above all else, if we?re going to have a service layer, I think it needs to be reasonably secured. At the moment, anyone authenticated via an IP address could change the password for any user, delete users, etc. I think we?d want to spend some time considering what should be part of the ?public? API and what should be part of the ?private? API. The ?public? search should respect ?OpacSuppression?, while the ?private? search would not. I suppose we could have one API, and control the output based on whether the user is authenticated into Koha and whether they?re authorized to use that particular part of the API. Mind you, if we have one API, I wonder where to put it?with the ?intranet? code or the ?opac? code (as in ?koha-restfull?). Personally, it probably makes more sense to locate it with the ?intranet? code as the majority of the API is probably going to need password protection. Exceptions being for ?search? and real-time item ?availability? probably (also accessing public lists, public tags, seeing ratings, public comments/reviews, and perhaps something else I haven?t thought of). Of course, users should be able to authenticate to Koha and be able to get the same data as they would if they logged into the OPAC. Maybe it?s worthwhile to have a public and a private API, although I wouldn?t want to duplicate code if we could avoid it. I suppose the ?public? and ?private? distinctions aren?t quite right. Rather, a ?staff? API and a ?user? API. Personally, I would love a user API that provides all the functionality of the current OPAC. I think that could lead to better integration with discovery services, potentially more mashups, integration with existing library and non-library websites. Theoretically, it could even ?lighten the load? on Koha developers in terms of accessibility and UX. If we?re providing all the necessary data via an API, the OPAC becomes a default interface?while people can build their own interfaces if they desire. That puts the onus back on them, and it also creates some potential for innovation. People (especially ?non-library? people) might find that they really would love to be able to do ?X? on their site, but the API isn?t providing that data. We, the Koha developers, modify the API (or schedule it for the next version), and they, the users/librarians/other developers, get the data they need. You could argue that a library management system really is the staff client. You need a public interface for people to search the library catalogue, to place holds, to have some of that Web 2.0 functionality, but? there?s no reason not to do it via an API and have the OPAC as the stock interface. I was thinking recently about ?Koha?. What is Koha? Is Koha the staff client, the OPAC, or both? In my mind, I think of Koha as the staff client, and I think of the OPAC as the Koha OPAC. The OPAC isn?t really a management system per se. It?s an end-user interface. We give access to the library holdings and give users a way of interacting with those holdings online, but the actual ?management? happens in the staff client. Ok, now I?m just rambling? A ?staff? API would be great as well for integrating with other tools such as MarcEdit, third-party apps, and for internal usage (as per Petter?s email). After reviewing the ?koha-restfull? code a bit more, the use of CGI::Application::Dispatch does look pretty cool. I?m not 100% certain about the use of ?POST? vs ?PUT? in ?koha-restfull? though. If I understand correctly, PUT should only be used when submitting a full resource (if you?re creating a resource or if you?re modifying it by submitting the entire resource), whereas POST should be used when making partial requests/modifications ( http://restcookbook.com/HTTP%20Methods/idempotency/). If we?re to follow all the standards, I would suggest switching PUT and POST in our implementation of ?/rest/v1/?. It might be a bit of a pedantic distinction, but it seems to be me that is how it is ?supposed? to be done. While I continue my pedantry, I?d want us to use English spellings like ?restful? instead of ?restfull?, and ?information? instead of ?informations?. Keeping in line with the ?svc? context, I?d probably prefer ?rest? (or ?rest/v1?)to ?rest.pl? as well. I suppose in terms of priority?I don?t know what to say. I have uses for both a ?staff? and a ?user? API. None of these uses are particularly urgent. If I need to use ?koha-restfull? in the short-term, I?d contribute patches back to BibLibre?s repository. Anyway, that?s my 2 cents (and then some) :p. Hope to see more people interested in this. I suppose there isn?t a lot of incentive to focus on building a Restful API rather than continuing to work on the existing structure. I know I?m more concerned at the moment with improving framework management and search, but?I would really like to see a proper Restful API come about. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Tomas Cohen Arazi [mailto:tomascohen at gmail.com] Sent: Thursday, 24 July 2014 10:30 AM To: David Cook Cc: Galen Charlton; koha-devel Subject: Re: [Koha-devel] RFC: /svc/ API We should do as we usually do: set a new context for URIs (/rest/ ?) and implement a RESTfull API there, following all the standards, and versioned from the beggining. We could use CGI::Application::Dispatch, merge koha-restfull and work on top of that (it should be discussed whether we agree on the current API or not), or even do it with a framework, like Dancer [1]. And then have a clear deprecation path for the old API. Would be happy to work on that if more people were interested. [1] http://irc.koha-community.org/koha/2014-07-18#i_1538096 On Wed, Jul 23, 2014 at 9:21 PM, David Cook > wrote: Ah, right you are, Galen. It does use a socket. Yeah, that should be trivial to update connexion_import_daemon.pl . None of our folks use OCLC, but that's good to know. Going back to my earlier email, MarcEdit would probably benefit from a richer Koha API as well. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- From: Galen Charlton [mailto:gmc at esilibrary.com ] Sent: Thursday, 24 July 2014 1:22 AM To: David Cook Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] RFC: /svc/ API Hi, On Tue, Jul 22, 2014 at 5:11 PM, David Cook > wrote: > +1 to a versioned API. I don't think that I use it for anything at the > moment, but I'm not 100% sure about all our apps. I think we might > have a third-party one that uses it. Also +1 to a versioned API. > This script should probably also use PUT, but I have no idea if OCLC > Connexion supports that. I don't believe it matters as far as Connexion is concerned, as it only talks to connexion_import_daemon.pl via a raw socket. > Since there are an indeterminate number of third-party software > systems using the existing API, I'd recommend versioning and using v2 > to handle things more RESTfully. MarcEdit is one program I know that uses the current API to inject records into a Koha database. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Prosecretar?a de Inform?tica Universidad Nacional de C?rdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Jul 24 08:59:37 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 24 Jul 2014 16:59:37 +1000 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B2@CL122726.oslofelles.oslo.kommune.no> <8761io77oq.fsf@yamato.home> Message-ID: <03dd01cfa70c$d5485fd0$7fd91f70$@prosentient.com.au> Hey Reed: 1) I?ve wondered a bit about that as well. So far, everything I?ve looked at appears to handle PUT and DELETE just fine, but I?m definitely a bit wary of running into odd problems like that. I?d love to hear more about that from others. 2) Agreed. I think POST for writes and GET for reads is the norm. 3) Agreed. Returning HTML sounds like a horrible idea. I?d say XML or JSON. 4) Could you clarify a bit more about what you mean a bout ?API level exceptions?? When I first read that, I thought ?he must be mad!? Then I started to think that perhaps you were talking about application level exceptions? Like??borrowernumber? not found or something like that? I did something similar. When they didn?t provide the borrowernumber, I returned a successful response with an error message. I figure it?s more useful than a ?bad request? http response or something of that sort. I suppose the only downside is that you need to know to check for the error in the response. So?it is tempting to use HTTP error responses instead. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Reed Wade Sent: Wednesday, 23 July 2014 8:09 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] RFC: /svc/ API Just to add my bits regarding rest style APIs because I've been making a lot of those lately: - sticking with GET and POST may simplify things because they're just a lot more typical and you're less likely to run into odd problems with less well tested lib and proxy support - a great rule of thumb is POST for writes and GET for reads; this makes it intentionally harder to compose a url that accidentally writes anything - avoid emitting HTML, the cool kids are letting the browser do all the work now Some folks will not like the next bit of advice because it's not pure REST. I like to never return http error responses for API level exceptions. Instead I like to provide a "success" boolean value in the json response and a text explanation in a separate variable. -reed -------------- next part -------------- An HTML attachment was scrubbed... URL: From petter.goksoyr.asen at kul.oslo.kommune.no Thu Jul 24 11:04:04 2014 From: petter.goksoyr.asen at kul.oslo.kommune.no (=?iso-8859-1?Q?Petter_Goks=F8yr_=C5sen?=) Date: Thu, 24 Jul 2014 11:04:04 +0200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <02fd01cfa622$9e4e3c60$daeab520$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B0@CL122726.oslofelles.oslo.kommune.no>, <02fd01cfa622$9e4e3c60$daeab520$@prosentient.com.au> Message-ID: <13834160A6C2994D8650749DA5EC061B0160585EE5B5@CL122726.oslofelles.oslo.kommune.no> Great comments, David! Thanks for taking the discussion further:) Some comments in line below: Fra: David Cook [dcook at prosentient.com.au] > I think that this also has the potential to increase separation of business > and presentation layers. Of course, I think presentation is important, but > if we focus on making sure that useful data is coming out, we're less likely > to cheat and combine them when we probably shouldn't. I agree - this would perhaps be the best takeaway, IMO. > 2) I'm not sure that I understand what you mean when you ask "should Koha's > templates make use of its own APIs?". > > Do you mean using the API via Javascript on the template, or using the API > via LWP in the Perl script? Yes, I was thinking about such cases, as in recent enhancements using ajax+datatables for fetching data asynchronously. I also think it can be used for more static data, which rarely change. Say for example the list of branches (we have around 30) which populates dropdown several places the staff interface. If this was fetched after page load, by an AJAX request to, say, GET koha/rest/v2/branches, we could set the Cache expiration headers, (to a day, or a month, I dunno) then the browser would cache this particular request, and thus not touch the database at all except when cache expires. For frequently used pages this could lead to a lot of less traffic to the database. Then there is the problem of when you actually DO change this "mostly" static data, like branches... Well, either you can wait until cache expires, you can force to reload (Cltr +R, or Cltr + F5 in most browser), or we must implement some logic on updates which modifies the cache expiration headers. Some more benefits of Koha using its own APIs: - They are kept up to date since they are used by Kohas core - More thought is being put into layout, organization and implementation of the API, as it not just for "someone else", some third-party integration, but for Koha itself. Regards, Petter Goks?yr ?sen Deichmanske bibliotek / Oslo Public Library From petter.goksoyr.asen at kul.oslo.kommune.no Thu Jul 24 11:14:26 2014 From: petter.goksoyr.asen at kul.oslo.kommune.no (=?Windows-1252?Q?Petter_Goks=F8yr_=C5sen?=) Date: Thu, 24 Jul 2014 11:14:26 +0200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <03dd01cfa70c$d5485fd0$7fd91f70$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B2@CL122726.oslofelles.oslo.kommune.no> <8761io77oq.fsf@yamato.home> , <03dd01cfa70c$d5485fd0$7fd91f70$@prosentient.com.au> Message-ID: <13834160A6C2994D8650749DA5EC061B0160585EE5B6@CL122726.oslofelles.oslo.kommune.no> As for error returns: there is nothing wrong with returning a proper HTTP status code AND a human/machine-readable error message. In fact, that's what I would go for. That way, the client can short circut just by checking the status code, or parse the response if it needs to give some feedback ... For example: curl -i -X GET /rest/biblionr/1235 Returns: HTTP/1.1 404 Not Found Date: Thu, 24 Jul 2014 09:11:07 GMT Content-Type: application/json; charset=utf-8 Transfer-Encoding: chunked { "error": "no record with biblilonumber 12345 found"} Regards Petter Goks?yr ?sen Deichmanske bibliotek / Oslo Public Library ________________________________________ Fra: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] på vegne av David Cook [dcook at prosentient.com.au] Sendt: 24. juli 2014 08:59 Til: 'Reed Wade'; koha-devel at lists.koha-community.org Emne: Re: [Koha-devel] RFC: /svc/ API Hey Reed: 1) I?ve wondered a bit about that as well. So far, everything I?ve looked at appears to handle PUT and DELETE just fine, but I?m definitely a bit wary of running into odd problems like that. I?d love to hear more about that from others. 2) Agreed. I think POST for writes and GET for reads is the norm. 3) Agreed. Returning HTML sounds like a horrible idea. I?d say XML or JSON. 4) Could you clarify a bit more about what you mean a bout ?API level exceptions?? When I first read that, I thought ?he must be mad!? Then I started to think that perhaps you were talking about application level exceptions? Like??borrowernumber? not found or something like that? I did something similar. When they didn?t provide the borrowernumber, I returned a successful response with an error message. I figure it?s more useful than a ?bad request? http response or something of that sort. I suppose the only downside is that you need to know to check for the error in the response. So?it is tempting to use HTTP error responses instead. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Reed Wade Sent: Wednesday, 23 July 2014 8:09 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] RFC: /svc/ API Just to add my bits regarding rest style APIs because I've been making a lot of those lately: - sticking with GET and POST may simplify things because they're just a lot more typical and you're less likely to run into odd problems with less well tested lib and proxy support - a great rule of thumb is POST for writes and GET for reads; this makes it intentionally harder to compose a url that accidentally writes anything - avoid emitting HTML, the cool kids are letting the browser do all the work now Some folks will not like the next bit of advice because it's not pure REST. I like to never return http error responses for API level exceptions. Instead I like to provide a "success" boolean value in the json response and a text explanation in a separate variable. -reed From reed at typist.geek.nz Thu Jul 24 12:24:25 2014 From: reed at typist.geek.nz (Reed Wade) Date: Thu, 24 Jul 2014 22:24:25 +1200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <03dd01cfa70c$d5485fd0$7fd91f70$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B2@CL122726.oslofelles.oslo.kommune.no> <8761io77oq.fsf@yamato.home> <03dd01cfa70c$d5485fd0$7fd91f70$@prosentient.com.au> Message-ID: On 24 July 2014 21:14, Petter Goks?yr ?sen < petter.goksoyr.asen at kul.oslo.kommune.no> wrote: > As for error returns: there is nothing wrong with returning a proper HTTP > status code > AND a human/machine-readable error message. In fact, that's what I would > go for. > That way, the client can short circut just by checking the status code, or > parse the response > if it needs to give some feedback ... > > For example: > curl -i -X GET /rest/biblionr/1235 > Returns: > HTTP/1.1 404 Not Found > Date: Thu, 24 Jul 2014 09:11:07 GMT > Content-Type: application/json; charset=utf-8 > Transfer-Encoding: chunked > > { "error": "no record with biblilonumber 12345 found"} > > Regards > Petter Goks?yr ?sen > Deichmanske bibliotek / Oslo Public Library > Yes, I think it comes down to a matter of preference. I can see good reasons to go either way on that. Going the other way is a little simpler to manage for me. And I'm certain some folks will feel more strongly about it than I do. On 24 July 2014 18:59, David Cook wrote: > Hey Reed: > > > > 1) I?ve wondered a bit about that as well. So far, everything I?ve > looked at appears to handle PUT and DELETE just fine, but I?m definitely a > bit wary of running into odd problems like that. I?d love to hear more > about that from others. > I think it's not super likely that PUT and DELETE would be genuine problem on average. I probly worry too much. 2) Agreed. I think POST for writes and GET for reads is the norm. > > 3) Agreed. Returning HTML sounds like a horrible idea. I?d say XML > or JSON. > > 4) Could you clarify a bit more about what you mean a bout ?API > level exceptions?? When I first read that, I thought ?he must be mad!? Then > I started to think that perhaps you were talking about application level > exceptions? Like??borrowernumber? not found or something like that? I did > something similar. When they didn?t provide the borrowernumber, I returned > a successful response with an error message. I figure it?s more useful than > a ?bad request? http response or something of that sort. I suppose the only > downside is that you need to know to check for the error in the response. > So?it is tempting to use HTTP error responses instead. > Petter's example is probably a good illustration. But, no, I take it to the extreme edge of reasonableness. Any application level error I can trap is wrapped in a message which I deliver to the client in an HTTP success response. I should note at this point I'm doing this all in Python which makes that simpler. My thinking is that I want to reserve HTTP errors for transport failures instead of application failures/errors. And it does seem to simplify the way I think about the client/javascript layer of the application. All handled responses are dealt with in one place if they're successful HTTP requests and anything else is a generic catastrophe. -reed > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St, Ultimo, NSW 2007 > > > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Reed Wade > *Sent:* Wednesday, 23 July 2014 8:09 PM > *To:* koha-devel at lists.koha-community.org > > *Subject:* Re: [Koha-devel] RFC: /svc/ API > > > > > > Just to add my bits regarding rest style APIs because I've been making a > lot of those lately: > > > > > > - sticking with GET and POST may simplify things because they're just a > lot more typical and you're less likely to run into odd problems with less > well tested lib and proxy support > > - a great rule of thumb is POST for writes and GET for reads; this makes > it intentionally harder to compose a url that accidentally writes anything > > - avoid emitting HTML, the cool kids are letting the browser do all the > work now > > > > Some folks will not like the next bit of advice because it's not pure > REST. I like to never return http error responses for API level exceptions. > Instead I like to provide a "success" boolean value in the json response > and a text explanation in a separate variable. > > > > -reed > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.charbonnier at inlibro.com Thu Jul 24 19:57:36 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Thu, 24 Jul 2014 13:57:36 -0400 Subject: [Koha-devel] VAT/GST rewrite In-Reply-To: References: Message-ID: <53D14910.6040705@inlibro.com> Hello Jonathan, hello all, Thank you for the RFC. I haven't checked the values but the calculations look good to me! I would like to point out that we have, here in Canada, libraries who manage shipment cost before taxes. So, when they enter the shipment cost (tax excluded), the invoice total is wrong since this cost is added to the total which includes taxes. Recently, inLibro submitted a patch waiting for signoff to fix this issue (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11062). This patch allows librarians to set up new values on the vendor page. They define if shipment costs are tax included or excluded and what the default tax rate is for the shipment cost. It updates the invoice total calculation as well. In the end, the invoice still shows the total tax included but this patch allows librarians to enter the shipment value before taxes and calculate the shipment cost including taxes before adding it to the invoice total. To all, are Canadian libraries the only one having this issue? Any thoughts on the way to fix it? Has what I have suggested look good to you? Jonathan, is it possible to add this feature in your development (and avoid conflicts withs our patch in the future)? I'm ready to update the RFC, answer your questions and, ultimately, test your development! ;^) I'm waiting for your go to update the wiki page. Thanks! Fran?ois Fran?ois Charbonnier, Bibl. prof. / Chef de produits T?l. : (888) 604-2627 francois.charbonnier at inLibro.com inLibro | pour esprit libre | www.inLibro.com Le 2014-07-21 11:32, Jonathan Druart a ?crit : > Hello, > > As promised, I have just finished to translate the spec for the VAT/GST rewrite. > > You can found them on the wiki: > http://wiki.koha-community.org/wiki/GST_Rewrite_RFC > > Note that I am waiting for some feedbacks before starting the development. > I really would like to know if the logic is good for all of you/your > customers/use cases and if you agree on the values calculation. > > Regards, > Jonathan > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Jul 25 01:57:30 2014 From: dcook at prosentient.com.au (David Cook) Date: Fri, 25 Jul 2014 09:57:30 +1000 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <13834160A6C2994D8650749DA5EC061B0160585EE5B6@CL122726.oslofelles.oslo.kommune.no> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B2@CL122726.oslofelles.oslo.kommune.no> <8761io77oq.fsf@yamato.home> , <03dd01cfa70c$d5485fd0$7fd91f70$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B6@CL122726.oslofelles.oslo.kommune.no> Message-ID: <046901cfa79b$07aa3b40$16feb1c0$@prosentient.com.au> Ah, I hadn't thought of that. I like that, Petter! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Petter Goks?yr ?sen Sent: Thursday, 24 July 2014 7:14 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] RFC: /svc/ API As for error returns: there is nothing wrong with returning a proper HTTP status code AND a human/machine-readable error message. In fact, that's what I would go for. That way, the client can short circut just by checking the status code, or parse the response if it needs to give some feedback ... For example: curl -i -X GET /rest/biblionr/1235 Returns: HTTP/1.1 404 Not Found Date: Thu, 24 Jul 2014 09:11:07 GMT Content-Type: application/json; charset=utf-8 Transfer-Encoding: chunked { "error": "no record with biblilonumber 12345 found"} Regards Petter Goks?yr ?sen Deichmanske bibliotek / Oslo Public Library ________________________________________ Fra: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] på vegne av David Cook [dcook at prosentient.com.au] Sendt: 24. juli 2014 08:59 Til: 'Reed Wade'; koha-devel at lists.koha-community.org Emne: Re: [Koha-devel] RFC: /svc/ API Hey Reed: 1) I?ve wondered a bit about that as well. So far, everything I?ve looked at appears to handle PUT and DELETE just fine, but I?m definitely a bit wary of running into odd problems like that. I?d love to hear more about that from others. 2) Agreed. I think POST for writes and GET for reads is the norm. 3) Agreed. Returning HTML sounds like a horrible idea. I?d say XML or JSON. 4) Could you clarify a bit more about what you mean a bout ?API level exceptions?? When I first read that, I thought ?he must be mad!? Then I started to think that perhaps you were talking about application level exceptions? Like ?borrowernumber? not found or something like that? I did something similar. When they didn?t provide the borrowernumber, I returned a successful response with an error message. I figure it?s more useful than a ?bad request? http response or something of that sort. I suppose the only downside is that you need to know to check for the error in the response. So it is tempting to use HTTP error responses instead. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Reed Wade Sent: Wednesday, 23 July 2014 8:09 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] RFC: /svc/ API Just to add my bits regarding rest style APIs because I've been making a lot of those lately: - sticking with GET and POST may simplify things because they're just a lot more typical and you're less likely to run into odd problems with less well tested lib and proxy support - a great rule of thumb is POST for writes and GET for reads; this makes it intentionally harder to compose a url that accidentally writes anything - avoid emitting HTML, the cool kids are letting the browser do all the work now Some folks will not like the next bit of advice because it's not pure REST. I like to never return http error responses for API level exceptions. Instead I like to provide a "success" boolean value in the json response and a text explanation in a separate variable. -reed _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From dcook at prosentient.com.au Fri Jul 25 02:15:57 2014 From: dcook at prosentient.com.au (David Cook) Date: Fri, 25 Jul 2014 10:15:57 +1000 Subject: [Koha-devel] FW: RFC: /svc/ API References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B0@CL122726.oslofelles.oslo.kommune.no>, <02fd01cfa622$9e4e3c60$daeab520$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B5@CL122726.oslofelles.oslo.kommune.no> Message-ID: <046b01cfa79d$9b1c4920$d154db60$@prosentient.com.au> You're very welcome, Petter. I'm happy to be having this discussion! I've included some inline comments below as well. > I also think it can be used for more static data, which rarely change. > Say for example the list of branches (we have around 30) which > populates dropdown several places the staff interface. If this was > fetched after page load, by an AJAX request to, say, GET > koha/rest/v2/branches, we could set the Cache expiration headers, (to > a day, or a month, I dunno) then the browser would cache this > particular request, and thus not touch the database at all except when > cache expires. For frequently used pages this could lead to a lot of > less traffic to the database. Then there is the problem of when you > actually DO change this "mostly" static data, like branches... Well, > either you can wait until cache expires, you can force to reload (Cltr > +R, or Cltr + F5 in most browser), or we must implement some logic on updates which modifies the cache expiration headers. I don't have much experience with caching, but that sounds interesting. One worry I have about using AJAX in the OPAC is the second or so that it can take to load an element on a page sometimes. The page loads and then elements can "jump". For instance, I added a drop-down menu for "Collection" next to the masthead search box. It didn't load very smoothly. I wonder if it would if it were cached as it doesn't need to do that database query. Of course, loading search result facets would take longer, but we could add a "Loading..." or "Calculating facets..." message in that case, so that users would know what the system is doing. > Some more benefits of Koha using its own APIs: > - They are kept up to date since they are used by Kohas core > - More thought is being put into layout, organization and > implementation of the API, as it > not just for "someone else", some third-party integration, but for > Koha itself. Agreed. Since Koha would be both client and server, I think more care would be put into architecture. Since it would depend on its own API, it would have to be up-to-date. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From jonathan.druart at biblibre.com Fri Jul 25 12:13:20 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Fri, 25 Jul 2014 12:13:20 +0200 Subject: [Koha-devel] VAT/GST rewrite In-Reply-To: <53D14910.6040705@inlibro.com> References: <53D14910.6040705@inlibro.com> Message-ID: Bonjour Fran?ois, On the koha-fr ML, Mathieu Saby asked me why I use the shipmentcost field in aqorders. And I think he is right, We should use the one in aqinvoices. I added an entry 'questions/notes' to the wiki. If you update the wiki with the different cases/values, I could take into account on refactoring/rewriting the code. If you promise me to test the patches, it is a good deal :) Cheers, Jonathan 2014-07-24 19:57 GMT+02:00 Francois Charbonnier : > Hello Jonathan, hello all, > > Thank you for the RFC. I haven't checked the values but the calculations > look good to me! > > I would like to point out that we have, here in Canada, libraries who manage > shipment cost before taxes. So, when they enter the shipment cost (tax > excluded), the invoice total is wrong since this cost is added to the total > which includes taxes. > > Recently, inLibro submitted a patch waiting for signoff to fix this issue > (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11062). This patch > allows librarians to set up new values on the vendor page. They define if > shipment costs are tax included or excluded and what the default tax rate is > for the shipment cost. It updates the invoice total calculation as well. > > In the end, the invoice still shows the total tax included but this patch > allows librarians to enter the shipment value before taxes and calculate the > shipment cost including taxes before adding it to the invoice total. > > To all, are Canadian libraries the only one having this issue? Any thoughts > on the way to fix it? Has what I have suggested look good to you? > > Jonathan, is it possible to add this feature in your development (and avoid > conflicts withs our patch in the future)? I'm ready to update the RFC, > answer your questions and, ultimately, test your development! ;^) > > I'm waiting for your go to update the wiki page. > > Thanks! > > Fran?ois > > Fran?ois Charbonnier, > Bibl. prof. / Chef de produits > > T?l. : (888) 604-2627 > francois.charbonnier at inLibro.com > > inLibro | pour esprit libre | www.inLibro.com > > Le 2014-07-21 11:32, Jonathan Druart a ?crit : > > Hello, > > As promised, I have just finished to translate the spec for the VAT/GST > rewrite. > > You can found them on the wiki: > http://wiki.koha-community.org/wiki/GST_Rewrite_RFC > > Note that I am waiting for some feedbacks before starting the development. > I really would like to know if the logic is good for all of you/your > customers/use cases and if you agree on the values calculation. > > Regards, > Jonathan > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From francois.charbonnier at inlibro.com Fri Jul 25 14:26:31 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Fri, 25 Jul 2014 08:26:31 -0400 Subject: [Koha-devel] VAT/GST rewrite In-Reply-To: References: <53D14910.6040705@inlibro.com> Message-ID: <53D24CF7.3040506@inlibro.com> Salut Jonathan, I agree with Mathieu. Using the value within aqinvoices is a better idea. I will update the wiki and yup, you have my word that I will test this one! ;^) Thanks! Fran?ois Fran?ois Charbonnier, Bibl. prof. / Chef de produits T?l. : (888) 604-2627 francois.charbonnier at inLibro.com inLibro | pour esprit libre | www.inLibro.com Le 2014-07-25 06:13, Jonathan Druart a ?crit : > Bonjour Fran?ois, > > On the koha-fr ML, Mathieu Saby asked me why I use the shipmentcost > field in aqorders. And I think he is right, We should use the one in > aqinvoices. > I added an entry 'questions/notes' to the wiki. > > If you update the wiki with the different cases/values, I could take > into account on refactoring/rewriting the code. > If you promise me to test the patches, it is a good deal :) > > Cheers, > Jonathan > > 2014-07-24 19:57 GMT+02:00 Francois Charbonnier > : >> Hello Jonathan, hello all, >> >> Thank you for the RFC. I haven't checked the values but the calculations >> look good to me! >> >> I would like to point out that we have, here in Canada, libraries who manage >> shipment cost before taxes. So, when they enter the shipment cost (tax >> excluded), the invoice total is wrong since this cost is added to the total >> which includes taxes. >> >> Recently, inLibro submitted a patch waiting for signoff to fix this issue >> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11062). This patch >> allows librarians to set up new values on the vendor page. They define if >> shipment costs are tax included or excluded and what the default tax rate is >> for the shipment cost. It updates the invoice total calculation as well. >> >> In the end, the invoice still shows the total tax included but this patch >> allows librarians to enter the shipment value before taxes and calculate the >> shipment cost including taxes before adding it to the invoice total. >> >> To all, are Canadian libraries the only one having this issue? Any thoughts >> on the way to fix it? Has what I have suggested look good to you? >> >> Jonathan, is it possible to add this feature in your development (and avoid >> conflicts withs our patch in the future)? I'm ready to update the RFC, >> answer your questions and, ultimately, test your development! ;^) >> >> I'm waiting for your go to update the wiki page. >> >> Thanks! >> >> Fran?ois >> >> Fran?ois Charbonnier, >> Bibl. prof. / Chef de produits >> >> T?l. : (888) 604-2627 >> francois.charbonnier at inLibro.com >> >> inLibro | pour esprit libre | www.inLibro.com >> >> Le 2014-07-21 11:32, Jonathan Druart a ?crit : >> >> Hello, >> >> As promised, I have just finished to translate the spec for the VAT/GST >> rewrite. >> >> You can found them on the wiki: >> http://wiki.koha-community.org/wiki/GST_Rewrite_RFC >> >> Note that I am waiting for some feedbacks before starting the development. >> I really would like to know if the logic is good for all of you/your >> customers/use cases and if you agree on the values calculation. >> >> Regards, >> Jonathan >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Fri Jul 25 15:32:14 2014 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Fri, 25 Jul 2014 15:32:14 +0200 Subject: [Koha-devel] Koha 3.14.09 released Message-ID: <53D25C5E.6080707@biblibre.com> The Koha community is proud to announce the release of 3.14.9. This is a maintenance release and contains some enhancements and several bugfixes. As always you can download the release from http://download.koha-community.org. Have a look at release post : http://koha-community.org/koha-3-14-9-released "Get the pie while it's hot" ;) Regards, -- Fridolin SOMERS Biblibre - P?les support et syst?me fridolin.somers at biblibre.com From z.tajoli at cineca.it Fri Jul 25 18:15:35 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Fri, 25 Jul 2014 18:15:35 +0200 Subject: [Koha-devel] Test of UTF-8 (bug 11944) Message-ID: <53D282A7.5040600@cineca.it> Hi, I have stopped to test bug 11944 on sandbox 6 because authority seems not indexed. On monday Paola Rossi tests circulation. Bye -- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate From z.tajoli at cineca.it Fri Jul 25 18:25:25 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Fri, 25 Jul 2014 18:25:25 +0200 Subject: [Koha-devel] Test of UTF-8 (bug 11944) - Problem on BibLibre Branch Message-ID: <53D284F5.20003@cineca.it> Hi to all, I'm not see this patch http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30016&action=diff in the BibLibre branch on bug 11944, this branch: biblibre/ft/bug_11944 in http://git.biblibre.com/biblibre/kohac.git Or do i check in the wrong place ? Bye Zeno Tajoli --------------- Dr. Zeno Tajoli Soluzioni per la Ricerca Istituzionale - Automazione Biblioteche z.tajoli at cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From kyle.m.hall at gmail.com Fri Jul 25 20:33:36 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Fri, 25 Jul 2014 14:33:36 -0400 Subject: [Koha-devel] Koha 3.12.14 Released! Message-ID: The Koha community is proud to announce the release of 3.12.14. This is a maintenance release and contains several bugfixes. As always you can download the release from http://download.koha-community.org. Release notes available at http://koha-community.org/koha-3-12-14-released/ http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.renvoize at ptfs-europe.com Tue Jul 29 11:51:44 2014 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Tue, 29 Jul 2014 10:51:44 +0100 Subject: [Koha-devel] FW: RFC: /svc/ API In-Reply-To: <046b01cfa79d$9b1c4920$d154db60$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B0@CL122726.oslofelles.oslo.kommune.no> <02fd01cfa622$9e4e3c60$daeab520$@prosentient.com.au> <13834160A6C2994D8650749DA5EC061B0160585EE5B5@CL122726.oslofelles.oslo.kommune.no> <046b01cfa79d$9b1c4920$d154db60$@prosentient.com.au> Message-ID: An interesting conversation all in all. I'm most certainly in favour of a well implemented restful api and dogfooding it for the opac so we keep it useful and up to date. I found this article very useful when crafting some api's for another product I work on regularly: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api As for the caching scenario, that's interesting indeed, and I can see huge advantages to gain here. I would suggest adding an optional hash/token to such requests and setting the cache time to 'forever'. That way we could link a change of the data to a change of the token, and hence manage the cache ourselves at the template level. If you want an idea of what I'm getting at, take a look at the docs for googles mod_pagespeed, as that's where I got my inspiration), or drop me a line for a chat. All exciting thoughts. I'll certainly be working on the API's at some point as part of our work using api's for the vufind connectors so I'm be happy to input a bit of time into this once the ball is rolling. Martin Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com On 25 July 2014 01:15, David Cook wrote: > > You're very welcome, Petter. I'm happy to be having this discussion! > > I've included some inline comments below as well. > > > I also think it can be used for more static data, which rarely change. > > Say for example the list of branches (we have around 30) which > > populates dropdown several places the staff interface. If this was > > fetched after page load, by an AJAX request to, say, GET > > koha/rest/v2/branches, we could set the Cache expiration headers, (to > > a day, or a month, I dunno) then the browser would cache this > > particular request, and thus not touch the database at all except when > > cache expires. For frequently used pages this could lead to a lot of > > less traffic to the database. Then there is the problem of when you > > actually DO change this "mostly" static data, like branches... Well, > > either you can wait until cache expires, you can force to reload (Cltr > > +R, or Cltr + F5 in most browser), or we must implement some logic on > updates which modifies the cache expiration headers. > > I don't have much experience with caching, but that sounds interesting. > > One worry I have about using AJAX in the OPAC is the second or so that it > can take to load an element on a page sometimes. The page loads and then > elements can "jump". For instance, I added a drop-down menu for > "Collection" > next to the masthead search box. It didn't load very smoothly. I wonder if > it would if it were cached as it doesn't need to do that database query. > > Of course, loading search result facets would take longer, but we could add > a "Loading..." or "Calculating facets..." message in that case, so that > users would know what the system is doing. > > > Some more benefits of Koha using its own APIs: > > - They are kept up to date since they are used by Kohas core > > - More thought is being put into layout, organization and > > implementation of the API, as it > > not just for "someone else", some third-party integration, but for > > Koha itself. > > Agreed. Since Koha would be both client and server, I think more care would > be put into architecture. Since it would depend on its own API, it would > have to be up-to-date. > > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St, Ultimo, NSW 2007 > > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Tue Jul 29 17:35:59 2014 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Tue, 29 Jul 2014 11:35:59 -0400 Subject: [Koha-devel] SIP2 AF field sent even if patron password is invalid Message-ID: I have an interesting SIP2 implementation issue. When authenticating through SIP2, if a valid patron id is passed in, but an *invalid* password is passed in, Koha's SIP2 server send back the AF ( screen message ) field even though the credentials are invalid. If a patron owes any fees, the server will send back the amount owed in an AF field. For instance, Overdrive will display this AF field even with an invalid password. Freegal does not ( but it may not display any AF field ). At least one SIP2 machine we tested against will also display the AF field when an invalid password is submitted. Is this a Koha issue, or a client side issue? The SIP2 protocol specification does not indicate that AF fields should be removed in the event of an invalid password. My guess is that some SIP2 server implementations may send back "Invalid password" messages which may be useful. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Tue Jul 29 17:55:45 2014 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 29 Jul 2014 08:55:45 -0700 Subject: [Koha-devel] SIP2 AF field sent even if patron password is invalid In-Reply-To: References: Message-ID: Hi, On Tue, Jul 29, 2014 at 8:35 AM, Kyle Hall wrote: > I have an interesting SIP2 implementation issue. When authenticating through > SIP2, if a valid patron id is passed in, but an *invalid* password is passed > in, Koha's SIP2 server send back the AF ( screen message ) field even though > the credentials are invalid. If a patron owes any fees, the server will send > back the amount owed in an AF field. Sadly, it looks like the only provision that the SIP2 specification makes for dealing with an invalid patron password is to set the CQ field. My reading of the spec is that the expected behavior regarding other fields in the patron status and patron information responses is undefined when an incorrect password is supplied. > For instance, Overdrive will display this AF field even with an invalid > password. Freegal does not ( but it may not display any AF field ). At least > one SIP2 machine we tested against will also display the AF field when an > invalid password is submitted. > > Is this a Koha issue, or a client side issue? The SIP2 protocol > specification does not indicate that AF fields should be removed in the > event of an invalid password. My guess is that some SIP2 server > implementations may send back "Invalid password" messages which may be > useful. Possibly. In any event, I think we should either not send an AF, or send one that contains something like "Invalid password" if the patron password is wrong. That leaves open the question about what to do with other fields, particularly in the patron information response. My feeling is that we should be conservative: if a patron password is sent via patron status or patron information requests, and it's wrong, no information about the patron should be returned. There may need to be a configuration option controlling this behavior. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From julian.maurice at biblibre.com Wed Jul 30 10:41:56 2014 From: julian.maurice at biblibre.com (Julian Maurice) Date: Wed, 30 Jul 2014 10:41:56 +0200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <036501cfa6d5$367fbe20$a37f3a60$@prosentient.com.au> Message-ID: <53D8AFD4.5090100@biblibre.com> We at BibLibre wrote koha-restful as a third-party application to be able to extend it quickly. Now that things are more stable (the last commit was written a month ago), I would be happy to submit a patch to integrate koha-restful into Koha. But IMO it lacks a decent identification/authentication system before it could be integrated. So if someone is interested to work on that, he is welcome :) Le 24/07/2014 02:30, Tomas Cohen Arazi a ?crit : > We should do as we usually do: set a new context for URIs (/rest/ ?) and > implement a RESTfull API there, following all the standards, and versioned > from the beggining. > > We could use CGI::Application::Dispatch, merge koha-restfull and work on > top of that (it should be discussed whether we agree on the current API or > not), or even do it with a framework, like Dancer [1]. > > And then have a clear deprecation path for the old API. > > Would be happy to work on that if more people were interested. > > [1] http://irc.koha-community.org/koha/2014-07-18#i_1538096 > > > > On Wed, Jul 23, 2014 at 9:21 PM, David Cook > wrote: > >> Ah, right you are, Galen. It does use a socket. Yeah, that should be >> trivial to update connexion_import_daemon.pl. >> >> None of our folks use OCLC, but that's good to know. >> >> Going back to my earlier email, MarcEdit would probably benefit from a >> richer Koha API as well. >> >> David Cook >> Systems Librarian >> Prosentient Systems >> 72/330 Wattle St, Ultimo, NSW 2007 >> >> -----Original Message----- >> From: Galen Charlton [mailto:gmc at esilibrary.com] >> Sent: Thursday, 24 July 2014 1:22 AM >> To: David Cook >> Cc: koha-devel at lists.koha-community.org >> Subject: Re: [Koha-devel] RFC: /svc/ API >> >> Hi, >> >> On Tue, Jul 22, 2014 at 5:11 PM, David Cook >> wrote: >>> +1 to a versioned API. I don't think that I use it for anything at the >>> moment, but I'm not 100% sure about all our apps. I think we might >>> have a third-party one that uses it. >> >> Also +1 to a versioned API. >> >>> This script should probably also use PUT, but I have no idea if OCLC >>> Connexion supports that. >> >> I don't believe it matters as far as Connexion is concerned, as it only >> talks to connexion_import_daemon.pl via a raw socket. >> >>> Since there are an indeterminate number of third-party software >>> systems using the existing API, I'd recommend versioning and using v2 >>> to handle things more RESTfully. >> >> MarcEdit is one program I know that uses the current API to inject records >> into a Koha database. >> >> Regards, >> >> Galen >> -- >> Galen Charlton >> Manager of Implementation >> Equinox Software, Inc. / The Open Source Experts >> email: gmc at esilibrary.com >> direct: +1 770-709-5581 >> cell: +1 404-984-4366 >> skype: gmcharlt >> web: http://www.esilibrary.com/ >> Supporting Koha and Evergreen: http://koha-community.org & >> http://evergreen-ils.org >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Julian Maurice BibLibre From dcook at prosentient.com.au Thu Jul 31 02:09:55 2014 From: dcook at prosentient.com.au (David Cook) Date: Thu, 31 Jul 2014 10:09:55 +1000 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <53D8AFD4.5090100@biblibre.com> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <036501cfa6d5$367fbe20$a37f3a60$@prosentient.com.au> <53D8AFD4.5090100@biblibre.com> Message-ID: <06ab01cfac53$c2165420$4642fc60$@prosentient.com.au> Awesome. Thanks, Julian! As for authentication, I think adding a call to C4::Auth:: check_api_auth() in rest.pl should probably do the trick. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Julian Maurice > Sent: Wednesday, 30 July 2014 6:42 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] RFC: /svc/ API > > We at BibLibre wrote koha-restful as a third-party application to be able to > extend it quickly. > Now that things are more stable (the last commit was written a month ago), I > would be happy to submit a patch to integrate koha-restful into Koha. > But IMO it lacks a decent identification/authentication system before it could > be integrated. So if someone is interested to work on that, he is welcome :) > > Le 24/07/2014 02:30, Tomas Cohen Arazi a ?crit : > > We should do as we usually do: set a new context for URIs (/rest/ ?) > > and implement a RESTfull API there, following all the standards, and > > versioned from the beggining. > > > > We could use CGI::Application::Dispatch, merge koha-restfull and work > > on top of that (it should be discussed whether we agree on the current > > API or not), or even do it with a framework, like Dancer [1]. > > > > And then have a clear deprecation path for the old API. > > > > Would be happy to work on that if more people were interested. > > > > [1] http://irc.koha-community.org/koha/2014-07-18#i_1538096 > > > > > > > > On Wed, Jul 23, 2014 at 9:21 PM, David Cook > > wrote: > > > >> Ah, right you are, Galen. It does use a socket. Yeah, that should be > >> trivial to update connexion_import_daemon.pl. > >> > >> None of our folks use OCLC, but that's good to know. > >> > >> Going back to my earlier email, MarcEdit would probably benefit from > >> a richer Koha API as well. > >> > >> David Cook > >> Systems Librarian > >> Prosentient Systems > >> 72/330 Wattle St, Ultimo, NSW 2007 > >> > >> -----Original Message----- > >> From: Galen Charlton [mailto:gmc at esilibrary.com] > >> Sent: Thursday, 24 July 2014 1:22 AM > >> To: David Cook > >> Cc: koha-devel at lists.koha-community.org > >> Subject: Re: [Koha-devel] RFC: /svc/ API > >> > >> Hi, > >> > >> On Tue, Jul 22, 2014 at 5:11 PM, David Cook > >> > >> wrote: > >>> +1 to a versioned API. I don't think that I use it for anything at > >>> +the > >>> moment, but I'm not 100% sure about all our apps. I think we might > >>> have a third-party one that uses it. > >> > >> Also +1 to a versioned API. > >> > >>> This script should probably also use PUT, but I have no idea if OCLC > >>> Connexion supports that. > >> > >> I don't believe it matters as far as Connexion is concerned, as it > >> only talks to connexion_import_daemon.pl via a raw socket. > >> > >>> Since there are an indeterminate number of third-party software > >>> systems using the existing API, I'd recommend versioning and using > >>> v2 to handle things more RESTfully. > >> > >> MarcEdit is one program I know that uses the current API to inject > >> records into a Koha database. > >> > >> Regards, > >> > >> Galen > >> -- > >> Galen Charlton > >> Manager of Implementation > >> Equinox Software, Inc. / The Open Source Experts > >> email: gmc at esilibrary.com > >> direct: +1 770-709-5581 > >> cell: +1 404-984-4366 > >> skype: gmcharlt > >> web: http://www.esilibrary.com/ > >> Supporting Koha and Evergreen: http://koha-community.org & > >> http://evergreen-ils.org > >> > >> > >> _______________________________________________ > >> Koha-devel mailing list > >> Koha-devel at lists.koha-community.org > >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > >> website : http://www.koha-community.org/ git : > >> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ > >> > > > > > > > > > > > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : http://www.koha-community.org/ > > git : http://git.koha-community.org/ > > bugs : http://bugs.koha-community.org/ > > > > > -- > Julian Maurice > BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From julian.maurice at biblibre.com Thu Jul 31 10:16:47 2014 From: julian.maurice at biblibre.com (Julian Maurice) Date: Thu, 31 Jul 2014 10:16:47 +0200 Subject: [Koha-devel] RFC: /svc/ API In-Reply-To: <06ab01cfac53$c2165420$4642fc60$@prosentient.com.au> References: <02f001cfa60a$9d55bf80$d8013e80$@prosentient.com.au> <036501cfa6d5$367fbe20$a37f3a60$@prosentient.com.au> <53D8AFD4.5090100@biblibre.com> <06ab01cfac53$c2165420$4642fc60$@prosentient.com.au> Message-ID: <53D9FB6F.3060307@biblibre.com> I was thinking about how to transmit user credentials from the third-party application to Koha. Something using private/public keys like Amazon AWS seems the way to go. Example: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ Le 31/07/2014 02:09, David Cook a ?crit : > Awesome. Thanks, Julian! > > As for authentication, I think adding a call to C4::Auth:: check_api_auth() > in rest.pl should probably do the trick. > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St, Ultimo, NSW 2007 > >> -----Original Message----- >> From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- >> bounces at lists.koha-community.org] On Behalf Of Julian Maurice >> Sent: Wednesday, 30 July 2014 6:42 PM >> To: koha-devel at lists.koha-community.org >> Subject: Re: [Koha-devel] RFC: /svc/ API >> >> We at BibLibre wrote koha-restful as a third-party application to be able > to >> extend it quickly. >> Now that things are more stable (the last commit was written a month ago), > I >> would be happy to submit a patch to integrate koha-restful into Koha. >> But IMO it lacks a decent identification/authentication system before it > could >> be integrated. So if someone is interested to work on that, he is welcome > :) >> >> Le 24/07/2014 02:30, Tomas Cohen Arazi a ?crit : >>> We should do as we usually do: set a new context for URIs (/rest/ ?) >>> and implement a RESTfull API there, following all the standards, and >>> versioned from the beggining. >>> >>> We could use CGI::Application::Dispatch, merge koha-restfull and work >>> on top of that (it should be discussed whether we agree on the current >>> API or not), or even do it with a framework, like Dancer [1]. >>> >>> And then have a clear deprecation path for the old API. >>> >>> Would be happy to work on that if more people were interested. >>> >>> [1] http://irc.koha-community.org/koha/2014-07-18#i_1538096 >>> >>> >>> >>> On Wed, Jul 23, 2014 at 9:21 PM, David Cook >>> wrote: >>> >>>> Ah, right you are, Galen. It does use a socket. Yeah, that should be >>>> trivial to update connexion_import_daemon.pl. >>>> >>>> None of our folks use OCLC, but that's good to know. >>>> >>>> Going back to my earlier email, MarcEdit would probably benefit from >>>> a richer Koha API as well. >>>> >>>> David Cook >>>> Systems Librarian >>>> Prosentient Systems >>>> 72/330 Wattle St, Ultimo, NSW 2007 >>>> >>>> -----Original Message----- >>>> From: Galen Charlton [mailto:gmc at esilibrary.com] >>>> Sent: Thursday, 24 July 2014 1:22 AM >>>> To: David Cook >>>> Cc: koha-devel at lists.koha-community.org >>>> Subject: Re: [Koha-devel] RFC: /svc/ API >>>> >>>> Hi, >>>> >>>> On Tue, Jul 22, 2014 at 5:11 PM, David Cook >>>> >>>> wrote: >>>>> +1 to a versioned API. I don't think that I use it for anything at >>>>> +the >>>>> moment, but I'm not 100% sure about all our apps. I think we might >>>>> have a third-party one that uses it. >>>> >>>> Also +1 to a versioned API. >>>> >>>>> This script should probably also use PUT, but I have no idea if OCLC >>>>> Connexion supports that. >>>> >>>> I don't believe it matters as far as Connexion is concerned, as it >>>> only talks to connexion_import_daemon.pl via a raw socket. >>>> >>>>> Since there are an indeterminate number of third-party software >>>>> systems using the existing API, I'd recommend versioning and using >>>>> v2 to handle things more RESTfully. >>>> >>>> MarcEdit is one program I know that uses the current API to inject >>>> records into a Koha database. >>>> >>>> Regards, >>>> >>>> Galen >>>> -- >>>> Galen Charlton >>>> Manager of Implementation >>>> Equinox Software, Inc. / The Open Source Experts >>>> email: gmc at esilibrary.com >>>> direct: +1 770-709-5581 >>>> cell: +1 404-984-4366 >>>> skype: gmcharlt >>>> web: http://www.esilibrary.com/ >>>> Supporting Koha and Evergreen: http://koha-community.org & >>>> http://evergreen-ils.org >>>> >>>> >>>> _______________________________________________ >>>> Koha-devel mailing list >>>> Koha-devel at lists.koha-community.org >>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>>> website : http://www.koha-community.org/ git : >>>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel at lists.koha-community.org >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >>> >> >> >> -- >> Julian Maurice >> BibLibre >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ > > -- Julian Maurice BibLibre From mh_zalabany at hotmail.com Thu Jul 31 11:10:57 2014 From: mh_zalabany at hotmail.com (Mohamed zalabany) Date: Thu, 31 Jul 2014 09:10:57 +0000 Subject: [Koha-devel] Paid Support list adding request Message-ID: Hi Allcould you please add our company information to the the Paid Support companies list Company Name: Egyptian Prime Vision (EPV) Contact Person: Mohamed el-Zalabany Contact email: info at egyprimevision.com Website: egyprimevision.com Telephone: +20237484275, Cell : +201069261930, +201154850780 Address : 13 Mohyee el-Din Abu el-Ezz st. ?Dokki-Giza-Egypt Short description of our services: We are Egyptian Prime Vision, an SME-level company working in the field of library technology and IT services operating in the Middle East market and based in Egypt. We have had 10 year experience implementing large projects of automating library system using open source systems covering areas like supporting digital document management systems and all other library related IT tasks such as indexing and digitization as well as system upgrading and training. Currently our customers include universities, public libraries. However, our customer portfolio is currently expanding to include corporate sectors and companies with various needs that our company can meet. Field of work : Library automation solutions including (KOHA ? DSPACE, and other software)- Digitization ? Web design and developing software ? out sourcing ? RFID solutions Thanks All Best -------------- next part -------------- An HTML attachment was scrubbed... URL: From wizzyrea at gmail.com Thu Jul 31 23:23:58 2014 From: wizzyrea at gmail.com (Liz Rea) Date: Fri, 1 Aug 2014 09:23:58 +1200 Subject: [Koha-devel] Paid Support list adding request In-Reply-To: References: Message-ID: Hi, Thank you for your submission. We would be happy to add your listing once your site complies with the requirements to be listed, outlined at http://koha-community.org/support/paid-support/how-to-get-listed/ Specifically, the Koha community requires a link from your product offering page (http://egyprimevision.com/?page_id=24) back to koha-community.org. Apologies if it is there and we missed it. Thank you, Liz Rea On Thu, Jul 31, 2014 at 9:10 PM, Mohamed zalabany wrote: > *Hi All* > > *could you please add our company information to the the *Paid Support > companies list > > > *Company Name*: Egyptian Prime Vision (EPV) > > *Contact Person*: Mohamed el-Zalabany > > *Contact email*: info at egyprimevision.com > > *Website*: egyprimevision.com > > *Telephone*: +20237484275, > > *Cell* : +201069261930, +201154850780 > > *Address *: 13 Mohyee el-Din Abu el-Ezz st. ?Dokki-Giza-Egypt > > > > *Short description of our services: * > > We are Egyptian Prime Vision, an SME-level company working in the field of > library technology and IT services operating in the Middle East market and > based in Egypt. > > We have had 10 year experience implementing large projects of automating > library system using open source systems covering areas like supporting > digital document management systems and all other library related IT > tasks such as indexing and digitization as well > as system upgrading and training. Currently our customers include > universities, public libraries. However, our customer portfolio is > currently expanding to include corporate sectors and companies with various > needs that our company can meet. > > *Field of work* : Library automation solutions including (KOHA ? DSPACE, > and other software)- Digitization ? Web design and developing software ? > out sourcing ? RFID solutions > > > > Thanks All Best > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: