From dung.hoang at dlcorp.com.vn Fri Aug 1 08:31:00 2014 From: dung.hoang at dlcorp.com.vn (Dung Hoang) Date: Fri, 1 Aug 2014 13:31:00 +0700 Subject: [Koha-devel] Paid Support list adding request In-Reply-To: References: Message-ID: <53db337f.6d45440a.4415.423f@mx.google.com> Dear Liz, community, I would like to submit our application for our company, D&L to be listed in Koha paid support list for Vietnam. We have complied all requirements as followed: - Company Name: D&L Technology Integration and Consulting JSC., Vietnam (D&L) - Contact Person: Dung Hoang - Director - Contact email: dung.hoang at dlcorp.com.vn - Website: www.koha.vn - Telephone: +84 4 6655 2836 - Address: 199E Dai La street, Hanoi, Vietnam - Short description of your services: o D&L is one of the most reputed IT and library services and solutions provider in Vietnam. We help library to build IT infrastructure (server, storage, network etc?), to deploy library software application (Koha, Dspace) and others such as EM and RFID applications. We also provide cataloging services to libraries. o With regards to Koha, D&L is the only one company in Vietnam until now promoting Koha for Vietnam and responsible for development and supports for libraries and developers. D&L?s Koha paid services are installation services, configurations services, customization services, training services. o D&L has uploaded the full Vietnamese translation for Koha 3.12 last month to the community (http://translate.koha-community.org/vi/312/ ). The Vietnamese translation of Koha 3.16 will be uploaded this month. o www.koha.vn which is 100% coded using Koha source code, is our official website for Koha services. The website has Demo/Download section (http://www.koha.vn/cgi-bin/koha/demo-download.pl ) where users can download all necessary Koha installation files and instruction. It also contain Demo system so that users can go in and test the system. o Koha-community.org link has been included in the website. Thank you and we are looking forward to be included in the list. Best regards Dung Hoang Director D&L Technology Integration and Consulting JSC and Koha Vietnam Email: dung.hoang at dlcorp.com.vn Cell: +84 936847430 Phone: +84 4 6655 2836 | Fax: +84 4 3767 8812 www.dlcorp.com.vn | www.koha.vn From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Liz Rea Sent: Friday, August 01, 2014 4:24 AM To: Mohamed zalabany Cc: koha_developers Subject: Re: [Koha-devel] Paid Support list adding request 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: From mh_zalabany at hotmail.com Fri Aug 1 10:55:35 2014 From: mh_zalabany at hotmail.com (Mohamed zalabany) Date: Fri, 1 Aug 2014 08:55:35 +0000 Subject: [Koha-devel] FW: Paid Support list adding request In-Reply-To: References: , , Message-ID: Dear Lizthank you for your interest and your replyi have put the link of the koha community web page in this pagehttp://egyprimevision.com/?page_id=24 please i need to change the cell phone number to Cell : +201009989496, +201154850780All best Mohamed el-ZalabanyGMEgyptian Prime Vision Date: Fri, 1 Aug 2014 09:23:58 +1200 Subject: Re: [Koha-devel] Paid Support list adding request From: wizzyrea at gmail.com To: mh_zalabany at hotmail.com CC: koha-devel at lists.koha-community.org 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 : +201009989496, +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: From arun25jun at gmail.com Mon Aug 4 09:30:35 2014 From: arun25jun at gmail.com (Arun kumar) Date: Mon, 4 Aug 2014 13:00:35 +0530 Subject: [Koha-devel] Basket Creation in neworderempty.pl Message-ID: Hello Guys, We are developing some Customization programming for KOHA 3.12 to meet our requirements, I have trouble in creation of basket in neworderempty.pl i have added the form in template of neworderempty.tmpl my $op = $input ->param('op'); my $booksellerid = $input->param('booksellerid'); my $branches = GetBranches; if ( $op eq 'add_form' ) { my @contractloop; my $basket; my $bookseller = GetBookSellerFromId($booksellerid); my $count = scalar @contractloop; if ( $count > 0) { $template->param(contractloop => \@contractloop, basketcontractnumber => $basket->{'contractnumber'}); } my @booksellers = C4::Bookseller::GetBookSeller(); $template->param( add_form => 1, basketname => $basket->{'basketname'}, basketnote => $basket->{'note'}, basketbooksellernote => $basket->{'booksellernote'}, booksellername => $bookseller->{'name'}, booksellerid => $booksellerid, basketno => $basketno, booksellers => \@booksellers, deliveryplace => $basket->{deliveryplace}, billingplace => $basket->{billingplace}, ); my $billingplace = $basket->{'billingplace'} || C4::Context->userenv->{"branch"}; my $deliveryplace = $basket->{'deliveryplace'} || C4::Context->userenv->{"branch"}; # Build the combobox to select the billing place my @billingplaceloop; my $branches = C4::Branch::GetBranchesLoop( $billingplace ); $template->param( billingplaceloop => $branches ); $branches = C4::Branch::GetBranchesLoop( $deliveryplace ); $template->param( deliveryplaceloop => $branches ); #End Edit } elsif ( $op eq 'add_validate' ) { #New basket # creation of basket per day basis for every vendor and all the orders for that day # will be added to the same basket of creation my $today = C4::Dates->today; print $today; my $dt = DateTime->now; # Stores current date and time as datetime object my $todaysdate = $dt->ymd; my $dbh = C4::Context->dbh; my $sql = q{ SELECT basketno, booksellerid, creationdate FROM aqbasket WHERE creationdate = ? AND booksellerid=?}; my $sth = $dbh->prepare($sql); $sth->execute($todaysdate, $booksellerid); if (my @basketdetails = $sth->fetchrow_array ){ my @data = @basketdetails; $basketno = splice(@data,0,1); $template->param(basketno => $basketno); }else{ $basketno = NewBasket( $booksellerid, $loggedinuser, $input->param('basketname'), $input->param('basketnote'), $input->param('basketbooksellernote'), $input->param('basketcontractnumber') || undef, $input->param('deliveryplace'), $input->param('billingplace'), ); $template->param(basketno => $basketno); } at the template end i have set it with to activate the new basket function when i save but doesn't seem inserting values for basket details in aqbasket table can any one help me please, thanks in advance Regards Arunkumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From Katrin.Fischer.83 at web.de Mon Aug 4 22:00:32 2014 From: Katrin.Fischer.83 at web.de (Katrin Fischer) Date: Mon, 04 Aug 2014 22:00:32 +0200 Subject: [Koha-devel] Basket Creation in neworderempty.pl In-Reply-To: References: Message-ID: <53DFE660.6000706@web.de> Hi Arunkumar, I was wondering why you are basing your customizations on 3.12 that is quite old by now. Also, the acquisitions related code is changing quite a lot between versions since a lot of enhancements and new features are added. I am worried you are in for a lot of headache in the future with customizations like that - making an update very hard. Have you thought about generalizing your features so they could be submitted and be included in Koha? Katrin Am 04.08.2014 um 09:30 schrieb Arun kumar: > Hello Guys, > > We are developing some Customization programming for KOHA 3.12 to meet > our requirements, I have trouble in creation of basket in > neworderempty.pl i have added the form in > template of neworderempty.tmpl? > > ? my $op = $input ->param('op'); > ? ? my $booksellerid = $input->param('booksellerid'); > ? ? my $branches = GetBranches; > > ? ? if ( $op eq 'add_form' ) { > ? ? my @contractloop; > ? ? my $basket; > > ? ? my $bookseller = GetBookSellerFromId($booksellerid); > ? ? my $count = scalar @contractloop; > ? ? if ( $count > 0) { > ? ? ? ? $template->param(contractloop => \@contractloop, > ? ? ? ? ? ? ? ? ? ? ? ? ? basketcontractnumber => > $basket->{'contractnumber'}); > ? ? } > ? ? my @booksellers = C4::Bookseller::GetBookSeller(); > ? ? $template->param( add_form => 1, > ? ? ? ? ? ? ? ? ? ? basketname => $basket->{'basketname'}, > ? ? ? ? ? ? ? ? ? ? basketnote => $basket->{'note'}, > ? ? ? ? ? ? ? ? ? ? basketbooksellernote => > $basket->{'booksellernote'}, > ? ? ? ? ? ? ? ? ? ? booksellername => $bookseller->{'name'}, > ? ? ? ? ? ? ? ? ? ? booksellerid => $booksellerid, > ? ? ? ? ? ? ? ? ? ? basketno => $basketno, > ? ? ? ? ? ? ? ? ? ? booksellers => \@booksellers, > ? ? ? ? ? ? ? ? ? ? deliveryplace => $basket->{deliveryplace}, > ? ? ? ? ? ? ? ? ? ? billingplace => $basket->{billingplace}, > ? ? ); > > ? ? my $billingplace = $basket->{'billingplace'} || > C4::Context->userenv->{"branch"}; > ? ? my $deliveryplace = $basket->{'deliveryplace'} || > C4::Context->userenv->{"branch"}; > ? ? # Build the combobox to select the billing place > ? ? my @billingplaceloop; > > ? ? my $branches = C4::Branch::GetBranchesLoop( $billingplace ); > ? ? $template->param( billingplaceloop => $branches ); > ? ? $branches = C4::Branch::GetBranchesLoop( $deliveryplace ); > ? ? $template->param( deliveryplaceloop => $branches ); > > #End Edit > > } elsif ( $op eq 'add_validate' ) { > ? #New basket > ? ? # creation of basket per day basis for every vendor and all the > orders for that day > ? ? # will be added to the same basket of creation > ? ? ? ? my $today = C4::Dates->today; > ? ? ? ? print $today; > ? ? ? ? my $dt ? = DateTime->now; ? # Stores current date and time > as datetime object > ? ? ? ? my $todaysdate = $dt->ymd; > ? ? ? ? my $dbh = C4::Context->dbh; > ? ? ? ? my $sql = q{ SELECT basketno, booksellerid, creationdate > FROM aqbasket WHERE creationdate = ? AND booksellerid=?}; > ? ? ? ? my $sth = $dbh->prepare($sql); > ? ? ? ? $sth->execute($todaysdate, $booksellerid); > ? ? ? ? if (my @basketdetails = $sth->fetchrow_array ){ > ? ? ? ? ? ? ? my @data = ? @basketdetails; > ? ? ? ? ? ? ? $basketno = splice(@data,0,1); > ? ? ? ? ? ? ? $template->param(basketno => $basketno); > ? ? ? ? }else{ > ? ? ? ? ? $basketno = NewBasket( > ? ? ? ? ? ? ? $booksellerid, > ? ? ? ? ? ? ? $loggedinuser, > ? ? ? ? ? ? ? $input->param('basketname'), > ? ? ? ? ? ? ? $input->param('basketnote'), > ? ? ? ? ? ? ? $input->param('basketbooksellernote'), > ? ? ? ? ? ? ? $input->param('basketcontractnumber') || undef, > ? ? ? ? ? ? ? $input->param('deliveryplace'), > ? ? ? ? ? ? ? $input->param('billingplace'), > ? ? ? ? ? ? ? ); > ? ? ? ? ? $template->param(basketno => $basketno); > ? ? ? ? ? ? ? } > at the template end i have set it with? > > > > to activate the new basket function when i save ? but doesn't seem > inserting values for basket details in aqbasket table? > > can any one help me please, thanks in advance > > Regards > > Arunkumar > > > > _______________________________________________ > 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 kohanews at gmail.com Tue Aug 5 22:29:20 2014 From: kohanews at gmail.com (Koha News) Date: Tue, 05 Aug 2014 13:29:20 -0700 Subject: [Koha-devel] Koha Community Newsletter: July 2014 Message-ID: <53E13EA0.3040704@gmail.com> Fellow Koha users: The Koha Community Newsletter for July 2014 is here: http://koha-community.org/koha-community-newsletter-july-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 julian.maurice at biblibre.com Fri Aug 8 10:43:19 2014 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 08 Aug 2014 10:43:19 +0200 Subject: [Koha-devel] Git tip of the day: taille de tabulation dans git diff Message-ID: <53E48DA7.90607@biblibre.com> Dans bokeh on a souvent du code align? avec des tabulations, par exemple: $exemplaires = Class_Exemplaire::findAllBy(['id_notice' => $id_notice, 'id_int_bib' => $this->id_int_bib, 'code_barres' => $ex['code_barres']]); Comme la taille de tabulation dans nos ?diteurs est de 2 et que par d?faut dans git diff, elle est de 8, on doit souvent scroller ? droite pour voir tout le code. Pour ?viter ?a, et dire ? git d'afficher des tabs de 2: git config core.pager 'less -x2' (peut aussi se faire avec la variable d'environnement LESS ? priori) -- Julian Maurice BibLibre From julian.maurice at biblibre.com Fri Aug 8 10:45:06 2014 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 08 Aug 2014 10:45:06 +0200 Subject: [Koha-devel] Git tip of the day: taille de tabulation dans git diff In-Reply-To: <53E48DA7.90607@biblibre.com> References: <53E48DA7.90607@biblibre.com> Message-ID: <53E48E12.3080309@biblibre.com> Le 08/08/2014 10:43, Julian Maurice a ?crit : > Dans bokeh on a souvent du code align? avec des tabulations, par exemple: > > $exemplaires = Class_Exemplaire::findAllBy(['id_notice' => $id_notice, > 'id_int_bib' => > $this->id_int_bib, > 'code_barres' => > $ex['code_barres']]); > > > Comme la taille de tabulation dans nos ?diteurs est de 2 et que par > d?faut dans git diff, elle est de 8, on doit souvent scroller ? droite > pour voir tout le code. > > Pour ?viter ?a, et dire ? git d'afficher des tabs de 2: > > git config core.pager 'less -x2' > > (peut aussi se faire avec la variable d'environnement LESS ? priori) > Oops, sorry! Wrong email address :) -- Julian Maurice BibLibre From veron at veron.ch Fri Aug 8 11:34:02 2014 From: veron at veron.ch (=?UTF-8?B?TWFyYyBWw6lyb24=?=) Date: Fri, 08 Aug 2014 11:34:02 +0200 Subject: [Koha-devel] Git tip of the day: taille de tabulation dans git diff In-Reply-To: <53E48E12.3080309@biblibre.com> References: <53E48DA7.90607@biblibre.com> <53E48E12.3080309@biblibre.com> Message-ID: <53E4998A.8010501@veron.ch> Tips and hints are always welcome :-) Marc Am 08.08.2014 10:45, schrieb Julian Maurice: > Le 08/08/2014 10:43, Julian Maurice a ?crit : >> Dans bokeh on a souvent du code align? avec des tabulations, par exemple: >> >> $exemplaires = Class_Exemplaire::findAllBy(['id_notice' => $id_notice, >> 'id_int_bib' => >> $this->id_int_bib, >> 'code_barres' => >> $ex['code_barres']]); >> >> >> Comme la taille de tabulation dans nos ?diteurs est de 2 et que par >> d?faut dans git diff, elle est de 8, on doit souvent scroller ? droite >> pour voir tout le code. >> >> Pour ?viter ?a, et dire ? git d'afficher des tabs de 2: >> >> git config core.pager 'less -x2' >> >> (peut aussi se faire avec la variable d'environnement LESS ? priori) >> > > Oops, sorry! Wrong email address :) > From julian.maurice at biblibre.com Fri Aug 8 11:44:28 2014 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 08 Aug 2014 11:44:28 +0200 Subject: [Koha-devel] Git tip of the day: taille de tabulation dans git diff In-Reply-To: <53E4998A.8010501@veron.ch> References: <53E48DA7.90607@biblibre.com> <53E48E12.3080309@biblibre.com> <53E4998A.8010501@veron.ch> Message-ID: <53E49BFC.8050503@biblibre.com> This tip is not really relevant for Koha, as we use spaces and not tabs, but could be useful in other projects, so, in short: if you want git to display tabs as 2 spaces instead of 8 (the default): git config core.pager 'less -x2' ;) Le 08/08/2014 11:34, Marc V?ron a ?crit : > Tips and hints are always welcome :-) > > Marc > > Am 08.08.2014 10:45, schrieb Julian Maurice: >> Le 08/08/2014 10:43, Julian Maurice a ?crit : >>> Dans bokeh on a souvent du code align? avec des tabulations, par exemple: >>> >>> $exemplaires = Class_Exemplaire::findAllBy(['id_notice' => $id_notice, >>> 'id_int_bib' => >>> $this->id_int_bib, >>> 'code_barres' => >>> $ex['code_barres']]); >>> >>> >>> Comme la taille de tabulation dans nos ?diteurs est de 2 et que par >>> d?faut dans git diff, elle est de 8, on doit souvent scroller ? droite >>> pour voir tout le code. >>> >>> Pour ?viter ?a, et dire ? git d'afficher des tabs de 2: >>> >>> git config core.pager 'less -x2' >>> >>> (peut aussi se faire avec la variable d'environnement LESS ? priori) >>> >> >> Oops, sorry! Wrong email address :) >> > -- Julian Maurice BibLibre From dptkvs at gmail.com Wed Aug 13 08:57:54 2014 From: dptkvs at gmail.com (DP Tripathi) Date: Wed, 13 Aug 2014 12:27:54 +0530 Subject: [Koha-devel] Koha Video Tutorial Message-ID: Dear All, Due to some technical issues, the website www.librarianguide.in is offline. I am in process to restore it at the earliest possible with new domain. In the meantime, Koha Video Tutorial can be downloaded at the link given below. https://drive.google.com/folderview?id=0B5x1jTCI3yK4dXhsZjkxVVVFTmM&usp=sharing These video can be downloaded and viewed with any media player which supports MP4. Hope it will be useful for everyone. Please share if you face any problem in downloading. Thanks, -- ********************* D. P. Tripathi Assistant Librarian Biju Patnaik Central Library NIT Rourkela Odisha - 769008 India ********************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Thu Aug 14 19:53:35 2014 From: kohanews at gmail.com (Koha News) Date: Thu, 14 Aug 2014 10:53:35 -0700 Subject: [Koha-devel] Call for news for August Newsletter Message-ID: <53ECF79F.5090107@gmail.com> Fellow Koha users ~ We're collecting news for the August 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 Thu Aug 14 19:55:11 2014 From: kohanews at gmail.com (Koha News) Date: Thu, 14 Aug 2014 10:55:11 -0700 Subject: [Koha-devel] Call for development news - August Newsletter Message-ID: <53ECF7FF.70309@gmail.com> Koha Development community ~ If you have any bugs or projects you'd like us to highlight or promote in the August 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 francois.charbonnier at inlibro.com Fri Aug 15 15:50:50 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Fri, 15 Aug 2014 09:50:50 -0400 Subject: [Koha-devel] RFC for overdue notice enhancements Message-ID: <53EE103A.1010609@inlibro.com> Hello all, Halland County Library in Sweden is going to sponsor new features. Their goals are to : * manage a reminder fee when a reminder is sent * manage different reminder delays depending on whether the item is reserved or not, and is free of charge or has a rental fee. We will start from a development inLibro did to manage invoices and fixed costs that goes along (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11092). Since, it hasn't been upstreamed yet, we will close this report and re-work it for a better integration with the new features. The requirements were thought to comply Halland County Library needs but also to be flexible and fulfill different settings. We also paid attention to keep Koha's behaviour, so libraries can keep their original set up if they doesn't need these new features. Here, you will find the RFCs : http://wiki.koha-community.org/wiki/Overdue_Notice_Enhancement Any comments, thoughts, suggestions are very welcome! 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Aug 18 13:42:49 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 18 Aug 2014 11:42:49 +0000 Subject: [Koha-devel] C4/Items.pm experts invited Message-ID: <809BE39CD64BFD4EB9036172EBCCFA314239E0D6@S-MAIL-1B.rijksmuseum.intra> Hi, Bug 7817 offers two approaches on resolving an issue with unmapped (internal) item fields. Your feedback is welcome. Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From yohann.dufour at biblibre.com Mon Aug 18 15:57:10 2014 From: yohann.dufour at biblibre.com (Yohann Dufour) Date: Mon, 18 Aug 2014 15:57:10 +0200 Subject: [Koha-devel] Presentation of TestBuilder In-Reply-To: <53CCE890.8000101@biblibre.com> References: <53CCE890.8000101@biblibre.com> Message-ID: <53F20636.40608@biblibre.com> Hi all, I just wanted to announce that this week is my last week of internship at BibLibre. I'm glad to have been able to contribute to Koha and improve the unit tests. I would like to thank you for your support and your help, especially BibLibre. However I didn't receive much feedback on the module I wrote in order to simplify the writing of unit tests : TestBuilder (bug 12603 ). So, if you could give your opinion about it before I go, it would be great :-) Regards, Yohann Le 21/07/2014 12:16, Yohann Dufour a ?crit : > 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 jonathan.druart at biblibre.com Tue Aug 19 10:20:40 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Tue, 19 Aug 2014 10:20:40 +0200 Subject: [Koha-devel] Test of UTF-8 (bug 11944) - Problem on BibLibre Branch In-Reply-To: <53D284F5.20003@cineca.it> References: <53D284F5.20003@cineca.it> Message-ID: Hi Zeno, Yesterday I added all patches on the branch, it's up-to-date (see my last comment on the bug report). Regards, Jonathan 2014-07-25 18:25 GMT+02:00 Zeno Tajoli : > 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/ > _______________________________________________ > 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 Tue Aug 19 22:41:05 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Tue, 19 Aug 2014 16:41:05 -0400 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: <53EE103A.1010609@inlibro.com> References: <53EE103A.1010609@inlibro.com> Message-ID: <53F3B661.1060404@inlibro.com> Hello all, This is a quick reminder in case you haven't noticed this email. We are going to start the developments next week. If you are working on something similar, think your work would conflict with ours, now is a good time to let us know! ;^) And thanks in advance for any comments, thoughts, suggestions you would have. Cheers! 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-08-15 09:50, Francois Charbonnier a ?crit : > Hello all, > > Halland County Library in Sweden is going to sponsor new features. > Their goals are to : > > * manage a reminder fee when a reminder is sent > * manage different reminder delays depending on whether the item > is reserved or not, and is free of charge or has a rental fee. > > We will start from a development inLibro did to manage invoices and > fixed costs that goes along > (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11092). > Since, it hasn't been upstreamed yet, we will close this report and > re-work it for a better integration with the new features. > > The requirements were thought to comply Halland County Library needs > but also to be flexible and fulfill different settings. We also paid > attention to keep Koha's behaviour, so libraries can keep their > original set up if they doesn't need these new features. > > Here, you will find the RFCs : > http://wiki.koha-community.org/wiki/Overdue_Notice_Enhancement > > Any comments, thoughts, suggestions are very welcome! > > 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 > > > _______________________________________________ > 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 martin.renvoize at ptfs-europe.com Wed Aug 20 07:46:27 2014 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Wed, 20 Aug 2014 06:46:27 +0100 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: <53F3B661.1060404@inlibro.com> References: <53EE103A.1010609@inlibro.com> <53F3B661.1060404@inlibro.com> Message-ID: You might want to check out http://splitter.koha-community.org for bugs touching the same files that are already in the works. On 19 Aug 2014 21:41, "Francois Charbonnier" < francois.charbonnier at inlibro.com> wrote: > Hello all, > This is a quick reminder in case you haven't noticed this email. > We are going to start the developments next week. > If you are working on something similar, think your work would conflict > with ours, now is a good time to let us know! ;^) > And thanks in advance for any comments, thoughts, suggestions you would > have. > Cheers! > 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-08-15 09:50, Francois Charbonnier a ?crit : > > Hello all, > > Halland County Library in Sweden is going to sponsor new features. Their > goals are to : > > - manage a reminder fee when a reminder is sent > - manage different reminder delays depending on whether the item > is reserved or not, and is free of charge or has a rental fee. > > We will start from a development inLibro did to manage invoices and fixed > costs that goes along ( > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11092). Since, > it hasn't been upstreamed yet, we will close this report and re-work it for > a better integration with the new features. > > The requirements were thought to comply Halland County Library needs but > also to be flexible and fulfill different settings. We also paid attention > to keep Koha's behaviour, so libraries can keep their original set up if > they doesn't need these new features. > > Here, you will find the RFCs : > http://wiki.koha-community.org/wiki/Overdue_Notice_Enhancement > > Any comments, thoughts, suggestions are very welcome! > > 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 > > > _______________________________________________ > Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://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 veron at veron.ch Wed Aug 20 10:02:17 2014 From: veron at veron.ch (=?ISO-8859-1?Q?Marc_V=E9ron?=) Date: Wed, 20 Aug 2014 10:02:17 +0200 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: References: <53EE103A.1010609@inlibro.com><53F3B661.1060404@inlibro.com> Message-ID: <53F45609.3000509@veron.ch> Great tool, would be nice to have it linked on http://dashboard.koha-community.org/ Marc Am 20.08.2014 07:46, schrieb Renvoize, Martin: > > You might want to check out http://splitter.koha-community.org for bugs > touching the same files that are already in the works. > > From chrisc at catalyst.net.nz Wed Aug 20 10:19:52 2014 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 20 Aug 2014 20:19:52 +1200 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: <53F45609.3000509@veron.ch> References: <53EE103A.1010609@inlibro.com><53F3B661.1060404@inlibro.com> <53F45609.3000509@veron.ch> Message-ID: You can send me a pull request on gitorious for this or any other features you want in the dashboard Chris On 20 August 2014 8:02:17 pm NZST, "Marc V?ron" wrote: >Great tool, would be nice to have it linked on >http://dashboard.koha-community.org/ > >Marc > >Am 20.08.2014 07:46, schrieb Renvoize, Martin: >> >> You might want to check out http://splitter.koha-community.org for >bugs >> touching the same files that are already in the works. >> >> > >_______________________________________________ >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/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at biblibre.com Wed Aug 20 10:42:00 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 20 Aug 2014 10:42:00 +0200 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: <53F3B661.1060404@inlibro.com> References: <53EE103A.1010609@inlibro.com> <53F3B661.1060404@inlibro.com> Message-ID: Salut Fran?ois, > manage more than 3 notification levels See bug 9296, MJ Ray already submitted some work for that (but seems stuck). How do you plan to implement that? How would be the DB table structure? I am not sure the pref is needed here, the number of tab could be manage on the interface (with some JS: + add a tab, - remove a tab). The page tools/overduerules.pl is quite dirty, I suppose you will refactore it and create a new module (using DBIC), isn't it? > notice fee management I development something like that (not rebased on master), see branch MT9888: http://git.biblibre.com/biblibre/kohac/commit/4f1ca08d13876439ef035af26e8f47833a90bc3a I linked the "fixed_fines" value to the overdue rules instead of the notice. Actually it is not at all the same goal, but it could help... > Overdue Notice/Status triggers tool I am not sure to understand the "on hold" checkbox. It should be checked on the last tab only, isn't it? Do you plan to refactore/export into a module (and add unit tests) for the overdue_notices.pl cronjob? What about reworking on the tools/overduerules.pl ergonomic? Maybe it could be better to have 1 line by rules (with all delay, mtt,etc.) and remove tabs. Just a suggestion. Good luck! :) Jonathan 2014-08-19 22:41 GMT+02:00 Francois Charbonnier : > Hello all, > This is a quick reminder in case you haven't noticed this email. > We are going to start the developments next week. > If you are working on something similar, think your work would conflict with > ours, now is a good time to let us know! ;^) > And thanks in advance for any comments, thoughts, suggestions you would > have. > Cheers! > 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-08-15 09:50, Francois Charbonnier a ?crit : > > Hello all, > > Halland County Library in Sweden is going to sponsor new features. Their > goals are to : > > manage a reminder fee when a reminder is sent > manage different reminder delays depending on whether the item is > reserved or not, and is free of charge or has a rental fee. > > We will start from a development inLibro did to manage invoices and fixed > costs that goes along > (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11092). Since, it > hasn't been upstreamed yet, we will close this report and re-work it for a > better integration with the new features. > > The requirements were thought to comply Halland County Library needs but > also to be flexible and fulfill different settings. We also paid attention > to keep Koha's behaviour, so libraries can keep their original set up if > they doesn't need these new features. > > Here, you will find the RFCs : > http://wiki.koha-community.org/wiki/Overdue_Notice_Enhancement > > Any comments, thoughts, suggestions are very welcome! > > 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 > > > _______________________________________________ > 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 tomascohen at gmail.com Wed Aug 20 14:30:59 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 20 Aug 2014 09:30:59 -0300 Subject: [Koha-devel] RFC: People using ILS-DI Message-ID: Hi, for those making use of Koha's ILS-DI implementation, could you please take the time to evaluate Bug 8868 - ILS-DI: CancelHold needs to take a reserve_id ? [1] It is on my list for 3.18, and it changes the current behaviour. So please consider answering to this thread. Thanks in advance. [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8868 -- 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 indradg at gmail.com Thu Aug 21 15:03:29 2014 From: indradg at gmail.com (Indranil Das Gupta) Date: Thu, 21 Aug 2014 13:03:29 +0000 Subject: [Koha-devel] Divergent handling (?) of Koha's Message-ID: Hi, I'm wondering why Koha's is handled differently between git / tarball and .deb packages. I'm seeing certain divergence (i think?) as follows: 1) Installed master from git (3.17.00.014) - found /var/lib/koha/plugins to exist under /home//koha-dev, created off /home/kohaclone/skel/var/lib/plugins. It is even defined in koha-conf.xml. 2) Downloaded and unzipped koha-latest.tar.gz - same thing, I see the folder "/var/lib/koha/plugins" under skel. 3) However in koha-common_3.16.02_all.deb, the same folder is not present. Instead, the directory has to be created as described in http://manual.koha-community.org/3.16/en/pluginsystem.html why is this so? thanks in advance. -- 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 indradg at gmail.com Fri Aug 22 00:16:06 2014 From: indradg at gmail.com (Indranil Das Gupta) Date: Thu, 21 Aug 2014 22:16:06 +0000 Subject: [Koha-devel] RFC: proposing change to Koha's plugins system Message-ID: Hi all, I've been trying to use the KPZ structure in some of my projects. In general, I've found it rather useful, with a few modifications. I would like to propose the following changes as http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12805 lets have your feedback on this. cheers -indra -- 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 paul.a at navalmarinearchive.com Fri Aug 22 02:32:53 2014 From: paul.a at navalmarinearchive.com (Paul A) Date: Thu, 21 Aug 2014 20:32:53 -0400 Subject: [Koha-devel] RFC: proposing change to Koha's plugins system In-Reply-To: Message-ID: <5.2.1.1.2.20140821193702.102e8eb0@pop.navalmarinearchive.com> At 10:16 PM 8/21/2014 +0000, Indranil Das Gupta wrote: >Hi all, > >I've been trying to use the KPZ structure in some of my projects. In >general, I've found it rather useful, with a few modifications. > >I would like to propose the following changes as >http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12805 > >lets have your feedback on this. With a view of maintaining core stability for Koha, all 'enhancements' (e.g. plug-ins) should be optional and not affect speed, size and cpu cycles of basic functionality. I think that this is what you are proposing... if I'm mistaken, please advise. I've been relatively quiet for some time about my intrinsic belief that a two year cycle of updating Koha (along the same 2-year lines of most OS's) should be the norm. "If it ain't broke, don't fix it." Enhancements (not security updates) should be for the end-user to decide upon, and most libraries do not have the personnel | time | budget to get involved every couple of months. I recognize that the paid consultants may have an interest -- and I have absolutely nothing against that; without them a huge amount of "Koha devel" would not take place. However, we are getting ready to upgrade our servers from 2012 to 2014 standards, and I've been looking at Koha 3.14 and 3.16. We are *not* a lending library -- just a big research centre -- and quite frankly I can find no totally compelling reason to upgrade from 3.8 (handheld browsers might be the exception.) Again, if I'm mistaken, please advise. Please don't misunderstand me. I'm all in favour of "improvments", but when a quick analysis of one of my OPAC pages come up with: Combine external CSS (6) Combine external JavaScript (11) Leverage browser caching (23) Leverage proxy caching (5) Minimize cookie size Serve static content from a cookieless domain (11) Specify image dimensions (1) Optimize the order of styles and scripts (2) Remove unused CSS rules (1335) Use normal CSS property names instead of vendor-prefixed ones (3) it's probably better to look at the 1,335 "unused CSS rules"... (bootstrap? doesn't do away with yahoo? does zebra depend on yahoo?) End rant. I promote Koha wherever I can, but in my job I've got to stay practical. Over the last four years we've put in place a marvelous OPAC meeting our users requirements. Please keep up the good work, but please also maintain core stability. Compare with Debian (lenny, squeeze, wheezy, 2 year cycle); Ubuntu (lynx, pangolin, tahr, 2 year cycle); Apache (2.2 ==> 2.4, eight/ten? year cycle); MySQL (fairly minor in the 5. series, no urgency); Perl (ditto); etc... Best -- Paul From chrisc at catalyst.net.nz Fri Aug 22 02:39:11 2014 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Fri, 22 Aug 2014 12:39:11 +1200 Subject: [Koha-devel] RFC: proposing change to Koha's plugins system In-Reply-To: <5.2.1.1.2.20140821193702.102e8eb0@pop.navalmarinearchive.com> References: <5.2.1.1.2.20140821193702.102e8eb0@pop.navalmarinearchive.com> Message-ID: <53F6912F.4070805@catalyst.net.nz> On 22/08/14 12:32, Paul A wrote: > At 10:16 PM 8/21/2014 +0000, Indranil Das Gupta wrote: >> Hi all, >> >> I've been trying to use the KPZ structure in some of my projects. In >> general, I've found it rather useful, with a few modifications. >> > > End rant. I promote Koha wherever I can, but in my job I've got to stay > practical. Over the last four years we've put in place a marvelous OPAC > meeting our users requirements. Please keep up the good work, but > please also maintain core stability. Compare with Debian (lenny, > squeeze, wheezy, 2 year cycle); Ubuntu (lynx, pangolin, tahr, 2 year > cycle); Apache (2.2 ==> 2.4, eight/ten? year cycle); MySQL (fairly minor > in the 5. series, no urgency); Perl (ditto); etc... > If you and others are willing to pay people to do this, it will get done. That's what it boils down. 4 years of something ... maybe time to contribute back? Chris From robin at catalyst.net.nz Fri Aug 22 02:50:19 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 22 Aug 2014 12:50:19 +1200 Subject: [Koha-devel] RFC: proposing change to Koha's plugins system In-Reply-To: <5.2.1.1.2.20140821193702.102e8eb0@pop.navalmarinearchive.com> References: <5.2.1.1.2.20140821193702.102e8eb0@pop.navalmarinearchive.com> Message-ID: <1408668619.30773.64.camel@zarathud.wgtn.cat-it.co.nz> Paul A schreef op do 21-08-2014 om 20:32 [-0400]: > With a view of maintaining core stability for Koha, all > 'enhancements' > (e.g. plug-ins) should be optional and not affect speed, size and cpu > cycles of basic functionality. I think that this is what you are > proposing... if I'm mistaken, please advise. Nothing in what Indranil is talking about is at all related to any of that, in the slightest. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From petter.goksoyr.asen at kul.oslo.kommune.no Fri Aug 22 08:26:23 2014 From: petter.goksoyr.asen at kul.oslo.kommune.no (=?iso-8859-1?Q?Petter_Goks=F8yr_=C5sen?=) Date: Fri, 22 Aug 2014 08:26:23 +0200 Subject: [Koha-devel] RFC: proposing change to Koha's plugins system In-Reply-To: <5.2.1.1.2.20140821193702.102e8eb0@pop.navalmarinearchive.com> References: , <5.2.1.1.2.20140821193702.102e8eb0@pop.navalmarinearchive.com> Message-ID: <13834160A6C2994D8650749DA5EC061B016059D92284@CL122726.oslofelles.oslo.kommune.no> > Please don't misunderstand me. I'm all in favour of "improvments", but I'm trying to understand you. You come across as somewhat saracstic, but I hope I'm wrong. The chrome audit analysis you cite is not that bad. If you run it even on google search page you will also find ~1000 unused css rules. Im not saying these kind of micro-optiizations not are worthwhile, but it's likely to have a very minor impact on Koha's performance as a whole. Some nanoseconds maybe. As for long vs short release cycles - I prefer frequent releases. Keep up the good work, everyone:) Best 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 Paul A [paul.a at navalmarinearchive.com] Sendt: 22. august 2014 02:32 Til: koha-devel at lists.koha-community.org Emne: Re: [Koha-devel] RFC: proposing change to Koha's plugins system At 10:16 PM 8/21/2014 +0000, Indranil Das Gupta wrote: >Hi all, > >I've been trying to use the KPZ structure in some of my projects. In >general, I've found it rather useful, with a few modifications. > >I would like to propose the following changes as >http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12805 > >lets have your feedback on this. With a view of maintaining core stability for Koha, all 'enhancements' (e.g. plug-ins) should be optional and not affect speed, size and cpu cycles of basic functionality. I think that this is what you are proposing... if I'm mistaken, please advise. I've been relatively quiet for some time about my intrinsic belief that a two year cycle of updating Koha (along the same 2-year lines of most OS's) should be the norm. "If it ain't broke, don't fix it." Enhancements (not security updates) should be for the end-user to decide upon, and most libraries do not have the personnel | time | budget to get involved every couple of months. I recognize that the paid consultants may have an interest -- and I have absolutely nothing against that; without them a huge amount of "Koha devel" would not take place. However, we are getting ready to upgrade our servers from 2012 to 2014 standards, and I've been looking at Koha 3.14 and 3.16. We are *not* a lending library -- just a big research centre -- and quite frankly I can find no totally compelling reason to upgrade from 3.8 (handheld browsers might be the exception.) Again, if I'm mistaken, please advise. Please don't misunderstand me. I'm all in favour of "improvments", but when a quick analysis of one of my OPAC pages come up with: Combine external CSS (6) Combine external JavaScript (11) Leverage browser caching (23) Leverage proxy caching (5) Minimize cookie size Serve static content from a cookieless domain (11) Specify image dimensions (1) Optimize the order of styles and scripts (2) Remove unused CSS rules (1335) Use normal CSS property names instead of vendor-prefixed ones (3) it's probably better to look at the 1,335 "unused CSS rules"... (bootstrap? doesn't do away with yahoo? does zebra depend on yahoo?) End rant. I promote Koha wherever I can, but in my job I've got to stay practical. Over the last four years we've put in place a marvelous OPAC meeting our users requirements. Please keep up the good work, but please also maintain core stability. Compare with Debian (lenny, squeeze, wheezy, 2 year cycle); Ubuntu (lynx, pangolin, tahr, 2 year cycle); Apache (2.2 ==> 2.4, eight/ten? year cycle); MySQL (fairly minor in the 5. series, no urgency); Perl (ditto); etc... Best -- Paul _______________________________________________ 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 Katrin.Fischer.83 at web.de Sat Aug 23 15:36:31 2014 From: Katrin.Fischer.83 at web.de (Katrin Fischer) Date: Sat, 23 Aug 2014 15:36:31 +0200 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: <53F45609.3000509@veron.ch> References: <53EE103A.1010609@inlibro.com><53F3B661.1060404@inlibro.com> <53F45609.3000509@veron.ch> Message-ID: <53F898DF.2010007@web.de> Hi, I put the link on the wiki start page - seemed like a good spot :) Katrin Am 20.08.2014 um 10:02 schrieb Marc V?ron: > Great tool, would be nice to have it linked on > http://dashboard.koha-community.org/ > > Marc > > Am 20.08.2014 07:46, schrieb Renvoize, Martin: >> >> You might want to check out http://splitter.koha-community.org for bugs >> touching the same files that are already in the works. >> >> > > _______________________________________________ > 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 Katrin.Fischer.83 at web.de Sun Aug 24 21:33:24 2014 From: Katrin.Fischer.83 at web.de (Katrin Fischer) Date: Sun, 24 Aug 2014 21:33:24 +0200 Subject: [Koha-devel] C4/Items.pm experts invited In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA314239E0D6@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA314239E0D6@S-MAIL-1B.rijksmuseum.intra> Message-ID: <53FA3E04.3020602@web.de> Hi Marcel, I have added a comment on the bug with some notes about the paidfor column: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7817 I think maybe better to solve this step by step, starting with permanent location. I agree it would be good if the internally used columns could not be edited in the cataloguing module and not mapped to subfields to avoid problems. Katrin Am 18.08.2014 um 13:42 schrieb Marcel de Rooy: > *Hi,* > > * * > > *Bug 7817 offers two approaches on resolving an issue with unmapped > (internal) item fields.* > > *Your 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/ > From paul.poulain at biblibre.com Mon Aug 25 13:56:50 2014 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 25 Aug 2014 13:56:50 +0200 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: <53EE103A.1010609@inlibro.com> References: <53EE103A.1010609@inlibro.com> Message-ID: <53FB2482.3010103@biblibre.com> Le 15/08/2014 15:50, Francois Charbonnier a ?crit : > Hello all, Hi Fran?ois, > Here, you will find the RFCs : > http://wiki.koha-community.org/wiki/Overdue_Notice_Enhancement About the replacement cost, a question/an idea : the amount, iiuc, is ADDED to the price in items table. Would it be relevant to have 2 other options: * the default replacementprice is REPLACING the items.replacementprice * the default is a % of additionnal fee. I'm not sure there's a real case for the 1st, but I'm sure that, for some libraries, the "overhead" for an overdue document is something like 20% of the initial price. Purchase price = 20USD (or CAN ;-) ) replacementprice = 20 + 4 = 24USD. -- Paul Poulain - Owner / Associ?-g?rant Tel : +33 4 91 81 35 08 http://www.biblibre.com Open Source software for libraries Logiciels Libres pour les biblioth?ques et les centres de documentation From francois.charbonnier at inlibro.com Mon Aug 25 17:01:28 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Mon, 25 Aug 2014 11:01:28 -0400 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: References: <53EE103A.1010609@inlibro.com> <53F3B661.1060404@inlibro.com> Message-ID: <53FB4FC8.607@inlibro.com> Salut Jonathan, Hi all, My answers bellow. 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-08-20 04:42, Jonathan Druart a ?crit : > Salut Fran?ois, > >> manage more than 3 notification levels > See bug 9296, MJ Ray already submitted some work for that (but seems stuck). > How do you plan to implement that? How would be the DB table structure? > I am not sure the pref is needed here, the number of tab could be > manage on the interface (with some JS: + add a tab, - remove a tab). > The page tools/overduerules.pl is quite dirty, I suppose you will > refactore it and create a new module (using DBIC), isn't it? Thanks for the heads-up. MJ's DB design looks like what we had in mind. We are going to base our development on MJ's work and submit a follow-up to his patch. The idea is to work first on the database design and then, on the UI. About the syspref VS some JS to manage the tabs, we will see that point when designing the UI. And no, we don't plan on refactoring the code. >> notice fee management > I development something like that (not rebased on master), see branch > MT9888: http://git.biblibre.com/biblibre/kohac/commit/4f1ca08d13876439ef035af26e8f47833a90bc3a > I linked the "fixed_fines" value to the overdue rules instead of the notice. > Actually it is not at all the same goal, but it could help... Thanks but it won't be necessary. We already have work done for this part. :^) >> Overdue Notice/Status triggers tool > I am not sure to understand the "on hold" checkbox. It should be > checked on the last tab only, isn't it? Nope. The idea is to have different set ups for available items and on-hold items (from the first letter to the last one). If the item is "on-hold" (another patron put an hold on it), you may want to send your patron a notice with a shorter delay to get back the items more quickly. With this new option, one could set up new rules specific to "on-hold" items. For example, the first letter could be sent after 7 days for an available book and after 2 days for a book if a patron requested it on hold. > Do you plan to refactore/export into a module (and add unit tests) for > the overdue_notices.pl cronjob? We will add unit tests for our develpments but we haven't planned any refactoring. > > What about reworking on the tools/overduerules.pl ergonomic? Maybe it > could be better to have 1 line by rules (with all delay, mtt,etc.) and > remove tabs. Just a suggestion. Sounds like a good idea. I'll check with our client first. > > Good luck! :) Thanks! > Jonathan > > 2014-08-19 22:41 GMT+02:00 Francois Charbonnier > : >> Hello all, >> This is a quick reminder in case you haven't noticed this email. >> We are going to start the developments next week. >> If you are working on something similar, think your work would conflict with >> ours, now is a good time to let us know! ;^) >> And thanks in advance for any comments, thoughts, suggestions you would >> have. >> Cheers! >> 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-08-15 09:50, Francois Charbonnier a ?crit : >> >> Hello all, >> >> Halland County Library in Sweden is going to sponsor new features. Their >> goals are to : >> >> manage a reminder fee when a reminder is sent >> manage different reminder delays depending on whether the item is >> reserved or not, and is free of charge or has a rental fee. >> >> We will start from a development inLibro did to manage invoices and fixed >> costs that goes along >> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11092). Since, it >> hasn't been upstreamed yet, we will close this report and re-work it for a >> better integration with the new features. >> >> The requirements were thought to comply Halland County Library needs but >> also to be flexible and fulfill different settings. We also paid attention >> to keep Koha's behaviour, so libraries can keep their original set up if >> they doesn't need these new features. >> >> Here, you will find the RFCs : >> http://wiki.koha-community.org/wiki/Overdue_Notice_Enhancement >> >> Any comments, thoughts, suggestions are very welcome! >> >> 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 >> >> >> _______________________________________________ >> 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 francois.charbonnier at inlibro.com Mon Aug 25 17:17:42 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Mon, 25 Aug 2014 11:17:42 -0400 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: <53FB2482.3010103@biblibre.com> References: <53EE103A.1010609@inlibro.com> <53FB2482.3010103@biblibre.com> Message-ID: <53FB5396.7080403@inlibro.com> Salut Paul! Answers bellow! 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-08-25 07:56, Paul Poulain a ?crit : > Le 15/08/2014 15:50, Francois Charbonnier a ?crit : >> Hello all, > Hi Fran?ois, > >> Here, you will find the RFCs : >> http://wiki.koha-community.org/wiki/Overdue_Notice_Enhancement > About the replacement cost, a question/an idea : the amount, iiuc, is > ADDED to the price in items table. Would it be relevant to have 2 > other options: > * the default replacementprice is REPLACING the items.replacementprice > * the default is a % of additionnal fee. > > I'm not sure there's a real case for the 1st, but I'm sure that, for > some libraries, the "overhead" for an overdue document is something > like 20% of the initial price. > Purchase price = 20USD (or CAN ;-) ) > replacementprice = 20 + 4 = 24USD. > The default replacement price will not be added to items.replacementprice value. It's not a value to adjust what we already have. The default replacement price will be used when there is no value in the items.replacementprice column. For example, the default replacement price is 20$. The patron lost the book A. items.replacementprice for book A = 30$. Long overdue cronjob will charge 30$ to the patron. The patron lost book B. items.replacementprice for book B = 0$ Long overdue cronjob will charge 20$ to the patron (the default replacement price). That's the feature we are going to implement. I agree, we could also update the mysql table to replace the 0 value by the default value but it means having access to the database, etc. With this development, librarians will be free to manage these values without having access to the database. I also like the idea of managing the replacement cost with a % of additionnal fee but it's a new feature. We don't have funding for this one so we won't add it to the development. Thanks for the suggestion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From indradg at gmail.com Tue Aug 26 07:25:54 2014 From: indradg at gmail.com (Indranil Das Gupta) Date: Tue, 26 Aug 2014 05:25:54 +0000 Subject: [Koha-devel] Proposed patch to add in-browser support of Indian/non-Latin language typing in Koha Message-ID: Hi all, [apologies for X-Posting] Browser based on-the-fly transliterated input on the OPAC was a long-standing requirement particularly in the Indian Koha user community. Indian government recognises 22 official languages for the purpose of official correspondance. The earlier attempts to add GoogleIndicTransliteration was a step in this direction. But that attempt did not finally clear QA. Google Transliteration API was deprecated in June 2011 and it's general Terms of Service (ToS) are not FOSS friendly. In contrast, jQuery.IME is dual-licensed under GPLv2+ and MIT. It is a key component of Wikimedia's (the organisation behind Wikipedia.org) global language engineering stack. At present, this represents robust, well tested support for over 135 input methods spanning over 67 languages. I've uploaded a patch (http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31152) against the bug number http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12815. The patch is against the current Koha master. I would like to request interested users to have a look and preferably test it. The patch work both in the OPAC as well as in Koha's staff client interface. Screenshots of the patch in action: http://imgur.com/a/2gB7H#0 and http://imgur.com/a/2gB7H#2 cheers, -indra -- 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 mathsabypro at gmail.com Tue Aug 26 10:08:44 2014 From: mathsabypro at gmail.com (Mathieu Saby) Date: Tue, 26 Aug 2014 10:08:44 +0200 Subject: [Koha-devel] Bugs related to Zebra indexing for Unimarc Message-ID: <53FC408C.9030101@gmail.com> Hi Some time ago I wrote a few patchs for making unimarc indexing more precise, especially 7XX and 6XX fields. One has just been signed off by Nick Clemens (thanks!), a MARC21 librarian. Could some UNIMARC people make the QA for it? http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9828 (for 6XX fields: subjects) During the test, we discovered that it was not possible to index some fields depending on the value of MARC indicators. It would be a nice improvement, so I created a bug for that (but I won't work on it...) http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12813 He was about to sign the 2d patch about 7XX fields (authors) http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9352 But there is an issue that I am not sure to be able to fix: The patch index only relevant subfields in author index (so, no more the profession of the author, its date, or its address, because those information are not here to be searched by users, but to disambiguate authors). As a result, each subfield is indexed separately in "phr" and "word" index. So the complete name is no more searchable with "au:phr" index Ex : in master, you can retreive a record with "Doe John" in "au:phr" index if you have 700$aDoe$bJohn with the patch, you get 0 record I don't want to spend days on that... so do you know if the problem occurs also for MARC21? Is there a way to resolve it by using some (new?) template in *koha-indexdefs-to-zebra.xsl ? Regards, Mathieu Saby* -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Tue Aug 26 11:21:30 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Tue, 26 Aug 2014 11:21:30 +0200 Subject: [Koha-devel] Bugs related to Zebra indexing for Unimarc In-Reply-To: <53FC408C.9030101@gmail.com> References: <53FC408C.9030101@gmail.com> Message-ID: <53FC519A.5030906@cineca.it> Hi Matieu, Il 26/08/2014 10:08, Mathieu Saby ha scritto: > He was about to sign the 2d patch about 7XX fields (authors) > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9352 > But there is an issue that I am not sure to be able to fix: > The patch index only relevant subfields in author index (so, no more the > profession of the author, its date, or its address, because those > information are not here to be searched by users, but to disambiguate > authors). > As a result, each subfield is indexed separately in "phr" and "word" > index. So the complete name is no more searchable with "au:phr" index > Ex : > in master, you can retreive a record with "Doe John" in "au:phr" index > if you have 700$aDoe$bJohn > with the patch, you get 0 record > > I don't want to spend days on that... so do you know if the problem > occurs also for MARC21? I think that a solution is possible, but is not easy. As first step for au:phr we need: ... a different entry from the entry of au:word that is: ... Then we need a XSLT procedure that create a phrase instead of single subunits. In fact DOM indexing is XSLT. In MARC21 all subfield in 100 (equivalent of 700 in Unimarc) are indexed in one shot. In biblio-koha-indexdefs.xml: Author:w Author:p Author:s Author-title:w Author-name-personal:w Name:w Name-and-title:w Personal-name:w The result in biblio-zebra-indexdefs.xsl is: > Is there a way to resolve it by using some > (new?) template in *koha-indexdefs-to-zebra.xsl ? Probsbly is, but we need to write a new template 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 mathsabypro at gmail.com Tue Aug 26 12:48:26 2014 From: mathsabypro at gmail.com (Mathieu Saby) Date: Tue, 26 Aug 2014 12:48:26 +0200 Subject: [Koha-devel] Bugs related to Zebra indexing for Unimarc In-Reply-To: <53FC519A.5030906@cineca.it> References: <53FC408C.9030101@gmail.com> <53FC519A.5030906@cineca.it> Message-ID: <53FC65FA.8030000@gmail.com> Le 26/08/2014 11:21, Zeno Tajoli a ?crit : > Hi Matieu, > Thank you for your answer > Il 26/08/2014 10:08, Mathieu Saby ha scritto: >> He was about to sign the 2d patch about 7XX fields (authors) >> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9352 >> But there is an issue that I am not sure to be able to fix: >> The patch index only relevant subfields in author index (so, no more the >> profession of the author, its date, or its address, because those >> information are not here to be searched by users, but to disambiguate >> authors). >> As a result, each subfield is indexed separately in "phr" and "word" >> index. So the complete name is no more searchable with "au:phr" index >> Ex : >> in master, you can retreive a record with "Doe John" in "au:phr" index >> if you have 700$aDoe$bJohn >> with the patch, you get 0 record >> >> I don't want to spend days on that... so do you know if the problem >> occurs also for MARC21? > > I think that a solution is possible, but is not easy. > > > As first step for au:phr we need: > > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" > subfields="abdg"> > ... > > > a different entry from the entry of au:word that is: > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" > subfields="bdg"> > ... > > Why not "abdg" for the second entry? For the first entry (phrase indexing), don't we need to define a new element instead of index_subfields (something like index_subfields_as_phrase)? like: or maybe to use an attribute like "index_as_phrase" so that the new xsl template could be applied only if we want so? like; Are we allowed to use new elements or attributes in *-koha-*.xml files ? There is a namespace defined in the file : xmlns:kohaidx="http://www.koha-community.org/schemas/index-defs". But I cannot find the definitions either on koha-community.org, or elsewhere. Do you know if it is avaiable somewhere? Excuse me if my remarks are silly, I don't really know XSLT ;-) Mathieu > > Then we need a XSLT procedure that create a phrase instead of single > subunits. > > In fact DOM indexing is XSLT. > > In MARC21 all subfield in 100 (equivalent of 700 in Unimarc) are > indexed in one shot. > > In biblio-koha-indexdefs.xml: > xmlns="http://www.koha-community.org/schemas/index-defs" tag="100"> > Author:w > Author:p > Author:s > Author-title:w > Author-name-personal:w > Name:w > Name-and-title:w > Personal-name:w > > > The result in biblio-zebra-indexdefs.xsl is: > > match="marc:datafield[@tag='100']"> > > > > > > > > > > > > > >> Is there a way to resolve it by using some >> (new?) template in *koha-indexdefs-to-zebra.xsl ? > > Probsbly is, but we need to write a new template > > Bye > Zeno Tajoli > From z.tajoli at cineca.it Tue Aug 26 15:43:27 2014 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Tue, 26 Aug 2014 15:43:27 +0200 Subject: [Koha-devel] Bugs related to Zebra indexing for Unimarc In-Reply-To: <53FC65FA.8030000@gmail.com> References: <53FC408C.9030101@gmail.com> <53FC519A.5030906@cineca.it> <53FC65FA.8030000@gmail.com> Message-ID: <53FC8EFF.2040605@cineca.it> Hi all Il 26/08/2014 12:48, Mathieu Saby ha scritto: >> As first step for au:phr we need: >> >> > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >> subfields="abdg"> >> ... >> >> >> a different entry from the entry of au:word that is: >> > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >> subfields="bdg"> >> ... >> >> > > Why not "abdg" for the second entry? I fact my only idea is that there is an error at line 317 of your path. The line is: but for phrase it needs to be so: Why for phrases and not for word ? Because there is the line 309 in the patch (304 in master): So the word's indexes for 700$a are OK, but not phrase. > Are we allowed to use new elements or attributes in *-koha-*.xml files ? I think yes, namespace declaration is present only to be complian with xml tools, but it is not really present. > There is a namespace defined in the file : > xmlns:kohaidx="http://www.koha-community.org/schemas/index-defs". But I > cannot find the definitions either on koha-community.org, or elsewhere. > Do you know if it is avaiable somewhere? No, I think that kohaidx="http://www.koha-community.org/schemas/index-defs" and xmlns="http://www.koha-community.org/schemas/index-defs" are here only for the sake of xsltproc. 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 mathsabypro at gmail.com Tue Aug 26 15:54:22 2014 From: mathsabypro at gmail.com (Mathieu Saby) Date: Tue, 26 Aug 2014 15:54:22 +0200 Subject: [Koha-devel] Bugs related to Zebra indexing for Unimarc In-Reply-To: <53FC8EFF.2040605@cineca.it> References: <53FC408C.9030101@gmail.com> <53FC519A.5030906@cineca.it> <53FC65FA.8030000@gmail.com> <53FC8EFF.2040605@cineca.it> Message-ID: <53FC918E.60806@gmail.com> Le 26/08/2014 15:43, Zeno Tajoli a ?crit : > Hi all > Il 26/08/2014 12:48, Mathieu Saby ha scritto: >>> As first step for au:phr we need: >>> >>> >> xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >>> subfields="abdg"> >>> ... >>> >>> >>> a different entry from the entry of au:word that is: >>> >> xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" >>> subfields="bdg"> >>> ... >>> >>> >> >> Why not "abdg" for the second entry? > > > I fact my only idea is that there is an error at line 317 of your path. > The line is: > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" > subfields="bdg"> > > but for phrase it needs to be so: > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" > subfields="abdg"> > > Why for phrases and not for word ? > Because there is the line 309 in the patch (304 in master): > xmlns="http://www.koha-community.org/schemas/index-defs" tag="700" > subfields="a"> > > So the word's indexes for 700$a are OK, but not phrase. OK, in fact my patch was just trying to preserve the indexing of $a (only) in "author:sort" index Currently it does: index 700$a in auhor:w, author:p, author:s and index 700$bdg in author:w, author:p I could do index 700$a in author:s and index 700$abdg in author:w, author:p But don't know if it is best ;-) Mathieu > >> Are we allowed to use new elements or attributes in *-koha-*.xml files ? > I think yes, namespace declaration is present only to be complian with > xml tools, but it is not really present. > >> There is a namespace defined in the file : >> xmlns:kohaidx="http://www.koha-community.org/schemas/index-defs". But I >> cannot find the definitions either on koha-community.org, or elsewhere. >> Do you know if it is avaiable somewhere? > No, I think that > kohaidx="http://www.koha-community.org/schemas/index-defs" > and > xmlns="http://www.koha-community.org/schemas/index-defs" > are here only for the sake of xsltproc. > > Bye > Zeno Tajoli > > From francois.charbonnier at inlibro.com Tue Aug 26 18:09:27 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Tue, 26 Aug 2014 12:09:27 -0400 Subject: [Koha-devel] Stemming and zebra Message-ID: <53FCB137.6000206@inlibro.com> Hello, I have tested the QueryStemming system preference on Koha 3.14 (my local installation) and I'm wondering, does zebra just right truncate the words or is there an algorithm to find the stems? I use ICU and I have enabled "QueryWeightFields". I don't have automatic truncation or fuzzy search on. I use these words for my tests: * ski, skiing, skills * fish, fished, fishing, fisher, fishxsdfe Each time, with QueryStemming on, skills and fishxsdfe come out in the search results. Is it what I should expect? "Skills", maybe but "fishxsdfe"? Do you know how it works? or have a good example that would help me to understand? Thanks! -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Aug 27 01:29:53 2014 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Aug 2014 09:29:53 +1000 Subject: [Koha-devel] Stemming and zebra In-Reply-To: <53FCB137.6000206@inlibro.com> References: <53FCB137.6000206@inlibro.com> Message-ID: <005b01cfc185$a3a5b1b0$eaf11510$@prosentient.com.au> Hi Francois Writing from a tablet so I will be brief. If you?re not using queryparser, there is a Perl module that does the stemming I believe. Lingua::Snowball or something like that. It would be easy to add to the queryparser too but haven?t gotten to it yet. Oh? now that I think about it? I think we mangle keywords before stemming them. I can?t remember why but there was some reason for it. Sorry this message is so incoherent. Will investigate and type a better response when I have a proper keyboard and not just thumbs on a small screen. David From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Francois Charbonnier Sent: Wednesday, 27 August 2014 2:09 AM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Stemming and zebra Hello, I have tested the QueryStemming system preference on Koha 3.14 (my local installation) and I'm wondering, does zebra just right truncate the words or is there an algorithm to find the stems? I use ICU and I have enabled "QueryWeightFields". I don't have automatic truncation or fuzzy search on. I use these words for my tests: * ski, skiing, skills * fish, fished, fishing, fisher, fishxsdfe Each time, with QueryStemming on, skills and fishxsdfe come out in the search results. Is it what I should expect? "Skills", maybe but "fishxsdfe"? Do you know how it works? or have a good example that would help me to understand? Thanks! -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Aug 27 10:22:15 2014 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Aug 2014 18:22:15 +1000 Subject: [Koha-devel] Stemming and zebra In-Reply-To: <53FCB137.6000206@inlibro.com> References: <53FCB137.6000206@inlibro.com> Message-ID: <010f01cfc1d0$0295e510$07c1af30$@prosentient.com.au> Hi Francois: I wrote an email earlier on my tablet, but not 100% sure if it got sent. In any case, I?m writing again now! You?ll want to look at C4::Search::_build_stemmed_operand(). Zebra doesn?t actually do any stemming itself. If you read through the Zebra docs (if you?re masochistic), you?ll notice that they say explicitly that Zebra doesn?t do any stemming, but that you can do stemming (using a stemmer like Snowball) while building a query. That?s exactly what we do in Koha. The Perl module that does the stemming is Lingua::Stem::Snowball. However, you might notice that your query?s operands aren?t always stemmed properly. I haven?t looked in a while, but I think it?s because we don?t build our queries very well at all (when not using QueryParser). If you want to understand why you?re getting ?skills? and ?fishxsdfe? in your results, I would suggest running some tests ( using ?Data::Dumper? and ?warn? ) so that you can see your query as it is built. I have a lot of work I want to do on C4::Search::buildQuery, but just don?t have the time :/. Unfortunately, at the moment, there is no stemming when using the QueryParser. However, fortunately, using Lingua::Stem::Snowball with QueryParser would be really really easy. I think that I?ve written a note on how to do that somewhere on Bugzilla or maybe on Trello? I hope that helps! Feel free to send me an email or shout at me on IRC if you want any clarification. I know I probably didn?t make it any clearer but hopefully this might help you on your path to understanding. 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 Francois Charbonnier Sent: Wednesday, 27 August 2014 2:09 AM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Stemming and zebra Hello, I have tested the QueryStemming system preference on Koha 3.14 (my local installation) and I'm wondering, does zebra just right truncate the words or is there an algorithm to find the stems? I use ICU and I have enabled "QueryWeightFields". I don't have automatic truncation or fuzzy search on. I use these words for my tests: * ski, skiing, skills * fish, fished, fishing, fisher, fishxsdfe Each time, with QueryStemming on, skills and fishxsdfe come out in the search results. Is it what I should expect? "Skills", maybe but "fishxsdfe"? Do you know how it works? or have a good example that would help me to understand? Thanks! -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathsabypro at gmail.com Wed Aug 27 11:30:19 2014 From: mathsabypro at gmail.com (Mathieu Saby) Date: Wed, 27 Aug 2014 11:30:19 +0200 Subject: [Koha-devel] Stemming and zebra In-Reply-To: <010f01cfc1d0$0295e510$07c1af30$@prosentient.com.au> References: <53FCB137.6000206@inlibro.com> <010f01cfc1d0$0295e510$07c1af30$@prosentient.com.au> Message-ID: <53FDA52B.8000508@gmail.com> Hi I had always thought stemming was made by Zebra, and only in english! In fact the algorithm for french language is here: http://snowball.tartarus.org/algorithms/french/stemmer.html (Lingua::Stem::Snowball is a Perl interface to the C version of the Snowball stemmers) Mathieu Saby Le 27/08/2014 10:22, David Cook a ?crit : > > Hi Francois: > > I wrote an email earlier on my tablet, but not 100% sure if it got > sent. In any case, I'm writing again now! > > You'll want to look at C4::Search::_build_stemmed_operand(). > > Zebra doesn't actually do any stemming itself. If you read through the > Zebra docs (if you're masochistic), you'll notice that they say > explicitly that Zebra doesn't do any stemming, but that you can do > stemming (using a stemmer like Snowball) while building a query. > That's exactly what we do in Koha. > > The Perl module that does the stemming is Lingua::Stem::Snowball. > > However, you might notice that your query's operands aren't always > stemmed properly. I haven't looked in a while, but I think it's > because we don't build our queries very well at all (when not using > QueryParser). > > If you want to understand why you're getting "skills" and "fishxsdfe" > in your results, I would suggest running some tests ( using > "Data::Dumper" and "warn" ) so that you can see your query as it is built. > > I have a lot of work I want to do on C4::Search::buildQuery, but just > don't have the time :/. > > Unfortunately, at the moment, there is no stemming when using the > QueryParser. However, fortunately, using Lingua::Stem::Snowball with > QueryParser would be really really easy. I think that I've written a > note on how to do that somewhere on Bugzilla or maybe on Trello... > > I hope that helps! Feel free to send me an email or shout at me on IRC > if you want any clarification. I know I probably didn't make it any > clearer but hopefully this might help you on your path to understanding. > > 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 > *Francois Charbonnier > *Sent:* Wednesday, 27 August 2014 2:09 AM > *To:* koha-devel at lists.koha-community.org > *Subject:* [Koha-devel] Stemming and zebra > > Hello, > > I have tested the QueryStemming system preference on Koha 3.14 (my > local installation) and I'm wondering, does zebra just right truncate > the words or is there an algorithm to find the stems? > > I use ICU and I have enabled "QueryWeightFields". I don't have > automatic truncation or fuzzy search on. I use these words for my tests: > > * ski, skiing, skills > * fish, fished, fishing, fisher, fishxsdfe > > Each time, with QueryStemming on, skills and fishxsdfe come out in the > search results. Is it what I should expect? "Skills", maybe but > "fishxsdfe"? > > Do you know how it works? or have a good example that would help me to > understand? > > Thanks! > > -- > > 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 > > > > _______________________________________________ > 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 Wed Aug 27 11:48:09 2014 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Aug 2014 19:48:09 +1000 Subject: [Koha-devel] Stemming and zebra In-Reply-To: <53FDA52B.8000508@gmail.com> References: <53FCB137.6000206@inlibro.com> <010f01cfc1d0$0295e510$07c1af30$@prosentient.com.au> <53FDA52B.8000508@gmail.com> Message-ID: <014c01cfc1dc$025a9350$070fb9f0$@prosentient.com.au> Hi Mathieu: I think many of us think certain things happen in Zebra when they actually happen in Koha before the query ever reaches Zebra ;). As for stemming, theoretically the language obtained via ?C4::Templates::getlanguage($cgi, 'intranet');? should filter down into the Snowball stemming. If it isn?t working in French, it might be because the right locale isn?t being passed to Snowball correctly. That?s very possible as I think we?re using arbitrary language codes rather than standard locales in some cases. It looks like there is a fallback to English in C4::Templates::getlanguage() as well. If it?s not working for French, it probably just needs a tweak! Yeah, I first heard about Snowball when reading through Zebra docs, and I was pleasantly surprised when I saw that Lingua::Stem::Snowball existed as a Perl interface for the C program. 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 Mathieu Saby Sent: Wednesday, 27 August 2014 7:30 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Stemming and zebra Hi I had always thought stemming was made by Zebra, and only in english! In fact the algorithm for french language is here: http://snowball.tartarus.org/algorithms/french/stemmer.html (Lingua::Stem::Snowball is a Perl interface to the C version of the Snowball stemmers) Mathieu Saby Le 27/08/2014 10:22, David Cook a ?crit : Hi Francois: I wrote an email earlier on my tablet, but not 100% sure if it got sent. In any case, I?m writing again now! You?ll want to look at C4::Search::_build_stemmed_operand(). Zebra doesn?t actually do any stemming itself. If you read through the Zebra docs (if you?re masochistic), you?ll notice that they say explicitly that Zebra doesn?t do any stemming, but that you can do stemming (using a stemmer like Snowball) while building a query. That?s exactly what we do in Koha. The Perl module that does the stemming is Lingua::Stem::Snowball. However, you might notice that your query?s operands aren?t always stemmed properly. I haven?t looked in a while, but I think it?s because we don?t build our queries very well at all (when not using QueryParser). If you want to understand why you?re getting ?skills? and ?fishxsdfe? in your results, I would suggest running some tests ( using ?Data::Dumper? and ?warn? ) so that you can see your query as it is built. I have a lot of work I want to do on C4::Search::buildQuery, but just don?t have the time :/. Unfortunately, at the moment, there is no stemming when using the QueryParser. However, fortunately, using Lingua::Stem::Snowball with QueryParser would be really really easy. I think that I?ve written a note on how to do that somewhere on Bugzilla or maybe on Trello I hope that helps! Feel free to send me an email or shout at me on IRC if you want any clarification. I know I probably didn?t make it any clearer but hopefully this might help you on your path to understanding. 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 Francois Charbonnier Sent: Wednesday, 27 August 2014 2:09 AM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] Stemming and zebra Hello, I have tested the QueryStemming system preference on Koha 3.14 (my local installation) and I'm wondering, does zebra just right truncate the words or is there an algorithm to find the stems? I use ICU and I have enabled "QueryWeightFields". I don't have automatic truncation or fuzzy search on. I use these words for my tests:  ski, skiing, skills  fish, fished, fishing, fisher, fishxsdfe Each time, with QueryStemming on, skills and fishxsdfe come out in the search results. Is it what I should expect? "Skills", maybe but "fishxsdfe"? Do you know how it works? or have a good example that would help me to understand? Thanks! -- 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 _______________________________________________ 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 Wed Aug 27 13:11:05 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Wed, 27 Aug 2014 13:11:05 +0200 Subject: [Koha-devel] Koha::Acquisition::Order? Message-ID: Hi developers, I've just sent a patch to put the order-related code into a new module. I would like to get some feedback on it. Please have a look at bug 12830 Note that the changes are not trivial and rebase the patch for a long time is dangerous. The sooner this first patch is integrated (adapted to your needs/requests), the faster I will provide a patch to fix the TODOs. Cheers, Jonathan http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12830 From francois.charbonnier at inlibro.com Wed Aug 27 14:26:11 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Wed, 27 Aug 2014 08:26:11 -0400 Subject: [Koha-devel] Stemming and zebra In-Reply-To: <014c01cfc1dc$025a9350$070fb9f0$@prosentient.com.au> References: <53FCB137.6000206@inlibro.com> <010f01cfc1d0$0295e510$07c1af30$@prosentient.com.au> <53FDA52B.8000508@gmail.com> <014c01cfc1dc$025a9350$070fb9f0$@prosentient.com.au> Message-ID: <53FDCE63.7060107@inlibro.com> Hi, Thanks Brooke for the support. I did read the rfc by the way but it's for queryparser which I'm not using now. I wish I'll find time to test it! Thanks David, I haven't read the whole zebra documention (ahah, sounds crazy) but did some researches. I had the impression zebra didn't manage stemming but it wasn't clear. So thank you for your answer. It will definitely help me to understand! Thanks Mathieu for the link. I'll have a look. For sure! Have a good day ! :^) 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-08-27 05:48, David Cook a ?crit : > > Hi Mathieu: > > I think many of us think certain things happen in Zebra when they > actually happen in Koha before the query ever reaches Zebra ;). > > As for stemming, theoretically the language obtained via > ?C4::Templates::getlanguage($cgi, 'intranet');? should filter down > into the Snowball stemming. If it isn?t working in French, it might be > because the right locale isn?t being passed to Snowball correctly. > That?s very possible as I think we?re using arbitrary language codes > rather than standard locales in some cases. It looks like there is a > fallback to English in C4::Templates::getlanguage() as well. If it?s > not working for French, it probably just needs a tweak! > > Yeah, I first heard about Snowball when reading through Zebra docs, > and I was pleasantly surprised when I saw that Lingua::Stem::Snowball > existed as a Perl interface for the C program. > > 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 > *Mathieu Saby > *Sent:* Wednesday, 27 August 2014 7:30 PM > *To:* koha-devel at lists.koha-community.org > *Subject:* Re: [Koha-devel] Stemming and zebra > > Hi > > I had always thought stemming was made by Zebra, and only in english! > > In fact the algorithm for french language is here: > http://snowball.tartarus.org/algorithms/french/stemmer.html > > (Lingua::Stem::Snowball is a Perl interface to the C version of the > Snowball stemmers) > > > Mathieu Saby > > > Le 27/08/2014 10:22, David Cook a ?crit : > > Hi Francois: > > I wrote an email earlier on my tablet, but not 100% sure if it got > sent. In any case, I?m writing again now! > > You?ll want to look at C4::Search::_build_stemmed_operand(). > > Zebra doesn?t actually do any stemming itself. If you read through > the Zebra docs (if you?re masochistic), you?ll notice that they > say explicitly that Zebra doesn?t do any stemming, but that you > can do stemming (using a stemmer like Snowball) while building a > query. That?s exactly what we do in Koha. > > The Perl module that does the stemming is Lingua::Stem::Snowball. > > However, you might notice that your query?s operands aren?t always > stemmed properly. I haven?t looked in a while, but I think it?s > because we don?t build our queries very well at all (when not > using QueryParser). > > If you want to understand why you?re getting ?skills? and > ?fishxsdfe? in your results, I would suggest running some tests ( > using ?Data::Dumper? and ?warn? ) so that you can see your query > as it is built. > > I have a lot of work I want to do on C4::Search::buildQuery, but > just don?t have the time :/. > > Unfortunately, at the moment, there is no stemming when using the > QueryParser. However, fortunately, using Lingua::Stem::Snowball > with QueryParser would be really really easy. I think that I?ve > written a note on how to do that somewhere on Bugzilla or maybe on > Trello? > > I hope that helps! Feel free to send me an email or shout at me on > IRC if you want any clarification. I know I probably didn?t make > it any clearer but hopefully this might help you on your path to > understanding. > > 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 > *Francois Charbonnier > *Sent:* Wednesday, 27 August 2014 2:09 AM > *To:* koha-devel at lists.koha-community.org > > *Subject:* [Koha-devel] Stemming and zebra > > Hello, > > I have tested the QueryStemming system preference on Koha 3.14 (my > local installation) and I'm wondering, does zebra just right > truncate the words or is there an algorithm to find the stems? > > I use ICU and I have enabled "QueryWeightFields". I don't have > automatic truncation or fuzzy search on. I use these words for my > tests: > > ski, skiing, skills > > fish, fished, fishing, fisher, fishxsdfe > > Each time, with QueryStemming on, skills and fishxsdfe come out in > the search results. Is it what I should expect? "Skills", maybe > but "fishxsdfe"? > > Do you know how it works? or have a good example that would help > me to understand? > > Thanks! > > -- > > 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 > > > > > _______________________________________________ > > 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 tomascohen at gmail.com Wed Aug 27 19:49:43 2014 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 27 Aug 2014 14:49:43 -0300 Subject: [Koha-devel] Call for development IRC meeting Message-ID: I forgot to announce last week's dev meeting so we missed it. Sorry for that. I propose doing it next tuesday: - 2 September 2014, 15UTC - 2 September 2014, 22UTC I encourage everyone interested on the UTF-8 cleanup effort to be on IRC, we need your opinions. We definitely need ideas for writing regression tests for this, and volunteers to work on that. The guys have worked a lot on this patches, and are rebasing them periodically. We have reached half of the 3.18 release cycle, and this stuff needs to get in so we have enough time to test and fix any possible regression before release on november. I remind you the wiki page where we are sumarizing what's left to be done so you make up your mind by tuesday: http://wiki.koha-community.org/wiki/Handling_UTF8_in_development I hope you can all join us. 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 chrisc at catalyst.net.nz Wed Aug 27 22:57:14 2014 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 28 Aug 2014 08:57:14 +1200 Subject: [Koha-devel] PROG/CCSR deprecation Message-ID: <53FE462A.1040403@catalyst.net.nz> Hi All I have been working on the prog/ccsr removal, I have all the patches that have been signed off pushed to a branch so we can test them all together. However I need 3 bugs to be signed off 12655 12539 12657 If someone could take a look at that and please sign them off, we can push them to the MM_OPAC/theme_dep to get them integration tested and then merge to master Thanks Chris From francois.charbonnier at inlibro.com Wed Aug 27 23:16:39 2014 From: francois.charbonnier at inlibro.com (Francois Charbonnier) Date: Wed, 27 Aug 2014 17:16:39 -0400 Subject: [Koha-devel] RFC for overdue notice enhancements In-Reply-To: References: <53EE103A.1010609@inlibro.com> <53F3B661.1060404@inlibro.com> Message-ID: <53FE4AB7.5000309@inlibro.com> Hi all, Jonathan suggested to change the ergonomy of the "Overdue notice/status triggers" tool. Our plan is to work on the database structure to be able to set up more than 3 reminder levels and Jonathan suggested that we gather together every rules in just one tab. This way, we won't be limited by the number of reminder level anymore. I like the idea because we will have a quick overview of every rules and have a more flexible tool. Note that a part of this development is to add also the ability to set up default rules which means fewer rules if you have the same one for every patron type. On the other hand, if you have a lot of specific rules, we will have a bigger table... For now, we can choose to keep either the original ergonomy (X tabs) or go for a new one (1 tab) which I like better (better overview, with the new table structure, we will have search and sort options, etc.). Any opinions for or against this new ergonomy? Thanks! 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-08-20 04:42, Jonathan Druart a ?crit : > Salut Fran?ois, > >> manage more than 3 notification levels > See bug 9296, MJ Ray already submitted some work for that (but seems stuck). > How do you plan to implement that? How would be the DB table structure? > I am not sure the pref is needed here, the number of tab could be > manage on the interface (with some JS: + add a tab, - remove a tab). > The page tools/overduerules.pl is quite dirty, I suppose you will > refactore it and create a new module (using DBIC), isn't it? > >> notice fee management > I development something like that (not rebased on master), see branch > MT9888: http://git.biblibre.com/biblibre/kohac/commit/4f1ca08d13876439ef035af26e8f47833a90bc3a > I linked the "fixed_fines" value to the overdue rules instead of the notice. > Actually it is not at all the same goal, but it could help... > >> Overdue Notice/Status triggers tool > I am not sure to understand the "on hold" checkbox. It should be > checked on the last tab only, isn't it? > > Do you plan to refactore/export into a module (and add unit tests) for > the overdue_notices.pl cronjob? > > What about reworking on the tools/overduerules.pl ergonomic? Maybe it > could be better to have 1 line by rules (with all delay, mtt,etc.) and > remove tabs. Just a suggestion. > > Good luck! :) > Jonathan > > 2014-08-19 22:41 GMT+02:00 Francois Charbonnier > : >> Hello all, >> This is a quick reminder in case you haven't noticed this email. >> We are going to start the developments next week. >> If you are working on something similar, think your work would conflict with >> ours, now is a good time to let us know! ;^) >> And thanks in advance for any comments, thoughts, suggestions you would >> have. >> Cheers! >> 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-08-15 09:50, Francois Charbonnier a ?crit : >> >> Hello all, >> >> Halland County Library in Sweden is going to sponsor new features. Their >> goals are to : >> >> manage a reminder fee when a reminder is sent >> manage different reminder delays depending on whether the item is >> reserved or not, and is free of charge or has a rental fee. >> >> We will start from a development inLibro did to manage invoices and fixed >> costs that goes along >> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11092). Since, it >> hasn't been upstreamed yet, we will close this report and re-work it for a >> better integration with the new features. >> >> The requirements were thought to comply Halland County Library needs but >> also to be flexible and fulfill different settings. We also paid attention >> to keep Koha's behaviour, so libraries can keep their original set up if >> they doesn't need these new features. >> >> Here, you will find the RFCs : >> http://wiki.koha-community.org/wiki/Overdue_Notice_Enhancement >> >> Any comments, thoughts, suggestions are very welcome! >> >> 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 >> >> >> _______________________________________________ >> 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 jonathan.druart at biblibre.com Thu Aug 28 11:58:44 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 28 Aug 2014 11:58:44 +0200 Subject: [Koha-devel] VAT/GST rewrite In-Reply-To: References: Message-ID: Thanks to Katrin and Colin for their questions/notes on the wiki page (http://wiki.koha-community.org/wiki/GST_Rewrite_RFC#Questions_.2F_notes) We need some pov on the following points: 1/ The DB field/variables names Colin suggested not to truncate the names. But, for instance, rrp_it would become recommended_retail_price_including_tax, not convenient. Any thought? 2/ Rounding I suggest to add a new pref to define the decimal to get for price calculation. So we need to change all the price DB fields to something like decimal(13,4). Does it make sense for everyone? 3/ Unified the "vat", "gst" and "tax" terms into "tax". Which is more generic. Please express yourself if you disagree. Regards, Jonathan 2014-07-21 17:32 GMT+02:00 Jonathan Druart : > 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 jonathan.druart at biblibre.com Thu Aug 28 12:02:03 2014 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 28 Aug 2014 12:02:03 +0200 Subject: [Koha-devel] VAT/GST rewrite In-Reply-To: References: Message-ID: Note that the bug report exists, if you want to follow it: Bug 12825 - GST / VAT rewrite Some preliminary works will be done on Bug 12826 - GST / VAT rewrite - plumbing Patches have already been submitted, feedbacks needed... 2014-08-28 11:58 GMT+02:00 Jonathan Druart : > Thanks to Katrin and Colin for their questions/notes on the wiki page > (http://wiki.koha-community.org/wiki/GST_Rewrite_RFC#Questions_.2F_notes) > > We need some pov on the following points: > 1/ The DB field/variables names > Colin suggested not to truncate the names. But, for instance, rrp_it > would become recommended_retail_price_including_tax, not convenient. > Any thought? > 2/ Rounding > I suggest to add a new pref to define the decimal to get for price > calculation. So we need to change all the price DB fields to something > like decimal(13,4). > Does it make sense for everyone? > 3/ Unified the "vat", "gst" and "tax" terms into "tax". Which is more generic. > > Please express yourself if you disagree. > > Regards, > Jonathan > > 2014-07-21 17:32 GMT+02:00 Jonathan Druart : >> 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 M.de.Rooy at rijksmuseum.nl Thu Aug 28 12:59:55 2014 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 28 Aug 2014 10:59:55 +0000 Subject: [Koha-devel] DBix relation names: discussion about biblioitem vs biblioitemnumber Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31423B67D0@S-MAIL-1B.rijksmuseum.intra> Hi, Please have a look at bug 11518 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11518, If the mail subject attracted your attention somehow.. Thx Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippe.blouin at inlibro.com Thu Aug 28 14:06:06 2014 From: philippe.blouin at inlibro.com (Philippe Blouin) Date: Thu, 28 Aug 2014 08:06:06 -0400 Subject: [Koha-devel] VAT/GST rewrite In-Reply-To: References: Message-ID: <53FF1B2E.8080908@inlibro.com> The first question is a trap? Feels like a troll to start a very long "discussion" :) Having played in that area, I can say that I had NO idea what each of the variable names meant. I had to go to their source to guess it. That said, maybe I could have gotten used to "rrp", if it's used commonly. But the "it" at the end is horrible. The only downside I can see (and it's not negligible) is that DB displays will go very large on my screen due to such long name used on small values. So, splitting hair, I'd say rrp_incl_tax, if rrp is commonly used. But that's just me. :) On 3), I like that very much, thank you! On 08/28/2014 05:58 AM, Jonathan Druart wrote: > Thanks to Katrin and Colin for their questions/notes on the wiki page > (http://wiki.koha-community.org/wiki/GST_Rewrite_RFC#Questions_.2F_notes) > > We need some pov on the following points: > 1/ The DB field/variables names > Colin suggested not to truncate the names. But, for instance, rrp_it > would become recommended_retail_price_including_tax, not convenient. > Any thought? > 2/ Rounding > I suggest to add a new pref to define the decimal to get for price > calculation. So we need to change all the price DB fields to something > like decimal(13,4). > Does it make sense for everyone? > 3/ Unified the "vat", "gst" and "tax" terms into "tax". Which is more generic. > > Please express yourself if you disagree. > > Regards, > Jonathan > > 2014-07-21 17:32 GMT+02:00 Jonathan Druart : >> 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/ -- 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 colin.campbell at ptfs-europe.com Thu Aug 28 15:06:22 2014 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Thu, 28 Aug 2014 14:06:22 +0100 Subject: [Koha-devel] VAT/GST rewrite In-Reply-To: <53FF1B2E.8080908@inlibro.com> References: <53FF1B2E.8080908@inlibro.com> Message-ID: <20140828130622.GA9115@zazou.cscnet.co.uk> On Thu, Aug 28, 2014 at 08:06:06AM -0400, Philippe Blouin wrote: > So, splitting hair, I'd say rrp_incl_tax, if rrp is commonly used. But > that's just me. :) > That is the point it is not a commonly used term (in all countries) and historically there has been some confusion within the Koha community as to what rrp actually is an abbreviation for and what this variable does/should represent. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 800 756 6803 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From paul.a at navalmarinearchive.com Thu Aug 28 15:26:14 2014 From: paul.a at navalmarinearchive.com (Paul A) Date: Thu, 28 Aug 2014 09:26:14 -0400 Subject: [Koha-devel] VAT/GST rewrite In-Reply-To: References: Message-ID: <5.2.1.1.2.20140828091820.019d2670@pop.navalmarinearchive.com> At 11:58 AM 8/28/2014 +0200, Jonathan Druart wrote: >Thanks to Katrin and Colin for their questions/notes on the wiki page >(http://wiki.koha-community.org/wiki/GST_Rewrite_RFC#Questions_.2F_notes) >[snip] >2/ Rounding >I suggest to add a new pref to define the decimal to get for price >calculation. So we need to change all the price DB fields to something >like decimal(13,4). Quick thought: not sure what other institutions use for "accounts", but we use Sage software which sets up the MySQL db to *two* decimal points for all items and at all three tax levels (0, 5 and 13%) -- it would perhaps be useful, particularly if other accounting systems do the same, to maintain consistency (or at least allow the choice.) The rounding errors are minor (they rarely if ever cascade), but a PITA for the auditors. Best -- Paul From robin at catalyst.net.nz Fri Aug 29 03:56:52 2014 From: robin at catalyst.net.nz (Robin Sheat) Date: Fri, 29 Aug 2014 13:56:52 +1200 Subject: [Koha-devel] GPL licensing and Javascript Message-ID: <1409277412.23268.31.camel@zarathud.wgtn.cat-it.co.nz> There's a few points to be aware of for us here: http://lwn.net/SubscriberLink/609709/7f0fa0e255e8143b/ Scroll down to the "JavaScript and the GPL" section (or, read the whole thing. Some might find certain parts have a slight air of familiarity about them.) -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: