- Koha-devel - lists.koha-community.org

What is biblioitemnumber for?
by Barton Chittenden 21 Nov '18

21 Nov '18

Just out of curiosity, why does biblioitemnumber exist? There should be a one-to-one relationship between biblio records and biblioitem records ... so why not use biblionumber as the primary key for biblioitems? --Barton

9 16

Hackfest in Marseille in 2019
by Paul Poulain 20 Nov '18

20 Nov '18

Hello Koha, I wrote a while ago that the hackfest in Marseille will not take place in spring, because of the KohaCon in Europe (congratulation Dublin). We've chosen : sept 30th - oct 4th. It may be a little bit early to book your flight but you can already set the dates in your agenda ;) -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

1 0

Notices and slips documentation RFC
by Barton Chittenden 19 Nov '18

19 Nov '18

Koha doesn't currently have a single point of truth for documentation of notices and slips, which has lead to a proliferation of markup syntaxes, especially in regard to repeating detail, e.g. DUEDGST/PREDUEDGST: <<items.content>> ODUE* <<items.content>> or <item> </item> CHECKOUT/CHECKIN/RENEWAL ---- Detail here ---- These have been documented in https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips#Notice_M… , but this has gotten out of date as new notices get added in each version of Koha. Work to be done: Add Koha/Notices.pod which will document the following for each notice in the Letter table: * Letter Code * Source file where the notice is populated * Logic that triggers the notice * Detail syntax (if any) * Available data (tables and substitutions) * Message transport restrictions The output from this pod should be used as the basis for the Koha user documentation. See Bug 21858 and https://wiki.koha-community.org/wiki/Notice_documentation_rfc

5 7

Permission to remove /misc/cronjobs/staticfines.pl
by Renvoize, Martin 16 Nov '18

16 Nov '18

Hi Everyone, In a quest to clean up an unused database field in the issuingrules table (Bug 21753 - issuingrules.chargename is unused and should be removed) I found a fines script which I've never seen before. It looks like a good candidate for removal after a quick query to the irc channels but I wanted to open it here to check if anyone is indeed still using this particular mode of calculating fines. Many thanks, *Martin Renvoize* <https://www.ptfs-europe.com> Development Team Manager *Phone:* +44 (0) 1483 378728 *Mobile:* +44 (0) 7725 985 636 *Email:* martin.renvoize(a)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(a)ptfs-europe.com

3 3

Koha plugins Apache Alias
by Fridolin SOMERS 16 Nov '18

16 Nov '18

Hi, For Koha plugins, there is in etc/koha-httpd.conf : Alias /plugin/ "__PLUGINS_DIR__/" I dont see this in debian/templates o_O Since we allow plugin to add load of JS/CSS files for intranet and OPAC, should be add this alias for both ? Looks like this is needed for actual EDS plugin. https://github.com/ebsco/edsapi-koha-plugin/ Best regards, -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> BibLibre, France - software and system maintainer

2 2

Re: [Koha-devel] [Koha] [EXTERNAL] Filtering inventory results by cn_sort vs. callnumber
by Eric Phetteplace 15 Nov '18

15 Nov '18

I'm in support of using cn_sort wherever sorting occurs as that's its purpose. If I'm not mistaken, it's already being used in some places without an existing system preference, and I don't see how the Inventory tool is categorically different. Is it possible, perhaps in a plugin, to configure new normalization methods for different classification sources? That seems to be the purpose of the Classification Sources admin settings but I'm not sure. To answer Heather—I think your second question is correct, the two problems are not intertwined. One deals with LC numbers being improperly normalized and another deals with the normalized strings not being used as the sorting value in places. Best, ERIC PHETTEPLACE Systems Librarian libraries.cca.edu | vault.cca.edu | 510.594.3660 5212 Broadway, Oakland, CA 94618 1111 8th St., San Francisco, CA 94107 Preferred Pronoun(s): he/him :(){ :|: & };: On Thu, Nov 15, 2018 at 8:01 AM Hernandez, Heather < heather_hernandez(a)nps.gov> wrote: > Hi, Nick-- > > I read through Bug 21629 and if I'm reading it correctly, it says that call > numbers are sorted correctly using cn_sort, but Bug 17269 describes how > call numbers are not sorted correctly using cn_sort, specifically the ones > with colons in them in the G Library of Congress classification schedule. > > Has Bug 21629 been tested using LC call numbers with colons in them? Or is > the problem of incorrect sorts of LC call numbers with colons in them > unrelated? > > Thank you! Cheers, > h2 > ~~~~~~~~~~~~~~ > Heather Hernandez > Technical Services Librarian > San Francisco Maritime National Historical Park Research Center > 2 Marina Blvd., Bldg. E, 3rd floor, San Francisco, CA 94123-1284 > 415-561-7032, heather_hernandez(a)nps.gov > Library catalog: http://keys.bywatersolutions.com/ > _______________________________________________ > Koha mailing list http://koha-community.org > Koha(a)lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

Signoff request
by Marcel de Rooy 15 Nov '18

15 Nov '18

Hi all, Please help getting bug 21774 into the next release by signing off. Marked as critical last week. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21774 Thanks, Marcel

1 0

removing some projects from git.koha-community.org
by Paul Poulain 14 Nov '18

14 Nov '18

Hello, on git.k-c.org, there are some project that have not been updated for years, and I'm wondering whether we should/could hide or delete them: This question is for the following repos: * koha-translations.git Translations files (.po) for... Translation Manager 3 years ago * mm/jcamins.git MM repo for authorities Jared Camins-Esakov 4 years ago * mm/chrisc.git MM repo for testing Chris Cormack 4 years ago * wip/koha-equinox.git Equinox work in progress Galen Charlton 5 years ago * koha-small.git main Koha release repository Koha Project 6 years ago * wip/koha-catalyst.git Catalyst work in progress Chris Cormack 6 years ago * wip/koha-chris_n.git Personal work in progress Chris Nighswonger 7 years ago * wip/koha-biblibre.git BibLibre work in progress Henri-Damien Laurent 7 years ago * wip/koha-fbc.git Foundations Bible College... Chris Nighswonger 7 years ago * wip/koha-ptfs.git PTFS work in progress J. David Bavousett 8 years ago the koha-biblibre.git, for sure, BibLibre don't use it at all, it can be discarded. I haven't listed: * website.git Koha website repository Koha Project 5 years ago * koha-archive.git Old Koha topic branches Koha Project 5 years ago but maybe they can be included as well. good idea or not ? -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

3 2

Filtering inventory results by cn_sort vs. callnumber
by Nick Clemens 14 Nov '18

14 Nov '18

Hello All! I put together a bug a while back for switching the sorting on inventory results filter from using 'callnumber' to the hidden/constructed column 'cn_sort' i.e. When inventorying a section by callnumber you would enter the range GT90 to GT100, Koha would then interpret this to (roughly) GT090 and GT100 as we do when constructing the cn_sort column. 'cn_sort' is the column we use to pad callnumbers with '0' and spaces to ensure that a callnumber of GT90 is sorted before GT100 (if sorted as normal strings 1 comes before 9) During review if the bug there was concern that some callnumber schemes may not work under this change, or some libraries might not have the cn_sort columns correctly filled and that we should add a system preference to control which column was used. On bug 21629 ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21629) we made sorting lists by callnumber use cn_sort by default. I am just writing to see if any libraries out there have concerns about the change, or if we think that always using cn_sort to filter the results would work. We want to be consistent throughtout the code (ideally) Let me know what thoughts you have and if you think we can simply assume cn_sort is the definitive column for sorting and defining ranges. -Nick -- Nick Clemens Sonic Screwdriver (Development Support) ByWater Solutions IRC: kidclamp

1 0

Replacing koha-plack, koha-start-zebra, etc with systemd services?
by David Cook 14 Nov '18

14 Nov '18

Hi all, I'm about to start working on a systemd service for running Plack (for a non-package Koha install), and I was wondering if anyone else has thought about or is using systemd services for Plack, Zebra, etc. Mason did a great job with a systemd service https://github.com/KohaAloha/koha-mysql-init/blob/master/koha-mysql-init.ser vice for getting around the autoincrement issue (fixed in MySQL 8.0 https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html and MariaDB 10.2.4 https://mariadb.com/kb/en/library/auto_increment/) Anyway, once I've got something working, I'm happy to share it. Curious if anyone has any systemd unit files they'd like to share. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

3 4