From fabriciosoares at yahoo.com Tue Jan 5 00:59:02 2016 From: fabriciosoares at yahoo.com (Fabricio Soares) Date: Mon, 4 Jan 2016 23:59:02 +0000 (UTC) Subject: [Koha-devel] Questions about the development process of koha References: <1613441456.24514.1451951942498.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1613441456.24514.1451951942498.JavaMail.yahoo@mail.yahoo.com> My name is Fabricio and participate in a team that studies the Koha in Brazil, we are writing a scientific article about the evolution of the development of Koha and bug fixes. We evaluate the information contained in Bugzilla and GitHub, but still remained some doubts. I would like to have contact with some Koha master developer to be able to solve our doubts but could not an email address to establish a contact. Below are some of the questions. 01) How to divide developers? 02) How the project's maintainers are organized? 03) How they separate new features treatment bugs? 04) The developers fixing bugs are the same as producing new features? 05) Github users also post questions in bugzilla? 06) Is there any way to relate the github user with bugzilla user? 07) Is there any study on incident response time? 08) They assign a delay so high between the opening of a call and incident resolution (average 805 days)? 09) As they face the forks LibLime and Kobli? 10) The project maintainer makes a comparison study between the development of Koha and OpenSource and Owners competitors? 11) The project maintainers evaluate the response performance to incidents? 12) Any development methodology to the new features is used? Grateful for the attention. Fabricio -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisc at catalyst.net.nz Tue Jan 5 01:22:10 2016 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 5 Jan 2016 13:22:10 +1300 Subject: [Koha-devel] Questions about the development process of koha In-Reply-To: <1613441456.24514.1451951942498.JavaMail.yahoo@mail.yahoo.com> References: <1613441456.24514.1451951942498.JavaMail.yahoo.ref@mail.yahoo.com> <1613441456.24514.1451951942498.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20160105002210.GM32150@rorohiko.wgtn.cat-it.co.nz> * Fabricio Soares (fabriciosoares at yahoo.com) wrote: > My name is Fabricio and participate in a team that studies the Koha in Brazil, > we are writing a scientific article about the evolution of the development of > Koha and bug fixes. We evaluate the information contained in Bugzilla and > GitHub, but still remained some doubts. I would like to have contact with some > Koha master developer to be able to solve our doubts but could not an email > address to establish a contact. Below are some of the questions. > For a start We don't use github, it is just a mirror of the repository, a free back up. git.koha-community.org is the canonical repository. > 01) How to divide developers? I don't understand this question. What are you asking? How developers decide what they want to work on? > 02) How the project's maintainers are organized? There are elections after every feature release (every 6 months) http://wiki.koha-community.org/wiki/Roles_for_3.24 > 03) How they separate new features treatment bugs? The people submitting a patch or submitting a bug/feature request assign one, but the release manager has the final decisions > 04) The developers fixing bugs are the same as producing new features? Some are, some aren't there were over 80 developers working on Koha in 2015, some did a lot, some not so much. > 05) Github users also post questions in bugzilla? We don't use Github for development of Koha > 06) Is there any way to relate the github user with bugzilla user? Don't be distracted by Github, it is just a mirror, no development, or merges are done there > 07) Is there any study on incident response time? Security incident? Our average is 3 days > 08) They assign a delay so high between the opening of a call and incident > resolution (average 805 days)? I don't know where the 805 is coming from? Perhaps you are looking at github not bugzilla? (Again, ignore github, it is just a mirror) > 09) As they face the forks LibLime and Kobli? Not sure what you mean here? > 10) The project maintainer makes a comparison study between the development of > Koha and OpenSource and Owners competitors? Again, I am not sure what you are asking? > 11) The project maintainers evaluate the response performance to incidents? Yes > 12) Any development methodology to the new features is used? > Yes, it is all documented on the wiki http://wiki.koha-community.org/wiki/Guidelines_for_Patch_Acceptance/Rejection http://wiki.koha-community.org/wiki/Coding_Guidelines But whatever development methodology the developers take in their companies, or individualy is up to them. As long as they follow the coding guidelines and the code passes QA Chris > Grateful for the attention. > > Fabricio > _______________________________________________ > 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/ -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From julian.maurice at biblibre.com Tue Jan 5 14:03:48 2016 From: julian.maurice at biblibre.com (Julian Maurice) Date: Tue, 5 Jan 2016 14:03:48 +0100 Subject: [Koha-devel] feature for bugzilla ? In-Reply-To: References: <5673D314.8050309@biblibre.com> Message-ID: <568BBF34.9090506@biblibre.com> Here's a slightly different version: http://pastebin.com/3kwqszbH Changes: - Only hide comments that start with 'Created', and contains a span.bz_obsolete (previous version was hiding some reply comments) - Use the already present "Toggle comment display" link instead of adding a new link And I initiated a Gist to track changes easily: https://gist.github.com/jajm/31bf1c3aecd5f16c4422 Le 30/12/2015 14:55, Jonathan Druart a ?crit : > I have updated the script to display the comments when the patch is quoted > > http://pastebin.com/fSffTHQw > > 2015-12-18 11:22 GMT+00:00 Jonathan Druart > : >> quick&dirty greasemonkey script to hide the description of obsolete >> patches in the comments: >> http://pastebin.com/c99G9KgG >> >> 2015-12-18 9:34 GMT+00:00 Paul Poulain : >>> Hi all, >>> >>> when an entry on bugzilla has a lot of comments, it can take "hours" to read >>> all the thread, find relevant and obsolete comments,... understand who said >>> what and where we are now. >>> >>> Justs have a look at -randomly chosen- >>> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6934 to see this >>> (only 33 comments, not so hard to follow, but will take a lot of time. Other >>> bugs are really a nightmare !!! ) >>> >>> I was wondering if there could be an Addon, a feature, un plugin, or >>> whatever, that could "obsolete" a comment. An obsoleted comment would be >>> collapsed by default. Anyone can obsolete a comment, it's just to >>> (hopefully) have a thread easier to read. >>> >>> Another option could be to put a color on comment that are relevant. >>> >>> There could be other way to achieve the goal. >>> >>> But currently, one must be highly motivated to work on a sign-off, except if >>> the bug is "new" ! (I suspect that's a reason why some patches are stuck) >>> >>> -- >>> Paul Poulain, Associ?-g?rant / co-owner >>> BibLibre, Services en logiciels libres pour les biblioth?ques >>> BibLibre, Open Source software and services for libraries >>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel at lists.koha-community.org >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Julian Maurice BibLibre From dcook at prosentient.com.au Wed Jan 6 03:14:52 2016 From: dcook at prosentient.com.au (David Cook) Date: Wed, 6 Jan 2016 13:14:52 +1100 Subject: [Koha-devel] API keys Message-ID: <004401d14828$06ff2050$14fd60f0$@prosentient.com.au> Hey all: What do people think about having keys for Koha APIs? Someone would register a key in Koha and give that key to the developer, the developer puts it in their app configuration, and they're good to go. One advantage would be that apps utilizing web services wouldn't actually have access to Koha itself - just to the APIs associated with the API key. By that same token, a Koha administrator could easily revoke access to an API if necessary for whatever reason. I'm sure there are other advantages as well. I was thinking a single API key could replace the username/password pair, but you still might want a client_id and an API key, so you're still managing two fields in your configuration. Anyway, just a thought. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Wed Jan 6 09:33:38 2016 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 6 Jan 2016 08:33:38 +0000 Subject: [Koha-devel] API keys In-Reply-To: <004401d14828$06ff2050$14fd60f0$@prosentient.com.au> References: <004401d14828$06ff2050$14fd60f0$@prosentient.com.au> Message-ID: Hi David, See bug 13920 and bug 14868. Cheers, Jonathan 2016-01-06 2:14 GMT+00:00 David Cook : > Hey all: > > > > What do people think about having keys for Koha APIs? Someone would register > a key in Koha and give that key to the developer, the developer puts it in > their app configuration, and they?re good to go. > > > > One advantage would be that apps utilizing web services wouldn?t actually > have access to Koha itself ? just to the APIs associated with the API key. > By that same token, a Koha administrator could easily revoke access to an > API if necessary for whatever reason. > > > > I?m sure there are other advantages as well. I was thinking a single API key > could replace the username/password pair, but you still might want a > client_id and an API key, so you?re still managing two fields in your > configuration. > > > > Anyway, just a thought. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St, Ultimo, NSW 2007 > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From dcook at prosentient.com.au Thu Jan 7 00:39:50 2016 From: dcook at prosentient.com.au (David Cook) Date: Thu, 7 Jan 2016 10:39:50 +1100 Subject: [Koha-devel] API keys In-Reply-To: References: <004401d14828$06ff2050$14fd60f0$@prosentient.com.au> Message-ID: <008201d148db$895c2490$9c146db0$@prosentient.com.au> Thanks, Jonathan. I figured someone must be thinking about this for the REST API : ) David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] > Sent: Wednesday, 6 January 2016 7:34 PM > To: David Cook > Cc: Koha Devel > Subject: Re: [Koha-devel] API keys > > Hi David, > > See bug 13920 and bug 14868. > > Cheers, > Jonathan > > 2016-01-06 2:14 GMT+00:00 David Cook : > > Hey all: > > > > > > > > What do people think about having keys for Koha APIs? Someone would > > register a key in Koha and give that key to the developer, the > > developer puts it in their app configuration, and they?re good to go. > > > > > > > > One advantage would be that apps utilizing web services wouldn?t > > actually have access to Koha itself ? just to the APIs associated with the API > key. > > By that same token, a Koha administrator could easily revoke access to > > an API if necessary for whatever reason. > > > > > > > > I?m sure there are other advantages as well. I was thinking a single > > API key could replace the username/password pair, but you still might > > want a client_id and an API key, so you?re still managing two fields > > in your configuration. > > > > > > > > Anyway, just a thought. > > > > > > > > David Cook > > > > Systems Librarian > > > > Prosentient Systems > > > > 72/330 Wattle St, Ultimo, NSW 2007 > > > > > > > > > > _______________________________________________ > > Koha-devel mailing list > > Koha-devel at lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > > website : http://www.koha-community.org/ git : > > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From mirko at abunchofthings.net Thu Jan 7 18:49:25 2016 From: mirko at abunchofthings.net (Mirko Tietgen) Date: Thu, 7 Jan 2016 18:49:25 +0100 Subject: [Koha-devel] Koha Hackfest in Berlin? In-Reply-To: <5675D3BD.8010300@abunchofthings.net> References: <559DA343.9010208@abunchofthings.net> <566732FC.7060002@abunchofthings.net> <566D68D4.4020703@abunchofthings.net> <56705DC7.4060802@abunchofthings.net> <5672CF87.8070406@biblibre.com> <5675D3BD.8010300@abunchofthings.net> Message-ID: <568EA525.7070506@abunchofthings.net> Hello everyone, a little update: room problems are sorted out now. There will be one short day (Thursday only until 4PM), afterwards we can either continue working in a beer garden or do touristy things. Apart from that we can use the room the whole week if we want to. Cheers, Mirko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From pianohacker at gmail.com Thu Jan 7 21:12:47 2016 From: pianohacker at gmail.com (Jesse) Date: Thu, 7 Jan 2016 13:12:47 -0700 Subject: [Koha-devel] RFC: Circulation Rules Interface and Backend Revamp RFC Message-ID: The backend and frontend of the circulation/policy rules in Koha have been extended and stretched to the point where they cause a fair amount of issues and frustration. Many librarians and developers are uncertain when default rules are applied, and the very large number of possible settings makes the interface and backend unwieldy. Full details for our intended solution can be found at the link at the bottom of this email, but here's the gist: Instead of having one database row with all settings for a given library/category/itemtype, allow each setting (checkout length, fine amount, holds allowed, etc.) to be specified separately. Rework the interface to more clearly show the specificity of default/specific rules, and allow for this new database model. Accomplish the above incrementally by gradually changing APIs. http://wiki.koha-community.org/wiki/Circulation_Rules_Interface_and_Backend_Revamp_RFC Any and all comments are appreciated. Development on this project has been fully sponsored, and we are looking to start work later this year. -- Jesse Weaver -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Fri Jan 8 10:17:06 2016 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 8 Jan 2016 09:17:06 +0000 Subject: [Koha-devel] [Koha] RFC: Circulation Rules Interface and Backend Revamp RFC In-Reply-To: References: Message-ID: (continuing on devel only) That's good news :) We absolutely need a discussion here indeed, not to reproduce previous attempts who failed. For instance, (I have only 2 examples in mind) : - Simplify the DB structure: Bug 8369 - default_branch_circ_rule and default_circ_rules tables useless - Modify the display : Bug 5872 - Enhancements to circulation You can find on comment 27 a screencast to show you the interface suggested: http://screencast.com/t/4duT8KV6VjQ (Thanks Liz for that!) As I completely agree the current interface has show its limits, I personally think that the table is a good way to have an overview of the rules. What you suggest seems less easy to understand, especially for libraries using very complex circ rules. Cheers and good luck :) Jonathan 2016-01-07 20:12 GMT+00:00 Jesse : > The backend and frontend of the circulation/policy rules in Koha have been > extended and stretched to the point where they cause a fair amount of > issues and frustration. Many librarians and developers are uncertain when > default rules are applied, and the very large number of possible settings > makes the interface and backend unwieldy. > > Full details for our intended solution can be found at the link at the > bottom of this email, but here's the gist: > > Instead of having one database row with all settings for a given > library/category/itemtype, allow each setting (checkout length, fine > amount, holds allowed, etc.) to be specified separately. > Rework the interface to more clearly show the specificity of > default/specific rules, and allow for this new database model. > Accomplish the above incrementally by gradually changing APIs. > > http://wiki.koha-community.org/wiki/Circulation_Rules_Interface_and_Backend_Revamp_RFC > > Any and all comments are appreciated. Development on this project has been > fully sponsored, and we are looking to start work later this year. > -- > Jesse Weaver > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha From dcook at prosentient.com.au Mon Jan 11 02:44:52 2016 From: dcook at prosentient.com.au (David Cook) Date: Mon, 11 Jan 2016 12:44:52 +1100 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC Message-ID: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> Hi all: Recently, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084 was pushed to master. It adds a cronjob which deletes bibliographic records, if their LDR05 is "d" (ie status deleted). While I'm all for that, I'm thinking that it would also be a good idea to hide these records with LDR05 "d" in the OPAC before the cronjob is run. We can't necessarily rely on all Koha instances running this cronjob, nor can we rely on the frequency. Shouldn't we be hiding these records from the OPAC as soon as they're marked as "deleted"? I've opened a bug for this purpose: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 It should be a pretty easy change, especially when using special attribute @attr 14=1 to avoid past OpacSuppression problems, but I thought I'd ask folk if it's something they'd be interested in. We'd probably still want to see these records in the Staff Client, as we want to be able to find all records in the database in the Staff Client. I admit that I have a special interest in this where I might be overlaying existing records using a mostly empty skeleton record generated from an OAI-PMH identifier and a OAI-PMH deleted status (OAI-PMH doesn't send metadata for deleted records). I'd match the existing record in Koha using the identifier, and then set LDR05 to "d" in accordance with the OAI-PMH deleted status. Then, that record would disappear from the OPAC, so that end users don't see this skeleton record. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Jan 11 07:20:22 2016 From: dcook at prosentient.com.au (David Cook) Date: Mon, 11 Jan 2016 17:20:22 +1100 Subject: [Koha-devel] Prevent normalization during matching/import process Message-ID: <009b01d14c38$2738d2d0$75aa7870$@prosentient.com.au> Hi all: I've opened a bug for preventing normalization during the matching/import process: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 I was trying to use a URL field as a matchpoint, and it was going horribly badly. 1) By default, punctuation is stripped, leading/trailing spaces are trimmed, and more than one space is condensed down to one space. This makes a URL into a string without any spaces or punctuation. 2) So, I had to add "Identifier-other:u" to biblio-zebra-indexdefs.xsl but I couldn't access it until I tried "id-other,st-urx" as my match point. The st-urx is necessary to make it use the ":u" register. 3) I also added some code to C4/Matcher.pm so that a match point normalizer of "None" would disable the normalization from #1. 4) I also plan to add a flag to C4::Search::SimpleSearch to disable the s/:/=/g normalization since that also destroys the URL in the query and makes it fail to match. I've only tested this so far with CHR but it works well. I'll probably look at ICU tomorrow. I'm sure there are probably other cases than just URLs where we will want to skip the default normalizing when doing matching. or normalize it in a way that accords with the way Zebra normalizes the data in records. For instance, Zebra will replace punctuation with a space for "phrase" indexes rather than just stripping it out and leaving nothing behind. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Mon Jan 11 15:57:19 2016 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 11 Jan 2016 14:57:19 +0000 Subject: [Koha-devel] Playing with NYTProf Message-ID: Hi devs, I have played with NYTProf at the end of the last week, here is my loosely structured notes: https://joubu.github.io/koha/nytprof/dbic/index.html I have not found big things to implement in order to improve the speed but I am wondering if there is not something wrong with the queries cache (Search in the page for "Update:") Hope to get some feedbacks. Cheers, Jonathan PS: If someone has a better idea to share the profiles, I am open-minded. From barton at bywatersolutions.com Mon Jan 11 16:35:07 2016 From: barton at bywatersolutions.com (Barton Chittenden) Date: Mon, 11 Jan 2016 10:35:07 -0500 Subject: [Koha-devel] Playing with NYTProf In-Reply-To: References: Message-ID: Nice work. On Mon, Jan 11, 2016 at 9:57 AM, Jonathan Druart < jonathan.druart at bugs.koha-community.org> wrote: > Hi devs, > > I have played with NYTProf at the end of the last week, here is my > loosely structured notes: > https://joubu.github.io/koha/nytprof/dbic/index.html > > I have not found big things to implement in order to improve the speed > but I am wondering if there is not something wrong with the queries > cache (Search in the page for "Update:") > > Hope to get some feedbacks. > > Cheers, > Jonathan > > PS: If someone has a better idea to share the profiles, I am open-minded. > _______________________________________________ > 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 info at bywatersolutions.com Mon Jan 11 18:58:57 2016 From: info at bywatersolutions.com (Brendan Gallagher) Date: Mon, 11 Jan 2016 09:58:57 -0800 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> Message-ID: Sounds good to me David. If you get some code up there I'll find someone to Test. Cheers, Brendan On Sunday, January 10, 2016, David Cook wrote: > Hi all: > > > > Recently, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084 > was pushed to master. It adds a cronjob which deletes bibliographic > records, if their LDR05 is ?d? (ie status deleted). > > > > While I?m all for that, I?m thinking that it would also be a good idea to > hide these records with LDR05 ?d? in the OPAC before the cronjob is run. > > > > We can?t necessarily rely on all Koha instances running this cronjob, nor > can we rely on the frequency. Shouldn?t we be hiding these records from the > OPAC as soon as they?re marked as ?deleted?? > > > > I?ve opened a bug for this purpose: > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 > > > > It should be a pretty easy change, especially when using special attribute > @attr 14=1 to avoid past OpacSuppression problems, but I thought I?d ask > folk if it?s something they?d be interested in. We?d probably still want to > see these records in the Staff Client, as we want to be able to find all > records in the database in the Staff Client. > > > > I admit that I have a special interest in this where I might be overlaying > existing records using a mostly empty skeleton record generated from an > OAI-PMH identifier and a OAI-PMH deleted status (OAI-PMH doesn?t send > metadata for deleted records). I?d match the existing record in Koha using > the identifier, and then set LDR05 to ?d? in accordance with the OAI-PMH > deleted status. Then, that record would disappear from the OPAC, so that > end users don?t see this skeleton record. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St, Ultimo, NSW 2007 > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Jan 11 23:21:59 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 12 Jan 2016 09:21:59 +1100 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> Message-ID: <00c601d14cbe$7d4d7320$77e85960$@prosentient.com.au> Awesome, Brendan! I?ll do that this morning : ). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Brendan Gallagher [mailto:info at bywatersolutions.com] Sent: Tuesday, 12 January 2016 4:59 AM To: David Cook Cc: Koha Devel Subject: Re: [Koha-devel] Hide records on Leader 05 = d in OPAC Sounds good to me David. If you get some code up there I'll find someone to Test. Cheers, Brendan On Sunday, January 10, 2016, David Cook > wrote: Hi all: Recently, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084 was pushed to master. It adds a cronjob which deletes bibliographic records, if their LDR05 is ?d? (ie status deleted). While I?m all for that, I?m thinking that it would also be a good idea to hide these records with LDR05 ?d? in the OPAC before the cronjob is run. We can?t necessarily rely on all Koha instances running this cronjob, nor can we rely on the frequency. Shouldn?t we be hiding these records from the OPAC as soon as they?re marked as ?deleted?? I?ve opened a bug for this purpose: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 It should be a pretty easy change, especially when using special attribute @attr 14=1 to avoid past OpacSuppression problems, but I thought I?d ask folk if it?s something they?d be interested in. We?d probably still want to see these records in the Staff Client, as we want to be able to find all records in the database in the Staff Client. I admit that I have a special interest in this where I might be overlaying existing records using a mostly empty skeleton record generated from an OAI-PMH identifier and a OAI-PMH deleted status (OAI-PMH doesn?t send metadata for deleted records). I?d match the existing record in Koha using the identifier, and then set LDR05 to ?d? in accordance with the OAI-PMH deleted status. Then, that record would disappear from the OPAC, so that end users don?t see this skeleton record. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.a at navalmarinearchive.com Tue Jan 12 01:56:39 2016 From: paul.a at navalmarinearchive.com (Paul A) Date: Mon, 11 Jan 2016 19:56:39 -0500 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> Message-ID: <5.2.1.1.2.20160111195603.10fa7490@pop.navalmarinearchive.com> At 12:44 PM 1/11/2016 +1100, David Cook wrote: >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_008A_01D14C6D.DDE56680" >Content-Language: en-au >Hi all: >Recently, >http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084 >was pushed to master. It adds a cronjob which deletes bibliographic >records, if their LDR05 is d(ie status deleted). Brendan, David, Thanks for your work on this. I have sometimes wondered what the LDR, Pos 05 - Record status d - Deleted "Record has been deleted" actually means. My question is: how many cataloguers take the time and trouble to modify LDR pos05, rather than just "hit delete" for a record? From a Koha db viewpoint, either the record is in MySQL and therefore (probably?) should get indexed by Zebra, or it has been deleted by a cataloguer -- logically gone, terminally, no bytes left on the hard disk -- except that Koha has tables "deletedbiblio", "deletedbiblioitems" and "deleteditems" which (as far as I can tell) do not contain the LDR, therefore cannot cross-reference pos05=d (and I'm not certain that there is a way to "undelete" -- can it be done?) Best -- Paul > > >While Im all for that, Im thinking that it would also be a good idea to >hide these records with LDR05 din the OPAC before the cronjob is run. > > > >We cant necessarily rely on all Koha instances running this cronjob, nor >can we rely on the frequency. Shouldnt we be hiding these records from the >OPAC as soon as theyre marked as deleted? > > > >Ive opened a bug for this purpose: >http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 > > > >It should be a pretty easy change, especially when using special attribute >@attr 14=1 to avoid past OpacSuppression problems, but I thought Id ask >folk if its something theyd be interested in. Wed probably still want to >see these records in the Staff Client, as we want to be able to find all >records in the database in the Staff Client. > > > >I admit that I have a special interest in this where I might be overlaying >existing records using a mostly empty skeleton record generated from an >OAI-PMH identifier and a OAI-PMH deleted status (OAI-PMH doesnt send >metadata for deleted records). Id match the existing record in Koha using >the identifier, and then set LDR05 to din accordance with the OAI-PMH >deleted status. Then, that record would disappear from the OPAC, so that >end users dont see this skeleton record. > > > >David Cook > >Systems Librarian > >Prosentient Systems > >72/330 Wattle St, Ultimo, NSW 2007 > > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Jan 12 03:37:55 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 12 Jan 2016 13:37:55 +1100 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: <5.2.1.1.2.20160111195603.10fa7490@pop.navalmarinearchive.com> References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> <5.2.1.1.2.20160111195603.10fa7490@pop.navalmarinearchive.com> Message-ID: <00db01d14ce2$3e179db0$ba46d910$@prosentient.com.au> I imagine that most cataloguers cataloguing in Koha would just hit "Delete record" in Koha. However, if you're cataloguing outside of Koha, you can modify LDR05 to "d", and then import a batch of MARC records into Koha. When you overlay the records in Koha, they would conceptually be deleted, so a cronjob could come and "reap" them later without any additional manual intervention. My work on http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 will prevent these records from showing up in the OPAC in the interim as well. That said, there is a question as to why we're saving records with a LDR05 of "d" in the database. In theory, if LDR05=d, we could just delete the record as soon as we see that. However, there are other considerations to make such as item-level data, subscription data, etc. That's a bit out of the scope of my caring at the moment. I'm working on batch importing of records, so I care about being able to signal to Koha that I want to add some records, update some records, and delete other records. As for "undeleting", I don't think anyone is currently working on that, but I'm sure someone could. Historically, I think the LDR05=d was used to remove records from the OPAC but still let staff see them for a certain period of time before they were removed. I think removal may have even been configurable. I've been working on Koha long enough to not recall 100% how other ILSes worked in that respect in the past. For what it's worth, the leader is stored in the deletedbiblioitems.marcxml as well. I think it's a perfect copy of the record at the point in time of its deletion. 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 Paul A Sent: Tuesday, 12 January 2016 11:57 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Hide records on Leader 05 = d in OPAC At 12:44 PM 1/11/2016 +1100, David Cook wrote: Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01D14C6D.DDE56680" Content-Language: en-au Hi all: Recently, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084 was pushed to master. It adds a cronjob which deletes bibliographic records, if their LDR05 is d(ie status deleted). Brendan, David, Thanks for your work on this. I have sometimes wondered what the LDR, Pos 05 - Record status d - Deleted "Record has been deleted" actually means. My question is: how many cataloguers take the time and trouble to modify LDR pos05, rather than just "hit delete" for a record? >From a Koha db viewpoint, either the record is in MySQL and therefore (probably?) should get indexed by Zebra, or it has been deleted by a cataloguer -- logically gone, terminally, no bytes left on the hard disk -- except that Koha has tables "deletedbiblio", "deletedbiblioitems" and "deleteditems" which (as far as I can tell) do not contain the LDR, therefore cannot cross-reference pos05=d (and I'm not certain that there is a way to "undelete" -- can it be done?) Best -- Paul While Im all for that, Im thinking that it would also be a good idea to hide these records with LDR05 din the OPAC before the cronjob is run. We cant necessarily rely on all Koha instances running this cronjob, nor can we rely on the frequency. Shouldnt we be hiding these records from the OPAC as soon as theyre marked as deleted? Ive opened a bug for this purpose: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 It should be a pretty easy change, especially when using special attribute @attr 14=1 to avoid past OpacSuppression problems, but I thought Id ask folk if its something theyd be interested in. Wed probably still want to see these records in the Staff Client, as we want to be able to find all records in the database in the Staff Client. I admit that I have a special interest in this where I might be overlaying existing records using a mostly empty skeleton record generated from an OAI-PMH identifier and a OAI-PMH deleted status (OAI-PMH doesnt send metadata for deleted records). Id match the existing record in Koha using the identifier, and then set LDR05 to din accordance with the OAI-PMH deleted status. Then, that record would disappear from the OPAC, so that end users dont see this skeleton record. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. > and > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Jan 12 03:40:03 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 12 Jan 2016 13:40:03 +1100 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> Message-ID: <00e001d14ce2$89f1f370$9dd5da50$@prosentient.com.au> I?ve whipped up some code and posted it at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537. It should work perfectly for MARC21 after applying the patch and doing a full re-index of Zebra. I?ve provided changes for NORMARC and UNIMARC as well, but I haven?t tested them. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Brendan Gallagher [mailto:info at bywatersolutions.com] Sent: Tuesday, 12 January 2016 4:59 AM To: David Cook Cc: Koha Devel Subject: Re: [Koha-devel] Hide records on Leader 05 = d in OPAC Sounds good to me David. If you get some code up there I'll find someone to Test. Cheers, Brendan On Sunday, January 10, 2016, David Cook > wrote: Hi all: Recently, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084 was pushed to master. It adds a cronjob which deletes bibliographic records, if their LDR05 is ?d? (ie status deleted). While I?m all for that, I?m thinking that it would also be a good idea to hide these records with LDR05 ?d? in the OPAC before the cronjob is run. We can?t necessarily rely on all Koha instances running this cronjob, nor can we rely on the frequency. Shouldn?t we be hiding these records from the OPAC as soon as they?re marked as ?deleted?? I?ve opened a bug for this purpose: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 It should be a pretty easy change, especially when using special attribute @attr 14=1 to avoid past OpacSuppression problems, but I thought I?d ask folk if it?s something they?d be interested in. We?d probably still want to see these records in the Staff Client, as we want to be able to find all records in the database in the Staff Client. I admit that I have a special interest in this where I might be overlaying existing records using a mostly empty skeleton record generated from an OAI-PMH identifier and a OAI-PMH deleted status (OAI-PMH doesn?t send metadata for deleted records). I?d match the existing record in Koha using the identifier, and then set LDR05 to ?d? in accordance with the OAI-PMH deleted status. Then, that record would disappear from the OPAC, so that end users don?t see this skeleton record. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.maurice at biblibre.com Tue Jan 12 09:16:26 2016 From: julian.maurice at biblibre.com (Julian Maurice) Date: Tue, 12 Jan 2016 09:16:26 +0100 Subject: [Koha-devel] Playing with NYTProf In-Reply-To: References: Message-ID: <5694B65A.3030309@biblibre.com> In the last part ("the real real life"), you say 30% of the time is take by C4::Context::preference, but I don't see where this number comes from. If I look at the flame graph of the "second profile" (https://joubu.github.io/koha/nytprof/dbic/nytprofhtml.21326_2/) C4::Context::preference only takes 2.42% In the last profile (which is with your patch, right ?), C4::Context::preference exclusive's time is bigger than any other subroutines and we spend 9.22s (inclusive) inside C4::Context::preference for "only" 283 calls, which seems huge. So... maybe I don't understand correctly NYTProf output, or there is something wrong with your patch Le 11/01/2016 15:57, Jonathan Druart a ?crit : > Hi devs, > > I have played with NYTProf at the end of the last week, here is my > loosely structured notes: > https://joubu.github.io/koha/nytprof/dbic/index.html > > I have not found big things to implement in order to improve the speed > but I am wondering if there is not something wrong with the queries > cache (Search in the page for "Update:") > > Hope to get some feedbacks. > > Cheers, > Jonathan > > PS: If someone has a better idea to share the profiles, I am open-minded. > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Julian Maurice BibLibre From gmc at esilibrary.com Tue Jan 12 14:48:21 2016 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 12 Jan 2016 08:48:21 -0500 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> Message-ID: Hi, On Sun, Jan 10, 2016 at 8:44 PM, David Cook wrote: > We can?t necessarily rely on all Koha instances running this cronjob, nor > can we rely on the frequency. Shouldn?t we be hiding these records from the > OPAC as soon as they?re marked as ?deleted?? > > I?ve opened a bug for this purpose: > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 I am in mild disfavor of this proposal, particularly as implemented in current patch. Using a cronjob to delete records where Leader/05 is set to 'd' is useful when the library has arranged their workflow such that they *know* that Leader/05 = 'd' is being used consistently to signify that a record is no longer wanted. However, for a library that has not hitherto cared about the values in that position, unconditionally suppressing the display of such records could come as an unwelcome surprise. That said, it is also a reasonable choice for a library to want to use the Leader/05 as suppression criterion. Consequently, I suggest adding a configuration option. For that matter, making it configurable (say, by allowing the library to specify a set of query additions for the purpose of filtering records from public display) could result in a more generally useful mechanism. > I admit that I have a special interest in this where I might > be overlaying existing records using a mostly empty skeleton > record generated from an OAI-PMH identifier and a OAI-PMH > deleted status (OAI-PMH doesn?t send metadata for deleted records). > I?d match the existing record in Koha using the identifier, and > then set LDR05 to ?d? in accordance with the OAI-PMH deleted > status. Then, that record would disappear from the OPAC, so that > end users don?t see this skeleton record. I do not find this a compelling use case as stated. If the goal is to allow harvesting and overlay records from an OAI-PMH provider to also delete bibs from a Koha database... coding so that the records are *actually* deleted seems more direct. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From jonathan.druart at bugs.koha-community.org Tue Jan 12 16:32:25 2016 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 12 Jan 2016 15:32:25 +0000 Subject: [Koha-devel] Playing with NYTProf In-Reply-To: <5694B65A.3030309@biblibre.com> References: <5694B65A.3030309@biblibre.com> Message-ID: Hi Julian, On the second profile of the real real life (nytprofhtml.21326_2), you can see the 30% on the flame graph. Search for 'Update' on the page, there is something I done understand. The queries don't look to be cached (what I was expecting). 2016-01-12 8:16 GMT+00:00 Julian Maurice : > In the last part ("the real real life"), you say 30% of the time is take > by C4::Context::preference, but I don't see where this number comes > from. If I look at the flame graph of the "second profile" > (https://joubu.github.io/koha/nytprof/dbic/nytprofhtml.21326_2/) > C4::Context::preference only takes 2.42% > In the last profile (which is with your patch, right ?), > C4::Context::preference exclusive's time is bigger than any other > subroutines and we spend 9.22s (inclusive) inside > C4::Context::preference for "only" 283 calls, which seems huge. > So... maybe I don't understand correctly NYTProf output, or there is > something wrong with your patch > > Le 11/01/2016 15:57, Jonathan Druart a ?crit : >> Hi devs, >> >> I have played with NYTProf at the end of the last week, here is my >> loosely structured notes: >> https://joubu.github.io/koha/nytprof/dbic/index.html >> >> I have not found big things to implement in order to improve the speed >> but I am wondering if there is not something wrong with the queries >> cache (Search in the page for "Update:") >> >> Hope to get some feedbacks. >> >> Cheers, >> Jonathan >> >> PS: If someone has a better idea to share the profiles, I am open-minded. >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > -- > Julian Maurice > BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From z.tajoli at cineca.it Tue Jan 12 20:06:50 2016 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Tue, 12 Jan 2016 20:06:50 +0100 (CET) Subject: [Koha-devel] Which version of Zebra in Debian Jessie? Message-ID: <973924157.78199140.1452625610544.JavaMail.root@cineca.it> Hi to all, testing the install of Koha oldstable (3.20.7.1 now) with packaging I find this problem about version of Zebra: 1)If I create only /etc/apt/sources.list.d/koha.list with deb http://debian.koha-community.org/koha oldstable main I install Zebra from debian jessie repo, so version 2.0.59 with the problem "ICU phrase searches for terms split by ICU ZEB-664" 2)If I add /etc/apt/sources.list.d/indexdata.list with deb http://ftp.indexdata.dk/debian jessie main The sistem try to install zebra 2.0.61 with new yaz lib (5.15.2) This version of yaz doesn't work with package libnet-z3950-zoom-perl, the essential package for search and cataloguing. So, do you have fund this problem ? Do you think that the only solution now is to install zebra 2.0.59 on Debian Jessie ? Bye Zeno Tajoli From Katrin.Fischer.83 at web.de Wed Jan 13 08:27:52 2016 From: Katrin.Fischer.83 at web.de (Katrin Fischer) Date: Wed, 13 Jan 2016 08:27:52 +0100 Subject: [Koha-devel] Reminder: General IRC meeting 13 January 2016 Message-ID: <5695FC78.3060002@web.de> Hi all, just a quick reminder of the Koha General IRC meeting on 13 January 2016 at 20:00 UTC http://wiki.koha-community.org/wiki/General_IRC_meeting_13_January_2016 Hope to see you there :) Katrin From colin.campbell at ptfs-europe.com Wed Jan 13 14:04:37 2016 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Wed, 13 Jan 2016 13:04:37 +0000 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> Message-ID: <20160113130437.GA8573@zazou.cscnet.co.uk> On Tue, Jan 12, 2016 at 08:48:21AM -0500, Galen Charlton wrote: > Hi, > > On Sun, Jan 10, 2016 at 8:44 PM, David Cook wrote: > > We can?t necessarily rely on all Koha instances running this cronjob, nor > > can we rely on the frequency. Shouldn?t we be hiding these records from the > > OPAC as soon as they?re marked as ?deleted?? > > > > I?ve opened a bug for this purpose: > > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 > > I am in mild disfavor of this proposal, particularly as implemented in > current patch. Using a cronjob to delete records where Leader/05 is > set to 'd' is useful when the library has arranged their workflow such > that they *know* that Leader/05 = 'd' is being used consistently to > signify that a record is no longer wanted. However, for a library that > has not hitherto cared about the values in that position, > unconditionally suppressing the display of such records could come as > an unwelcome surprise. > I'd echo Galen's caution, especially if records are being imported, I've seen cases where trying to do this has revealed that records in use locally have inherited a deleted status from an upstream provider and does not reflect local status. 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 jonathan.druart at bugs.koha-community.org Wed Jan 13 16:46:56 2016 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 13 Jan 2016 15:46:56 +0000 Subject: [Koha-devel] Merge borrowers and deletedborrowers tables Message-ID: Hi devs, I am sure the community has already discussed about that: I am wondering why do we have a borrowers and a deletedborrowers tables when a "delete" flag in the borrowers table could do the trick. I am sure it's a matter of optimizing the sql queries, but did someone already compare on a descent database? It would help a lot to have the foreign keys set on other tables, to display the data if the library wants to displayed them. See bugs 13534 13668 14849 Doing this way, we make the DB structure consistent, but we will lost info. Cheers, Jonathan From M.de.Rooy at rijksmuseum.nl Wed Jan 13 16:57:06 2016 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 13 Jan 2016 15:57:06 +0000 Subject: [Koha-devel] Merge borrowers and deletedborrowers tables In-Reply-To: References: Message-ID: <809BE39CD64BFD4EB9036172EBCCFA315B007D9E@S-MAIL-1B.rijksmuseum.intra> Do not forget all cascaded updates and deletes. If you only set the flag, you will still need to perform those. What would be the big advantage of doing this? > I am wondering why do we have a borrowers and a deletedborrowers tables > when a "delete" flag in the borrowers table could do the trick. From jonathan.druart at bugs.koha-community.org Wed Jan 13 17:23:52 2016 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Wed, 13 Jan 2016 16:23:52 +0000 Subject: [Koha-devel] Merge borrowers and deletedborrowers tables In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA315B007D9E@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA315B007D9E@S-MAIL-1B.rijksmuseum.intra> Message-ID: Some of the existing constraints are wrong, some does not exist. On the 3 bug reports (see original message), I have submitted patches to add/fix the FK constraint, but we will loose data. The big advantage is... not to loose these data :) For the major part of the existing foreign keys, we can keep them, even if the patron is "deleted". We will need to provide a script to really remove the patrons a library would want to delete. 2016-01-13 15:57 GMT+00:00 Marcel de Rooy : > Do not forget all cascaded updates and deletes. If you only set the flag, you will still need to perform those. > What would be the big advantage of doing this? > >> I am wondering why do we have a borrowers and a deletedborrowers tables >> when a "delete" flag in the borrowers table could do the trick. > _______________________________________________ > 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 pianohacker at gmail.com Wed Jan 13 20:45:44 2016 From: pianohacker at gmail.com (Jesse) Date: Wed, 13 Jan 2016 12:45:44 -0700 Subject: [Koha-devel] [Koha] RFC: Circulation Rules Interface and Backend Revamp RFC In-Reply-To: References: Message-ID: It's a bit hard to parse out the changes in 5872, but I believe that the main difference between this proposal and 8369/5872 are the non-tabular interface and the new database structure. Here's my main argument for a non-tabular interface: many of the circ policies are common to an entire branch, category or itemtype, but the current interface requires them to be duplicated for every combination that needs new circ rules. It's very very difficult for a table to show the per-policy inheritance that we need to untangle this mess; 5872 made an effort, but I'd argue that with as complicated as the inheritance can be, the grey-cell approach could become quite confusing rather quickly. The new interface might need tuning, but I believe we need something different from what we have now. (By the way, if you have a system with very complicated issuingrules, please post a dump on bug 15521! It'll be very useful for planning the backend and interface.) 2016-01-08 2:17 GMT-07:00 Jonathan Druart < jonathan.druart at bugs.koha-community.org>: > (continuing on devel only) > > That's good news :) > We absolutely need a discussion here indeed, not to reproduce previous > attempts who failed. > For instance, (I have only 2 examples in mind) : > - Simplify the DB structure: Bug 8369 - default_branch_circ_rule and > default_circ_rules tables useless > - Modify the display : Bug 5872 - Enhancements to circulation > You can find on comment 27 a screencast to show you the interface > suggested: http://screencast.com/t/4duT8KV6VjQ (Thanks Liz for that!) > > As I completely agree the current interface has show its limits, I > personally think that the table is a good way to have an overview of > the rules. What you suggest seems less easy to understand, especially > for libraries using very complex circ rules. > > Cheers and good luck :) > Jonathan > > 2016-01-07 20:12 GMT+00:00 Jesse : > > The backend and frontend of the circulation/policy rules in Koha have > been > > extended and stretched to the point where they cause a fair amount of > > issues and frustration. Many librarians and developers are uncertain when > > default rules are applied, and the very large number of possible settings > > makes the interface and backend unwieldy. > > > > Full details for our intended solution can be found at the link at the > > bottom of this email, but here's the gist: > > > > Instead of having one database row with all settings for a given > > library/category/itemtype, allow each setting (checkout length, fine > > amount, holds allowed, etc.) to be specified separately. > > Rework the interface to more clearly show the specificity of > > default/specific rules, and allow for this new database model. > > Accomplish the above incrementally by gradually changing APIs. > > > > > http://wiki.koha-community.org/wiki/Circulation_Rules_Interface_and_Backend_Revamp_RFC > > > > Any and all comments are appreciated. Development on this project has > been > > fully sponsored, and we are looking to start work later this year. > > -- > > Jesse Weaver > > _______________________________________________ > > Koha mailing list http://koha-community.org > > Koha at lists.katipo.co.nz > > https://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ > 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/ > -- Jesse Weaver -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Jan 15 06:46:25 2016 From: dcook at prosentient.com.au (David Cook) Date: Fri, 15 Jan 2016 16:46:25 +1100 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> Message-ID: <006001d14f58$127e04a0$377a0de0$@prosentient.com.au> Hi Galen: I think adding a configuration option makes sense in that case. The thought occurred to me at the time, but I figured it would be ubiquitously welcome without one. A configuration option is easy enough to add. Adding a mechanism for specifying a set of query additions could be interesting, although it would involve some refactoring and re-testing of existing Koha code, which I doubt anyone would want to do. > I do not find this a compelling use case as stated. If the goal is to allow > harvesting and overlay records from an OAI-PMH provider to also delete bibs > from a Koha database... coding so that the records are > *actually* deleted seems more direct. Originally, I thought the same thing, Galen. I thought that I would download the OAI-PMH data, see the deleted status, and then just delete the record from Koha. However, I soon realized that I actually didn't have any way of doing that. The OAI-PMH data only contains the deleted status and the unique OAI-PMH identifier. The update is coming from upstream and it has no knowledge of downstream. So I first need to match that unique OAI-PMH identifier with a record in Koha before I can directly delete the record. At this point, I think the consensus amongst community members is to use Zebra, the record matching rules, and the MARC import_bib API for ingesting MARC records programmatically. And that works really well for additions and updates. However, it doesn't work so well for deletions. In theory, we could try to make it delete a record as soon as it sees a Leader/05=d, but that runs into the risks you and Colin described where librarians might not realize that Leader/05=d is set. I suppose another option could be added that makes this more explicit, but then we're changing an API which has been in steady use for years. I suppose I could keep a table tying the OAI-PMH identifier to a Koha biblionumber, but that's error-prone (especially due to bibliographic record merges, local deletions, etc) and it's a lot of data to keep for the single purpose of deleting records. Additionally, processing the deletions directly is inherently problematic. If there are items, the deletion will fail. I think there might be a few other foreign relationships which will cause bibliographic record deletes to fail. At that point, the third-party is at an impasse. They might know that they have failed to delete a record in Koha, but no one in Koha knows that a record wasn't successfully deleted. Going back to the added table idea, I suppose I could store the OAI-PMH identifier, and note an error if it fails to delete, and then Koha users can check that. However, that adds more overhead to the import of MARC records via an OAI-PMH provider. I'd have to make another web service to update the OAI-PMH table before trying to send it to import_bib. That's double the HTTP requests though, so maybe I'd just make import_oai and skip import_bib all together, but then I'm duplicating most of the code in import_bib just to support deletions. That seems inefficient and error-prone as well. I'm reflecting on the wording in your last message, Galen. I suppose the main goal is to harvest records from an OAI-PMH server, and then to add/update MARC records in Koha. That works well. But a secondary goal is to delete records from Koha where they've been deleted upstream in the OAI-PMH server, yes. As I noted above though, upstream doesn't have knowledge of downstream. I suppose I could query Zebra myself using Z39.50 or SRU (although SRU is disabled by default I believe), but then I lose the record matching rules, which are vital to matching MARC record fields with Zebra indexes. But let's say I query Zebra directly, I could then get the biblionumber I need and then use "/svc/bib" to attempt a deletion. Although that still runs into the same problem as before... the automatic deletion might fail... and no one in Koha will know. At that point, I suppose I could try sending an email, or have some other error reporting mechanism to Koha users... but then the added code is simply to explain that a deletion has failed. It seems simpler and less error-prone to mark a record as deleted, hide it from the OPAC, and then let Koha users either use searches or reports to find Leader/05=d records to deal with according to their own discretion. I suppose the reports would be difficult on larger databases, but a search would work well. "Record-status=d" would show all records listed as deleted with reasonable efficiency. I like the idea of just deleting records directly, but I think it's more complex than it appears at first glance. It's not just an issue with OAI-PMH either really. It's an issue any time you try to delete a record without providing feedback to an end-user. I am open to suggestions though. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: Galen Charlton [mailto:gmc at esilibrary.com] > Sent: Wednesday, 13 January 2016 12:48 AM > To: David Cook > Cc: Koha Devel > Subject: Re: [Koha-devel] Hide records on Leader 05 = d in OPAC > > Hi, > > On Sun, Jan 10, 2016 at 8:44 PM, David Cook > wrote: > > We can?t necessarily rely on all Koha instances running this cronjob, > > nor can we rely on the frequency. Shouldn?t we be hiding these records > > from the OPAC as soon as they?re marked as ?deleted?? > > > > I?ve opened a bug for this purpose: > > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 > > I am in mild disfavor of this proposal, particularly as implemented in current > patch. Using a cronjob to delete records where Leader/05 is set to 'd' is > useful when the library has arranged their workflow such that they *know* > that Leader/05 = 'd' is being used consistently to signify that a record is no > longer wanted. However, for a library that has not hitherto cared about the > values in that position, unconditionally suppressing the display of such > records could come as an unwelcome surprise. > > That said, it is also a reasonable choice for a library to want to use the > Leader/05 as suppression criterion. Consequently, I suggest adding a > configuration option. For that matter, making it configurable (say, by > allowing the library to specify a set of query additions for the purpose of > filtering records from public display) could result in a more generally useful > mechanism. > > > I admit that I have a special interest in this where I might be > > overlaying existing records using a mostly empty skeleton record > > generated from an OAI-PMH identifier and a OAI-PMH deleted status > > (OAI-PMH doesn?t send metadata for deleted records). > > I?d match the existing record in Koha using the identifier, and then > > set LDR05 to ?d? in accordance with the OAI-PMH deleted status. Then, > > that record would disappear from the OPAC, so that end users don?t see > > this skeleton record. > > I do not find this a compelling use case as stated. If the goal is to allow > harvesting and overlay records from an OAI-PMH provider to also delete bibs > from a Koha database... coding so that the records are > *actually* deleted seems more direct. > > Regards, > > Galen > -- > Galen Charlton > Infrastructure and Added Services Manager Equinox Software, Inc. / The > Open Source Experts > email: gmc at esilibrary.com > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web: http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org From dcook at prosentient.com.au Fri Jan 15 06:50:46 2016 From: dcook at prosentient.com.au (David Cook) Date: Fri, 15 Jan 2016 16:50:46 +1100 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: <20160113130437.GA8573@zazou.cscnet.co.uk> References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> <20160113130437.GA8573@zazou.cscnet.co.uk> Message-ID: <006101d14f58$ae034020$0a09c060$@prosentient.com.au> Hi Colin: That's interesting. I suppose it does depend on the relationship that one has with the upstream provider. In the case of OAI-PMH, I think it would make sense for that status to be updated downstream. However, in the case of Z39.50, I could see that being very bad. While that library may have "deleted" that record, it is still of use to your library. Of course, in that case, maybe we should be mitigating that in C4::Biblio::AddBiblio. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Colin Campbell > Sent: Thursday, 14 January 2016 12:05 AM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Hide records on Leader 05 = d in OPAC > > On Tue, Jan 12, 2016 at 08:48:21AM -0500, Galen Charlton wrote: > > Hi, > > > > On Sun, Jan 10, 2016 at 8:44 PM, David Cook > wrote: > > > We can?t necessarily rely on all Koha instances running this > > > cronjob, nor can we rely on the frequency. Shouldn?t we be hiding > > > these records from the OPAC as soon as they?re marked as ?deleted?? > > > > > > I?ve opened a bug for this purpose: > > > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537 > > > > I am in mild disfavor of this proposal, particularly as implemented in > > current patch. Using a cronjob to delete records where Leader/05 is > > set to 'd' is useful when the library has arranged their workflow such > > that they *know* that Leader/05 = 'd' is being used consistently to > > signify that a record is no longer wanted. However, for a library that > > has not hitherto cared about the values in that position, > > unconditionally suppressing the display of such records could come as > > an unwelcome surprise. > > > I'd echo Galen's caution, especially if records are being imported, I've seen > cases where trying to do this has revealed that records in use locally have > inherited a deleted status from an upstream provider and does not reflect > local status. > > 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 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/ bugs : http://bugs.koha-community.org/ From z.tajoli at cineca.it Fri Jan 15 13:02:48 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Fri, 15 Jan 2016 13:02:48 +0100 Subject: [Koha-devel] Fwd: Call for testers: next release of Net::OAI::Harvester Perl module may break legacy custom handlers In-Reply-To: <5698DA29.70902@Gymel.com> References: <5698DA29.70902@Gymel.com> Message-ID: <5698DFE8.4070801@cineca.it> -------- Messaggio Inoltrato -------- Oggetto: Call for testers: next release of Net::OAI::Harvester Perl module may break legacy custom handlers Data: Fri, 15 Jan 2016 12:38:17 +0100 Mittente: Thomas Berger Rispondi-a: ThB at Gymel.com Organizzazione: Gymel.com A: Perl for libraries , Using XML in libraries -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for cross-posting] The Perl module Net::OAI::Harvester implements a client framework for the OAI Protocol for Metadata Harvesting (OAI-PMH) and was authored and originally maintained by Ed Summers. It has been available on CPAN ever since 2003 and its last stable version 1.15 has been released almost four years ago: < http://search.cpan.org/~thb/OAI-Harvester-1.15/ >. Since one of the repositories used for testing vanished from the web some time ago and this is breaking the test suite a new version has to be released fairly soon. Over time I had been tackling various minor issues and published developer releases on CPAN, cf. the list at the end of this mail or the Changes document linked at the CPAN page for the current release 1.16_12: < http://search.cpan.org/~thb/OAI-Harvester-1.16_12/ > However the sum of these changes is not negligible and specifically their impact on "custom metadata handlers" (which are to be used when processing other metadata formats than oai_dc) may affect applications using the module: >>>>> Up to version 1.15 the metadataHandler was inconsistently fed with input : - GetRecord exposed the almost complete XML response to the Handler (including start_document/end_document events) - ListRecords exposed the (OAI)record element (header, metadata and optional about containers) but did not propagate start_document or end_document events. In both cases the events for the header tags itself and for the optional setSpec subelements had not been forwarded Version 1.20 introduces a modified behavior for metadataHandler and an additional recordHandler: - a metadataHandler will see only the (single) subelement of the OAI metadata element (so for an deleted record it might never be invoced at all) - a recordHandler will see the OAI record element and its subelements Therefore a metadataHandler will now be confined to the metadata fragment(s) of the response, and the new recordHandler approximates the old behavior of ListRecords, however OAI-PMH:identifier and OAI-PMH:datestamp will now be properly encapsulated within their OAI-PMH:header element. Additionally, two new methods responseDate() and request() allow access to the corresponding top-level OAI-PMH elements in all response types. A SAX filter of class Net::OAI::Record::DocumentHelper may be used to inject start_document and end_document events into the chain if they are needed. As a temporary measure, you may set $Net::OAI::Harvester::OLDmetadataHandler =1 to change the behavior of handlers passed as "metadataHandler" into that of a recordHandler. <<<<<< Obviously the change of semantics for a metadataHandler to deal with the "metadata" elements of the response instead of the "record" elements is a design decision and may be questioned by users of the module. The current version also contains several changes which solve deficiencies of Net::OAI::Harvester 1.15 but possibly break existing workarounds for these deficiencies. For example officially (per documentation) you never could acccess the responseDate of the OAI-PMH result, but due to a sloppy implementation of processing for the identify verb it was possible to extract it in this case by an undocumented method. The current version supplies a dedicated responseDate() accessor for all verbs but at the same time fixes the behavior in the identify case. I may be overly optimistic but my impression is that the changes between the current 1.15 and the coming version (most probably numbered 1.20) do actually fix many issues but the fear is realistic (I experienced that myself with an old application of mine using the module) that these fixes may conflict with workarounds introduced by users to make things work before. *** So please, if you are currently using Net::OAI::Harvester *and* had been forced to introduce workarounds or tweak internals of the module, perform thorough testing before upgrading to the coming stable version, preferably already now with the developer version 1.16_12. And, please, please: provide feedback if you should run into trouble, either via the CPAN request tracker for the module at < https://rt.cpan.org/Public/Dist/Display.html?Name=OAI-Harvester > or by direct mail. Sorry for the inconvenience viele Gruesse Thomas Berger Changes to Net::OAI::Harvester since version 1.15 1.16_12 Tue, Jan 12 00:20:05 CET 2016 - - dealing with CPANTS Kwalitee issues, esp. version number mess - - new filter class Net::OAI::Record::DocumentHelper for tweaking 1.16_11 Tue, Jan 12 00:20:05 CET 2016 - - minor cleanup 1.16_10 Mon, Jan 11 01:29:46 CET 2016 - - renamed alldata() method for accessing recordHandler results to recorddata() - - better propagation of namespace prefix mapping events - - Net::OAI::NamespaceFilter with a result() method - - Net::OAI::NamespaceFilter tested with XML::SAX::Writer - - AUTHOR formatting 1.16_09 Sun, Feb 14 17:29:39 CET 2014 - - Net::OAI::NamespaceFilter as kind of generic metadata handler - - Queries are now constructed basing on a copy of the Harvester's baseURL - - pass parameters to URI->query_form() more reproducably, (esp. "verb" should now always be first to accommodate some allegedly broken repositories) - - temporary? tests for correctness of LWP operations 1.16_07 Tue, Apr 30 01:26:40 CEST 2013 - - added new methods: response(), responseDate(), error() - - Smoke still tests failed on 'Bad Host' tests (wrong error codes induced by HTTP proxies?) - - aligned behavior of metadataHandler for listRecords() and getRecord() - - introducing alternative recordHandler for listRecords() and getRecord() - - removed erroneous resumptionToken handling for identify() 1.16_04 Fri Dec 7 09:49:03 CET 2012 - - consider HTTP proxies in design of t/003.error.t - - 'Bad Host' tests failing b/c error code 500 is not the expected code 404 (due to some recent change in LWP)? 1.16_01 Mon Apr 2 23:14:35 CEST 2012 - - Modules were not namespace aware. - - Add HTTPRetryAfter() method (catches HTTP Retry-After header) - - Check responses for Content-Type and charset before parsing - - Net::OAI::Header handed up (empty) header elements and other stuff to the request's metadataHandler - - SKIP tests when HTTP errors are encountered -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iJwEAQECAAYFAlaY2iYACgkQYhMlmJ6W47MMCwP/Yhij11TfEL1dfYtimdXG8hkf FYLvvXECzECPxKbHIC0dKvf5v4myW8oedlK3B+oOzIjjOY60pT7pdC4KB/xgU+a1 N1djewSgT4hJ3IoacmUkLpnh81NSM1oA0osw48qVco4qpxDOY2HrR3bdBZksKBcI lQH10kIYqo/TZYGXHYQ= =v03A -----END PGP SIGNATURE----- From kyle.m.hall at gmail.com Fri Jan 15 14:53:30 2016 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Fri, 15 Jan 2016 08:53:30 -0500 Subject: [Koha-devel] Merge borrowers and deletedborrowers tables In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA315B007D9E@S-MAIL-1B.rijksmuseum.intra> Message-ID: I'm am totally in favor of merging borrowers and deletedborrowers! I think the same could be said for most if not all of the deleted/old tables. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Jan 13, 2016 at 11:23 AM, Jonathan Druart < jonathan.druart at bugs.koha-community.org> wrote: > Some of the existing constraints are wrong, some does not exist. > On the 3 bug reports (see original message), I have submitted patches > to add/fix the FK constraint, but we will loose data. > The big advantage is... not to loose these data :) > For the major part of the existing foreign keys, we can keep them, > even if the patron is "deleted". > We will need to provide a script to really remove the patrons a > library would want to delete. > > 2016-01-13 15:57 GMT+00:00 Marcel de Rooy : > > Do not forget all cascaded updates and deletes. If you only set the > flag, you will still need to perform those. > > What would be the big advantage of doing this? > > > >> I am wondering why do we have a borrowers and a deletedborrowers tables > >> when a "delete" flag in the borrowers table could do the trick. > > _______________________________________________ > > 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 barton at bywatersolutions.com Fri Jan 15 15:32:41 2016 From: barton at bywatersolutions.com (Barton Chittenden) Date: Fri, 15 Jan 2016 09:32:41 -0500 Subject: [Koha-devel] Merge borrowers and deletedborrowers tables In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA315B007D9E@S-MAIL-1B.rijksmuseum.intra> Message-ID: On Fri, Jan 15, 2016 at 8:53 AM, Kyle Hall wrote: > I'm am totally in favor of merging borrowers and deletedborrowers! I think > the same could be said for most if not all of the deleted/old tables. > I couldn't +1 this more vigorously if I tried... I write a lot of reports for libraries, and I waste^H^H^H^H^Hspend more time writing clever coalesce statements in an effort to avoid MySQL's performance penalties for subqueries and unions... the results tend to be ugly and brittle. --Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Fri Jan 15 15:49:27 2016 From: gmc at esilibrary.com (Galen Charlton) Date: Fri, 15 Jan 2016 09:49:27 -0500 Subject: [Koha-devel] Merge borrowers and deletedborrowers tables In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA315B007D9E@S-MAIL-1B.rijksmuseum.intra> Message-ID: Hi, On Wed, Jan 13, 2016 at 11:23 AM, Jonathan Druart wrote: > Some of the existing constraints are wrong, some does not exist. > On the 3 bug reports (see original message), I have submitted patches > to add/fix the FK constraint, but we will loose data. > The big advantage is... not to loose these data :) That is not an unambiguous advantage: one's "losing" patron data is another's "better protecting patron privacy". Also, merging the two tables will impose a cost on every user that has written reports that query the borrowers table and will be faced with the task of determining if they need to tack on "AND NOT deleted" clauses to the queries. That said, in Evergreen patron records do have a boolean flag that expresses logical deletion status. That approach has generally worked, but at the cost of requiring more code to fully delete and/or anonymize records for patrons who no longer have any relationship with the library. Overall, I'm neutral on the design question of using one table or two; I'm more dubious about the potential for disruption if we make a change, since we're not starting from scratch here. I note that the three bugs you've cited are concerned with the deletion of *staff* user accounts. A more minimal change might be to treat staff accounts specially and devise a way to mark them inactive instead of deleting them. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From gmc at esilibrary.com Fri Jan 15 16:36:09 2016 From: gmc at esilibrary.com (Galen Charlton) Date: Fri, 15 Jan 2016 10:36:09 -0500 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: <006001d14f58$127e04a0$377a0de0$@prosentient.com.au> References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> <006001d14f58$127e04a0$377a0de0$@prosentient.com.au> Message-ID: Hi, On Fri, Jan 15, 2016 at 12:46 AM, David Cook wrote: > I like the idea of just deleting records directly, but I think it's > more complex than it appears at first glance. It's not just an > issue with OAI-PMH either really. It's an issue any time you > try to delete a record without providing feedback to an end-user. I've got a question for you: for the specific project you're coding for, which ends do you control? The Koha instance, the data provider publishing via OAI-PMH, or both? To make a general point: yep, there are definitely edge cases and error conditions to consider when implementing a mechanism by which a third party can specify that records should be deleted in a Koha database. Some of those might be better solved by policy rather than code; for example, if the OAI-PMH provider in some sense "owns" the records that Koha ingests from it, does the Koha library need to a have policy of not adding items to such records? If so, it might be appropriate to add an option that specifies that bib deletions are to forcibly cascade. Conversely, if it *is* legitimate for the Koha user to add items to those records, does that mean that the OAI-PMH provider no longer has "ownership"? To make another general point: I think it would be better for the consequences of record deletion to be handled *within the context of OAI-PMH harvesting* (or more generally, mechanisms to sync records with an external provider), but *not* to have those consequences spill over for users who are not doing such harvesting as all. Your original proposal to unconditionally hide Leader/05='d' records from the public catalog would be an example of such spillover. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From kohanews at gmail.com Fri Jan 15 21:03:25 2016 From: kohanews at gmail.com (kohanews) Date: Fri, 15 Jan 2016 12:03:25 -0800 Subject: [Koha-devel] Call for development news: January 2016 Newsletter Message-ID: <5699508D.2070901@gmail.com> Let the community hear what cool things you're working on! Send me some bugs that need testing, sign-offs and user feedback. Suggestions welcome! k o h a news AT gmail dot com Thank you! -- Chad Roseburg Editor, Koha Community Newsletter From kohanews at gmail.com Sat Jan 16 02:46:10 2016 From: kohanews at gmail.com (kohanews) Date: Fri, 15 Jan 2016 17:46:10 -0800 Subject: [Koha-devel] Call for news: January 2016 Newsletter Message-ID: <5699A0E2.8030506@gmail.com> Fellow Koha users ~ I'm collecting news for the January newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events -- **** one month back is the cut-off ***. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. -- Chad Roseburg Editor, Koha Community Newsletter From dcook at prosentient.com.au Mon Jan 18 05:33:20 2016 From: dcook at prosentient.com.au (David Cook) Date: Mon, 18 Jan 2016 15:33:20 +1100 Subject: [Koha-devel] Hide records on Leader 05 = d in OPAC In-Reply-To: References: <008901d14c11$aa745240$ff5cf6c0$@prosentient.com.au> <006001d14f58$127e04a0$377a0de0$@prosentient.com.au> Message-ID: <014a01d151a9$5bc205a0$134610e0$@prosentient.com.au> Hi, For this specific project, I personally don't have control of anything per se, but the sponsors of the code will have control of their Koha instance and theoretically the data in the upstream data provider - although not control of the data provider itself. I have thought a bit about policy, but I'm not sure that it's entirely relevant in this case. Regardless of ownership, you can't really do a cascade delete if a bib's items are on loan or on hold or otherwise engaged. For example, let's say that the upstream data provider was the sole provider of bib and item data into Koha. If they delete the record upstream but an item is engaged downstream, the delete will fail. I suppose in my particular case it might not matter too much... as the library might not delete their records from upstream until the items have been dealt with downstream. But I doubt that would be the case for all users and it doesn't account for user mistakes either. You could still end up with orphaned records in Koha that no one necessarily knows to remove. As for the scenario where the Koha user can add items to harvested bibs, which may be the case for the sponsors, that is indeed more complicated. On one hand, the upstream data provider provides all the bibliographic data so they "own" the record. On the other hand, does the upstream data provider have knowledge of the downstream items? They might or they might not... I think perhaps I'm beginning to understand your point. Due to the variety of scenarios, perhaps it makes sense to track all OAI-PMH transactions, and then have policies for controlling how deletions are processed from there. That way, even if direct deletions are the norm, errors for failed deletions can be tracked. Or if users would prefer to know that an upstream bib has been deleted but they want to keep their downstream bib, that can be an option too. Those options can also be fleshed out over time as needed in terms of a dashboard, alerting, etc. Tracking the transactions in the database would help me prevent some race conditions for asynchronous importing as well... Hmm, yes, I can see the sense of preventing that spill over beyond the OAI-PMH import domain. I think perhaps my original proposal was trying to cut too many corners. I'm tempted to amend the Bugzilla patch to include a system preference, but I suspect that I won't end up using this in my project anymore. Thanks for your feedback, Galen. It's much appreciated. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: Galen Charlton [mailto:gmc at esilibrary.com] > Sent: Saturday, 16 January 2016 2:36 AM > To: David Cook > Cc: Koha Devel > Subject: Re: [Koha-devel] Hide records on Leader 05 = d in OPAC > > Hi, > > On Fri, Jan 15, 2016 at 12:46 AM, David Cook > wrote: > > I like the idea of just deleting records directly, but I think it's > > more complex than it appears at first glance. It's not just an issue > > with OAI-PMH either really. It's an issue any time you try to delete a > > record without providing feedback to an end-user. > > I've got a question for you: for the specific project you're coding for, which > ends do you control? The Koha instance, the data provider publishing via > OAI-PMH, or both? > > To make a general point: yep, there are definitely edge cases and error > conditions to consider when implementing a mechanism by which a third > party can specify that records should be deleted in a Koha database. Some of > those might be better solved by policy rather than code; for example, if the > OAI-PMH provider in some sense "owns" the records that Koha ingests from > it, does the Koha library need to a have policy of not adding items to such > records? If so, it might be appropriate to add an option that specifies that bib > deletions are to forcibly cascade. > > Conversely, if it *is* legitimate for the Koha user to add items to those > records, does that mean that the OAI-PMH provider no longer has > "ownership"? > > To make another general point: I think it would be better for the > consequences of record deletion to be handled *within the context of OAI- > PMH harvesting* (or more generally, mechanisms to sync records with an > external provider), but *not* to have those consequences spill over for > users who are not doing such harvesting as all. Your original proposal to > unconditionally hide Leader/05='d' records from the public catalog would be > an example of such spillover. > > Regards, > > Galen > -- > Galen Charlton > Infrastructure and Added Services Manager Equinox Software, Inc. / The > Open Source Experts > email: gmc at esilibrary.com > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web: http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org From wosch at freebsd.org Mon Jan 18 11:15:48 2016 From: wosch at freebsd.org (Wolfram Schneider) Date: Mon, 18 Jan 2016 11:15:48 +0100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <973924157.78199140.1452625610544.JavaMail.root@cineca.it> References: <973924157.78199140.1452625610544.JavaMail.root@cineca.it> Message-ID: On 12 January 2016 at 20:06, Zeno Tajoli wrote: > Hi to all, > > testing the install of Koha oldstable (3.20.7.1 now) with packaging I find this > problem about version of Zebra: > > 1)If I create only /etc/apt/sources.list.d/koha.list with > deb http://debian.koha-community.org/koha oldstable main > > I install Zebra from debian jessie repo, so version 2.0.59 > with the problem "ICU phrase searches for terms split by ICU ZEB-664" > > 2)If I add /etc/apt/sources.list.d/indexdata.list with > deb http://ftp.indexdata.dk/debian jessie main > > The sistem try to install zebra 2.0.61 with new yaz lib (5.15.2) > This version of yaz doesn't work with package libnet-z3950-zoom-perl, > the essential package for search and cataloguing. which version of libnet-z3950-zoom-perl are you using? What do you mean with does'nt work with yaz? Maybe you need to de-install libnet-z3950-zoom-perl, and then install it again. -Wolfram > So, do you have fund this problem ? > Do you think that the only solution now is to install zebra 2.0.59 on Debian Jessie ? > > Bye > Zeno Tajoli -- Wolfram Schneider http://wolfram.schneider.org From dcook at prosentient.com.au Mon Jan 18 23:29:35 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 19 Jan 2016 09:29:35 +1100 Subject: [Koha-devel] Fwd: Call for testers: next release of Net::OAI::Harvester Perl module may break legacy custom handlers In-Reply-To: <5698DFE8.4070801@cineca.it> References: <5698DA29.70902@Gymel.com> <5698DFE8.4070801@cineca.it> Message-ID: <000301d1523f$b5b54c70$211fe550$@prosentient.com.au> Yeah, I saw that in the perl4lib email, but we don't actually use Net::OAI::Harvester in Koha. We use HTTP::OAI for the OAI-PMH server, and I'm using HTTP::OAI for the harvester as well (although it certainly has some issues...). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Tajoli Zeno > Sent: Friday, 15 January 2016 11:03 PM > To: koha-devel > Subject: [Koha-devel] Fwd: Call for testers: next release of > Net::OAI::Harvester Perl module may break legacy custom handlers > > > > > -------- Messaggio Inoltrato -------- > Oggetto: Call for testers: next release of Net::OAI::Harvester Perl module > may break legacy custom handlers > Data: Fri, 15 Jan 2016 12:38:17 +0100 > Mittente: Thomas Berger > Rispondi-a: ThB at Gymel.com > Organizzazione: Gymel.com > A: Perl for libraries , Using XML in libraries > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [Apologies for cross-posting] > > The Perl module Net::OAI::Harvester implements a client framework for the > OAI Protocol for Metadata Harvesting (OAI-PMH) and was authored and > originally maintained by Ed Summers. It has been available on CPAN ever > since 2003 and its last stable version 1.15 has been released almost four years > ago: > < http://search.cpan.org/~thb/OAI-Harvester-1.15/ >. > > Since one of the repositories used for testing vanished from the web some > time ago and this is breaking the test suite a new version has to be released > fairly soon. > > Over time I had been tackling various minor issues and published developer > releases on CPAN, cf. the list at the end of this mail or the Changes document > linked at the CPAN page for the current release 1.16_12: < > http://search.cpan.org/~thb/OAI-Harvester-1.16_12/ > > > However the sum of these changes is not negligible and specifically their > impact on "custom metadata handlers" (which are to be used when > processing other metadata formats than oai_dc) may affect applications > using the module: > > >>>>> > Up to version 1.15 the metadataHandler was inconsistently fed with input > : > > - GetRecord exposed the almost complete XML response to the Handler > (including start_document/end_document events) > - ListRecords exposed the (OAI)record element (header, metadata and > optional about containers) but did not propagate start_document or > end_document events. > > In both cases the events for the header tags itself and for the optional > setSpec subelements had not been forwarded > > Version 1.20 introduces a modified behavior for metadataHandler and an > additional recordHandler: > - a metadataHandler will see only the (single) subelement of the OAI > metadata element (so for an deleted record it might never be invoced > at all) > - a recordHandler will see the OAI record element and its subelements > > Therefore a metadataHandler will now be confined to the metadata > fragment(s) of the response, and the new recordHandler approximates the > old behavior of ListRecords, however OAI-PMH:identifier and OAI- > PMH:datestamp will now be properly encapsulated within their OAI- > PMH:header element. > > Additionally, two new methods responseDate() and request() allow access to > the corresponding top-level OAI-PMH elements in all response types. > A SAX filter of class Net::OAI::Record::DocumentHelper may be used to inject > start_document and end_document events into the chain if they are > needed. > > As a temporary measure, you may set > $Net::OAI::Harvester::OLDmetadataHandler =1 to change the behavior of > handlers passed as "metadataHandler" into that of a recordHandler. > <<<<<< > > Obviously the change of semantics for a metadataHandler to deal with the > "metadata" elements of the response instead of the "record" elements is a > design decision and may be questioned by users of the module. > > The current version also contains several changes which solve deficiencies of > Net::OAI::Harvester 1.15 but possibly break existing workarounds for these > deficiencies. For example officially (per > documentation) you never could acccess > the responseDate of the OAI-PMH result, but due to a sloppy > implementation of processing for the identify verb it was possible to extract > it in this case by an undocumented method. The current version supplies a > dedicated responseDate() accessor for all verbs but at the same time fixes > the behavior in the identify case. > > I may be overly optimistic but my impression is that the changes between > the current 1.15 and the coming version (most probably numbered 1.20) do > actually fix many issues but the fear is realistic (I experienced that myself > with an old application of mine using the module) that these fixes may > conflict with workarounds introduced by users to make things work before. > > *** > > So please, if you are currently using Net::OAI::Harvester *and* had been > forced to introduce workarounds or tweak internals of the module, perform > thorough testing before upgrading to the coming stable version, preferably > already now with the developer version 1.16_12. > > And, please, please: provide feedback if you should run into trouble, either > via the CPAN request tracker for the module at < > https://rt.cpan.org/Public/Dist/Display.html?Name=OAI-Harvester > or by > direct mail. > > Sorry for the inconvenience > viele Gruesse > Thomas Berger > > > Changes to Net::OAI::Harvester since version 1.15 > > 1.16_12 Tue, Jan 12 00:20:05 CET 2016 > - - dealing with CPANTS Kwalitee issues, esp. version number mess > - - new filter class Net::OAI::Record::DocumentHelper for tweaking > > 1.16_11 Tue, Jan 12 00:20:05 CET 2016 > - - minor cleanup > > 1.16_10 Mon, Jan 11 01:29:46 CET 2016 > - - renamed alldata() method for accessing recordHandler results > to recorddata() > - - better propagation of namespace prefix mapping events > - - Net::OAI::NamespaceFilter with a result() method > - - Net::OAI::NamespaceFilter tested with XML::SAX::Writer > - - AUTHOR formatting > > 1.16_09 Sun, Feb 14 17:29:39 CET 2014 > - - Net::OAI::NamespaceFilter as kind of generic metadata handler > - - Queries are now constructed basing on a copy of the Harvester's > baseURL > - - pass parameters to URI->query_form() more reproducably, > (esp. "verb" should now always be first to accommodate some > allegedly broken repositories) > - - temporary? tests for correctness of LWP operations > > 1.16_07 Tue, Apr 30 01:26:40 CEST 2013 > - - added new methods: response(), responseDate(), error() > - - Smoke still tests failed on 'Bad Host' tests (wrong error codes > induced by HTTP proxies?) > - - aligned behavior of metadataHandler for listRecords() and > getRecord() > - - introducing alternative recordHandler for listRecords() and > getRecord() > - - removed erroneous resumptionToken handling for identify() > > 1.16_04 Fri Dec 7 09:49:03 CET 2012 > - - consider HTTP proxies in design of t/003.error.t > - - 'Bad Host' tests failing b/c error code 500 is not the expected > code 404 (due to some recent change in LWP)? > > 1.16_01 Mon Apr 2 23:14:35 CEST 2012 > - - Modules were not namespace aware. > - - Add HTTPRetryAfter() method (catches HTTP Retry-After header) > - - Check responses for Content-Type and charset before parsing > - - Net::OAI::Header handed up (empty) header elements and other stuff > to the request's metadataHandler > - - SKIP tests when HTTP errors are encountered > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iJwEAQECAAYFAlaY2iYACgkQYhMlmJ6W47MMCwP/Yhij11TfEL1dfYtimdXG8h > kf > FYLvvXECzECPxKbHIC0dKvf5v4myW8oedlK3B+oOzIjjOY60pT7pdC4KB/xgU+a > 1 > N1djewSgT4hJ3IoacmUkLpnh81NSM1oA0osw48qVco4qpxDOY2HrR3bdBZksK > BcI > lQH10kIYqo/TZYGXHYQ= > =v03A > -----END PGP SIGNATURE----- > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/ bugs : http://bugs.koha-community.org/ From dcook at prosentient.com.au Tue Jan 19 03:15:03 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 19 Jan 2016 13:15:03 +1100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: References: <973924157.78199140.1452625610544.JavaMail.root@cineca.it> Message-ID: <003101d1525f$35424000$9fc6c000$@prosentient.com.au> I'm also curious about what you mean when you say that "libnet-z3950-zoom-perl" doesn't work for you. It may indeed be necessary to re-install it as it probably compiles against whatever YAZ is installed in the system at the time. Honestly haven't looked into it myself as we use openSUSE so we don't use the Debian packages... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Wolfram Schneider > Sent: Monday, 18 January 2016 9:16 PM > To: Zeno Tajoli ; Wolfram Schneider > > Cc: Koha Devel > Subject: Re: [Koha-devel] Which version of Zebra in Debian Jessie? > > On 12 January 2016 at 20:06, Zeno Tajoli wrote: > > Hi to all, > > > > testing the install of Koha oldstable (3.20.7.1 now) with packaging I > > find this problem about version of Zebra: > > > > 1)If I create only /etc/apt/sources.list.d/koha.list with deb > > http://debian.koha-community.org/koha oldstable main > > > > I install Zebra from debian jessie repo, so version 2.0.59 with the > > problem "ICU phrase searches for terms split by ICU ZEB-664" > > > > 2)If I add /etc/apt/sources.list.d/indexdata.list with deb > > http://ftp.indexdata.dk/debian jessie main > > > > The sistem try to install zebra 2.0.61 with new yaz lib (5.15.2) This > > version of yaz doesn't work with package libnet-z3950-zoom-perl, the > > essential package for search and cataloguing. > > which version of libnet-z3950-zoom-perl are you using? What do you mean > with does'nt work with yaz? > > Maybe you need to de-install libnet-z3950-zoom-perl, and then install it > again. > > -Wolfram > > > So, do you have fund this problem ? > > Do you think that the only solution now is to install zebra 2.0.59 on Debian > Jessie ? > > > > Bye > > Zeno Tajoli > > -- > Wolfram Schneider http://wolfram.schneider.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 dcook at prosentient.com.au Tue Jan 19 05:10:36 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 19 Jan 2016 15:10:36 +1100 Subject: [Koha-devel] Searching URLs in Zebra Message-ID: <004d01d1526f$597ff2e0$0c7fd8a0$@prosentient.com.au> Hey brains trust, I'm reaching out to everyone as I'm a bit stuck with http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 at the moment. There's currently no way to search an index with the "url" (ie "u") register. A URL is stored "as is" in that index, but all our Koha search methods use s/:/=/g or s/=/:/g and that plays havoc with the URLs used in a search query, which makes the match fail against the indexed URL. C4::Matcher::get_matches() strips spaces and punctuation, so I've added a "none" or "raw" normalizer that performs no normalization, but C4::Search::SimpleSearch() does that global replacement for ":" and "=" (depending on your QueryParser settings and what qualifiers you've specified in your Record Matching Rules). I thought about adding a "skip normalization" flag to C4::Search::SimpleSearch, but that doesn't work because C4::Matcher uses : for QueryParser and = for non-QueryParser. except C4::Search::SimpleSearch() deactivates QueryParser mode if you have a "index,phr" set of qualifiers. which means that you get a ":" when you need a "=" for the non-QueryParser CCL query. I suppose the solution might be the following: Current Matcher.pm: $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser')); Current Search.pm $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/)); Future Matcher.pm: $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/)); If I just have that conditional the same in both Search.pm and Matcher.pm. then maybe a "skip_normalization" flag in SimpleSearch() would work. I might try that in a minute. but opening it up because I could really use a hand with this. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Jan 19 05:31:10 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 19 Jan 2016 15:31:10 +1100 Subject: [Koha-devel] Searching URLs in Zebra Message-ID: <005201d15272$391baf00$ab530d00$@prosentient.com.au> Ah, just realized again that qq($QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/));) won't work in C4::Matcher because there's no $query. The only equivalent of that would be to check all the $matchpoint->{'index'} fields in the $self->{'matchpoints'} arrayref. Which we might have to do because the QueryParser doesn't seem to be able to handle the "index,phr" (ie "qualifier,qualifier") format. That's verified by the fact that C4::Search::SimpleSearch is doing that regex. Sure, we could just not use a list of qualifiers for a Record Matching Rule index, but then we have no control over what index register we're using and that's also a problem. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: David Cook [mailto:dcook at prosentient.com.au] Sent: Tuesday, 19 January 2016 3:11 PM To: 'Koha Devel' Subject: Searching URLs in Zebra Hey brains trust, I'm reaching out to everyone as I'm a bit stuck with http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 at the moment. There's currently no way to search an index with the "url" (ie "u") register. A URL is stored "as is" in that index, but all our Koha search methods use s/:/=/g or s/=/:/g and that plays havoc with the URLs used in a search query, which makes the match fail against the indexed URL. C4::Matcher::get_matches() strips spaces and punctuation, so I've added a "none" or "raw" normalizer that performs no normalization, but C4::Search::SimpleSearch() does that global replacement for ":" and "=" (depending on your QueryParser settings and what qualifiers you've specified in your Record Matching Rules). I thought about adding a "skip normalization" flag to C4::Search::SimpleSearch, but that doesn't work because C4::Matcher uses : for QueryParser and = for non-QueryParser. except C4::Search::SimpleSearch() deactivates QueryParser mode if you have a "index,phr" set of qualifiers. which means that you get a ":" when you need a "=" for the non-QueryParser CCL query. I suppose the solution might be the following: Current Matcher.pm: $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser')); Current Search.pm $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/)); Future Matcher.pm: $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/)); If I just have that conditional the same in both Search.pm and Matcher.pm. then maybe a "skip_normalization" flag in SimpleSearch() would work. I might try that in a minute. but opening it up because I could really use a hand with this. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Jan 19 05:40:03 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 19 Jan 2016 15:40:03 +1100 Subject: [Koha-devel] Searching URLs in Zebra Message-ID: <005701d15273$76821bd0$63865370$@prosentient.com.au> Sorry to spam you all. The following works: $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ( grep { $_->{'index'} =~ m/\w,\w/ } @{ $self->{'matchpoints'} })); We might want to actually double-check other places in Koha where we're checking for 'UseQueryParser', as it might not always be possible to use the QueryParser due to limitations such as the "qualifier,qualifier" CCL syntax. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: David Cook [mailto:dcook at prosentient.com.au] Sent: Tuesday, 19 January 2016 3:31 PM To: 'Koha Devel' Subject: RE: Searching URLs in Zebra Ah, just realized again that qq($QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/));) won't work in C4::Matcher because there's no $query. The only equivalent of that would be to check all the $matchpoint->{'index'} fields in the $self->{'matchpoints'} arrayref. Which we might have to do because the QueryParser doesn't seem to be able to handle the "index,phr" (ie "qualifier,qualifier") format. That's verified by the fact that C4::Search::SimpleSearch is doing that regex. Sure, we could just not use a list of qualifiers for a Record Matching Rule index, but then we have no control over what index register we're using and that's also a problem. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: David Cook [mailto:dcook at prosentient.com.au] Sent: Tuesday, 19 January 2016 3:11 PM To: 'Koha Devel' > Subject: Searching URLs in Zebra Hey brains trust, I'm reaching out to everyone as I'm a bit stuck with http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 at the moment. There's currently no way to search an index with the "url" (ie "u") register. A URL is stored "as is" in that index, but all our Koha search methods use s/:/=/g or s/=/:/g and that plays havoc with the URLs used in a search query, which makes the match fail against the indexed URL. C4::Matcher::get_matches() strips spaces and punctuation, so I've added a "none" or "raw" normalizer that performs no normalization, but C4::Search::SimpleSearch() does that global replacement for ":" and "=" (depending on your QueryParser settings and what qualifiers you've specified in your Record Matching Rules). I thought about adding a "skip normalization" flag to C4::Search::SimpleSearch, but that doesn't work because C4::Matcher uses : for QueryParser and = for non-QueryParser. except C4::Search::SimpleSearch() deactivates QueryParser mode if you have a "index,phr" set of qualifiers. which means that you get a ":" when you need a "=" for the non-QueryParser CCL query. I suppose the solution might be the following: Current Matcher.pm: $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser')); Current Search.pm $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/)); Future Matcher.pm: $QParser = C4::Context->queryparser if (C4::Context->preference('UseQueryParser') && ! ($query =~ m/\w,\w|\w=\w/)); If I just have that conditional the same in both Search.pm and Matcher.pm. then maybe a "skip_normalization" flag in SimpleSearch() would work. I might try that in a minute. but opening it up because I could really use a hand with this. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Jan 19 07:10:06 2016 From: dcook at prosentient.com.au (David Cook) Date: Tue, 19 Jan 2016 17:10:06 +1100 Subject: [Koha-devel] Help testing a bug (willing to swap sign offs) Message-ID: <006201d15280$0ae7a5e0$20b6f1a0$@prosentient.com.au> Hey all, I would appreciate it if someone could test bug 15541 for me (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541), or even just provide feedback. I would be willing to swap testing/sign offs as well. I'm hoping to get this one into the 3.24 release along with 15555, which is already signed off. Happy to walk people through any of the Zebra stuff as well if that makes anyone uncomfortable. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Tue Jan 19 08:13:38 2016 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Tue, 19 Jan 2016 08:13:38 +0100 (CET) Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: Message-ID: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> Hi to all, >> install zebra 2.0.61 with new yaz lib (5.15.2) >> This version of yaz doesn't work with package libnet-z3950-zoom-perl, >> the essential package for search and cataloguing. >which version of libnet-z3950-zoom-perl are you using? What do you >mean with does'nt work with yaz? working with debian jessie, I installed libnet-z3950-zoom-perl 1.30.1 https://packages.debian.org/jessie/libnet-z3950-zoom-perl In debian jessie yaz lib version is 4.2.30-4 https://packages.debian.org/jessie/yaz If I add the file /etc/apt/sources.list.d/indexdata.list with deb http://ftp.indexdata.dk/debian jessie main when I install koha-common the version installed is 5.15.2 (the last in IndexData repo) And I do: sudo apt-get update sudo apt-get upgrade sudo apt-get install koha-common the installation of koha package goes wrong on installation of libnet-z3950-zoom-perl. I can't install package libnet-z3950-zoom-perl 1.30.1 from debian jessie using package yaz 5.15.2 from Indexdata. The two packeges are compatible between them. Bye Zeno Tajoli From dcook at prosentient.com.au Tue Jan 19 23:26:27 2016 From: dcook at prosentient.com.au (David Cook) Date: Wed, 20 Jan 2016 09:26:27 +1100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> Message-ID: <009401d15308$7031ca10$50955e30$@prosentient.com.au> What do you mean by "goes wrong"? Can you paste the results into an email? On openSUSE, I'm using Zebra 2.0.60, YAZ 5.1.2, and Net::Z3950::ZOOM 1.30, and everything works fine. The latest change from Zebra 2.0.60 to 2.0.61... that looks like it moves some libraries and modules around... that might be a factor: http://www.indexdata.com/zebra/doc/NEWS YAZ has seen a lot of changes http://www.indexdata.com/yaz/doc/NEWS, so I suppose there might have been some change between 5.1.2 and 5.15.2 that makes it incompatible with Net::Z3950::ZOOM's XS code. I don't know. You might try contacting Indexdata about it, especially if you can give more information about what is exactly happening on your system. You might try pinning your yaz package to 4.2.30-4, but I don't know if that would work with Zebra. According to http://www.indexdata.com/yaz/doc/NEWS, As of 2.0.56, Zebra still compiles fine with YAZ 4... so you might try uninstalling Zebra and YAZ, pinning YAZ, and reinstalling YAZ and Zebra. But I think that would be a short-term solution... and it would be better to fix whatever the underlying problem is. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Zeno Tajoli > Sent: Tuesday, 19 January 2016 6:14 PM > To: Wolfram Schneider > Cc: Koha Devel > Subject: Re: [Koha-devel] Which version of Zebra in Debian Jessie? > > Hi to all, > > >> install zebra 2.0.61 with new yaz lib (5.15.2) This version of yaz > >> doesn't work with package libnet-z3950-zoom-perl, the essential > >> package for search and cataloguing. > > >which version of libnet-z3950-zoom-perl are you using? What do you mean > >with does'nt work with yaz? > > > working with debian jessie, I installed libnet-z3950-zoom-perl 1.30.1 > https://packages.debian.org/jessie/libnet-z3950-zoom-perl > > In debian jessie yaz lib version is 4.2.30-4 > https://packages.debian.org/jessie/yaz > > If I add the file /etc/apt/sources.list.d/indexdata.list with deb > http://ftp.indexdata.dk/debian jessie main > > when I install koha-common the version installed is 5.15.2 (the last in > IndexData repo) > > And I do: > sudo apt-get update > sudo apt-get upgrade > sudo apt-get install koha-common > > the installation of koha package goes wrong on installation of libnet-z3950- > zoom-perl. > I can't install package libnet-z3950-zoom-perl 1.30.1 from debian jessie using > package yaz 5.15.2 from Indexdata. > > The two packeges are compatible between them. > > Bye > Zeno Tajoli > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/ bugs : http://bugs.koha-community.org/ From dcook at prosentient.com.au Tue Jan 19 23:52:59 2016 From: dcook at prosentient.com.au (David Cook) Date: Wed, 20 Jan 2016 09:52:59 +1100 Subject: [Koha-devel] Help testing a bug (willing to swap sign offs) In-Reply-To: <569E3601.8030804@inlibro.com> References: <006201d15280$0ae7a5e0$20b6f1a0$@prosentient.com.au> <569E3601.8030804@inlibro.com> Message-ID: <009501d1530c$251a5250$6f4ef6f0$@prosentient.com.au> Awesome! Cheers, Philippe. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Philippe Blouin [mailto:philippe.blouin at inlibro.com] Sent: Wednesday, 20 January 2016 12:11 AM To: David Cook Subject: Re: [Koha-devel] Help testing a bug (willing to swap sign offs) I have just the guy for you. I'll ask bouzid to have a look today. I want him to become an expert in indexes... Philippe Blouin, Responsable du d?veloppement informatique T?l. : (888) 604-2627 philippe.blouin at inLibro.com inLibro | pour esprit libre | www.inLibro.com On 01/19/2016 01:10 AM, David Cook wrote: Hey all, I would appreciate it if someone could test bug 15541 for me (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541), or even just provide feedback. I would be willing to swap testing/sign offs as well. I?m hoping to get this one into the 3.24 release along with 15555, which is already signed off. Happy to walk people through any of the Zebra stuff as well if that makes anyone uncomfortable. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Jan 20 04:07:34 2016 From: dcook at prosentient.com.au (David Cook) Date: Wed, 20 Jan 2016 14:07:34 +1100 Subject: [Koha-devel] Is anyone using the QueryParser? Message-ID: <00ae01d1532f$b56a35a0$203ea0e0$@prosentient.com.au> Hey all, Is anyone actually using the QueryParser in a production system? I've been looking at the import matching recently, and I'm noticing more and more discrepancies between the queryparser.yml and ccl.properties. This time it was "Control-number". It didn't work in QueryParser, because queryparser.yml has it written as "control-number" and it appears to be case sensitive. The CCL2RPN is case insensitive so it doesn't matter too much so long as one remembers to use the form recognized by the QueryParser. But that's not the only limitation of the QueryParser. It also can't handle "index,phr" type queries, and it doesn't always fail gracefully. I've added some extra checking in Bug 15541 so that it falls back to CCL2RPN when it says "index,phr", but I'm just wondering if we need to disable the QueryParser completely. I like the idea of it. I like it a lot. In fact, I'd love to see it completed. But as it is currently implemented, it causes no end of headaches and inconsistent behaviour. So I'm curious if anyone is using it in production. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wosch at freebsd.org Wed Jan 20 11:26:06 2016 From: wosch at freebsd.org (Wolfram Schneider) Date: Wed, 20 Jan 2016 11:26:06 +0100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> Message-ID: On 19 January 2016 at 08:13, Zeno Tajoli wrote: > Hi to all, > >>> install zebra 2.0.61 with new yaz lib (5.15.2) >>> This version of yaz doesn't work with package libnet-z3950-zoom-perl, >>> the essential package for search and cataloguing. > >>which version of libnet-z3950-zoom-perl are you using? What do you >>mean with does'nt work with yaz? > > > working with debian jessie, I installed libnet-z3950-zoom-perl 1.30.1 > https://packages.debian.org/jessie/libnet-z3950-zoom-perl > > In debian jessie yaz lib version is 4.2.30-4 > https://packages.debian.org/jessie/yaz > > If I add the file /etc/apt/sources.list.d/indexdata.list with > deb http://ftp.indexdata.dk/debian jessie main > > when I install koha-common the version installed is 5.15.2 (the last in IndexData repo) > > And I do: > sudo apt-get update > sudo apt-get upgrade > sudo apt-get install koha-common > > the installation of koha package goes wrong on installation of libnet-z3950-zoom-perl. > I can't install package libnet-z3950-zoom-perl 1.30.1 from debian jessie using package yaz 5.15.2 from Indexdata. > > The two packeges are compatible between them. how about installing libnet-z3950-zoom-perl from the Indexdata repository? http://ftp.indexdata.com/pub/debian/pool/dists/jessie/main/amd64/libnet-z3950-zoom-perl_1.30-1.indexdata_amd64.deb -Wolfram > Bye > Zeno Tajoli -- Wolfram Schneider http://wolfram.schneider.org From z.tajoli at cineca.it Wed Jan 20 12:00:03 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Wed, 20 Jan 2016 12:00:03 +0100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> Message-ID: <569F68B3.40501@cineca.it> Hi all Il 20/01/2016 11:26, Wolfram Schneider ha scritto: > how about installing libnet-z3950-zoom-perl from the Indexdata repository? > http://ftp.indexdata.com/pub/debian/pool/dists/jessie/main/amd64/libnet-z3950-zoom-perl_1.30-1.indexdata_amd64.deb the problem is that in a normal installation yaz and zebra are installed BEFORE libnet-z3950-zoom-perl. I don't know if apt-get try to use libnet-z3950-zoom-perl from Indexdata repo or from general Jessie repo. The version of Indexdata is the same on general Jessie repo. See also my other answer to David Cook. Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From z.tajoli at cineca.it Wed Jan 20 12:16:13 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Wed, 20 Jan 2016 12:16:13 +0100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <009401d15308$7031ca10$50955e30$@prosentient.com.au> References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> <009401d15308$7031ca10$50955e30$@prosentient.com.au> Message-ID: <569F6C7D.4050803@cineca.it> Hi David and all Il 19/01/2016 23:26, David Cook ha scritto: > What do you mean by "goes wrong"? Can you paste the results into an email? > > On openSUSE, I'm using Zebra 2.0.60, YAZ 5.1.2, and Net::Z3950::ZOOM 1.30, > and everything works fine. I think is a problem on integration Jessie general repo and Indexdata repo. Recreate the problem is quite long, you need to start from a basic Jessie with only ssh server. The steps are: 1)A new debian jessie with only ssh server 2)Login as 'root' 3)vi /etc/apt/sources.list.d/koha.list deb http://debian.koha-community.org/koha oldstable main 4)vi /etc/apt/sources.list.d/indexdata.list deb http://ftp.indexdata.dk/debian jessie main deb-src http://ftp.indexdata.dk/debian jessie main 5)wget -O- http://debian.koha-community.org/koha/gpg.asc | apt-key add - 6)wget -O- http://ftp.indexdata.dk/debian/indexdata.asc | apt-key add - 7)apt-get update 8)apt-get upgrade 9)apt-get install koha-deps Now you have installed yaz (5.15.2-1.indexdata) and idzebra-2.0 (2.0.61-1.indexdata) 10)install koha-perldeps Now the error: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: koha-perldeps : Depends: libnet-z3950-zoom-perl but it is not going to be installed E: Unable to correct problems, you have held broken packages. If I use koha-common instead of koha-deps and koha-perldeps I receive the same error. I write also to indexdato to ask them to create a new version of libnet-z3950-zoom-perl for Jessie. Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From z.tajoli at cineca.it Wed Jan 20 14:19:11 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Wed, 20 Jan 2016 14:19:11 +0100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <569F6C7D.4050803@cineca.it> References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> <009401d15308$7031ca10$50955e30$@prosentient.com.au> <569F6C7D.4050803@cineca.it> Message-ID: <569F894F.90903@cineca.it> Hi David and all a more specific debug: 1)after install yaz and zebra from Indexdata repo apt-get install libnet-z3950-zoom-perl [...] The following information may help to resolve the situation: The following packages have unmet dependencies: libnet-z3950-zoom-perl : Depends: perlapi-5.18.2 but it is not installable E: Unable to correct problems, you have held broken packages. apt show libnet-z3950-zoom-perl ... Version: 1.30-1.indexdata Depends: perl (>= 5.18.2-2+b1), perlapi-5.18.2, libc6 (>= 2.2.5), libxml2 (>= 2.6.27), libxslt1.1 (>= 1.1.25), libyaz5 (>= 5.0.11), libmarc-record-perl 2)after install yaz and zebra from ONLY Debian Jessie apt show libnet-z3950-zoom-perl ... Version: 1.30-1+b1 Depends: perl (>= 5.20.0-4), perlapi-5.20.0, libc6 (>= 2.4), libxml2 (>= 2.6.27), libxslt1.1 (>= 1.1.25), libyaz4 (>= 4.2.18), libmarc-record-perl Now in Debian Jessie perl is 5.20 So the solutions cuold be: 1)Build a package with perlapi-5.20.0 AND libyaz5 2)Wait unitl IndexData update its version of libnet-z3950-zoom-perl Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From paul.poulain at biblibre.com Wed Jan 20 15:18:49 2016 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 20 Jan 2016 15:18:49 +0100 Subject: [Koha-devel] RFC for a really new stuff : sharing data worldwide Message-ID: <569F9749.7040006@biblibre.com> Ladies & gentlemen, We're competing more and more against providers that promote a "cloud multi-tenant LMS". Koha is a cloud application (and it is since 2000, long before cloud is born). What does "multi-tenant" mean ? It mean that you'll get access to many resources that are shared worldwide. I think that the "multi-tenancy" is a way for proprietary vendors to lock-in their customers [1]. But the idea of having a worldwide database for some informations is interesting and relevant. Proprietary vendors take care of updating this database. Open Source projects are not working centrally, so we must find another way of creating and maintaining such a database. With this thing in mind, BibLibre has decided to sponsor an intern + some internal resources for next summer dedicated to a project dedicated to sharing data between koha instances worldwide. I wrote a 1st draft of RFC and I'd like to have your feedback: http://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc If this project is successful, in the automn version of Koha, we may see a way to share worlwide data between all Koha libraries ! [1] if you're a proprietary vendor and are reading this: I don't mean it's the only reason for multi-tenancy. -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries From z.tajoli at cineca.it Wed Jan 20 16:38:41 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Wed, 20 Jan 2016 16:38:41 +0100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <569F894F.90903@cineca.it> References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> <009401d15308$7031ca10$50955e30$@prosentient.com.au> <569F6C7D.4050803@cineca.it> <569F894F.90903@cineca.it> Message-ID: <569FAA01.4010605@cineca.it> Hi David and all > 2)Wait unitl IndexData update its version of libnet-z3950-zoom-perl news from IndexData: Adam Dickmeiss has update libnet-z3950-zoom-perl with http://ftp.indexdata.com/pub/debian/pool/dists/jessie/main/amd64/libnet-z3950-zoom-perl_1.30-2.indexdata_amd64.deb so now, if you install libnet-z3950-zoom-perl with IndexData repository you retrive: sudo apt show libnet-z3950-zoom-perl ... Version: 1.30-2.indexdata Depends: perl (>= 5.20.2-3+deb8u1), perlapi-5.20.2, libc6 (>= 2.2.5), libxml2 (>= 2.6.27), libxslt1.1 (>= 1.1.25), libyaz5 (>= 5.13.0), libmarc-record-perl So now my answer to the question "Which version of Zebra in Debian Jessie?" is: "The version that you retrive from IndexData repository." For me now, if you use Debian Jessie, it is a good idea to add also IndexData repository in /etc/apt/sources.list.d/ Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From paul.a at navalmarinearchive.com Thu Jan 21 00:47:47 2016 From: paul.a at navalmarinearchive.com (Paul A) Date: Wed, 20 Jan 2016 18:47:47 -0500 Subject: [Koha-devel] Apache error logs Message-ID: <5.2.1.1.2.20160120183409.020dd6a0@stormy.ca> For the last couple of days, our production server has "gone bonkers" with tens of thousands of the following: [Wed Jan 20 18:41:58 2016] opac-search.pl: Use of uninitialized value $code_wanted in string eq at /usr/share/perl5/MARC/Field.pm line 314. Appears to involve control fields MARC < 10 I have noted that two new (to us) spiders are quite busy, and date-times appear to correspond -- webmeup-crawler.com and ahrefs.com -- but I don't want to libel them before digging deeper (probably end up firewalling them.) It *might* have something to do with ISBD view. Has anyone got any thoughts? Thanks and best regards -- Paul From dcook at prosentient.com.au Thu Jan 21 01:57:38 2016 From: dcook at prosentient.com.au (David Cook) Date: Thu, 21 Jan 2016 11:57:38 +1100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <569FAA01.4010605@cineca.it> References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> <009401d15308$7031ca10$50955e30$@prosentient.com.au> <569F6C7D.4050803@cineca.it> <569F894F.90903@cineca.it> <569FAA01.4010605@cineca.it> Message-ID: <010301d153e6$b91d8c80$2b58a580$@prosentient.com.au> Hi Zeno: Thanks for all the emails. That really helped clarify things : ). That's great that Adam got back to you so fast as well. Yeah, I think it's OK to use Debian's Zebra packages if you use CHR indexing, if you use ICU indexing, I think you have to use Indexdata's Zebra (and related) packages, or it won't work well. Robin opened a bug report on Debian to get updated Zebra packages, but it appears to have been ignored by the Debian maintainer for idzebra-2.0 :/. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Tajoli Zeno > Sent: Thursday, 21 January 2016 2:39 AM > To: 'Koha Devel' > Subject: Re: [Koha-devel] Which version of Zebra in Debian Jessie? > > Hi David and all > > > 2)Wait unitl IndexData update its version of libnet-z3950-zoom-perl > > news from IndexData: Adam Dickmeiss has update libnet-z3950-zoom-perl > with > http://ftp.indexdata.com/pub/debian/pool/dists/jessie/main/amd64/libnet- > z3950-zoom-perl_1.30-2.indexdata_amd64.deb > > so now, if you install libnet-z3950-zoom-perl with IndexData repository you > retrive: > > sudo apt show libnet-z3950-zoom-perl > ... > Version: 1.30-2.indexdata > Depends: perl (>= 5.20.2-3+deb8u1), perlapi-5.20.2, libc6 (>= 2.2.5), > libxml2 (>= 2.6.27), libxslt1.1 (>= 1.1.25), libyaz5 (>= 5.13.0), libmarc-record- > perl > > So now my answer to the question "Which version of Zebra in Debian > Jessie?" is: > > "The version that you retrive from IndexData repository." > > For me now, if you use Debian Jessie, it is a good idea to add also IndexData > repository in /etc/apt/sources.list.d/ > > Bye > Zeno Tajoli > > -- > Zeno Tajoli > /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche > Email: z.tajoli at cineca.it Fax: 051/6132198 > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/ bugs : http://bugs.koha-community.org/ From z.tajoli at cineca.it Thu Jan 21 10:17:53 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Thu, 21 Jan 2016 10:17:53 +0100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <010301d153e6$b91d8c80$2b58a580$@prosentient.com.au> References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> <009401d15308$7031ca10$50955e30$@prosentient.com.au> <569F6C7D.4050803@cineca.it> <569F894F.90903@cineca.it> <569FAA01.4010605@cineca.it> <010301d153e6$b91d8c80$2b58a580$@prosentient.com.au> Message-ID: <56A0A241.80909@cineca.it> Hi David and all, Il 21/01/2016 01:57, David Cook ha scritto: > Yeah, I think it's OK to use Debian's Zebra packages if you use CHR > indexing, if you use ICU indexing, I think you have to use Indexdata's Zebra > (and related) packages, or it won't work well. in fact for myself ICU indexing is mandatory, so I need to use Indexdata's Zebra. Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From jonathan.druart at bugs.koha-community.org Thu Jan 21 12:30:37 2016 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Thu, 21 Jan 2016 11:30:37 +0000 Subject: [Koha-devel] Update guarantees on updating guarantor Message-ID: Hello, Looking at the code, there is some broken with the guarantees code. It seems that the expected behavior would be to update address, fax, B_city, mobile, city and phone info of the guarantees when a guarantor is modified. But the code in C4::Members::ModMember is broken: 668 my $borrowercategory= GetBorrowercategory( $data{'category_type'} ); 669 if ( exists $borrowercategory->{'category_type'} && $borrowercategory->{'category_type'} eq ('A' || 'S') ) { 670 # is adult check guarantees; 671 UpdateGuarantees(%data); 672 } First, GetBorrowerCategory expects a categorycode, not a category_type. Then UpdateGuarantees retrieves the param like: 989 sub UpdateGuarantees { 990 my %data = shift; Which means that %data will always be something like ( a_key => undef ) And nothing more. The updateguarantees subroutine (It has been renamed) has been introduced by commit 56825e415fc232e38f0a874dc9a81fa2169ef06b Date: Mon Aug 30 13:48:58 2004 +0000 modularizing (with Members.pm) members management (beginning of...) And the `%data = shift` already existed... So I think that this behavior has never worked and we could remove the related code. Any protests? Cheers, Jonathan From veron at veron.ch Thu Jan 21 13:15:31 2016 From: veron at veron.ch (=?UTF-8?Q?Marc_V=c3=a9ron?=) Date: Thu, 21 Jan 2016 13:15:31 +0100 Subject: [Koha-devel] Update guarantees on updating guarantor In-Reply-To: References: Message-ID: <56A0CBE3.2090605@veron.ch> +1 Marc Am 21.01.2016 um 12:30 schrieb Jonathan Druart: > So I think that this behavior has never worked and we could remove the > related code. From paul.poulain at biblibre.com Thu Jan 21 16:00:39 2016 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 21 Jan 2016 16:00:39 +0100 Subject: [Koha-devel] xisbn about to disappear Message-ID: <56A0F297.2010901@biblibre.com> Hi Koha-devel, Have you seen this : http://go-to-hellman.blogspot.fr/2015/12/xisbn-rip.html ? According to http://hea.koha-community.org/systempreferences, almost half of the libraries that are linked to hea are using xisbn, shame for them !!! And we will have to clean some code ! Any idea for a replacement ? -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries From oleonard at myacpl.org Thu Jan 21 16:09:05 2016 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 21 Jan 2016 10:09:05 -0500 Subject: [Koha-devel] xisbn about to disappear In-Reply-To: <56A0F297.2010901@biblibre.com> References: <56A0F297.2010901@biblibre.com> Message-ID: > Have you seen this : http://go-to-hellman.blogspot.fr/2015/12/xisbn-rip.html Galen was on the case right away with a bug report: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15369 > According to http://hea.koha-community.org/systempreferences, almost half of > the libraries that are linked to hea are using xisbn, shame for them !!! Yeah, it's another example of the problem with relying on "free" services from entities which don't really have your best interests in mind (RIP Google Reader). > Any idea for a replacement ? Sounds like we need some kind of worldwide data-sharing system for Koha libraries ;) -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From oleonard at myacpl.org Thu Jan 21 16:15:49 2016 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 21 Jan 2016 10:15:49 -0500 Subject: [Koha-devel] xisbn about to disappear In-Reply-To: <56A0F297.2010901@biblibre.com> References: <56A0F297.2010901@biblibre.com> Message-ID: > Have you seen this : http://go-to-hellman.blogspot.fr/2015/12/xisbn-rip.html Also, this quote: "In 2015, most of us can all afford our own data crunching big-data-stores-in-the-cloud..." That appears to be said in seriousness? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From dcook at prosentient.com.au Fri Jan 22 04:55:42 2016 From: dcook at prosentient.com.au (David Cook) Date: Fri, 22 Jan 2016 14:55:42 +1100 Subject: [Koha-devel] Which version of Zebra in Debian Jessie? In-Reply-To: <56A0A241.80909@cineca.it> References: <1038750102.5675172.1453187618101.JavaMail.root@cineca.it> <009401d15308$7031ca10$50955e30$@prosentient.com.au> <569F6C7D.4050803@cineca.it> <569F894F.90903@cineca.it> <569FAA01.4010605@cineca.it> <010301d153e6$b91d8c80$2b58a580$@prosentient.com.au> <56A0A241.80909@cineca.it> Message-ID: <018401d154c8$c3f6d160$4be47420$@prosentient.com.au> Makes sense to me. We have some libraries where it would be mandatory as well, so I'll probably be in the same boat when we upgrade Debian for those libraries... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Tajoli Zeno > Sent: Thursday, 21 January 2016 8:18 PM > To: 'Koha Devel' > Subject: Re: [Koha-devel] Which version of Zebra in Debian Jessie? > > Hi David and all, > > Il 21/01/2016 01:57, David Cook ha scritto: > > > Yeah, I think it's OK to use Debian's Zebra packages if you use CHR > > indexing, if you use ICU indexing, I think you have to use Indexdata's > > Zebra (and related) packages, or it won't work well. > > in fact for myself ICU indexing is mandatory, so I need to use Indexdata's > Zebra. > > Bye > Zeno Tajoli > > -- > Zeno Tajoli > /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche > Email: z.tajoli at cineca.it Fax: 051/6132198 > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/ bugs : http://bugs.koha-community.org/ From dcook at prosentient.com.au Fri Jan 22 05:08:39 2016 From: dcook at prosentient.com.au (David Cook) Date: Fri, 22 Jan 2016 15:08:39 +1100 Subject: [Koha-devel] RFC for a really new stuff : sharing data worldwide In-Reply-To: <569F9749.7040006@biblibre.com> References: <569F9749.7040006@biblibre.com> Message-ID: <018501d154ca$92fbd680$b8f38380$@prosentient.com.au> "Multi-tenant" is certainly a vague term. Koha via Debian packages is already multi-tenant at the code level. Personally I don't know why someone would promote "multi-tenant" as something desirable in a lot of contexts, but I see that you're referring to it in the sense of sharing data. That's cool. One of my first tasks at Prosentient, back when I was an intern, was to create a SQL report database that was shared amongst all our Koha customers. It was early in my programmer days, so it's rather awful, but I think it may have been useful for a time. Each different Koha database user had read access to a central database schema of reports, and they could clone those reports into their local Koha database. I think Chris Cormack, Liz Rea, and I were actually talking about the SQL Report Library on the wiki and how it's quite unwieldy... and Liz was saying how it would be great if you could upvote and downvote reports. I think that's something that you mention in your RFC (e.g. "good data" vs "bad data"). I think that's a great idea. Vendors, serial (publishing) patterns... yeah I could see that being useful too. "Subscriptions" per se maybe not so much as those are specific to vendor-client contracts. But yeah I think overall it's a good idea. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Paul Poulain > Sent: Thursday, 21 January 2016 1:19 AM > To: koha-devel at lists.koha-community.org > Subject: [Koha-devel] RFC for a really new stuff : sharing data worldwide > > Ladies & gentlemen, > > We're competing more and more against providers that promote a "cloud > multi-tenant LMS". > Koha is a cloud application (and it is since 2000, long before cloud is born). > What does "multi-tenant" mean ? It mean that you'll get access to many > resources that are shared worldwide. > > I think that the "multi-tenancy" is a way for proprietary vendors to lock-in > their customers [1]. But the idea of having a worldwide database for some > informations is interesting and relevant. Proprietary vendors take care of > updating this database. Open Source projects are not working centrally, so > we must find another way of creating and maintaining such a database. > > With this thing in mind, BibLibre has decided to sponsor an intern + some > internal resources for next summer dedicated to a project dedicated to > sharing data between koha instances worldwide. > > I wrote a 1st draft of RFC and I'd like to have your feedback: > http://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc > > If this project is successful, in the automn version of Koha, we may see a way > to share worlwide data between all Koha libraries ! > > [1] if you're a proprietary vendor and are reading this: I don't mean it's the > only reason for multi-tenancy. > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open > Source software and services for libraries > > _______________________________________________ > 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 Fri Jan 22 09:54:43 2016 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 22 Jan 2016 09:54:43 +0100 Subject: [Koha-devel] Jenkins (we want to move the server) Message-ID: <56A1EE53.1060803@biblibre.com> Hi koha-devel (and especially chris I think) The jenkins server is now pretty old, we (BibLibre) have new (fancy) platforms where we would like to move it. First question: do we agree that jenkins.koha-community.org is now only collecting data from other servers as "master", and no integration is made on BibLibre server anymore ? If I'm wrong we need some explanations ! Migration plan: what do we need to move ? the .war only ? a mysql db we have [koha, koha_univ_lyon3, koha_biblibre_master] ? Another question: it seems I don't have an account anymore on jenkins http. thx to answer by including laurent, our sysop (he's not on koha-devel) -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries From frederic at tamil.fr Fri Jan 22 10:41:12 2016 From: frederic at tamil.fr (=?UTF-8?B?RnLDqWTDqXJpYyBEZW1pYW5z?=) Date: Fri, 22 Jan 2016 10:41:12 +0100 Subject: [Koha-devel] RFC for a really new stuff : sharing data worldwide In-Reply-To: <569F9749.7040006@biblibre.com> References: <569F9749.7040006@biblibre.com> Message-ID: About sharing data, it may be an Koha-independent project, but a linked-one also, there is the issue of the books cover images. There are now coming from various providers (Google, Amazon, etc.). It would be great to have an images storage server which could replace the one integrated in Koha (local cover images). This would allow libraries to share scanning work. OpenLibrary was supposed to be that exactly. From tomascohen at gmail.com Fri Jan 22 12:09:33 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 22 Jan 2016 08:09:33 -0300 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: <56A1EE53.1060803@biblibre.com> References: <56A1EE53.1060803@biblibre.com> Message-ID: Paul, you are right: we are not using the jenkins server as an execution node, so we just need the webapp running with its db/files. It would be handy this it kept the current ip (firewall on the nodes) but we could survive. And please keep the pubkeys :-) Thanks El 22/1/2016 5:54, "Paul Poulain" escribi?: > Hi koha-devel (and especially chris I think) > > The jenkins server is now pretty old, we (BibLibre) have new (fancy) > platforms where we would like to move it. > > First question: do we agree that jenkins.koha-community.org is now only > collecting data from other servers as "master", and no integration is made > on BibLibre server anymore ? If I'm wrong we need some explanations ! > > Migration plan: what do we need to move ? the .war only ? a mysql db we > have [koha, koha_univ_lyon3, koha_biblibre_master] ? > > Another question: it seems I don't have an account anymore on jenkins http. > > thx to answer by including laurent, our sysop (he's not on koha-devel) > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > _______________________________________________ > 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 bargioni at pusc.it Fri Jan 22 12:38:59 2016 From: bargioni at pusc.it (Stefano Bargioni) Date: Fri, 22 Jan 2016 12:38:59 +0100 Subject: [Koha-devel] xisbn about to disappear In-Reply-To: <56A0F297.2010901@biblibre.com> References: <56A0F297.2010901@biblibre.com> Message-ID: <6172797C-A3D7-4DD1-AB84-C3E85CCB4EB6@pusc.it> The OCLC announcement is at https://www.oclc.org/developer/news/2015/change-to-xid-services.en.html Maybe many of use can write to Karen Coombs coombsk at oclc.org asking not to shutdown xID. I wrote two services based on xISBN, one for my Koha and the other for Ebsco Discovery Service... :-( sb > On 21 gen 2016, at 16:00, Paul Poulain wrote: > > Hi Koha-devel, > > Have you seen this : http://go-to-hellman.blogspot.fr/2015/12/xisbn-rip.html ? > > According to http://hea.koha-community.org/systempreferences, almost half of the libraries that are linked to hea are using xisbn, shame for them !!! > > And we will have to clean some code ! > Any idea for a replacement ? > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > _______________________________________________ > 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 Jan 25 09:55:05 2016 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 25 Jan 2016 09:55:05 +0100 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: References: <56A1EE53.1060803@biblibre.com> Message-ID: <56A5E2E9.9000609@biblibre.com> Le 22/01/2016 12:09, Tomas Cohen Arazi a ?crit : > > Paul, you are right: we are not using the jenkins server as an > execution node, so we just need the webapp running with its db/files. > It would be handy this it kept the current ip (firewall on the nodes) > but we could survive. > Sorry Tomas, but the IP will change (new provider) > > And please keep the pubkeys :-) > > Thanks > > El 22/1/2016 5:54, "Paul Poulain" > escribi?: > > Hi koha-devel (and especially chris I think) > > The jenkins server is now pretty old, we (BibLibre) have new > (fancy) platforms where we would like to move it. > > First question: do we agree that jenkins.koha-community.org > is now only collecting data > from other servers as "master", and no integration is made on > BibLibre server anymore ? If I'm wrong we need some explanations ! > > Migration plan: what do we need to move ? the .war only ? a mysql > db we have [koha, koha_univ_lyon3, koha_biblibre_master] ? > > Another question: it seems I don't have an account anymore on > jenkins http. > > thx to answer by including laurent, our sysop (he's not on koha-devel) > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > _______________________________________________ > 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/ > -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From laurent.ducos at biblibre.com Mon Jan 25 10:14:41 2016 From: laurent.ducos at biblibre.com (Laurent Ducos) Date: Mon, 25 Jan 2016 09:14:41 +0000 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: <56A5E2E9.9000609@biblibre.com> References: <56A5E2E9.9000609@biblibre.com> <56A1EE53.1060803@biblibre.com> Message-ID: <1da148737b99aab93bd5ce4b03db2b2f@webmail.biblibre.com> The new ip adress will be 212.47.240.49 if I understood , just copy the webroot /var/cache/jenkins/war,? /usr/share/jenkins/, /var/lib/jenkins and /home/jenkins/jobs/ for the jobs and plugins on the new server ? Laurent Ducos Administrateur Syst?mes et R?seaux +33974770716 25 janvier 2016 09:55 "Paul Poulain" a ?crit: Le 22/01/2016 12:09, Tomas Cohen Arazi a ?crit?:? Paul, you are right: we are not using the jenkins server as an execution node, so we just need the webapp running with its db/files. It would be handy this it kept the current ip (firewall on the nodes) but we could survive.Sorry Tomas, but the IP will change (new provider) ? And please keep the pubkeys :-) Thanks El 22/1/2016 5:54, "Paul Poulain" escribi?:Hi koha-devel (and especially chris I think) The jenkins server is now pretty old, we (BibLibre) have new (fancy) platforms where we would like to move it. First question: do we agree that jenkins.koha-community.org (http://jenkins.koha-community.org) is now only collecting data from other servers as "master", and no integration is made on BibLibre server anymore ? If I'm wrong we need some explanations ! Migration plan: what do we need to move ? the .war only ? a mysql db we have [koha, koha_univ_lyon3, koha_biblibre_master] ? Another question: it seems I don't have an account anymore on jenkins http. thx to answer by including laurent, our sysop (he's not on koha-devel) -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org (mailto:Koha-devel at lists.koha-community.org) http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel (http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel) website : http://www.koha-community.org/ (http://www.koha-community.org/) git : http://git.koha-community.org/ (http://git.koha-community.org/) bugs : http://bugs.koha-community.org/ (http://bugs.koha-community.org/)? -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikourmou at lib.auth.gr Mon Jan 25 12:04:12 2016 From: ikourmou at lib.auth.gr (=?UTF-8?B?zpPOuc6szr3Ovc63z4IgzprOv8+Fz4HOvM6/z43Ou863z4I=?=) Date: Mon, 25 Jan 2016 13:04:12 +0200 Subject: [Koha-devel] KohaCon16 - Registrations & Call for proposals Open Message-ID: ??Dear koha lists members We are pleased to announce that Registration and Call for Proposals are now open for Kohacon16! Registration is free. Developers, technical support staff, librarians are invited to share their experience by contributing with a presentation proposal based on their knowledge, ideas, best practices and even mistakes! (Please note that all presentations will be in English). KohaCon16 will be organized by the Library & Information Centre and will be held at the Aristostle University of Thessaloniki on 30 May ? 4 June 2016. For detailed information and updates, please visit the *KohaCon16 site* . ?Let's make it Ko-ha-ppen!?? KohaCon16 Library & Information Center Aristotle University of Thessaloniki GR-54124 Thessaloniki Greece ? ?tel: +30 2310 99 5368 <+302310995368> ? email: kohacon16 at lib.auth.gr ?url: ?kohacon2016.lib.auth.gr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecjjegcg.png Type: image/png Size: 1164 bytes Desc: not available URL: From jonathan.druart at bugs.koha-community.org Mon Jan 25 13:49:29 2016 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Mon, 25 Jan 2016 12:49:29 +0000 Subject: [Koha-devel] Update guarantees on updating guarantor In-Reply-To: References: Message-ID: I have opened a bug report, see bug 15653. 2016-01-21 11:30 GMT+00:00 Jonathan Druart : > Hello, > > Looking at the code, there is some broken with the guarantees code. > It seems that the expected behavior would be to update address, fax, > B_city, mobile, city and phone info of the guarantees when a guarantor > is modified. > But the code in C4::Members::ModMember is broken: > > 668 my $borrowercategory= GetBorrowercategory( > $data{'category_type'} ); > 669 if ( exists $borrowercategory->{'category_type'} && > $borrowercategory->{'category_type'} eq ('A' || 'S') ) { > 670 # is adult check guarantees; > 671 UpdateGuarantees(%data); > 672 } > > > First, GetBorrowerCategory expects a categorycode, not a category_type. > Then UpdateGuarantees retrieves the param like: > > 989 sub UpdateGuarantees { > 990 my %data = shift; > > Which means that %data will always be something like ( a_key => undef ) > And nothing more. > > The updateguarantees subroutine (It has been renamed) has been introduced by > > commit 56825e415fc232e38f0a874dc9a81fa2169ef06b > Date: Mon Aug 30 13:48:58 2004 +0000 > modularizing (with Members.pm) members management > (beginning of...) > > And the `%data = shift` already existed... > So I think that this behavior has never worked and we could remove the > related code. > > Any protests? > > Cheers, > Jonathan From tomascohen at gmail.com Mon Jan 25 14:52:11 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 25 Jan 2016 10:52:11 -0300 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: <56A5E2E9.9000609@biblibre.com> References: <56A1EE53.1060803@biblibre.com> <56A5E2E9.9000609@biblibre.com> Message-ID: No problem, only small firewall changes. 2016-01-25 5:55 GMT-03:00 Paul Poulain : > Le 22/01/2016 12:09, Tomas Cohen Arazi a ?crit : > > Paul, you are right: we are not using the jenkins server as an execution > node, so we just need the webapp running with its db/files. > It would be handy this it kept the current ip (firewall on the nodes) but > we could survive. > > Sorry Tomas, but the IP will change (new provider) > > And please keep the pubkeys :-) > > Thanks > El 22/1/2016 5:54, "Paul Poulain" < > paul.poulain at biblibre.com> escribi?: > >> Hi koha-devel (and especially chris I think) >> >> The jenkins server is now pretty old, we (BibLibre) have new (fancy) >> platforms where we would like to move it. >> >> First question: do we agree that jenkins.koha-community.org is now only >> collecting data from other servers as "master", and no integration is made >> on BibLibre server anymore ? If I'm wrong we need some explanations ! >> >> Migration plan: what do we need to move ? the .war only ? a mysql db we >> have [koha, koha_univ_lyon3, koha_biblibre_master] ? >> >> Another question: it seems I don't have an account anymore on jenkins >> http. >> >> thx to answer by including laurent, our sysop (he's not on koha-devel) >> >> -- >> Paul Poulain, Associ?-g?rant / co-owner >> BibLibre, Services en logiciels libres pour les biblioth?ques >> BibLibre, Open Source software and services for libraries >> >> _______________________________________________ >> 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/ > > > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Mon Jan 25 14:52:30 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 25 Jan 2016 10:52:30 -0300 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: <1da148737b99aab93bd5ce4b03db2b2f@webmail.biblibre.com> References: <56A1EE53.1060803@biblibre.com> <56A5E2E9.9000609@biblibre.com> <1da148737b99aab93bd5ce4b03db2b2f@webmail.biblibre.com> Message-ID: When are you planning the switch? Do u need my help? 2016-01-25 6:14 GMT-03:00 Laurent Ducos : > > The new ip adress will be 212.47.240.49 > if I understood , just copy the webroot /var/cache/jenkins/war, > /usr/share/jenkins/, /var/lib/jenkins and /home/jenkins/jobs/ for the jobs > and plugins on the new server ? > Laurent Ducos > Administrateur Syst?mes et R?seaux > +33974770716 > > > 25 janvier 2016 09:55 "Paul Poulain" <%22Paul%20Poulain%22%20%3Cpaul.poulain at biblibre.com%3E>> a ?crit: > > Le 22/01/2016 12:09, Tomas Cohen Arazi a ?crit : > > > Paul, you are right: we are not using the jenkins server as an execution > node, so we just need the webapp running with its db/files. > It would be handy this it kept the current ip (firewall on the nodes) but > we could survive. > > Sorry Tomas, but the IP will change (new provider) > > > > And please keep the pubkeys :-) > > Thanks > El 22/1/2016 5:54, "Paul Poulain" escribi?: > > Hi koha-devel (and especially chris I think) > > The jenkins server is now pretty old, we (BibLibre) have new (fancy) > platforms where we would like to move it. > > First question: do we agree that jenkins.koha-community.org is now only > collecting data from other servers as "master", and no integration is made > on BibLibre server anymore ? If I'm wrong we need some explanations ! > > Migration plan: what do we need to move ? the .war only ? a mysql db we > have [koha, koha_univ_lyon3, koha_biblibre_master] ? > > Another question: it seems I don't have an account anymore on jenkins http. > > thx to answer by including laurent, our sysop (he's not on koha-devel) > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > _______________________________________________ > 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/ > > > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Mon Jan 25 14:53:41 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 25 Jan 2016 10:53:41 -0300 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: <1da148737b99aab93bd5ce4b03db2b2f@webmail.biblibre.com> References: <56A1EE53.1060803@biblibre.com> <56A5E2E9.9000609@biblibre.com> <1da148737b99aab93bd5ce4b03db2b2f@webmail.biblibre.com> Message-ID: 2016-01-25 6:14 GMT-03:00 Laurent Ducos : > > The new ip adress will be 212.47.240.49 > if I understood , just copy the webroot /var/cache/jenkins/war, > /usr/share/jenkins/, /var/lib/jenkins and /home/jenkins/jobs/ for the jobs > and plugins on the new server ? > That's pretty much all of it. > > Laurent Ducos > Administrateur Syst?mes et R?seaux > +33974770716 > > > 25 janvier 2016 09:55 "Paul Poulain" <%22Paul%20Poulain%22%20%3Cpaul.poulain at biblibre.com%3E>> a ?crit: > > Le 22/01/2016 12:09, Tomas Cohen Arazi a ?crit : > > > Paul, you are right: we are not using the jenkins server as an execution > node, so we just need the webapp running with its db/files. > It would be handy this it kept the current ip (firewall on the nodes) but > we could survive. > > Sorry Tomas, but the IP will change (new provider) > > > > And please keep the pubkeys :-) > > Thanks > El 22/1/2016 5:54, "Paul Poulain" escribi?: > > Hi koha-devel (and especially chris I think) > > The jenkins server is now pretty old, we (BibLibre) have new (fancy) > platforms where we would like to move it. > > First question: do we agree that jenkins.koha-community.org is now only > collecting data from other servers as "master", and no integration is made > on BibLibre server anymore ? If I'm wrong we need some explanations ! > > Migration plan: what do we need to move ? the .war only ? a mysql db we > have [koha, koha_univ_lyon3, koha_biblibre_master] ? > > Another question: it seems I don't have an account anymore on jenkins http. > > thx to answer by including laurent, our sysop (he's not on koha-devel) > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > _______________________________________________ > 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/ > > > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Mon Jan 25 16:12:57 2016 From: gmc at esilibrary.com (Galen Charlton) Date: Mon, 25 Jan 2016 10:12:57 -0500 Subject: [Koha-devel] KohaCon16 - Registrations & Call for proposals Open In-Reply-To: References: Message-ID: Hi, On Mon, Jan 25, 2016 at 6:04 AM, ??????? ?????????? wrote: > > Developers, technical support staff, librarians are invited to share their > experience by contributing with a presentation proposal based on their > knowledge, ideas, best practices and even mistakes! (Please note that all > presentations will be in English). > Will proposals for remote presentations (i.e., via webinar) be considered? Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Tue Jan 26 09:41:46 2016 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 26 Jan 2016 21:41:46 +1300 Subject: [Koha-devel] Koha bugzilla now using https Message-ID: Hi all bugs.koha-community.org is now being served over https, which is cool. However you will need to tell git bz to use https This is as simple as running git config --global bz-tracker.bugs.koha-community.org.https true (I think it should work without the --global, if you run it in your koha checkout too) I have updated the wiki documentation for git bz also, the kohadevbox will need to be updated at some point also Chris From laurent.ducos at biblibre.com Tue Jan 26 11:47:32 2016 From: laurent.ducos at biblibre.com (Laurent Ducos) Date: Tue, 26 Jan 2016 10:47:32 +0000 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: References: <56A1EE53.1060803@biblibre.com> <56A5E2E9.9000609@biblibre.com> <1da148737b99aab93bd5ce4b03db2b2f@webmail.biblibre.com> Message-ID: <4b28ef56e616584259300177f2835ad8@webmail.biblibre.com> I have a problem with the following directories ?/home/jenkins/jobs/Koha_3.14.x and /home/jenkins/jobs/Koha_master 22Go + 28Go, very big no ?? maybe they are obsolete ? 15M?? ?/home/jenkins/jobs/Koha_3.18.x_U12 40M?? ?/home/jenkins/jobs/Koha_3.14.x_U12 12K?? ?/home/jenkins/jobs/Koha_Docs_3.12.x 6,8M?? ?/home/jenkins/jobs/Koha_3.22.x_D8_MariaDB10.0 218M?? ?/home/jenkins/jobs/Koha_Master_U14_MariaDB10.1 100M?? ?/home/jenkins/jobs/Koha_Master_D6 212M?? ?/home/jenkins/jobs/Koha_Master_D7 141M?? ?/home/jenkins/jobs/Koha_3.22.x_D8 13M?? ?/home/jenkins/jobs/Koha_3.20.x_D8 22G?? ?/home/jenkins/jobs/Koha_3.14.x 35M?? ?/home/jenkins/jobs/Koha_3.16.x_U12 15M?? ?/home/jenkins/jobs/Koha_3.18.x_U14 224M?? ?/home/jenkins/jobs/Koha_Master_U14 28G?? ?/home/jenkins/jobs/Koha_master 172K?? ?/home/jenkins/jobs/Koha_Docs_3.16.x 60M?? ?/home/jenkins/jobs/Koha_3.18.x_D6 35M?? ?/home/jenkins/jobs/Koha_3.16.x_D7 47M?? ?/home/jenkins/jobs/Koha_3.14.x_U14 400K?? ?/home/jenkins/jobs/Koha_Docs_3.14.x 81M?? ?/home/jenkins/jobs/Koha_3.20.x_U12 77M?? ?/home/jenkins/jobs/Koha_3.20.x_U14 115M?? ?/home/jenkins/jobs/Koha_3.22.x_U14 12K?? ?/home/jenkins/jobs/Koha_3.8.x 85M?? ?/home/jenkins/jobs/Koha_3.20.x_D7 46M?? ?/home/jenkins/jobs/Koha_3.14.x_D7 28M?? ?/home/jenkins/jobs/Koha_3.16.x_U14 180K?? ?/home/jenkins/jobs/Koha_Docs_3.18.x 134M?? ?/home/jenkins/jobs/Koha_Master_U12 2,8M?? ?/home/jenkins/jobs/Koha_Docs 59M?? ?/home/jenkins/jobs/Koha_3.14.x_D6 136K?? ?/home/jenkins/jobs/Koha_Docs_3.20.x 16M?? ?/home/jenkins/jobs/Koha_3.18.x_D7 15M?? ?/home/jenkins/jobs/Koha_3.16.x_D6 217M?? ?/home/jenkins/jobs/Koha_Master_D8 219M?? ?/home/jenkins/jobs/Koha_Master_D8_MariaDB10.0 Laurent Ducos Administrateur Syst?mes et R?seaux +33974770716 25 janvier 2016 14:54 "Tomas Cohen Arazi" a ?crit: ? ? 2016-01-25 6:14 GMT-03:00 Laurent Ducos : ? The new ip adress will be 212.47.240.49 if I understood , just copy the webroot /var/cache/jenkins/war,? /usr/share/jenkins/, /var/lib/jenkins and /home/jenkins/jobs/ for the jobs and plugins on the new server ? That's pretty much all of it. ? Laurent Ducos Administrateur Syst?mes et R?seaux +33974770716 25 janvier 2016 09:55 "Paul Poulain" a ?crit: Le 22/01/2016 12:09, Tomas Cohen Arazi a ?crit?:? Paul, you are right: we are not using the jenkins server as an execution node, so we just need the webapp running with its db/files. It would be handy this it kept the current ip (firewall on the nodes) but we could survive.Sorry Tomas, but the IP will change (new provider) ? And please keep the pubkeys :-) Thanks El 22/1/2016 5:54, "Paul Poulain" escribi?:Hi koha-devel (and especially chris I think) The jenkins server is now pretty old, we (BibLibre) have new (fancy) platforms where we would like to move it. First question: do we agree that jenkins.koha-community.org (http://jenkins.koha-community.org) is now only collecting data from other servers as "master", and no integration is made on BibLibre server anymore ? If I'm wrong we need some explanations ! Migration plan: what do we need to move ? the .war only ? a mysql db we have [koha, koha_univ_lyon3, koha_biblibre_master] ? Another question: it seems I don't have an account anymore on jenkins http. thx to answer by including laurent, our sysop (he's not on koha-devel) -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org (mailto:Koha-devel at lists.koha-community.org) http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel (http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel) website : http://www.koha-community.org/ (http://www.koha-community.org/) git : http://git.koha-community.org/ (http://git.koha-community.org/) bugs : http://bugs.koha-community.org/ (http://bugs.koha-community.org/)? -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org (mailto:Koha-devel at lists.koha-community.org) http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel (http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel) website : http://www.koha-community.org/ (http://www.koha-community.org/) git : http://git.koha-community.org/ (http://git.koha-community.org/) bugs : http://bugs.koha-community.org/ (http://bugs.koha-community.org/)? -- Tom?s Cohen AraziTheke Solutions (http://theke.io (http://theke.io/)) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Tue Jan 26 14:26:59 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 26 Jan 2016 10:26:59 -0300 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: <4b28ef56e616584259300177f2835ad8@webmail.biblibre.com> References: <56A1EE53.1060803@biblibre.com> <56A5E2E9.9000609@biblibre.com> <1da148737b99aab93bd5ce4b03db2b2f@webmail.biblibre.com> <4b28ef56e616584259300177f2835ad8@webmail.biblibre.com> Message-ID: I'd say 3.14.x should go away. Regarding the Koha_Master task, maybe we'd like to keep it for historical purposes. Maybe discuss is on IRC? 2016-01-26 7:47 GMT-03:00 Laurent Ducos : > I have a problem with the following directories > /home/jenkins/jobs/Koha_3.14.x and /home/jenkins/jobs/Koha_master 22Go + > 28Go, very big no ? maybe they are obsolete ? > > 15M /home/jenkins/jobs/Koha_3.18.x_U12 > 40M /home/jenkins/jobs/Koha_3.14.x_U12 > 12K /home/jenkins/jobs/Koha_Docs_3.12.x > 6,8M /home/jenkins/jobs/Koha_3.22.x_D8_MariaDB10.0 > 218M /home/jenkins/jobs/Koha_Master_U14_MariaDB10.1 > 100M /home/jenkins/jobs/Koha_Master_D6 > 212M /home/jenkins/jobs/Koha_Master_D7 > 141M /home/jenkins/jobs/Koha_3.22.x_D8 > 13M /home/jenkins/jobs/Koha_3.20.x_D8 > 22G /home/jenkins/jobs/Koha_3.14.x > 35M /home/jenkins/jobs/Koha_3.16.x_U12 > 15M /home/jenkins/jobs/Koha_3.18.x_U14 > 224M /home/jenkins/jobs/Koha_Master_U14 > 28G /home/jenkins/jobs/Koha_master > 172K /home/jenkins/jobs/Koha_Docs_3.16.x > 60M /home/jenkins/jobs/Koha_3.18.x_D6 > 35M /home/jenkins/jobs/Koha_3.16.x_D7 > 47M /home/jenkins/jobs/Koha_3.14.x_U14 > 400K /home/jenkins/jobs/Koha_Docs_3.14.x > 81M /home/jenkins/jobs/Koha_3.20.x_U12 > 77M /home/jenkins/jobs/Koha_3.20.x_U14 > 115M /home/jenkins/jobs/Koha_3.22.x_U14 > 12K /home/jenkins/jobs/Koha_3.8.x > 85M /home/jenkins/jobs/Koha_3.20.x_D7 > 46M /home/jenkins/jobs/Koha_3.14.x_D7 > 28M /home/jenkins/jobs/Koha_3.16.x_U14 > 180K /home/jenkins/jobs/Koha_Docs_3.18.x > 134M /home/jenkins/jobs/Koha_Master_U12 > 2,8M /home/jenkins/jobs/Koha_Docs > 59M /home/jenkins/jobs/Koha_3.14.x_D6 > 136K /home/jenkins/jobs/Koha_Docs_3.20.x > 16M /home/jenkins/jobs/Koha_3.18.x_D7 > 15M /home/jenkins/jobs/Koha_3.16.x_D6 > 217M /home/jenkins/jobs/Koha_Master_D8 > 219M /home/jenkins/jobs/Koha_Master_D8_MariaDB10.0 > > > Laurent Ducos > Administrateur Syst?mes et R?seaux > +33974770716 > > 25 janvier 2016 14:54 "Tomas Cohen Arazi" <%22Tomas%20Cohen%20Arazi%22%20%3Ctomascohen at gmail.com%3E>> a ?crit: > > > > 2016-01-25 6:14 GMT-03:00 Laurent Ducos : > > > > > The new ip adress will be 212.47.240.49 > if I understood , just copy the webroot /var/cache/jenkins/war, > /usr/share/jenkins/, /var/lib/jenkins and /home/jenkins/jobs/ for the jobs > and plugins on the new server ? > > That's pretty much all of it. > > > > Laurent Ducos > Administrateur Syst?mes et R?seaux > +33974770716 > > > 25 janvier 2016 09:55 "Paul Poulain" <%22Paul%20Poulain%22%20%3Cpaul.poulain at biblibre.com%3E>> a ?crit: > > Le 22/01/2016 12:09, Tomas Cohen Arazi a ?crit : > > > Paul, you are right: we are not using the jenkins server as an execution > node, so we just need the webapp running with its db/files. > It would be handy this it kept the current ip (firewall on the nodes) but > we could survive. > > Sorry Tomas, but the IP will change (new provider) > > > > And please keep the pubkeys :-) > > Thanks > El 22/1/2016 5:54, "Paul Poulain" escribi?: > > Hi koha-devel (and especially chris I think) > > The jenkins server is now pretty old, we (BibLibre) have new (fancy) > platforms where we would like to move it. > > First question: do we agree that jenkins.koha-community.org is now only > collecting data from other servers as "master", and no integration is made > on BibLibre server anymore ? If I'm wrong we need some explanations ! > > Migration plan: what do we need to move ? the .war only ? a mysql db we > have [koha, koha_univ_lyon3, koha_biblibre_master] ? > > Another question: it seems I don't have an account anymore on jenkins http. > > thx to answer by including laurent, our sysop (he's not on koha-devel) > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > _______________________________________________ > 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/ > > > > -- > Paul Poulain, Associ?-g?rant / co-owner > BibLibre, Services en logiciels libres pour les biblioth?ques > BibLibre, Open Source software and services for libraries > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > -- > Tom?s Cohen Arazi > Theke Solutions (http://theke.io) > ? +54 9351 3513384 > GPG: B2F3C15F > > -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Tue Jan 26 16:13:50 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 26 Jan 2016 12:13:50 -0300 Subject: [Koha-devel] Koha bugzilla now using https In-Reply-To: References: Message-ID: The kohadevbox:ansible branch is already updated for this change. Great work Chris! Thanks! 2016-01-26 5:41 GMT-03:00 Chris Cormack : > Hi all > > bugs.koha-community.org is now being served over https, which is cool. > However you will need to tell git bz to use https > > This is as simple as running > > git config --global bz-tracker.bugs.koha-community.org.https true > > (I think it should work without the --global, if you run it in your > koha checkout too) > > I have updated the wiki documentation for git bz also, the kohadevbox > will need to be updated at some point also > > Chris > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Tue Jan 26 16:54:46 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Tue, 26 Jan 2016 16:54:46 +0100 Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work Message-ID: <56A796C6.2030908@cineca.it> Hi all, I trying to check my indexes in Zebra. My setup: OS: Debian jessie Koha: 3.20.7 [manual install] Zebra: 2.0.61 [install from IndexData repo] Format: UNIMARC Probably the fact that I use unimarc is relevant but I don't understand where. I do the debug described here: http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#Why_does_a_search_return_that_result The result of a working search is: Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo 'zebra::snippet' but my ../etc/zebradb/retrieval-info-bib-dom.xml is correct: Do I need to check in other places for the setup of ' zebra::snippet' ? Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From tomascohen at gmail.com Tue Jan 26 17:08:39 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 26 Jan 2016 13:08:39 -0300 Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: <56A796C6.2030908@cineca.it> References: <56A796C6.2030908@cineca.it> Message-ID: Maybe they just removed the zebra::snippet elem? 2016-01-26 12:54 GMT-03:00 Tajoli Zeno : > Hi all, > > I trying to check my indexes in Zebra. > My setup: > OS: Debian jessie > Koha: 3.20.7 [manual install] > Zebra: 2.0.61 [install from IndexData repo] > Format: UNIMARC > > Probably the fact that I use unimarc is relevant but I don't understand > where. > I do the debug described here: > > http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#Why_does_a_search_return_that_result > > The result of a working search is: > > Diagnostic message(s) from database: > [25] Specified element set name not valid for specified database -- v2 > addinfo 'zebra::snippet' > > but my ../etc/zebradb/retrieval-info-bib-dom.xml is correct: > > > > > > inputcharset="utf-8" > outputcharset="utf-8"/> > > > > > inputcharset="utf-8" > outputcharset="utf-8"/> > > > > > identifier="info:srw/schema/1/marcxml-v1.1"/> > identifier="info:srw/schema/1/marcxml-v1.1"/> > > > > Do I need to check in other places for the setup of ' zebra::snippet' ? > > Bye > Zeno Tajoli > > > -- > Zeno Tajoli > / SVILUPPO PRODOTTI/ - Automazione Biblioteche > Email: z.tajoli at cineca.it Fax: 051/6132198 > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Tue Jan 26 17:19:38 2016 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Tue, 26 Jan 2016 17:19:38 +0100 (CET) Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: Message-ID: <546802428.15282298.1453825178022.JavaMail.root@cineca.it> Hi to all, >Maybe they just removed the zebra::snippet elem? I try also Z> format xml Z> elements zebra::data Z> base biblios Z> f git Z> show 1 The result is the same: Sent presentRequest (1+1). Records: 1 Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo '' nextResultSetPosition = 2 Elapsed: 0.000759 So it is something differnt. Bye Zeno Tajoli Hi all, I trying to check my indexes in Zebra. My setup: OS: Debian jessie Koha: 3.20.7 [manual install] Zebra: 2.0.61 [install from IndexData repo] Format: UNIMARC Probably the fact that I use unimarc is relevant but I don't understand where. I do the debug described here: http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#Why_does_a_search_return_that_result The result of a working search is: Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo 'zebra::snippet' but my ../etc/zebradb/retrieval-info-bib-dom.xml is correct: Do I need to check in other places for the setup of ' zebra::snippet' ? Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions ( http://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F From tomascohen at gmail.com Tue Jan 26 17:21:16 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 26 Jan 2016 13:21:16 -0300 Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: <546802428.15282298.1453825178022.JavaMail.root@cineca.it> References: <546802428.15282298.1453825178022.JavaMail.root@cineca.it> Message-ID: You need to check if you are actually using the etc/zebradb/retrieval-info-bib-dom.xml file. Maybe is using a different one, without the line. 2016-01-26 13:19 GMT-03:00 Zeno Tajoli : > Hi to all, > > > >Maybe they just removed the zebra::snippet elem? > > I try also > Z> format xml > Z> elements zebra::data > Z> base biblios > Z> f git > Z> show 1 > > The result is the same: > Sent presentRequest (1+1). > Records: 1 > Diagnostic message(s) from database: > [25] Specified element set name not valid for specified database -- v2 > addinfo '' > nextResultSetPosition = 2 > Elapsed: 0.000759 > > So it is something differnt. > > Bye > Zeno Tajoli > > > > > > > > Hi all, > > I trying to check my indexes in Zebra. > My setup: > OS: Debian jessie > Koha: 3.20.7 [manual install] > Zebra: 2.0.61 [install from IndexData repo] > Format: UNIMARC > > Probably the fact that I use unimarc is relevant but I don't understand > where. > I do the debug described here: > > http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#Why_does_a_search_return_that_result > > The result of a working search is: > > Diagnostic message(s) from database: > [25] Specified element set name not valid for specified database -- v2 > addinfo 'zebra::snippet' > > but my ../etc/zebradb/retrieval-info-bib-dom.xml is correct: > > > > > > inputcharset="utf-8" > outputcharset="utf-8"/> > > > > > inputcharset="utf-8" > outputcharset="utf-8"/> > > > > > identifier="info:srw/schema/1/marcxml-v1.1"/> > identifier="info:srw/schema/1/marcxml-v1.1"/> > > > > Do I need to check in other places for the setup of ' zebra::snippet' ? > > Bye > Zeno Tajoli > > > -- > Zeno Tajoli > / SVILUPPO PRODOTTI/ - Automazione Biblioteche > Email: z.tajoli at cineca.it Fax: 051/6132198 > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > > -- > > > > > > Tom?s Cohen Arazi > Theke Solutions ( http://theke.io ) > ? +54 9351 3513384 > GPG: B2F3C15F > -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Tue Jan 26 18:03:05 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Tue, 26 Jan 2016 18:03:05 +0100 Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: References: <546802428.15282298.1453825178022.JavaMail.root@cineca.it> Message-ID: <56A7A6C9.4020108@cineca.it> Hi Tomas, Il 26/01/2016 17:21, Tomas Cohen Arazi ha scritto: > You need to check if you are actually using the > etc/zebradb/retrieval-info-bib-dom.xml file. Maybe is using a different > one, without the line. I read koha-conf.xml and I find: this is the path to the correct retrieval-info-bib-dom.xml file. This file has the line "" Could I check samething else ^ Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From wwwretive at yahoo.fr Tue Jan 26 18:42:34 2016 From: wwwretive at yahoo.fr (philippe kloos) Date: Tue, 26 Jan 2016 18:42:34 +0100 Subject: [Koha-devel] koha-plack --enable does not enable plack when plack has never been enabled Message-ID: <56A7B00A.8030807@yahoo.fr> hello, When running koha-plack --enable, the script assumes that there is already a commented line that includes the plack configuration in the apache virtual host's config of the instance. The script would comment out the line : (from /usr/sbin/koha-plack line 148) : sed -i 's:^\s*#\(\s*Include /etc/koha/apache-shared-opac-plack.conf\)$:\1:' "$instancefile" sed -i 's:^\s*#\(\s*Include /etc/koha/apache-shared-intranet-plack.conf\)$:\1:' "$instancefile" For old fashioned installs there is no commented line that includes plack configuration, so the regular expression doesn't match and the script doesn't enable plack. In my config (we've set up koha 3 years ago) i had to add the plack-related line directly in the apache virtual host config. Since the included files use the ${instance} variable, i had to define that variable as well in my vhost config : Define instance myinstancename (the "Define" keyword is not well documented in the apache docs ; i used it because SetEnv didn't work). Instead of commenting out the (possibibly non-existent) plack related lines, it is possible to find where the "/etc/koha/apache-shared-{opac,intranet}.conf" files are included and add the two relevant lines : --- a/debian/scripts/koha-plack +++ b/debian/scripts/koha-plack @@ -144,9 +144,9 @@ enable_plack() local instancefile=$(get_apache_config_for "$instancename") if ! is_plack_enabled $instancename; then - # Uncomment the plack related lines for OPAC and intranet - sed -i 's:^\s*#\(\s*Include /etc/koha/apache-shared-opac-plack.conf\)$:\1:' "$instancefile" - sed -i 's:^\s*#\(\s*Include /etc/koha/apache-shared-intranet-plack.conf\)$:\1:' "$instancefile" + # Define the instance name and add the plack related lines for OPAC and intranet + sed -i "s:^\(\s*\)\(Include /etc/koha/apache-shared-opac.conf\):\1\2\n\1Define instance $instancename\n\1Include /etc/koha/apache-shared-opac-plack.conf:" "$instancefile" + sed -i "s:^\(\s*\)\(Include /etc/koha/apache-shared-intranet.conf\):\1\2\n\1Define instance $instancename\n\1Include /etc/koha/apache-shared-intranet-plack.conf:" "$instancefile" [ "${quiet}" != "yes" ] && warn "Plack enabled for ${instancename}" return 0 else To disable plack, one could remove the two added lines (although removing the "Define instance $instancename" line could have side effects). Should i file a bug about this ? Regards, Philippe K. https://laretive.info From z.tajoli at cineca.it Tue Jan 26 22:20:08 2016 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Tue, 26 Jan 2016 22:20:08 +0100 (CET) Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: Message-ID: <715057982.15552963.1453843208318.JavaMail.root@cineca.it> ----- Messaggio originale ----- Da: "Tomas Cohen Arazi" A: "Zeno Tajoli" Cc: "koha-devel" Inviato: Marted?, 26 gennaio 2016 17:21:16 Oggetto: Re: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work You need to check if you are actually using the etc/zebradb/retrieval-info- bib-dom.xml file. Maybe is using a different one, without the line. 2016-01-26 13:19 GMT-03:00 Zeno Tajoli < z.tajoli at cineca.it > : Hi to all, >Maybe they just removed the zebra::snippet elem? I try also Z> format xml Z> elements zebra::data Z> base biblios Z> f git Z> show 1 The result is the same: Sent presentRequest (1+1). Records: 1 Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo '' nextResultSetPosition = 2 Elapsed: 0.000759 So it is something differnt. Bye Zeno Tajoli Hi all, I trying to check my indexes in Zebra. My setup: OS: Debian jessie Koha: 3.20.7 [manual install] Zebra: 2.0.61 [install from IndexData repo] Format: UNIMARC Probably the fact that I use unimarc is relevant but I don't understand where. I do the debug described here: http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#Why_does_a_search_return_that_result The result of a working search is: Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo 'zebra::snippet' but my ../etc/zebradb/retrieval-info-bib-dom.xml is correct: Do I need to check in other places for the setup of ' zebra::snippet' ? Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions ( http://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F -- Tom?s Cohen Arazi Theke Solutions ( http://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F From z.tajoli at cineca.it Tue Jan 26 22:28:06 2016 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Tue, 26 Jan 2016 22:28:06 +0100 (CET) Subject: [Koha-devel] Do we use '"zebra::*"' only for facets ? Message-ID: <2039340728.15560083.1453843686152.JavaMail.root@cineca.it> Hi to all, as I say in previous thread I have problems with retrieval data from zebra::*. Now I want to check how we use the zebra::*. As I see from the code and from comment in git repo, we use zebra::* only for facets, with instruction: C4/Search.pm: my $facet_element = 'zebra::facet::' . $facet_idx . ':0:' . $facetMaxCount; Is it correct ? Bye Zeno Tajoli From chris at bigballofwax.co.nz Tue Jan 26 22:31:56 2016 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 27 Jan 2016 10:31:56 +1300 Subject: [Koha-devel] koha-plack --enable does not enable plack when plack has never been enabled In-Reply-To: <56A7B00A.8030807@yahoo.fr> References: <56A7B00A.8030807@yahoo.fr> Message-ID: On 27 January 2016 at 06:42, philippe kloos wrote: > > Should i file a bug about this ? > Hi Philippe Please do file a bug. Chris From tomascohen at gmail.com Tue Jan 26 22:37:48 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 26 Jan 2016 18:37:48 -0300 Subject: [Koha-devel] Do we use '"zebra::*"' only for facets ? In-Reply-To: <2039340728.15560083.1453843686152.JavaMail.root@cineca.it> References: <2039340728.15560083.1453843686152.JavaMail.root@cineca.it> Message-ID: That's correct. El 26/1/2016 18:28, "Zeno Tajoli" escribi?: > Hi to all, > > as I say in previous thread I have problems with retrieval data from > zebra::*. > > Now I want to check how we use the zebra::*. > As I see from the code and from comment in git repo, we use zebra::* only > for > facets, with instruction: > > C4/Search.pm: my $facet_element = 'zebra::facet::' . $facet_idx . ':0:' > . $facetMaxCount; > > Is it correct ? > > Bye > Zeno Tajoli > _______________________________________________ > 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 Tue Jan 26 23:55:49 2016 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Jan 2016 09:55:49 +1100 Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: <56A7A6C9.4020108@cineca.it> References: <546802428.15282298.1453825178022.JavaMail.root@cineca.it> <56A7A6C9.4020108@cineca.it> Message-ID: <017001d1588c$b2ef54b0$18cdfe10$@prosentient.com.au> Hi Zeno, That's pretty strange. I'm using Zebra 2.0.60, and the zebra::* elements work fine on openSUSE. "/etc/zebradb/retrieval-info-bib-dom.xml" is an interesting filepath. You installed Koha with the Debian Packages, yes? Historically, that filepath has been something like /etc/koha/marc21-retrieval-info-bib-dom.xml (I imagine there might be a similar unimarc one although unimarc installs might use the marc21 one anyway). While bug 12216 changed the Debian Koha Zebra profile path to " profilePath:/etc/koha/sites/__KOHASITE__:/etc/koha/zebradb/biblios/etc:/etc/ koha/zebradb/etc:/etc/koha/zebradb/marc_defs/__ZEBRA_MARC_FORMAT__/biblios:/ etc/koha/zebradb/lang_defs/__ZEBRA_LANGUAGE__:/etc/koha/zebradb/xsl", that might not be relevant in your case if you're not using the packaged Koha. Are you using a Gitified Koha or a Git Dev install of Koha? My Git Dev install has something like "/home/dcook/koha-dev/etc/zebradb/retrieval-info-bib-dom.xsl". Did you load an old Koha configuration and database? Or did you start fresh? You might need to do a Zebra re-index and a Zebra re-start. Nothing in the Zebra changelog (http://www.indexdata.com/zebra/doc/NEWS) suggests that the zebra::* elements have been removed. Are you able to do normal searches in Koha or yaz-client? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Tajoli Zeno > Sent: Wednesday, 27 January 2016 4:03 AM > To: Tomas Cohen Arazi > Cc: koha-devel > Subject: Re: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work > > Hi Tomas, > > Il 26/01/2016 17:21, Tomas Cohen Arazi ha scritto: > > You need to check if you are actually using the > > etc/zebradb/retrieval-info-bib-dom.xml file. Maybe is using a > > different one, without the > line. > > I read koha-conf.xml and I find: > xmlns:xi="http://www.w3.org/2001/XInclude"/> > > this is the path to the correct retrieval-info-bib-dom.xml file. > This file has the line "" > > Could I check samething else ^ > > Bye > Zeno Tajoli > > -- > Zeno Tajoli > / SVILUPPO PRODOTTI/ - Automazione Biblioteche > Email: z.tajoli at cineca.it Fax: 051/6132198 > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) > _______________________________________________ > 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 info at bywatersolutions.com Wed Jan 27 00:24:18 2016 From: info at bywatersolutions.com (Brendan Gallagher) Date: Tue, 26 Jan 2016 15:24:18 -0800 Subject: [Koha-devel] It's that time - Calling for a dev meeting in IRC - Feb 2nd Message-ID: Hello All - I'd like to call for a dev meeting(QA meetup/catch up) for Feb 2nd at 15utc. The reason there is such short notice was that I thought we should complete the meeting so we can bring any announcements to the General IRC meeting the following day. Please see the agenda. https://wiki.koha-community.org/wiki/Development_IRC_meeting_2_February_2016 Time converter - http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting&iso=20160102T15 Thanks much, B -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirko at abunchofthings.net Wed Jan 27 04:45:19 2016 From: mirko at abunchofthings.net (Mirko Tietgen) Date: Wed, 27 Jan 2016 03:45:19 GMT Subject: [Koha-devel] It's that time - Calling for a dev meeting in IRC - Feb 2nd References: Message-ID: <1453866350299.c7e40a833bf098@mozgaia> An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Wed Jan 27 06:19:30 2016 From: z.tajoli at cineca.it (Zeno Tajoli) Date: Wed, 27 Jan 2016 06:19:30 +0100 (CET) Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: <017001d1588c$b2ef54b0$18cdfe10$@prosentient.com.au> Message-ID: <1147165401.15972231.1453871970457.JavaMail.root@cineca.it> Hi David and all, >That's pretty strange. I'm using Zebra 2.0.60, and the zebra::* elements >work fine on openSUSE. this installation is Zebra 2.0.61. on Debian Jessie >"/etc/zebradb/retrieval-info-bib-dom.xml" is an interesting >filepath. [...] >Are you using a Gitified Koha or a Git Dev install of Koha? My Git Dev >install has something like >"/home/dcook/koha-dev/etc/zebradb/retrieval-info-bib-dom.xsl". It is a Git Dev install of Koha. So insert '' in the mail because is out of standard place >Did you load an old Koha configuration and database? Or did you start fresh? >You might need to do a Zebra re-index and a Zebra re-start. It is a start from fresh install and I do same Zebra re-index and a Zebra re-start. But now I try starting from a fresh debian 8 and I will say the result. > Are you able to do normal searches in Koha or yaz-client? In fact yes, I can do normal searches with Koha Opac and with yaz-client. Bye Zeno Tajoli From laurent.ducos at biblibre.com Wed Jan 27 15:58:26 2016 From: laurent.ducos at biblibre.com (Laurent Ducos) Date: Wed, 27 Jan 2016 14:58:26 +0000 Subject: [Koha-devel] maintenance on jenkins Message-ID: Hello Maintenance operation before migration of jenkins server, thursday 28, from 10 A.M to 11 A.M french hour. Please do not use http://jenkins.koha-community.org/ durig this period. Have a good day. Laurent Ducos BibLibre -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Wed Jan 27 16:28:45 2016 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 27 Jan 2016 12:28:45 -0300 Subject: [Koha-devel] maintenance on jenkins In-Reply-To: References: Message-ID: +1 Good job, Laurent! 2016-01-27 11:58 GMT-03:00 Laurent Ducos : > Hello > Maintenance operation before migration of jenkins server, thursday 28, > from 10 A.M to 11 A.M french hour. > Please do not use http://jenkins.koha-community.org/ durig this period. > Have a good day. > > Laurent Ducos > BibLibre > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Theke Solutions (http://theke.io) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From z.tajoli at cineca.it Wed Jan 27 18:15:42 2016 From: z.tajoli at cineca.it (Tajoli Zeno) Date: Wed, 27 Jan 2016 18:15:42 +0100 Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: <1147165401.15972231.1453871970457.JavaMail.root@cineca.it> References: <1147165401.15972231.1453871970457.JavaMail.root@cineca.it> Message-ID: <56A8FB3E.4030301@cineca.it> Hi David and all, Il 27/01/2016 06:19, Zeno Tajoli ha scritto: >> Did you load an old Koha configuration and database? Or did you start fresh? >> You might need to do a Zebra re-index and a Zebra re-start. > > It is a start from fresh install and I do same Zebra re-index and a Zebra re-start. > But now I try starting from a fresh debian 8 and I will say the result. I finish my test about 'elements zebra::snippet'. I have done 4 different installation on debian 8 (jessie) In every case: Install type: koha-common OS: Debian 8 (jessie) Lang: en Koha versione: 3.20.7.1 (oldstable) 1)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: MARC21 -- 'elements zebra::snippet' doesn't work 2)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: UNIMARC -- 'elements zebra::snippet' doesn't work 3)Zebra: 2.0.59. Repos: Koha only. MARC type: MARC21 -- 'elements zebra::snippet' WORKS 4)Zebra: 2.0.59. Repos: Koha only. MARC type: UNIMARC -- 'elements zebra::snippet' WORKS So the problem is not connect with MARC21/UNIMARC. David says that on OpenSuse Zebra 2.0.60 is ok about 'elements zebra::snippet'. It is not clear if it is a Debian 8 problem or an error on Zebra 2.0.61 I try to ask in Zebra mailing list. Bye Zeno Tajoli -- Zeno Tajoli / SVILUPPO PRODOTTI/ - Automazione Biblioteche Email: z.tajoli at cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From dhd.koha at gmail.com Wed Jan 27 18:22:37 2016 From: dhd.koha at gmail.com (Dhd Koha (grharry)) Date: Wed, 27 Jan 2016 19:22:37 +0200 Subject: [Koha-devel] OAI service for Authorities Message-ID: <56A8FCDD.8010501@gmail.com> Hi List, I'm wondering if there is an OAI service providing authorities records. Please correct me if I am wrong. Browsing through the code, implementation would involve some SQL code I presume?? Kind Regards, Harry From dcook at prosentient.com.au Thu Jan 28 00:21:03 2016 From: dcook at prosentient.com.au (David Cook) Date: Thu, 28 Jan 2016 10:21:03 +1100 Subject: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work In-Reply-To: <56A8FB3E.4030301@cineca.it> References: <1147165401.15972231.1453871970457.JavaMail.root@cineca.it> <56A8FB3E.4030301@cineca.it> Message-ID: <01f001d15959$63cb8a20$2b629e60$@prosentient.com.au> Sounds like a good idea asking on the Zebra listserv. I'm also planning on doing a Debian 8 Jessie install today or tomorrow, so I'll take a look at this myself too. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: Tajoli Zeno [mailto:z.tajoli at cineca.it] > Sent: Thursday, 28 January 2016 4:16 AM > To: David Cook > Cc: koha-devel > Subject: Re: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work > > Hi David and all, > > Il 27/01/2016 06:19, Zeno Tajoli ha scritto: > >> Did you load an old Koha configuration and database? Or did you start > fresh? > >> You might need to do a Zebra re-index and a Zebra re-start. > > > > It is a start from fresh install and I do same Zebra re-index and a Zebra re- > start. > > But now I try starting from a fresh debian 8 and I will say the result. > > I finish my test about 'elements zebra::snippet'. > I have done 4 different installation on debian 8 (jessie) In every case: > Install type: koha-common > OS: Debian 8 (jessie) > Lang: en > Koha versione: 3.20.7.1 (oldstable) > > 1)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: MARC21 > -- 'elements zebra::snippet' doesn't work > > 2)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: UNIMARC > -- 'elements zebra::snippet' doesn't work > > 3)Zebra: 2.0.59. Repos: Koha only. MARC type: MARC21 > -- 'elements zebra::snippet' WORKS > > 4)Zebra: 2.0.59. Repos: Koha only. MARC type: UNIMARC > -- 'elements zebra::snippet' WORKS > > So the problem is not connect with MARC21/UNIMARC. > > David says that on OpenSuse Zebra 2.0.60 is ok about 'elements > zebra::snippet'. > > It is not clear if it is a Debian 8 problem or an error on Zebra 2.0.61 > > I try to ask in Zebra mailing list. > > Bye > Zeno Tajoli > > > > > > -- > Zeno Tajoli > / SVILUPPO PRODOTTI/ - Automazione Biblioteche > Email: z.tajoli at cineca.it Fax: 051/6132198 > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From dcook at prosentient.com.au Thu Jan 28 00:28:39 2016 From: dcook at prosentient.com.au (David Cook) Date: Thu, 28 Jan 2016 10:28:39 +1100 Subject: [Koha-devel] OAI service for Authorities In-Reply-To: <56A8FCDD.8010501@gmail.com> References: <56A8FCDD.8010501@gmail.com> Message-ID: <01f101d1595a$73988880$5ac99980$@prosentient.com.au> Hi Harry: I don't think there's an OAI endpoint for authority records in Koha at present, no. Yes, implementation would involve some coding. I've thought a bit about it, but it's not something I would personally be interested in doing until later in the year. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of Dhd Koha (grharry) > Sent: Thursday, 28 January 2016 4:23 AM > To: koha-devel at lists.koha-community.org > Subject: [Koha-devel] OAI service for Authorities > > Hi List, > I'm wondering if there is an OAI service providing authorities records. > > Please correct me if I am wrong. > Browsing through the code, implementation would involve some SQL code I > presume?? > > Kind Regards, > Harry > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/ bugs : http://bugs.koha-community.org/ From dcook at prosentient.com.au Thu Jan 28 00:31:37 2016 From: dcook at prosentient.com.au (David Cook) Date: Thu, 28 Jan 2016 10:31:37 +1100 Subject: [Koha-devel] It's that time - Calling for a dev meeting in IRC - Feb 2nd In-Reply-To: References: Message-ID: <01f201d1595a$dde758b0$99b60a10$@prosentient.com.au> 2am is a bit too early for me, but my main thing is the OAI stuff I mentioned on IRC the other day anyway. Hopefully will be posting something on Bugzilla 10662 in the next week or two? 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 Brendan Gallagher Sent: Wednesday, 27 January 2016 10:24 AM To: Koha Devel Subject: [Koha-devel] It's that time - Calling for a dev meeting in IRC - Feb 2nd Hello All - I'd like to call for a dev meeting(QA meetup/catch up) for Feb 2nd at 15utc. The reason there is such short notice was that I thought we should complete the meeting so we can bring any announcements to the General IRC meeting the following day. Please see the agenda. https://wiki.koha-community.org/wiki/Development_IRC_meeting_2_February_2016 Time converter - http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IRC+Meeting &iso=20160102T15 Thanks much, B -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Jan 28 02:59:11 2016 From: dcook at prosentient.com.au (David Cook) Date: Thu, 28 Jan 2016 12:59:11 +1100 Subject: [Koha-devel] [SOLVED] Zebra: the 'elements zebra::snippet' doesn't work Message-ID: <020001d1596f$7b616f40$72244dc0$@prosentient.com.au> Hi Zeno: I believe that I've solved the symptom, although I admit that I don't 100% understand the root casue of the problem. The problem appears to be the line '' in "etc/zebradb/retrieval-info-bib-dom.xml". If you remove that and restart Zebra for your instance, you'll find that you're once again able to use "zebra::index", "zebra::snippet", "zebra::data", "zebra::facet::index:register:count". The in-depth explanation starts here: The vital line really is ''. With that line, we have access to the special retrieval elements (http://www.indexdata.com/zebra/doc/special-retrieval.html), as well as the ones that we've defined in the "retrieve pipeline" in /etc/koha/zebradb/biblios/etc/dom-config.xml, such as "zebra", "index", "marc", and "marcxml". (See /etc/koha/sites/libraryname/zebra-biblios-dom.cfg for the reference to /etc/koha/zebradb/biblios/etc/dom-config.xml. Also see http://www.indexdata.com/zebra/doc/record-model-domxml-pipeline.html for an explanation of the pipeline: "The possible multiple pipeline definitions are distinguished by their unique name attributes, these are the literal schema or element set names used in SRW, SRU and Z39.50 protocol queries."). I'm going to guess that the problem arose with YAZ 5.8.1 2015/01/13: "retrieval: pick matched element-set rule YAZ-813" (http://www.indexdata.com/yaz/doc/NEWS). Here's the git commit: http://git.indexdata.com/?p=yaz-moved-to-github.git;a=commit;h=f24766f1e9fc5 404fc0b512af8607d7f7054f4be. I haven't read through it extensively, so I could be wrong, but perhaps it caused some sort of problem where Zebra/YAZ was trying to find "zebra::*" in /etc/koha/zebradb/biblios/etc/dom-config.xml. I'm guessing that it didn't check that it was a special retrieval element and that it failed to find the backend element in the retrieve pipeline, and that's why it failed. We don't actually need any of the following lines: The only thing we need is . That provides access to the "marc", "marcxml", "zebra", and "index" backends defined in /etc/koha/zebradb/biblios/etc/dom-config.xml, as well as the zebra::* special retrieval elements. I've actually tested that on YAZ 5.1.2 and Zebra 2.0.60 on openSUSE, and it works great. I suppose the thing to do at this point is open a Bugzilla report to change "etc/zebradb/retrieval-info-bib-dom.xml", as well as "marc21-retrieval-info-bib-dom.xml", "normarc-retrieval-info-bib-dom.xml", and "unimarc-retrieval-info-bib-dom.xml". -- Installed Koha and Zebra on Debian Jessie using packages from scratch: sudo ls wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - echo 'deb http://debian.koha-community.org/koha oldstable main' | sudo tee /etc/apt/sources.list.d/koha.list sudo apt-get update sudo apt-get install koha-common -- sudo apt-get install mysql-server sudo a2enmod rewrite sudo a2enmod cgi sudo service apache2 restart echo 'deb http://ftp.indexdata.dk/debian jessie main' | sudo tee /etc/apt/sources.list.d/indexdata.list sudo apt-get update -- sudo apt-get install libidzebra-2.0 sudo koha-create --create-db libraryname sudo a2dissite 000-default.conf sudo vi /etc/apache2/ports.conf sudo service apache2 restart sudo xmlstarlet sel -t -v 'yazgfs/config/user' /etc/koha/sites/libraryname/koha-conf.xml sudo xmlstarlet sel -t -v 'yazgfs/config/pass' /etc/koha/sites/libraryname/koha-conf.xml yaz-client unix:/var/run/koha/libraryname/bibliosocket base biblios find test [109] Database unavailable -- v2 addinfo 'biblios' base biblios find test Number of hits: 1, setno 3 show 1 format xml show 1 elements zebra::snippet show 1 [25] Specified element set name not valid for specified database -- v2 addinfo '' elements index show 1 elements marcxml ehow 1 elements marc -- elements zebra show 1 [biblios]Record type: XML -- sudo vi /etc/koha/marc21-retrieval-info-bib-dom.xml sudo koha-restart-zebra libraryname Z> elements zebra::snippet Z> show 1 Sent presentRequest (1+1). Records: 1 Record type: XML test This is a test nextResultSetPosition = 2 Elapsed: 0.001125 Z> elements zebra::facet::title:w Z> show 1 Sent presentRequest (1+1). Records: 1 Record type: XML a is test this I had suspected in the past that we might be re-defining retrieval elements in the /etc/koha/marc21-retrieval-info-bib-dom.xml file... and this appears to confirm it. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: Tajoli Zeno [mailto:z.tajoli at cineca.it] > Sent: Thursday, 28 January 2016 4:16 AM > To: David Cook > Cc: koha-devel > Subject: Re: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't work > > Hi David and all, > > Il 27/01/2016 06:19, Zeno Tajoli ha scritto: > >> Did you load an old Koha configuration and database? Or did you start > fresh? > >> You might need to do a Zebra re-index and a Zebra re-start. > > > > It is a start from fresh install and I do same Zebra re-index and a Zebra re- > start. > > But now I try starting from a fresh debian 8 and I will say the result. > > I finish my test about 'elements zebra::snippet'. > I have done 4 different installation on debian 8 (jessie) In every case: > Install type: koha-common > OS: Debian 8 (jessie) > Lang: en > Koha versione: 3.20.7.1 (oldstable) > > 1)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: MARC21 > -- 'elements zebra::snippet' doesn't work > > 2)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: UNIMARC > -- 'elements zebra::snippet' doesn't work > > 3)Zebra: 2.0.59. Repos: Koha only. MARC type: MARC21 > -- 'elements zebra::snippet' WORKS > > 4)Zebra: 2.0.59. Repos: Koha only. MARC type: UNIMARC > -- 'elements zebra::snippet' WORKS > > So the problem is not connect with MARC21/UNIMARC. > > David says that on OpenSuse Zebra 2.0.60 is ok about 'elements > zebra::snippet'. > > It is not clear if it is a Debian 8 problem or an error on Zebra 2.0.61 > > I try to ask in Zebra mailing list. > > Bye > Zeno Tajoli > > > > > > -- > Zeno Tajoli > / SVILUPPO PRODOTTI/ - Automazione Biblioteche > Email: z.tajoli at cineca.it Fax: 051/6132198 > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From dcook at prosentient.com.au Thu Jan 28 03:18:26 2016 From: dcook at prosentient.com.au (David Cook) Date: Thu, 28 Jan 2016 13:18:26 +1100 Subject: [Koha-devel] Problems when using Indexdata's Zebra deb packages on Debian Jessie Message-ID: <020101d15972$2bfe3980$83faac80$@prosentient.com.au> Hi all, As Zeno Tajoli has mentioned on the "Zebra: the 'elements zebra::snippet'" thread, there are problems using Indexdata's apt repository for Zebra on Debian Jessie. It looks to me that the problems arise from YAZ 5.8.1 onwards, although YAZ 5.15.2 is the version at which we're looking. But the problem might not be with YAZ/Zebra per se. It seems to me that the problem is actually with our Zebra configuration files. Namely retrieval-info-bib-dom.xml, but also marc21-retrieval-info-bib-dom.xml, normarc-retrieval-info-bib-dom.xml, and unimarc-retrieval-info-bib-dom.xml (in debian/templates), which are used by the Debian packages. We define many front-end elements using , but we don't really need to do that. We can just use . That gives us access to the elements we define in retrieve pipeline in the etc/zebradb/biblios/etc/dom-conf.xml file, as well as the special retrieval zebra::* elements. It seems that doesn't work with Zebra 2.0.61 (or I suspect more accurately recent versions of YAZ). I suspect that Zebra/YAZ is looking in etc/zebradb/biblios/etc/dom-conf.xml for the element names and failing without realizing that it's actually a special retrieval element built-in to Zebra/YAZ. All is fixed if we remove the and restart Zebra. Personally, I think we should remove all the lines and just use . That's worked on Zebra 2.0.61/YAZ 5.15.2 on Debian 8, and Zebra 2.0.60/YAZ 5.1.2 on openSUSE 13.2. I suppose the thing to do now is just open a Bugzilla bug and fix it, but I thought I'd give a more succinct FYI than I gave in my reply to Zeno (outlined below). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > From: David Cook [mailto:dcook at prosentient.com.au] > Sent: Thursday, 28 January 2016 12:59 PM > To: 'Tajoli Zeno' > Cc: 'koha-devel' ; 'Wolfram > Schneider' > Subject: RE: [Koha-devel] [SOLVED] Zebra: the 'elements zebra::snippet' > doesn't work > > Hi Zeno: > > I believe that I've solved the symptom, although I admit that I don't 100% > understand the root casue of the problem. > > The problem appears to be the line ' name="zebra::*" />' in "etc/zebradb/retrieval-info-bib-dom.xml". > > If you remove that and restart Zebra for your instance, you'll find that you're > once again able to use "zebra::index", "zebra::snippet", "zebra::data", > "zebra::facet::index:register:count". > > The in-depth explanation starts here: > > The vital line really is ''. With that line, we have > access to the special retrieval elements > (http://www.indexdata.com/zebra/doc/special-retrieval.html), as well as > the ones that we've defined in the "retrieve pipeline" in > /etc/koha/zebradb/biblios/etc/dom-config.xml, such as "zebra", "index", > "marc", and "marcxml". (See /etc/koha/sites/libraryname/zebra-biblios- > dom.cfg for the reference to /etc/koha/zebradb/biblios/etc/dom- > config.xml. Also see http://www.indexdata.com/zebra/doc/record-model- > domxml-pipeline.html for an explanation of the pipeline: "The possible > multiple pipeline definitions are distinguished by their unique > name attributes, these are the literal schema or element set names used in > SRW, SRU and Z39.50 protocol queries."). > > I'm going to guess that the problem arose with YAZ 5.8.1 2015/01/13: > "retrieval: pick matched element-set rule YAZ-813" > (http://www.indexdata.com/yaz/doc/NEWS). Here's the git commit: > http://git.indexdata.com/?p=yaz-moved-to- > github.git;a=commit;h=f24766f1e9fc5404fc0b512af8607d7f7054f4be. I > haven't read through it extensively, so I could be wrong, but perhaps it > caused some sort of problem where Zebra/YAZ was trying to find "zebra::*" > in /etc/koha/zebradb/biblios/etc/dom-config.xml. I'm guessing that it didn't > check that it was a special retrieval element and that it failed to find the > backend element in the retrieve pipeline, and that's why it failed. > > We don't actually need any of the following lines: > > identifier="info:srw/schema/1/marcxml-v1.1"/> > identifier="info:srw/schema/1/marcxml-v1.1"/> > > > The only thing we need is . That provides access to > the "marc", "marcxml", "zebra", and "index" backends defined in > /etc/koha/zebradb/biblios/etc/dom-config.xml, as well as the zebra::* > special retrieval elements. > > I've actually tested that on YAZ 5.1.2 and Zebra 2.0.60 on openSUSE, and it > works great. > > I suppose the thing to do at this point is open a Bugzilla report to change > "etc/zebradb/retrieval-info-bib-dom.xml", as well as "marc21-retrieval-info- > bib-dom.xml", "normarc-retrieval-info-bib-dom.xml", and "unimarc- > retrieval-info-bib-dom.xml". > > -- > Installed Koha and Zebra on Debian Jessie using packages from scratch: > sudo ls > wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key > add - echo 'deb http://debian.koha-community.org/koha oldstable main' | > sudo tee /etc/apt/sources.list.d/koha.list sudo apt-get update sudo apt-get > install koha-common > -- > sudo apt-get install mysql-server > > sudo a2enmod > rewrite sudo a2enmod cgi sudo service apache2 restart echo 'deb > http://ftp.indexdata.dk/debian jessie main' | sudo tee > /etc/apt/sources.list.d/indexdata.list > sudo apt-get update > -- > sudo apt-get install libidzebra-2.0 > > sudo koha-create --create-db libraryname sudo a2dissite 000-default.conf > sudo vi /etc/apache2/ports.conf sudo service apache2 > restart > > sudo xmlstarlet sel -t -v 'yazgfs/config/user' > /etc/koha/sites/libraryname/koha-conf.xml > sudo xmlstarlet sel -t -v 'yazgfs/config/pass' > /etc/koha/sites/libraryname/koha-conf.xml > > > > > > > yaz-client unix:/var/run/koha/libraryname/bibliosocket > base biblios > find test > [109] Database unavailable -- v2 addinfo 'biblios' > > base biblios > find test > Number of hits: 1, setno 3 > show 1 > > format xml > show 1 > > elements zebra::snippet > show 1 > [25] Specified element set name not valid for specified database -- v2 > addinfo '' > elements index > show 1 > > elements marcxml > ehow 1 > > elements marc > > -- > elements zebra > show 1 > [biblios]Record type: XML > > z:filename="/tmp/yIjODFCwAP/upd_biblio/exported_records" z:rank="0" > z:score="" z:schema="zebra" z:size="938"/> > -- > sudo vi /etc/koha/marc21-retrieval-info-bib-dom.xml > > sudo koha-restart-zebra libraryname > > Z> elements zebra::snippet > Z> show 1 > Sent presentRequest (1+1). > Records: 1 > Record type: XML > > test > This is a test > nextResultSetPosition = 2 > Elapsed: 0.001125 > > Z> elements zebra::facet::title:w > Z> show 1 > Sent presentRequest (1+1). > Records: 1 > Record type: XML > > > a > is > test > this > > > > I had suspected in the past that we might be re-defining retrieval elements in > the /etc/koha/marc21-retrieval-info-bib-dom.xml file... and this appears to > confirm it. > > > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St, Ultimo, NSW 2007 > > > > -----Original Message----- > > From: Tajoli Zeno [mailto:z.tajoli at cineca.it] > > Sent: Thursday, 28 January 2016 4:16 AM > > To: David Cook > > Cc: koha-devel > > Subject: Re: [Koha-devel] Zebra: the 'elements zebra::snippet' doesn't > > work > > > > Hi David and all, > > > > Il 27/01/2016 06:19, Zeno Tajoli ha scritto: > > >> Did you load an old Koha configuration and database? Or did you > > >> start > > fresh? > > >> You might need to do a Zebra re-index and a Zebra re-start. > > > > > > It is a start from fresh install and I do same Zebra re-index and a > > > Zebra re- > > start. > > > But now I try starting from a fresh debian 8 and I will say the result. > > > > I finish my test about 'elements zebra::snippet'. > > I have done 4 different installation on debian 8 (jessie) In every case: > > Install type: koha-common > > OS: Debian 8 (jessie) > > Lang: en > > Koha versione: 3.20.7.1 (oldstable) > > > > 1)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: MARC21 > > -- 'elements zebra::snippet' doesn't work > > > > 2)Zebra: 2.0.61. Repos: Indexdata and Koha. MARC type: UNIMARC > > -- 'elements zebra::snippet' doesn't work > > > > 3)Zebra: 2.0.59. Repos: Koha only. MARC type: MARC21 > > -- 'elements zebra::snippet' WORKS > > > > 4)Zebra: 2.0.59. Repos: Koha only. MARC type: UNIMARC > > -- 'elements zebra::snippet' WORKS > > > > So the problem is not connect with MARC21/UNIMARC. > > > > David says that on OpenSuse Zebra 2.0.60 is ok about 'elements > > zebra::snippet'. > > > > It is not clear if it is a Debian 8 problem or an error on Zebra > > 2.0.61 > > > > I try to ask in Zebra mailing list. > > > > Bye > > Zeno Tajoli > > > > > > > > > > > > -- > > Zeno Tajoli > > / SVILUPPO PRODOTTI/ - Automazione Biblioteche > > Email: z.tajoli at cineca.it Fax: 051/6132198 > > *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI) From julian.maurice at biblibre.com Thu Jan 28 08:50:46 2016 From: julian.maurice at biblibre.com (Julian Maurice) Date: Thu, 28 Jan 2016 08:50:46 +0100 Subject: [Koha-devel] RFC: Allow to reserve first available item from a group of titles Message-ID: <56A9C856.7080400@biblibre.com> Hi, I'm working on this new feature but I have some concerns about its implementation. I made a small, proof-of-concept, patch, and would love to have some feedback before continuing to work on it. It's in bug 15516 [1] and my concerns are described there, next to the test plan :) Thanks. [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 -- Julian Maurice BibLibre From M.de.Rooy at rijksmuseum.nl Thu Jan 28 09:10:58 2016 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 28 Jan 2016 08:10:58 +0000 Subject: [Koha-devel] RFC: Allow to reserve first available item from a group of titles In-Reply-To: <56A9C856.7080400@biblibre.com> References: <56A9C856.7080400@biblibre.com> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA315B01D5E2@S-MAIL-1B.rijksmuseum.intra> Brave plan :) I am just wondering if the benefits of this new group reserve concept will outweigh the costs for additional complexity in code that is already hard to maintain and should be moved/refactored. Note that holds are affected by a lot of preferences (with interesting combinations) that will need to be tested against these changes. Compare that against the fact that currently a user can already place a hold on these three titles he wants. And could cancel the other two holds as soon as the first available is waiting for pickup. Instead of adding the group, could you just make it easier for the user to place those three holds on the same title in multiple biblios? Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Julian Maurice Verzonden: donderdag 28 januari 2016 8:51 Aan: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] RFC: Allow to reserve first available item from a group of titles Hi, I'm working on this new feature but I have some concerns about its implementation. I made a small, proof-of-concept, patch, and would love to have some feedback before continuing to work on it. It's in bug 15516 [1] and my concerns are described there, next to the test plan :) Thanks. [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 -- Julian Maurice BibLibre _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From julian.maurice at biblibre.com Fri Jan 29 09:36:20 2016 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 29 Jan 2016 09:36:20 +0100 Subject: [Koha-devel] RFC: Allow to reserve first available item from a group of titles In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA315B01D5E2@S-MAIL-1B.rijksmuseum.intra> References: <56A9C856.7080400@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA315B01D5E2@S-MAIL-1B.rijksmuseum.intra> Message-ID: <56AB2484.2070705@biblibre.com> The main benefit of this feature is to not have to cancel manually each other hold, and to avoid having a copy of each title being set to "waiting for pickup" status at the same time, so I don't think I can drop this. But it can be interesting to know how you think we can make placing multiple holds easier. Actually, what I do is: - search - check, check, check - place hold link - confirm Le 28/01/2016 09:10, Marcel de Rooy a ?crit : > Brave plan :) > I am just wondering if the benefits of this new group reserve concept will outweigh the costs for additional complexity in code that is already hard to maintain and should be moved/refactored. > Note that holds are affected by a lot of preferences (with interesting combinations) that will need to be tested against these changes. > > Compare that against the fact that currently a user can already place a hold on these three titles he wants. And could cancel the other two holds as soon as the first available is waiting for pickup. > Instead of adding the group, could you just make it easier for the user to place those three holds on the same title in multiple biblios? > > Marcel > > -----Oorspronkelijk bericht----- > Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Julian Maurice > Verzonden: donderdag 28 januari 2016 8:51 > Aan: koha-devel at lists.koha-community.org > Onderwerp: [Koha-devel] RFC: Allow to reserve first available item from a group of titles > > Hi, > > I'm working on this new feature but I have some concerns about its implementation. > I made a small, proof-of-concept, patch, and would love to have some feedback before continuing to work on it. > It's in bug 15516 [1] and my concerns are described there, next to the test plan :) > > Thanks. > > [1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 > > -- > Julian Maurice BibLibre _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ > -- Julian Maurice BibLibre From laurent.ducos at biblibre.com Fri Jan 29 14:39:01 2016 From: laurent.ducos at biblibre.com (Laurent Ducos) Date: Fri, 29 Jan 2016 13:39:01 +0000 Subject: [Koha-devel] Jenkins (we want to move the server) In-Reply-To: References: <56A1EE53.1060803@biblibre.com> <56A5E2E9.9000609@biblibre.com> <1da148737b99aab93bd5ce4b03db2b2f@webmail.biblibre.com> Message-ID: <01a3ee577734db9654e1e866457302cd@webmail.biblibre.com> Hello. Here is the plan to move the server. 1 : redirect via proxy pass on the actual server to new server, server Monday 1 at 9 h am french hour. (please no job on jenkins) ? 1a : check all is OK 2 : migrate dns , the new IP is 212.47.240.49 galen can you do it? maybe Tuesday 2. 3 by by old server. 4 i'ts possible to create a TLS certificat for https transaction ? CN jenkins.koha-community.org? ?? -> galen again ??? Thanks Chris for the jekins admin access. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bargioni at pusc.it Fri Jan 29 15:04:08 2016 From: bargioni at pusc.it (Stefano Bargioni) Date: Fri, 29 Jan 2016 15:04:08 +0100 Subject: [Koha-devel] OAI service for Authorities In-Reply-To: <56A8FCDD.8010501@gmail.com> References: <56A8FCDD.8010501@gmail.com> Message-ID: <0BFD7830-DD6D-46C1-96BE-B8B6ECCED769@pusc.it> Hi, Harry: this sounds very interesting for library consortia. And maybe for the "RFC for a really new stuff : sharing data worldwide" launched by Paul Poulain some days ago. And what about an RDF output, for linked data environments? Stefano > On 27 gen 2016, at 18:22, Dhd Koha (grharry) wrote: > > Hi List, > I'm wondering if there is an OAI service providing authorities records. > > Please correct me if I am wrong. > Browsing through the code, implementation would involve some SQL code I presume?? > > Kind Regards, > Harry > > > > _______________________________________________ > 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 akafortes at gmail.com Fri Jan 29 15:17:33 2016 From: akafortes at gmail.com (akafortes) Date: Fri, 29 Jan 2016 07:17:33 -0700 (MST) Subject: [Koha-devel] Staff Client Normal View details Message-ID: <1454077053891-5872284.post@n5.nabble.com> Hello everyone, I'd like to ask if it is possible to add the value of a MARC field as a label in one of the Normal view fields. I use the "UNIMARCslim2intranetDetail.xsl". And I have something like this: 700 Main Author Which in the Normal View, on the Staff Client would Display: Main Author: Author's Name from 700 I use the 700$4 to store a code that Identifies, in a way, what that person is. I use a list of authorized value of this form: Value Description 005 Actor 070 Author . . . What I'd like to do is something like this: 700 700$4 Description So for example if record has "Author" in the 700$4 then I'd want the normal view to display that as a label Can anyone please tell me if: 1) is this possible to be done? 2) if it is possible, how would I go about doing it? Thank you very much -- View this message in context: http://koha.1045719.n5.nabble.com/Staff-Client-Normal-View-details-tp5872284.html Sent from the Koha-devel mailing list archive at Nabble.com. From kohanews at gmail.com Sat Jan 30 05:30:58 2016 From: kohanews at gmail.com (kohanews) Date: Fri, 29 Jan 2016 20:30:58 -0800 Subject: [Koha-devel] Koha Community Newsletter: January 2016 Message-ID: <56AC3C82.30006@gmail.com> Fellow Koha users: The Koha Community Newsletter for January 2016 is here: https://koha-community.org/koha-community-newsletter-january-2016/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: