From kohanews at gmail.com Fri Feb 1 04:44:54 2019 From: kohanews at gmail.com (kohanews) Date: Thu, 31 Jan 2019 19:44:54 -0800 Subject: [Koha-devel] Koha Community Newsletter: January 2019 Message-ID: <80591d81-170c-0f2f-4791-9df16cb26570@gmail.com> The Koha Community Newsletter for January 2019 is here: https://koha-community.org/koha-community-newsletter-january-2019/ 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. -- Chad Roseburg Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Feb 4 01:02:46 2019 From: dcook at prosentient.com.au (David Cook) Date: Mon, 4 Feb 2019 11:02:46 +1100 Subject: [Koha-devel] Overdue maybe not going out for a checkout after item branch changed after checkout Message-ID: <020a01d4bc1c$f5a5ffb0$e0f1ff10$@prosentient.com.au> Hi all, I found a scenario where it seems overdues were't going out for a checkout/issue that had a branch that no longer exists in Koha. The item itself belonged to a new branch, and the branch used to check it out had been deleted. There's no referential integrity between the issue table and the branches table, so nothing would've happened there automatically. Looking at the code for overdue notices (which was terrifyingly long and in need of a refactor), it seemed like maybe it would've been fine that the issue didn't have an existing branch (because the overdue rules table entries still existed for the old branch), but. in the end it wasn't worth the time chasing down this edge case. I thought I'd share the experience here though just in case someone else had experienced this issue or was scrambling to explain the same behaviour. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Feb 4 07:10:25 2019 From: dcook at prosentient.com.au (David Cook) Date: Mon, 4 Feb 2019 17:10:25 +1100 Subject: [Koha-devel] zebraidx with 1 large MARC file rather than many small MARC files Message-ID: <028801d4bc50$51d0a1e0$f571e5a0$@prosentient.com.au> Hi all, I haven't looked into it too deeply, but I was curious if Zebra would have better performance indexing with 1 large MARC file versus many small MARC files. At the moment, we generate 1 huge MARC file and then pass that to zebraidx as an argument. Is that something we've always done or was it done as a performance enhancement? I haven't looked at the Zebra internals to see whether it reads the entire file into memory and then processes it or if it parses the XML using a stream reader. Zebraidx can also take a list of files from stdin*, but if you had tonnes of small files that could be troublesome. I suppose it doesn't matter too much as we march on to ElasticSearch, but I figure lots of people are using Zebra still and probably will for a long time, so perhaps worth thinking about. https://software.indexdata.com/zebra/doc/zebraidx.html David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Feb 4 07:24:52 2019 From: dcook at prosentient.com.au (David Cook) Date: Mon, 4 Feb 2019 17:24:52 +1100 Subject: [Koha-devel] zebraidx with 1 large MARC file rather than many small MARC files In-Reply-To: <028801d4bc50$51d0a1e0$f571e5a0$@prosentient.com.au> References: <028801d4bc50$51d0a1e0$f571e5a0$@prosentient.com.au> Message-ID: <029201d4bc52$568a2060$039e6120$@prosentient.com.au> To answer my own question. I have a zebraidx running on 461MB (or 77000 records) and it's only using 2% of memory on a 4GB system, so I'm thinking it is using a stream reader and updating the shadow files on disk as it goes through the massive MARC file. In that case, while it might be slow to export records to that file, zebraidx probably does read 1 large file much faster than many small files. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of David Cook Sent: Monday, 4 February 2019 5:10 PM To: 'Koha Devel' Cc: tomascohen at theke.io Subject: [Koha-devel] zebraidx with 1 large MARC file rather than many small MARC files Hi all, I haven't looked into it too deeply, but I was curious if Zebra would have better performance indexing with 1 large MARC file versus many small MARC files. At the moment, we generate 1 huge MARC file and then pass that to zebraidx as an argument. Is that something we've always done or was it done as a performance enhancement? I haven't looked at the Zebra internals to see whether it reads the entire file into memory and then processes it or if it parses the XML using a stream reader. Zebraidx can also take a list of files from stdin*, but if you had tonnes of small files that could be troublesome. I suppose it doesn't matter too much as we march on to ElasticSearch, but I figure lots of people are using Zebra still and probably will for a long time, so perhaps worth thinking about. https://software.indexdata.com/zebra/doc/zebraidx.html David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur.suzuki at biblibre.com Mon Feb 11 09:21:55 2019 From: arthur.suzuki at biblibre.com (Arthur Suzuki) Date: Mon, 11 Feb 2019 09:21:55 +0100 Subject: [Koha-devel] Fwd: Newbies at Biblibre! Message-ID: <2865946.4YYVc4cdro@localhost.localdomain> Wrong start... Now sent to the proper mailing list ;) Have a nice one, Arthur ---------- Message transmis ---------- Objet : [Koha-devel] Newbies at Biblibre! Date : jeudi 7 f?vrier 2019, 17 h 14 min 11 s CET De : Arthur ? : koha-devel at nongnu.org Hello World :) Some of you may already know me from a previous position in Lyon 3 Uni where I've been working a bit with Koha already and made a use case for the plugin system implemented by Kyle Hall : https://github.com/liliputech/ koharecommenderengine I'm very happy to announce that I've been hired since the 4th of February at Biblibre where I'll take a Support Developper position. Thank you Biblibre for this opportunity to connect back with the Koha community after one year of unavailability! Back to the source ;) I'll be mainly focusing on interactions between Koha and Bokeh, a library- oriented CMS with Opac functionnality. Wish everyone a nice day and hopefully see you around soon! Arthur Suzuki - now a Biblibre employee ----------------------------------------- -------------- section suivante -------------- Une pi?ce jointe autre que texte a ?t? nettoy?e... Nom: signature.asc Type: application/pgp-signature Taille: 488 octets Desc: This is a digitally signed message part. URL: From kohanews at gmail.com Thu Feb 14 21:14:16 2019 From: kohanews at gmail.com (kohanews) Date: Thu, 14 Feb 2019 12:14:16 -0800 Subject: [Koha-devel] Call for News: February 2019 Newsletter Message-ID: <3dea4e4c-7979-dd6b-53bc-c6c4be94e243@gmail.com> I'm collecting news for the February 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. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter From jonathan.druart at bugs.koha-community.org Thu Feb 14 23:19:06 2019 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Thu, 14 Feb 2019 19:19:06 -0300 Subject: [Koha-devel] Anyone else seeing "Reference is already weak" in their error logs? In-Reply-To: <007d01d4a6eb$4c489ea0$e4d9dbe0$@prosentient.com.au> References: <007d01d4a6eb$4c489ea0$e4d9dbe0$@prosentient.com.au> Message-ID: Hi David, Never seen it. Which versions of Koha and Template::Plugin::Filter? Which url is hit? See also https://github.com/abw/Template2/issues/206 (?) Cheers, Jonathan Le lun. 7 janv. 2019 ? 21:44, David Cook a ?crit : > > Hi all, > > > > My Apache CGI OPAC is generating a huge number of the following error: > > > > Reference is already weak at /usr/lib/perl5/site_perl/5.26.1/x86_64-linux-thread-multi/Template/Plugin/Filter.pm line 68 > > > > Is anyone else getting these? > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > _______________________________________________ > 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 Feb 15 00:36:10 2019 From: dcook at prosentient.com.au (David Cook) Date: Fri, 15 Feb 2019 10:36:10 +1100 Subject: [Koha-devel] Anyone else seeing "Reference is already weak" in their error logs? In-Reply-To: References: <007d01d4a6eb$4c489ea0$e4d9dbe0$@prosentient.com.au> Message-ID: <002101d4c4be$10c80000$32580000$@prosentient.com.au> Hi Jonathan, Thanks for your email. It's affecting every version of Koha (e.g. 17.05, 18.11) Template::Plugin::Filter version is 1.38 (Template is version 2.28 which appears to be the most recent version from October 2018). It seems to happen for every URL hit on OPAC or Staff Client. "Reference is already weak at /usr/lib/perl5/site_perl/5.26.1/x86_64-linux-thread-multi/Template/Plugin/Filter.pm line 68" Based on that link you sent, it looks like a spurious warning from Template::Plugin::Filter then. If you're not seeing it, I imagine it must be a bug in versions newer than 2.22. Thanks for following up with me! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: Jonathan Druart [mailto:jonathan.druart at bugs.koha-community.org] Sent: Friday, 15 February 2019 9:19 AM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Anyone else seeing "Reference is already weak" in their error logs? Hi David, Never seen it. Which versions of Koha and Template::Plugin::Filter? Which url is hit? See also https://github.com/abw/Template2/issues/206 (?) Cheers, Jonathan Le lun. 7 janv. 2019 ? 21:44, David Cook a ?crit : > > Hi all, > > > > My Apache CGI OPAC is generating a huge number of the following error: > > > > Reference is already weak at > /usr/lib/perl5/site_perl/5.26.1/x86_64-linux-thread-multi/Template/Plu > gin/Filter.pm line 68 > > > > Is anyone else getting these? > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > _______________________________________________ > 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 Feb 15 00:54:59 2019 From: dcook at prosentient.com.au (David Cook) Date: Fri, 15 Feb 2019 10:54:59 +1100 Subject: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day In-Reply-To: <9f02d5c8cbb64c31b50136ea4ba1a7fb@nExchange2.hsg.intra> References: <344c9c7da48f469781a743c54c093c7f@nExchange2.hsg.intra> <9f02d5c8cbb64c31b50136ea4ba1a7fb@nExchange2.hsg.intra> Message-ID: <002801d4c4c0$b189ccb0$149d6610$@prosentient.com.au> Just letting folk know that I've refactored the logic for the autorenewals at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22333. It's the exact same behaviour as before but it deduplicates some code by using an existing function and it just writes it in a way that is more readable/maintainable. Locally, I've also duplicated a section of the code into automatic_renewals.pl (and wrapped it with a system preference) so that the first thing checked is the earliest renewal date and if it's in the future, then I skip CanBookBeRenewed all together (so as to avoid the issues with holds, max checkouts, etc causing confusing email notices to go out). After some local testing, I'll post a patch with that too, which hopefully will meet everyone's needs between the current behaviour and what I (and some others) consider the more logical behaviour. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Holger Meissner Sent: Tuesday, 11 December 2018 9:30 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Autorenewals renewing an item then sending a renew failure email the next day On Mon, Dec 10, 2018 at 06:02 PM McGowan, Janet wrote: > Yes, using the PREDUE notice is a way around this, however it would > only work if No renewal before is set to 1. I disagree. For example, we set "no renewal before" to 11 days and send PREDUE 10 days in advance. We locally prevent patrons from changing that setting. Nobody complained about it so far. A more elegant and more user-friendly solution would be a feature enforcing PREDUE <= no renewal before. Or maybe just a warning popup for spam producing values. Regards, Holger _______________________________________________ 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 Feb 15 03:12:36 2019 From: dcook at prosentient.com.au (David Cook) Date: Fri, 15 Feb 2019 13:12:36 +1100 Subject: [Koha-devel] Limits cannot contain parentheses Message-ID: <004801d4c4d3$eb02f490$c108ddb0$@prosentient.com.au> Hi all, I noticed that the CCL2RPN parser throws fatal errors when limits have parentheses in them. I have a fix for it (described at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22344), but it makes for an escaped $limit_cgi and an ugly $limit_desc. It doesn't break anything, but it's not aesthetically pleasing. Would people prefer an ugly fix that is easy to implement, or a more beautiful but difficult to implement fix? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.grousset at biblibre.com Mon Feb 18 18:32:48 2019 From: victor.grousset at biblibre.com (Victor Grousset) Date: Mon, 18 Feb 2019 18:32:48 +0100 Subject: [Koha-devel] makePreviousSerialAvailable: should we not touch the itype of the subscription.previousitemtype is invalid? Message-ID: Hi, :) Can someone confirm that bug 20461 doesn't prevent to create subscriptions that will create items with invalid itypes? https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20461#c15 If so, then we could ignore previousitemtype when it's invalid. To not corrupt items when has been forgotten or to handle the existing data which didn't had a previousitemtype due to bug 20461. For some reason I'm very confused by this issue and have a very varying understanding of it. That's why it seems wiser to ask for a confirmation before preparing a follow up :) Cheers, -- Victor Grousset, dev support/maintenance BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Libre/Open Source software and services for libraries From skhild at yahoo.co.nz Wed Feb 20 09:08:50 2019 From: skhild at yahoo.co.nz (Steven Hill) Date: Wed, 20 Feb 2019 08:08:50 +0000 (UTC) Subject: [Koha-devel] New User Trying to Run Koha as Localhost In-Reply-To: <1802945549.1411840.1550562824421@mail.yahoo.com> References: <1802945549.1411840.1550562824421.ref@mail.yahoo.com> <1802945549.1411840.1550562824421@mail.yahoo.com> Message-ID: <839098622.2069523.1550650130642@mail.yahoo.com> Hello everyone, I am trying to install and run Koha on my laptop at home.? My laptop has Ubuntu 16.04 and Windows 10 installed on it with a dual boot option. I am a computer programmer who has worked on a browser based library management system in the past so I am familiar with most of the concepts and steps here.? Although the system I worked on only ran on Windows we did use Apache on some sites so I am also familiar with configuring Apache.? My intention is to initially run it on my computer as "localhost" while I familiarise myself with it. I have gone through the process of installation as detailed on wiki.koha-community.org/wiki/Debian without error as far as: "Access the web interface". So to summarise my system has: Ubuntu 16.04 LTSKoha 18.11 current stableMySQL database I have completed the following steps without error: 1. Install Koha2. Install the database (MySQL)3. Configure the defaults4. Create a Koha instance The next step "Access the web interface" did not work. At this point I get the standard 'Apache2 Ubuntu Default Page' telling me that Apache is working but the site may be down for maintenance etc. My koha-sites.conf file has:DOMAIN=".localhost" It seems to me that there is a configuration directive to find the Koha default.html or index.html that is missing or looking in the wrong place.? Can anyone help me find where this configuration directive is or tell me what I'm doing wrong.? I imagine it is something very simple. Thank you very much -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.graham4 at herts.ac.uk Wed Feb 20 12:25:26 2019 From: s.graham4 at herts.ac.uk (Stephen Graham) Date: Wed, 20 Feb 2019 11:25:26 +0000 Subject: [Koha-devel] Circulation API Question Message-ID: Hi All - we have a locally developed mobile app. It's mainly used for stuff like campus wayfinding, but there is also a notifications section. We are thinking of adding Koha notifications to this area - e.g. if the user needs to return a book because there is a reservation and/or it's reached max renewals, if there is a reservation for them to collect etc. I just trying to get a feel for the best way of doing this - using one of the Koha API services. We are currently on 17.11. I'm looking at https://wiki.koha-community.org/wiki/APIs_and_protocols_supported_by_Koha , and there are two possible methods that jump out at me: * ILS-DI * Restful HTTP Service/HTTP API (not sure where the RESTful service is up to development wise, but I don't think we have the https://wiki.koha-community.org/wiki/Koha_/svc/_HTTP_API service set up on our Koha) We could always write our own solution, but would rather use a Koha "supported" one. At the moment it looks like we might use the ILD-DI method. Are there any other recommend/better ways? Cheers, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.grousset at biblibre.com Wed Feb 20 15:38:59 2019 From: victor.grousset at biblibre.com (Victor Grousset) Date: Wed, 20 Feb 2019 15:38:59 +0100 Subject: [Koha-devel] Serial: numbering patterns: how to make it more clear that months and weekdays start from 0 ? Message-ID: Hi :) , That might not be clear, even for developer, and even less for a librarian. How could this info be delivered reliably to the user? To avoid running in circle during too long before realizing that? Even more hard to understand when there are cases like biannual where if you start from February, it will work even if you assumed that January was 1. But if you start from February, there will be issues after one year. Should there be tooltips? The related fields are marked with a red dot in the following screenshot. https://framapic.org/4P2ZzbgJpuvA/SIleKzEuYVaG.png Cheers, -- Victor Grousset, dev support/maintenance BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Libre/Open Source software and services for libraries From giuseppe.ciaccio at unige.it Wed Feb 20 16:06:14 2019 From: giuseppe.ciaccio at unige.it (giuseppe) Date: Wed, 20 Feb 2019 08:06:14 -0700 (MST) Subject: [Koha-devel] search result list is void of information Message-ID: <1550675174603-0.post@n5.nabble.com> Hello all, (already posted on koha-general, but maybe here a better place -- sorry for possible cross postings -- I will file a bug report if nothing happens here too) I've replaced an old Koha 17.11 by a fresh install of Koha 18.11 (on a fresh install of Debian 9.7 64bit). After install, as superlibrarian I successfully populated the DB with sample records including a couple of items, for test purposes. Afterwards, as normal user I tried a search for a keyword matching more than one record, and thus I got a list of search results. The list is correct, but, as you can see, each entry is void of textual information -- no title/author/etc. . If I click on the "image preview" of one single entry (not visible in the screenshot) I get access to the full info of that entry, which shows correct. But the search results void of textual information is uninformative for a user. This misbehaviour is also present in Koha 18.05 but not in Koha 17.11. Is this just a matter of misconfiguration? What should I do to restore the original behaviour? Thank you. -- Sent from: http://koha.1045719.n5.nabble.com/Koha-devel-f3063671.html From marka at pobox.com Wed Feb 20 19:26:21 2019 From: marka at pobox.com (Mark Alexander) Date: Wed, 20 Feb 2019 13:26:21 -0500 Subject: [Koha-devel] New User Trying to Run Koha as Localhost In-Reply-To: <839098622.2069523.1550650130642@mail.yahoo.com> References: <1802945549.1411840.1550562824421.ref@mail.yahoo.com> <1802945549.1411840.1550562824421@mail.yahoo.com> <839098622.2069523.1550650130642@mail.yahoo.com> Message-ID: <1550686441-sup-1238@x201s> Excerpts from Steven Hill's message of 2019-02-20 08:08:50 +0000: > The next step "Access the web interface" did not work. > At this point I get the standard 'Apache2 Ubuntu Default Page' telling me that Apache is working but the site may be down for maintenance etc. There are several things you might want to check. Look at /etc/apache2/sites-available/INSTANCE.conf, where INSTANCE is your Koha instance name. In particular, check the port numbers in the VirtualHost lines. Make sure that those ports are listed in separate Listen statements in /etc/apache2/ports.conf . Then check the port number in /etc/apache2/sites-available/000-default.conf, by examining the VirtualHost line. It will probably be port 80, and if that is the same as one of the ports used by Koha, you'll either need to change the ports used by Koha, or disable 000-default.conf by using the a2dissite command. Make sure that the Koha site is enabled by using the a2ensite command. You'll need to restart Apache after making any configuration changes. This is probably done using 'systemctl restart apache2'. (I hope this helps, but I'm not an Apache expert, and all of my experience is on Debian 8/9, so I may have missed something specific or relevant to Apache or Ubuntu in the above.) From dcook at prosentient.com.au Thu Feb 21 00:14:16 2019 From: dcook at prosentient.com.au (David Cook) Date: Thu, 21 Feb 2019 10:14:16 +1100 Subject: [Koha-devel] New User Trying to Run Koha as Localhost In-Reply-To: <1550686441-sup-1238@x201s> References: <1802945549.1411840.1550562824421.ref@mail.yahoo.com> <1802945549.1411840.1550562824421@mail.yahoo.com> <839098622.2069523.1550650130642@mail.yahoo.com> <1550686441-sup-1238@x201s> Message-ID: <03be01d4c971$ffe1c2e0$ffa548a0$@prosentient.com.au> I'd say the key here is not to think about it as a Koha problem so much as an Apache problem. If you're getting the default "Apache2 Ubuntu Default Page" page, that just means that Apache can't match the hostname you're supplying with the ServerName directive in the VirtualHost found in a configuration file in /etc/apache2/sites-available/.conf file. (Disabling the 000-default.conf file might work but that just means Apache is blindly handing your Koha site out as the default site on port 80. I wouldn't recommend doing that.) Take a look at your /etc/apache2/sites-available/.conf file and double-check the ServerName directive. You can either change the directive there or you can try to change the koha-sites.conf file and re-create your instance. Based on your description, I'm guessing your ServerName is going to be something like "INSTANCE.localhost" and you're going to "localhost" or "localhost.localhost" in the browser? You can either change the ServerName or you could add "INSTANCE.localhost" to your /etc/hosts so that it resolves correctly. (Although keep in mind it'll only work on your machine.) For what it's worth, this is the step that trips up everybody new to Koha. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Mark Alexander Sent: Thursday, 21 February 2019 5:26 AM To: koha-devel Subject: Re: [Koha-devel] New User Trying to Run Koha as Localhost Excerpts from Steven Hill's message of 2019-02-20 08:08:50 +0000: > The next step "Access the web interface" did not work. > At this point I get the standard 'Apache2 Ubuntu Default Page' telling me that Apache is working but the site may be down for maintenance etc. There are several things you might want to check. Look at /etc/apache2/sites-available/INSTANCE.conf, where INSTANCE is your Koha instance name. In particular, check the port numbers in the VirtualHost lines. Make sure that those ports are listed in separate Listen statements in /etc/apache2/ports.conf . Then check the port number in /etc/apache2/sites-available/000-default.conf, by examining the VirtualHost line. It will probably be port 80, and if that is the same as one of the ports used by Koha, you'll either need to change the ports used by Koha, or disable 000-default.conf by using the a2dissite command. Make sure that the Koha site is enabled by using the a2ensite command. You'll need to restart Apache after making any configuration changes. This is probably done using 'systemctl restart apache2'. (I hope this helps, but I'm not an Apache expert, and all of my experience is on Debian 8/9, so I may have missed something specific or relevant to Apache or Ubuntu in the above.) _______________________________________________ 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 Feb 21 01:10:52 2019 From: dcook at prosentient.com.au (David Cook) Date: Thu, 21 Feb 2019 11:10:52 +1100 Subject: [Koha-devel] Problems with "LOC" authorized values and tokenization Message-ID: <03cd01d4c979$e8749fd0$b95ddf70$@prosentient.com.au> Hi all, I have a library with lots of problematic data in their "LOC" authorized value codes, and it's led me to a few issues. 1. LOC authorized values can contain "*", "(", and ")" but all of these characters will cause the ZOOM library to fail to compile the CCL2RPN query. 2. mc-loc (from the "Shelving location" tab on /cgi-bin/koha/catalogue/search.pl) seems to be doing an incomplete search. That means if you have two locations like "Big Box" and "Big Box - Drawer", "Big Box" will return items for both locations. The reason for #2 is actually kind of interesting. While the RPN/PQF query is "@attr 1=8013 @attr 4=1 apple_street" and @attr 4=1 represents a "phrase" search, Zebra is actually using the "w" register and not the "p" register. It's because of the "Completeness Attributes (type = 6)": "Incomplete subfield (1) is the default, and makes Zebra use register type="w", whereas Complete field (3) triggers search and scan in index type="p"." (https://software.indexdata.com/zebra/doc/querymodel-rpn.html). If we wanted to actually just get the exact location, we'd want to use "mc-loc,complete-field", but then we'd get Zebra errors because mc-loc doesn't use the "p" type register currently, although that would be easy enough to add. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.a at navalmarinearchive.com Thu Feb 21 01:32:35 2019 From: paul.a at navalmarinearchive.com (Paul A) Date: Wed, 20 Feb 2019 19:32:35 -0500 Subject: [Koha-devel] Problems with "LOC" authorized values and tokenization In-Reply-To: <03cd01d4c979$e8749fd0$b95ddf70$@prosentient.com.au> References: <03cd01d4c979$e8749fd0$b95ddf70$@prosentient.com.au> Message-ID: <4dd60f9c-6fb9-7ca5-ddec-e3f5f1f79503@navalmarinearchive.com> On 2019-02-20 7:10 p.m., David Cook wrote: [snip] > 2.mc-loc (from the ?Shelving location? tab on > /cgi-bin/koha/catalogue/search.pl) seems to be doing an incomplete > search. That means if you have two locations like ?Big Box? and ?Big Box > ? Drawer?, ?Big Box? will return items for both locations. I fully agree -- this problem is getting very close to the top of my list of "things to fix". My analysis (so far) is very close to yours in that it's a question of getting the correct request in, and answer out of, Zebra, but while I am very happy with Zebra, I've never tried (yet) to play with it. Are you suggesting that this would require PERL changes? or can Zebra alone handle modifying a request at input time? Thanks and best regards, Paul > > The reason for #2 is actually kind of interesting. While the RPN/PQF > query is ?@attr 1=8013 @attr 4=1 apple_street? and @attr 4=1 represents > a ?phrase? search, Zebra is actually using the ?w? register and not the > ?p? register. It?s because of the ?Completeness Attributes (type = 6)?: > > ?Incomplete subfield (1) is the default, and makes Zebra use register > type="w", whereas Complete field (3) triggers search and scan in index > type="p".? (https://software.indexdata.com/zebra/doc/querymodel-rpn.html). > > If we wanted to actually just get the exact location, we?d want to use > ?mc-loc,complete-field?, but then we?d get Zebra errors because mc-loc > doesn?t use the ?p? type register currently, although that would be easy > enough to add. > > David Cook From dcook at prosentient.com.au Thu Feb 21 03:42:18 2019 From: dcook at prosentient.com.au (David Cook) Date: Thu, 21 Feb 2019 13:42:18 +1100 Subject: [Koha-devel] Problems with "LOC" authorized values and tokenization In-Reply-To: <4dd60f9c-6fb9-7ca5-ddec-e3f5f1f79503@navalmarinearchive.com> References: <03cd01d4c979$e8749fd0$b95ddf70$@prosentient.com.au> <4dd60f9c-6fb9-7ca5-ddec-e3f5f1f79503@navalmarinearchive.com> Message-ID: <03ef01d4c98f$0fb51920$2f1f4b60$@prosentient.com.au> One solution would be to change "mc-loc" to "mc-loc,ext" (or mc-loc,complete-field) in the Koha template and then to update the Zebra XSLT to index location into the "p" register and do a full re-index (or re-index every record that has items with a location). That would solve the problem. I was thinking of writing a patch, but I have a lot on my plate at the moment. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul A Sent: Thursday, 21 February 2019 11:33 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Problems with "LOC" authorized values and tokenization On 2019-02-20 7:10 p.m., David Cook wrote: [snip] > 2.mc-loc (from the "Shelving location" tab on > /cgi-bin/koha/catalogue/search.pl) seems to be doing an incomplete > search. That means if you have two locations like "Big Box" and "Big > Box - Drawer", "Big Box" will return items for both locations. I fully agree -- this problem is getting very close to the top of my list of "things to fix". My analysis (so far) is very close to yours in that it's a question of getting the correct request in, and answer out of, Zebra, but while I am very happy with Zebra, I've never tried (yet) to play with it. Are you suggesting that this would require PERL changes? or can Zebra alone handle modifying a request at input time? Thanks and best regards, Paul > > The reason for #2 is actually kind of interesting. While the RPN/PQF > query is "@attr 1=8013 @attr 4=1 apple_street" and @attr 4=1 > represents a "phrase" search, Zebra is actually using the "w" register > and not the "p" register. It's because of the "Completeness Attributes (type = 6)": > > "Incomplete subfield (1) is the default, and makes Zebra use register > type="w", whereas Complete field (3) triggers search and scan in index > type="p"." (https://software.indexdata.com/zebra/doc/querymodel-rpn.html). > > If we wanted to actually just get the exact location, we'd want to use > "mc-loc,complete-field", but then we'd get Zebra errors because mc-loc > doesn't use the "p" type register currently, although that would be > easy enough to add. > > David Cook _______________________________________________ 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 ere.maijala at helsinki.fi Thu Feb 21 07:58:25 2019 From: ere.maijala at helsinki.fi (Ere Maijala) Date: Thu, 21 Feb 2019 08:58:25 +0200 Subject: [Koha-devel] [Koha] RFC for MARC holdings record support In-Reply-To: <0ef2bb5f-2579-139f-4ffd-ff9ed1750462@helsinki.fi> References: <01f42439-d61a-7eb5-6a9b-7413fbd5dcd5@web.de> <69ed94ae-96b0-f925-eba1-b8f3645ceb30@helsinki.fi> <016701d3cd37$f6ba3490$e42e9db0$@prosentient.com.au> <02bdbd49-a15e-93cb-3311-b9b687996492@web.de> <01bb01d3cd76$adae9090$090bb1b0$@prosentient.com.au> <0ef2bb5f-2579-139f-4ffd-ff9ed1750462@helsinki.fi> Message-ID: I've now rewritten the holdings implementation in bug 20447 to use the Koha namespace and modern code style. Feel free to comment. :) --Ere Ere Maijala kirjoitti 9.4.2018 klo 11.41: > There's now an initial patch available, so feel free to take a look at > how much it touches areas waiting to be rewritten or cleaned. I don't > feel it's very high impact, but then I'm the one hoping for this to be > accepted. I'm ready to clean up any of the added code as necessary. It's > currently styled in the way biblios are handled. > > The impact on current codebase in numbers: > > ?C4/Biblio.pm?????????????????????????????????????? |? 17 + > ?C4/Items.pm??????????????????????????????????????? |?? 4 +- > ?C4/Search.pm?????????????????????????????????????? |?? 8 + > ?C4/XSLT.pm???????????????????????????????????????? |? 33 +- > ?acqui/z3950_search.pl????????????????????????????? |?? 2 +- > ?admin/biblio_framework.pl????????????????????????? |?? 5 +- > ?catalogue/detail.pl??????????????????????????????? |? 10 +- > ?cataloguing/addbiblio.pl?????????????????????????? |?? 2 +- > ?cataloguing/addbooks.pl??????????????????????????? |?? 2 +- > ?cataloguing/additem.pl???????????????????????????? |? 11 + > ?.../intranet-tmpl/prog/en/includes/cat-toolbar.inc |?? 4 + > ?.../prog/en/modules/admin/biblio_framework.tt????? |? 22 +- > ?.../en/modules/admin/preferences/cataloguing.pref? |?? 7 + > ?.../prog/en/modules/catalogue/detail.tt??????????? |? 73 +- > ?.../prog/en/modules/catalogue/moredetail.tt??????? |?? 2 + > ?.../prog/en/modules/catalogue/results.tt?????????? |? 14 + > ?.../opac-tmpl/bootstrap/en/modules/opac-detail.tt? |? 28 + > ?.../opac-tmpl/bootstrap/en/modules/opac-results.tt |? 10 + > ?.../bootstrap/en/xslt/MARC21slim2OPACResults.xsl?? |? 19 +- > ?opac/opac-detail.pl??????????????????????????????? |?? 7 + > ?t/db_dependent/Koha/BiblioFrameworks.t???????????? |?? 2 + > > I think this is actually a pretty low number of changes, but then I've > deliberately tried to keep the feature such that it doesn't affect > current functionality. > > MARC may die, and the underlying code can accommodate other formats too. > But since there's no viable replacement for MARC holdings or a framework > that would support those in Koha, I wouldn't consider MARC dead, nor do > I see it dying anytime soon. It's tempting to try to define a more > simple holdings format, but I believe that in real life it won't fulfil > many of the requirements until it's evolved into a bad recreation of > MARC holdings. > > --Ere > > Jonathan Druart kirjoitti 6.4.2018 klo 17.06: >> I am not sure I understand all the ramifications of this RFC, what it >> implies (and I do not have time to dedicate to this right now), but I >> feel like Marcel. >> It sounds like these changes will touch lot of areas in Koha that are >> waiting to be rewritten/cleaned. >> We already have a lot of things waiting in our bug tracker, I would >> not start another big work now. >> >> And...Must not MARC die? >> >> On Fri, 6 Apr 2018 at 04:26 Marcel de Rooy > > wrote: >> >> ??? If I am reading about possible impact on holds functionality, I >> ??? guess that we could better prioritize finishing REST API and moving >> ??? to DBIx/Koha::Object. >> >> >> ??? _______________________________________________ >> ??? 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/ >> > -- Ere Maijala Kansalliskirjasto / The National Library of Finland From katrin.fischer.83 at web.de Fri Feb 22 08:29:31 2019 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Fri, 22 Feb 2019 08:29:31 +0100 Subject: [Koha-devel] Circulation API Question In-Reply-To: References: Message-ID: <66048c2e-afec-5a6c-ea64-969b4934b5ee@web.de> Hi Stephen, I think the REST API in 17.11 doesn't have enough functionality for what you want to do yet, but ILS-DI will probably work. You can see the progress on the REST API endpoints here: https://wiki.koha-community.org/wiki/REST_api_RFCs Hope this helps, Katrin On 20.02.19 12:25, Stephen Graham wrote: > > Hi All ? we have a locally developed mobile app. It?s mainly used for > stuff like campus wayfinding, but there is also a notifications > section. We are thinking of adding Koha notifications to this area ? > e.g. if the user needs to return a book because there is a reservation > and/or it?s reached max renewals, if there is a reservation for them > to collect etc. > > I just trying to get a feel for the best way of doing this ? using one > of the Koha API services. We are currently on 17.11. I?m looking at > https://wiki.koha-community.org/wiki/APIs_and_protocols_supported_by_Koha > , and there are two possible methods that jump out at me: > > * ILS-DI > * Restful HTTP Service/HTTP API (not sure where the RESTful service > is up to development wise, but I don?t think we have the > https://wiki.koha-community.org/wiki/Koha_/svc/_HTTP_API service > set up on our Koha) > > We could always write our own solution, but would rather use a Koha > ?supported? one. At the moment it looks like we might use the ILD-DI > method. Are there any other recommend/better ways? > > Cheers, Stephen > > > _______________________________________________ > 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 s.graham4 at herts.ac.uk Fri Feb 22 08:57:04 2019 From: s.graham4 at herts.ac.uk (Stephen Graham) Date: Fri, 22 Feb 2019 07:57:04 +0000 Subject: [Koha-devel] Circulation API Question In-Reply-To: <66048c2e-afec-5a6c-ea64-969b4934b5ee@web.de> References: <66048c2e-afec-5a6c-ea64-969b4934b5ee@web.de> Message-ID: Hi Katrin ? thanks for the link, I?d over looked that one. Are there any people familiar with the ILS-DI interface? I cannot see a way of finding out if a book I have on loan has got a hold/reservation on it. I can see the other way round ? if I have a hold on a item/title. I?m using: service=GetPatronInfo&patron_id=&show_holds=1&show_loans=1&show_contact=0 But I cannot see anything that indicates there is a hold on an item that I have on loan (there definitely is one!) Stephen From: koha-devel-bounces at lists.koha-community.org On Behalf Of Katrin Fischer Sent: 22 February 2019 07:30 To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Circulation API Question Hi Stephen, I think the REST API in 17.11 doesn't have enough functionality for what you want to do yet, but ILS-DI will probably work. You can see the progress on the REST API endpoints here: https://wiki.koha-community.org/wiki/REST_api_RFCs Hope this helps, Katrin On 20.02.19 12:25, Stephen Graham wrote: Hi All ? we have a locally developed mobile app. It?s mainly used for stuff like campus wayfinding, but there is also a notifications section. We are thinking of adding Koha notifications to this area ? e.g. if the user needs to return a book because there is a reservation and/or it?s reached max renewals, if there is a reservation for them to collect etc. I just trying to get a feel for the best way of doing this ? using one of the Koha API services. We are currently on 17.11. I?m looking at https://wiki.koha-community.org/wiki/APIs_and_protocols_supported_by_Koha , and there are two possible methods that jump out at me: * ILS-DI * Restful HTTP Service/HTTP API (not sure where the RESTful service is up to development wise, but I don?t think we have the https://wiki.koha-community.org/wiki/Koha_/svc/_HTTP_API service set up on our Koha) We could always write our own solution, but would rather use a Koha ?supported? one. At the moment it looks like we might use the ILD-DI method. Are there any other recommend/better ways? Cheers, Stephen _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.renvoize at ptfs-europe.com Fri Feb 22 14:18:38 2019 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Fri, 22 Feb 2019 13:18:38 +0000 Subject: [Koha-devel] Koha 18.11.03 release Message-ID: The Koha community is proud to announce the release of Koha 18.11.03. This is a maintenance release. The full release notes are available at https://koha-community.org/koha-18-11-03-release/ Debian packages will be uploaded in a few days. Best regards and thanks to all those who have contributed to this release. *Martin Renvoize* Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize at ptfs-europe.com *Fax:* +44 (0) 800 756 6384 www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From barton at bywatersolutions.com Fri Feb 22 21:00:35 2019 From: barton at bywatersolutions.com (Barton Chittenden) Date: Fri, 22 Feb 2019 15:00:35 -0500 Subject: [Koha-devel] Discussion of account types / labels Message-ID: The accounts system uses the following codes to show what kind of fee or credit has been issued: A = Account management fee C = Credit F = Overdue fine FOR = Forgiven FU = Overdue, still accruing L = Lost item LR = Lost item returned/refunded M = Sundry N = New card PAY = Payment W = Writeoff The labels, such as 'Account management fee' and 'Overdue fine' are hard coded in various template toolkit files. This is problematic for a number of reasons: 1) It's not obvious where these are defined -- most other constants in Koha are in authorized values. https://koha-community.org/manual/18.05/en/html/faq.html#fines-table is the only place where a koha user can find them all in one place. 2) Because they're not in the database, they can't be used in reports (at least without kludgy case statements). 3) They're not available outside the web interface, so SIP2 and any API endpoints must show the raw codes. 4) 'FU' is a common abbreviation for an obscenity in English, and this has a tendency to show in up in a lot of places where it really shouldn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.grousset at biblibre.com Mon Feb 25 11:50:17 2019 From: victor.grousset at biblibre.com (Victor Grousset) Date: Mon, 25 Feb 2019 11:50:17 +0100 Subject: [Koha-devel] Discussion of account types / labels In-Reply-To: References: Message-ID: <2bd2d26f-9583-c21d-7b8a-432394567e15@biblibre.com> Hi, On 19-02-22 21:00, Barton Chittenden wrote: > The accounts system uses the following codes to show what kind of fee or > credit has been issued: > > [...] > > The labels, such as 'Account management fee' and 'Overdue fine' are hard > coded in various template toolkit files. This is problematic for a > number of reasons: > > 1) It's not obvious where these are defined -- most other constants in > Koha are in authorized values. > https://koha-community.org/manual/18.05/en/html/faq.html#fines-table is > the only place where a koha user can find them all in one place. > 2) Because they're not in the database, they can't be used in reports > (at least without kludgy case statements). > 3) They're not available outside the web interface, so SIP2 and any API > endpoints must show the raw codes. > 4) 'FU' is a common abbreviation for an obscenity in English, and this > has a tendency to show in up in a lot of places where it really shouldn't. Thanks for bringing that up. Indeed, and the codes doesn't really speak for themselves so having very minimal doc doesn't help I don't even know how FU relates it's description. Maybe it's the actual obscenity. To express discontent with the accruing overdue ? Joking aside, is there one obvious clean way that this would have been done today? Authorized values? Would there be downsides of the clean alternative(s) compared to now? (hopefully it was like that because of "historical reasons") ?++ -- Victor Grousset, dev support/maintenance BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Libre/Open Source software and services for libraries From chrisc at catalyst.net.nz Mon Feb 25 12:50:59 2019 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 26 Feb 2019 00:50:59 +1300 Subject: [Koha-devel] Discussion of account types / labels In-Reply-To: <2bd2d26f-9583-c21d-7b8a-432394567e15@biblibre.com> References: <2bd2d26f-9583-c21d-7b8a-432394567e15@biblibre.com> Message-ID: It's Fine Unreturned Whatever they are changed to needs to be translatable. Chris On 25 February 2019 11:50:17 PM NZDT, Victor Grousset wrote: >Hi, > >On 19-02-22 21:00, Barton Chittenden wrote: >> The accounts system uses the following codes to show what kind of fee >or >> credit has been issued: > > > > [...] > > >> The labels, such as 'Account management fee' and 'Overdue fine' are >hard >> coded in various template toolkit files. This is problematic for a >> number of reasons: >> >> 1) It's not obvious where these are defined -- most other constants >in >> Koha are in authorized values. >> https://koha-community.org/manual/18.05/en/html/faq.html#fines-table >is >> the only place where a koha user can find them all in one place. >> 2) Because they're not in the database, they can't be used in reports > >> (at least without kludgy case statements). >> 3) They're not available outside the web interface, so SIP2 and any >API >> endpoints must show the raw codes. >> 4) 'FU' is a common abbreviation for an obscenity in English, and >this >> has a tendency to show in up in a lot of places where it really >shouldn't. > >Thanks for bringing that up. >Indeed, and the codes doesn't really speak for themselves so having >very >minimal doc doesn't help >I don't even know how FU relates it's description. >Maybe it's the actual obscenity. To express discontent with the >accruing >overdue ? > >Joking aside, is there one obvious clean way that this would have been >done today? >Authorized values? > >Would there be downsides of the clean alternative(s) compared to now? >(hopefully it was like that because of "historical reasons") > > >?++ > >-- >Victor Grousset, dev support/maintenance >BibLibre, Services en logiciels libres pour les biblioth?ques >BibLibre, Libre/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/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From barton at bywatersolutions.com Mon Feb 25 14:57:40 2019 From: barton at bywatersolutions.com (Barton Chittenden) Date: Mon, 25 Feb 2019 08:57:40 -0500 Subject: [Koha-devel] Discussion of account types / labels In-Reply-To: References: <2bd2d26f-9583-c21d-7b8a-432394567e15@biblibre.com> Message-ID: On Mon, Feb 25, 2019 at 6:51 AM Chris Cormack wrote: > > Whatever they are changed to needs to be translatable. > Agreed. I suspect that the trade-offs between 'We would like this to be translatable' and 'we need these values to be un-editable' (I.e. not authorized values) are probably what's kept things as they are. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Feb 26 00:11:01 2019 From: dcook at prosentient.com.au (David Cook) Date: Tue, 26 Feb 2019 10:11:01 +1100 Subject: [Koha-devel] Discussion of account types / labels In-Reply-To: References: <2bd2d26f-9583-c21d-7b8a-432394567e15@biblibre.com> Message-ID: <06ea01d4cd5f$5feb7280$1fc25780$@prosentient.com.au> I was pondering this yesterday as well. I figure a lookup table in the database that contains the code and a description (for reporting and administration purposes), but use translatable strings in templates using the code as hooks. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Barton Chittenden Sent: Tuesday, 26 February 2019 12:58 AM To: Chris Cormack Cc: Koha-devel Subject: Re: [Koha-devel] Discussion of account types / labels On Mon, Feb 25, 2019 at 6:51 AM Chris Cormack > wrote: Whatever they are changed to needs to be translatable. Agreed. I suspect that the trade-offs between 'We would like this to be translatable' and 'we need these values to be un-editable' (I.e. not authorized values) are probably what's kept things as they are. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Tue Feb 26 07:14:50 2019 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Tue, 26 Feb 2019 07:14:50 +0100 Subject: [Koha-devel] Koha 17.11.15 release Message-ID: The Koha community is proud to announce the release of Koha 17.11.15. This is a maintenance release. The full release notes are available at https://koha-community.org/koha-17-11-15-release/ Debian packages will be upgraded in a few days. I may end this maintaining with 19.05 release in may, so last version should be 17.11.18. Regards, -- Fridolin SOMERS BibLibre, France - software and system maintainer From katrin.fischer.83 at web.de Tue Feb 26 07:27:48 2019 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Tue, 26 Feb 2019 07:27:48 +0100 Subject: [Koha-devel] Discussion of account types / labels In-Reply-To: <06ea01d4cd5f$5feb7280$1fc25780$@prosentient.com.au> References: <2bd2d26f-9583-c21d-7b8a-432394567e15@biblibre.com> <06ea01d4cd5f$5feb7280$1fc25780$@prosentient.com.au> Message-ID: Hi all, please keep in mind that 'translated' doesn't mean into one language, but should allow for supporting different languages at the same time, especially if those descriptions were to be used for APIs as well. Katrin On 26.02.19 00:11, David Cook wrote: > > I was pondering this yesterday as well. > > I figure a lookup table in the database that contains the code and a > description (for reporting and administration purposes), but use > translatable strings in templates using the code as hooks. > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > *From:*koha-devel-bounces at lists.koha-community.org > [mailto:koha-devel-bounces at lists.koha-community.org] *On Behalf Of > *Barton Chittenden > *Sent:* Tuesday, 26 February 2019 12:58 AM > *To:* Chris Cormack > *Cc:* Koha-devel > *Subject:* Re: [Koha-devel] Discussion of account types / labels > > On Mon, Feb 25, 2019 at 6:51 AM Chris Cormack > wrote: > > > Whatever they are changed to needs to be translatable. > > Agreed. I suspect that the trade-offs between 'We would like this to > be translatable' and 'we need these values to be un-editable' (I.e. > not authorized values) are probably what's kept things as they are. > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Tue Feb 26 09:31:00 2019 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Tue, 26 Feb 2019 09:31:00 +0100 Subject: [Koha-devel] FW: [Koha] Koha 18 support In-Reply-To: <000001d4b2d9$02306380$06912a80$@umt.edu.pk> References: <002f01d4b23d$b098f370$11cada50$@umt.edu.pk> <000001d4b2d9$02306380$06912a80$@umt.edu.pk> Message-ID: <87fa5efd-08b8-70f1-5283-b1e121a30a31@biblibre.com> Hi, Looks like your Zebra configuration is still in GRS-1 which is strongly deprecated. Try switch to DOM : https://wiki.koha-community.org/wiki/Switching_to_dom_indexing Which is you OS and how did you install Koha please ? Best regards, Le 23/01/2019 ? 06:03, faiz at umt.edu.pk a ?crit?: > Dear Fridolin and Koha friends > > Our koha is not searching and when we rebuild Koha zebra it gives zebraidx error which is attached, our installation package is on ubuntu 16.04, when we rebuild Zebra from root login it works in the begning but as the indexing finishes after 20 min it starts generating errors, please share resolution. > > > Kind Regards > > > Muhammad Faiz Chishti > Team Lead Systems > Office of Technology Support (OTS) > University of Management and Technology > C 2 Johar Town > Tell: +42 111300200 Ext: 3640 Cell: +923054440632 > Website: www.umt.edu.pk Email: faiz at umt.edu.pk > > Please consider the environment before printing this email. > > > -----Original Message----- > From: faiz at umt.edu.pk > Sent: Tuesday, January 22, 2019 8:30 PM > To: 'Fridolin SOMERS' ; 'koha at lists.katipo.co.nz' ; 'koha-devel' > Subject: RE: [Koha] Koha 18 support > > Dear brother > > We are using a pre compiled version by total library solution, We are facing error with zebra, it fails and the stops Koha search, we than rebuild Koha index and restart the server 2 or three times, this in return brings the service up. Now when we rebuild zebra it gives zebraidx error and does not rebuild. > > > The error is attached > > Kind Regards > > > Muhammad Faiz Chishti > Team Lead Systems > Office of Technology Support (OTS) > University of Management and Technology > C 2 Johar Town > Tell: +42 111300200 Ext: 3640 Cell: +923054440632 > Website: www.umt.edu.pk Email: faiz at umt.edu.pk > > Please consider the environment before printing this email. > > > -----Original Message----- > From: Koha On Behalf Of Fridolin SOMERS > Sent: Tuesday, January 22, 2019 8:20 PM > To: koha at lists.katipo.co.nz; 'koha-devel' > Subject: Re: [Koha] Koha 18 support > > Hi > > What is your zebraidx error ? > > How did you install ? Debian Package ? > > Regards, > > Le 22/01/2019 ? 11:31, faiz at umt.edu.pk a ?crit : >> >> We are facing error with our daily Cron jobs, it fails and the stops Koha search, we than rebuild Koha index and restart the server 2 or three times, this in return brings the service up. Now when we rebuild zebra it gives zebraidx error and does not rebuild. >> >> We require support and maintenance of our locally installed instance. >> >> >> - Current system >> * Koha 18.05 >> >> - Number of bibliographic records >> * 127K >> >> - Average annual circulation >> * 35K approx. >> >> >> >> Kind Regards >> >> >> Muhammad Faiz Chishti >> Team Lead Systems >> Office of Technology Support (OTS) >> University of Management and Technology C 2 Johar Town >> Tell: +42 111300200 Ext: 3640 Cell: +923054440632 >> Website: www.umt.edu.pk Email: faiz at umt.edu.pk >> >> Please consider the environment before printing this email. >> >> > > -- > Fridolin SOMERS BibLibre, France - software and system maintainer _______________________________________________ > Koha mailing list http://koha-community.org Koha at lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha > -- Fridolin SOMERS BibLibre, France - software and system maintainer From fridolin.somers at biblibre.com Tue Feb 26 09:36:28 2019 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Tue, 26 Feb 2019 09:36:28 +0100 Subject: [Koha-devel] zebraidx with 1 large MARC file rather than many small MARC files In-Reply-To: <029201d4bc52$568a2060$039e6120$@prosentient.com.au> References: <028801d4bc50$51d0a1e0$f571e5a0$@prosentient.com.au> <029201d4bc52$568a2060$039e6120$@prosentient.com.au> Message-ID: <8d28e851-f324-1094-20c8-5bc50c466ae8@biblibre.com> Hi, The problem with redinxing full catalogue is the huge XML files that will be generated in /tmp/. Some servers dont have space enought. So we at Biblibre use a shell script to reindex step by steps : https://git.biblibre.com/biblibre/tools/src/branch/master/zebra/rebuild_full.sh Ah if it crashes you may restart from last good step ;) Best regards, Le 04/02/2019 ? 07:24, David Cook a ?crit?: > To answer my own question. > > > > I have a zebraidx running on 461MB (or 77000 records) and it's only using 2% > of memory on a 4GB system, so I'm thinking it is using a stream reader and > updating the shadow files on disk as it goes through the massive MARC file. > > > > In that case, while it might be slow to export records to that file, > zebraidx probably does read 1 large file much faster than many small files. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > From: koha-devel-bounces at lists.koha-community.org > [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of David Cook > Sent: Monday, 4 February 2019 5:10 PM > To: 'Koha Devel' > Cc: tomascohen at theke.io > Subject: [Koha-devel] zebraidx with 1 large MARC file rather than many small > MARC files > > > > Hi all, > > > > I haven't looked into it too deeply, but I was curious if Zebra would have > better performance indexing with 1 large MARC file versus many small MARC > files. > > > > At the moment, we generate 1 huge MARC file and then pass that to zebraidx > as an argument. > > > > Is that something we've always done or was it done as a performance > enhancement? > > > > I haven't looked at the Zebra internals to see whether it reads the entire > file into memory and then processes it or if it parses the XML using a > stream reader. Zebraidx can also take a list of files from stdin*, but if > you had tonnes of small files that could be troublesome. > > > > I suppose it doesn't matter too much as we march on to ElasticSearch, but I > figure lots of people are using Zebra still and probably will for a long > time, so perhaps worth thinking about. > > > > https://software.indexdata.com/zebra/doc/zebraidx.html > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer From fridolin.somers at biblibre.com Tue Feb 26 09:40:11 2019 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Tue, 26 Feb 2019 09:40:11 +0100 Subject: [Koha-devel] Limits cannot contain parentheses In-Reply-To: <004801d4c4d3$eb02f490$c108ddb0$@prosentient.com.au> References: <004801d4c4d3$eb02f490$c108ddb0$@prosentient.com.au> Message-ID: Thanks for working on that David. We use zebra on xenial so actually 2.1.4 and it does not even support signle quotes in limits. I could not say how to fix ugly or beautiful ;) Le 15/02/2019 ? 03:12, David Cook a ?crit?: > Hi all, > > > > I noticed that the CCL2RPN parser throws fatal errors when limits have > parentheses in them. I have a fix for it (described at > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22344), but it > makes for an escaped $limit_cgi and an ugly $limit_desc. It doesn't break > anything, but it's not aesthetically pleasing. > > > > Would people prefer an ugly fix that is easy to implement, or a more > beautiful but difficult to implement fix? > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer From fridolin.somers at biblibre.com Tue Feb 26 09:44:47 2019 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Tue, 26 Feb 2019 09:44:47 +0100 Subject: [Koha-devel] search result list is void of information In-Reply-To: <1550675174603-0.post@n5.nabble.com> References: <1550675174603-0.post@n5.nabble.com> Message-ID: <49f7dbe4-578e-7578-fd93-c6f62e65ee6f@biblibre.com> Hi, If you are using UNIMARC, it may be caused by : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22085 It is corrected in 18.11.03 released this week, you may try to upgrade. Best regards, Le 20/02/2019 ? 16:06, giuseppe a ?crit?: > Hello all, > > (already posted on koha-general, but maybe here a better place -- sorry for > possible cross postings -- I will file a bug report if nothing happens here > too) > > I've replaced an old Koha 17.11 by a fresh install of Koha 18.11 (on a fresh > install of Debian 9.7 64bit). After install, as superlibrarian I > successfully populated the DB with sample records including a couple of > items, for test purposes. > > > > Afterwards, as normal user I tried a search for a keyword matching more than > one record, and thus I got a list of search results. > > > > The list is correct, but, as you can see, each entry is void of textual > information -- no title/author/etc. . If I click on the "image preview" of > one single entry (not visible in the screenshot) I get access to the full > info of that entry, which shows correct. But the search results void of > textual information is uninformative for a user. This misbehaviour is also > present in Koha 18.05 but not in Koha 17.11. > > Is this just a matter of misconfiguration? What should I do to restore the > original behaviour? > > Thank you. > > > > -- > Sent from: http://koha.1045719.n5.nabble.com/Koha-devel-f3063671.html > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer From fridolin.somers at biblibre.com Tue Feb 26 09:48:34 2019 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Tue, 26 Feb 2019 09:48:34 +0100 Subject: [Koha-devel] Problems with "LOC" authorized values and tokenization In-Reply-To: <03cd01d4c979$e8749fd0$b95ddf70$@prosentient.com.au> References: <03cd01d4c979$e8749fd0$b95ddf70$@prosentient.com.au> Message-ID: <6ff8c42d-5510-e89b-b89f-e907e2e7d38e@biblibre.com> Hi, Authorized values works really better if you stick to [0-9A-Z] in values. I know its not always easy ;) Le 21/02/2019 ? 01:10, David Cook a ?crit?: > Hi all, > > > > I have a library with lots of problematic data in their "LOC" authorized > value codes, and it's led me to a few issues. > > > > 1. LOC authorized values can contain "*", "(", and ")" but all of > these characters will cause the ZOOM library to fail to compile the CCL2RPN > query. > > 2. mc-loc (from the "Shelving location" tab on > /cgi-bin/koha/catalogue/search.pl) seems to be doing an incomplete search. > That means if you have two locations like "Big Box" and "Big Box - Drawer", > "Big Box" will return items for both locations. > > > > The reason for #2 is actually kind of interesting. While the RPN/PQF query > is "@attr 1=8013 @attr 4=1 apple_street" and @attr 4=1 represents a "phrase" > search, Zebra is actually using the "w" register and not the "p" register. > It's because of the "Completeness Attributes (type = 6)": > > > > "Incomplete subfield (1) is the default, and makes Zebra use register > type="w", whereas Complete field (3) triggers search and scan in index > type="p"." (https://software.indexdata.com/zebra/doc/querymodel-rpn.html). > > > > If we wanted to actually just get the exact location, we'd want to use > "mc-loc,complete-field", but then we'd get Zebra errors because mc-loc > doesn't use the "p" type register currently, although that would be easy > enough to add. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer From giuseppe.ciaccio at unige.it Tue Feb 26 14:14:47 2019 From: giuseppe.ciaccio at unige.it (giuseppe) Date: Tue, 26 Feb 2019 06:14:47 -0700 (MST) Subject: [Koha-devel] importing from a UNIMARC backup will import biblio records but not items Message-ID: <1551186887386-0.post@n5.nabble.com> Hello again, today I'm playing the following game (with Koha 18.11.03): 1) create two empty instances, A and B, both in the UNIMARC flavour; 2) populate A with ten bibliorecords, two ones with associated items; 3) create a backup from A so that only UNIMARC records having items are exported; 4) import the backup into instance B; 5) contrary to expectations, see that B now contains two biblio records but no items associated to them. If I inspect the records in the catalog of B, I see that they are void of the field 995 ( https://wiki.koha-community.org/wiki/Holdings_data_fields_%289xx%29#UNIMARC_Holding_field.2C_3.2_default_-_field_995 ). However, the records staged in the temporary area of B during import phase do have that field. Any suggestions (before I file a bug report)? Thank you, Giuseppe -- Sent from: http://koha.1045719.n5.nabble.com/Koha-devel-f3063671.html From jonathan.druart at bugs.koha-community.org Tue Feb 26 16:57:46 2019 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 26 Feb 2019 12:57:46 -0300 Subject: [Koha-devel] Give a try to RabbitMQ (background jobs rewrite) - POC! Message-ID: Hi devs, I have submited a proof of concept (POC) on bug 22417 (Delegate background jobs execution). The idea would be to isolate our background jobs code (the one in the .pl) into module then use RabbitMQ to process them. More stuffs on the bug! https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417 Cheers, Jonathan From bob at calyx.net.au Wed Feb 27 06:24:03 2019 From: bob at calyx.net.au (Bob Birchall) Date: Wed, 27 Feb 2019 16:24:03 +1100 Subject: [Koha-devel] Auto-increment problem has re-emerged Message-ID: We're running multiple instances of Koha 18.05.06 installed on stretch from packages. In recent days we've struck the auto-increment problem several times, in relation to issues / old_issues. Known fixes are applied. Is anyone else experiencing this? Thanks, Bob Calyx From dcook at prosentient.com.au Wed Feb 27 06:25:04 2019 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Feb 2019 16:25:04 +1100 Subject: [Koha-devel] Discussion of account types / labels In-Reply-To: References: <2bd2d26f-9583-c21d-7b8a-432394567e15@biblibre.com> <06ea01d4cd5f$5feb7280$1fc25780$@prosentient.com.au> Message-ID: <080501d4ce5c$cb8bb1f0$62a315d0$@prosentient.com.au> Hi Katrin, I don?t understand your email. My suggestion would yield support for different languages (for anything using Template Toolkit templates). As far as I understand, that?s how we currently provide internationalization support in Koha. Am I missing something? Admittedly, I haven?t done much with the REST API yet, but I assume that the API would just deal with codes? And if we were calling the API from the OPAC, we?d just use templates that rely on the codes. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Katrin Fischer Sent: Tuesday, 26 February 2019 5:28 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Discussion of account types / labels Hi all, please keep in mind that 'translated' doesn't mean into one language, but should allow for supporting different languages at the same time, especially if those descriptions were to be used for APIs as well. Katrin On 26.02.19 00:11, David Cook wrote: I was pondering this yesterday as well. I figure a lookup table in the database that contains the code and a description (for reporting and administration purposes), but use translatable strings in templates using the code as hooks. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Barton Chittenden Sent: Tuesday, 26 February 2019 12:58 AM To: Chris Cormack Cc: Koha-devel Subject: Re: [Koha-devel] Discussion of account types / labels On Mon, Feb 25, 2019 at 6:51 AM Chris Cormack > wrote: Whatever they are changed to needs to be translatable. Agreed. I suspect that the trade-offs between 'We would like this to be translatable' and 'we need these values to be un-editable' (I.e. not authorized values) are probably what's kept things as they are. _______________________________________________ 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 Feb 27 06:29:49 2019 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Feb 2019 16:29:49 +1100 Subject: [Koha-devel] zebraidx with 1 large MARC file rather than many small MARC files In-Reply-To: <8d28e851-f324-1094-20c8-5bc50c466ae8@biblibre.com> References: <028801d4bc50$51d0a1e0$f571e5a0$@prosentient.com.au> <029201d4bc52$568a2060$039e6120$@prosentient.com.au> <8d28e851-f324-1094-20c8-5bc50c466ae8@biblibre.com> Message-ID: <081101d4ce5d$755852b0$6008f810$@prosentient.com.au> That's interesting. I do have some large Koha instances that have run into that space problem I think. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Fridolin SOMERS Sent: Tuesday, 26 February 2019 7:36 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] zebraidx with 1 large MARC file rather than many small MARC files Hi, The problem with redinxing full catalogue is the huge XML files that will be generated in /tmp/. Some servers dont have space enought. So we at Biblibre use a shell script to reindex step by steps : https://git.biblibre.com/biblibre/tools/src/branch/master/zebra/rebuild_full .sh Ah if it crashes you may restart from last good step ;) Best regards, Le 04/02/2019 ? 07:24, David Cook a ?crit?: > To answer my own question. > > > > I have a zebraidx running on 461MB (or 77000 records) and it's only > using 2% of memory on a 4GB system, so I'm thinking it is using a > stream reader and updating the shadow files on disk as it goes through the massive MARC file. > > > > In that case, while it might be slow to export records to that file, > zebraidx probably does read 1 large file much faster than many small files. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > From: koha-devel-bounces at lists.koha-community.org > [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of > David Cook > Sent: Monday, 4 February 2019 5:10 PM > To: 'Koha Devel' > Cc: tomascohen at theke.io > Subject: [Koha-devel] zebraidx with 1 large MARC file rather than many > small MARC files > > > > Hi all, > > > > I haven't looked into it too deeply, but I was curious if Zebra would > have better performance indexing with 1 large MARC file versus many > small MARC files. > > > > At the moment, we generate 1 huge MARC file and then pass that to > zebraidx as an argument. > > > > Is that something we've always done or was it done as a performance > enhancement? > > > > I haven't looked at the Zebra internals to see whether it reads the > entire file into memory and then processes it or if it parses the XML > using a stream reader. Zebraidx can also take a list of files from > stdin*, but if you had tonnes of small files that could be troublesome. > > > > I suppose it doesn't matter too much as we march on to ElasticSearch, > but I figure lots of people are using Zebra still and probably will > for a long time, so perhaps worth thinking about. > > > > https://software.indexdata.com/zebra/doc/zebraidx.html > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer _______________________________________________ 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 Wed Feb 27 06:32:33 2019 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Feb 2019 16:32:33 +1100 Subject: [Koha-devel] Problems with "LOC" authorized values and tokenization In-Reply-To: <6ff8c42d-5510-e89b-b89f-e907e2e7d38e@biblibre.com> References: <03cd01d4c979$e8749fd0$b95ddf70$@prosentient.com.au> <6ff8c42d-5510-e89b-b89f-e907e2e7d38e@biblibre.com> Message-ID: <081201d4ce5d$d6e77380$84b65a80$@prosentient.com.au> I totally agree. Unfortunately, it's difficult to control hundreds of librarians by words alone. I've been thinking perhaps a good way forward would be some Javascript to prevent people from adding anything non-alphanumeric. It wouldn't stop vendors from doing problematic data migrations but it would prevent library staff from making it worse? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Fridolin SOMERS Sent: Tuesday, 26 February 2019 7:49 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Problems with "LOC" authorized values and tokenization Hi, Authorized values works really better if you stick to [0-9A-Z] in values. I know its not always easy ;) Le 21/02/2019 ? 01:10, David Cook a ?crit?: > Hi all, > > > > I have a library with lots of problematic data in their "LOC" > authorized value codes, and it's led me to a few issues. > > > > 1. LOC authorized values can contain "*", "(", and ")" but all of > these characters will cause the ZOOM library to fail to compile the > CCL2RPN query. > > 2. mc-loc (from the "Shelving location" tab on > /cgi-bin/koha/catalogue/search.pl) seems to be doing an incomplete search. > That means if you have two locations like "Big Box" and "Big Box - > Drawer", "Big Box" will return items for both locations. > > > > The reason for #2 is actually kind of interesting. While the RPN/PQF > query is "@attr 1=8013 @attr 4=1 apple_street" and @attr 4=1 represents a "phrase" > search, Zebra is actually using the "w" register and not the "p" register. > It's because of the "Completeness Attributes (type = 6)": > > > > "Incomplete subfield (1) is the default, and makes Zebra use register > type="w", whereas Complete field (3) triggers search and scan in index > type="p"." (https://software.indexdata.com/zebra/doc/querymodel-rpn.html). > > > > If we wanted to actually just get the exact location, we'd want to use > "mc-loc,complete-field", but then we'd get Zebra errors because mc-loc > doesn't use the "p" type register currently, although that would be > easy enough to add. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ > -- Fridolin SOMERS BibLibre, France - software and system maintainer _______________________________________________ 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 Wed Feb 27 06:38:42 2019 From: dcook at prosentient.com.au (David Cook) Date: Wed, 27 Feb 2019 16:38:42 +1100 Subject: [Koha-devel] Give a try to RabbitMQ (background jobs rewrite) - POC! In-Reply-To: References: Message-ID: <081301d4ce5e$b30c1c30$19245490$@prosentient.com.au> Awesome! I'm very excited to see your email and read the bug report, Jonathan! I've been wanting to add a message queue to Koha for years now. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Jonathan Druart Sent: Wednesday, 27 February 2019 2:58 AM To: koha-devel Subject: [Koha-devel] Give a try to RabbitMQ (background jobs rewrite) - POC! Hi devs, I have submited a proof of concept (POC) on bug 22417 (Delegate background jobs execution). The idea would be to isolate our background jobs code (the one in the .pl) into module then use RabbitMQ to process them. More stuffs on the bug! https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417 Cheers, Jonathan _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From nick at bywatersolutions.com Thu Feb 28 14:24:36 2019 From: nick at bywatersolutions.com (Nick Clemens) Date: Thu, 28 Feb 2019 08:24:36 -0500 Subject: [Koha-devel] Critical bug fix to prevent data loss (Bug 22395) Message-ID: Hello all, It has been discovered there is a bug in the stable versions of Koha, 18.05.09 and 17.11.15 which can cause quoted text in records to be deleted upon edit/save https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22395 If you have not yet upgraded to the most recent maintenance release please wait a few days as we are releasing a new version to fix the issue. If you are running these versions please be aware of this bug and we will be sending a notice when the new versions are available. Thanks, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at bywatersolutions.com Thu Feb 28 14:26:45 2019 From: nick at bywatersolutions.com (Nick Clemens) Date: Thu, 28 Feb 2019 08:26:45 -0500 Subject: [Koha-devel] Critical bug fix to prevent data loss (Bug 22395) In-Reply-To: References: Message-ID: Correction, this affects 18.05.08 and 17.11.14 as well On Thu, Feb 28, 2019 at 8:24 AM Nick Clemens wrote: > Hello all, > > It has been discovered there is a bug in the stable versions of Koha, > 18.05.09 and 17.11.15 which can cause quoted text in records to be deleted > upon edit/save > > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22395 > > If you have not yet upgraded to the most recent maintenance release please > wait a few days as we are releasing a new version to fix the issue. > > If you are running these versions please be aware of this bug and we will > be sending a notice when the new versions are available. > > Thanks, > Nick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: