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

Master broken by 20521 (sql modes)
by Jonathan Druart 19 Oct '18

19 Oct '18

Hi devs, I quick email to let you know that master and tests are (completely) broken because of the recent push of bug 20521. It turned on the "problematic SQL modes" for dev installs (I let you search for that in your emails if it did not ring you the bell). I am working on fixing the different test failures (the ones we introduced since bug 20144, 6 months ago). They are all regressions and there are a lot! This shows us that we absolutely need this change, to alert us when we are doing something wrong, that's why I would not recommend a revert. If you are stuck in something urgent/important you can revert commit aafd0476342ca9691fd8a7c2c754c425ae1cf61f Bug 20521: Enable problematic SQL modes for dev installs Or easier, remove the dev_install flag in your koha-conf (but do not forget to switch it back in a few days!). Cheers, Jonathan

3 4

Call for News: October 2018 Newsletter
by kohanews 17 Oct '18

17 Oct '18

I'm collecting news for the October 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

1 0

Invitation to join the core team
by Renvoize, Martin 12 Oct '18

12 Oct '18

Hi everyone, I just wanted to remind you all that the role proposals page for the upcoming 19.05 development cycle is available at https://wiki.koha-community.org/wiki/Roles_for_19.05 and we'd love to see some new names on the volunteers' list. The vote on roles will be held at the next irc general meeting. Roles to draw your attention to: * Bug Wranglers - We can always do with more bug wranglers! These people love to keep things tidy and Bugzilla is always in need of your help. We need people to help manage 'the list', identifying the duplicates, promoting bugs to specialists and finding people to do signoffs and testing. Everyone is invited to this party, we need you! * Documentation Team - The documentation team is a growing team that's made great inroads into bringing Koha's documentation up to date and ensuring we have a really well-documented piece of software. There's plenty more to do and they're always on the lookout for new contributors. * Wiki Curators - Koha's wiki is bursting at the seams with good information, but we need your help to bring order to the chaos and keep improving the content. If you've got an interest in maintaining an area of the Wiki, helping identify out of date information or categorizing data then this is a job for you. * Quality Assurance Team - This vitally important team is always looking for new recruits! If you've got an eye for detail, or you're a tester who likes rolling up their sleeves a little bit and looking at how a piece of code works, then we'd love to hear from you. Again, there's always support available from 'the usual suspects' so don't shy away, why not make this your first cycle on the QA team and see how much fun it can be working with this important team. * Quality Assurance Topic Expert - Do you know one particular area of koha better than the rest? Are you the 'go to' guy (or gal) for SIP2, EDI, Acquisitions or another area of Koha? We'd like to hear from you too. You don't have to know the whole codebase to be a great QA Specialist, you're an expert in what you know and we always need more experts. * Release Maintainer 18.05 - I've enjoyed being RMaint this last five months, and have offered to take up the mantle again for the next 'stable' (18.11) release. So, we need someone to take up my mantle and maintain 'oldstable' (18.05). As ever, the community is a great place and lots of support will be available to show you the ropes. See https://wiki.koha-community.org/wiki/Release_maintenance for a description of the day to day activities of this role. Those are just a few highlights, please see the wiki page above for the full list. *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

1 0

Possible issues with 942$0 (totalissues) values?
by Theodoros Theodoropoulos 10 Oct '18

10 Oct '18

Hello everyone, There might be some issues in Koha involving 942$0, update_totalissues script and sorting by popularity. If I understand correctly, the update_totalissues script updates biblioitems.totalissues and updates the 942$0 too (see C4::UpdateTotalIssues). Also I believe that sorting by popularity is based on the indexed 942$0 values and not on the values in biblioitems.totalissues So, I think there are a couple of cases where this number can be inaccurate leading to a false sorting-by-polularity. 1. If the value is prefilled by the script, regardless of the 942$0 subfield being hidden in the Marc framework, a librarian with cataloguing permissions may go into the marc editor and change it directly. That number will be indexed by zebra and used in sorting by popularity. The only way of 942$0 being 'fixed' by the system is after a checkout of an item of this biblio is made. Then, the update_totalissues script will requery the DB tables to count the total number of checkouts and update 942$0 2. Likewise, when a librarian with cataloguing permissions duplicates a biblio record with a value in 942$0, this value will be copied to the cloned record as well. As you imagine, this is wrong because it's a NEW biblio record (and probably has no items yet, so no checkouts), so 942$0 should be initially 0. Again this 'cloned' value will be taken by the system as the 'official' number of total checkouts for this biblio (at least for sorting purposes) and will remain there until a checkout of an item of this biblio is made (so the script will recalculate the proper number and hopefully update it) The 1st cannot be solved by simply 'hiding' 942$0 in the Default framework. The script will have the value filled, so the subfield will be visible and editable. Is there a way to hide (or make readonly) certain fields from the cataloguer (even in the advanced editor?). Maybe a new syspref could be incorporated to restrict viewing/editing of certain MARC field/subfields? The 2nd issue seems equally (if not more) important because it's more likely to happen. I vaguely remember a discussion from the past where it was mentioned that by selecting 'flagged' in "Edit Framework Subfields > Advanced constraint values > Visibility", the value of that subfield would not be cloned in a new biblio, but I couldn't reproduce it in my tests. Maybe we could use this for differentiating the case when all checkboxes are unchecked and where flagged is selected? (I believe that right now the behavior of these two is identical). I'm only thinking aloud, so any ideas/comments would be more than welcome! Kind regards, Theodoros Theodoropoulos

1 0

Translation too long
by BOUIS Sonia 09 Oct '18

09 Oct '18

Hello, I've noticed that there's a translation too long in french in catalogue/moredetail.pl so it's unreadable. Cf image. Is there's something to change in the code to allow a longer but clearer translation : Accession date -> Date d'entrée dans les collections Or should we just change the translation for a shorter one ? Thanks in advance [cid:image001.png@01D45D60.7B76E4E0] Sonia BOUIS ------------------------------------------------------ Responsable du Service des applications documentaires Bibliothèques universitaires Université Jean Moulin Lyon 3 ADRESSE GÉOGRAPHIQUE > Manufacture des Tabacs | 6 cours Albert Thomas | LYON 8e ADRESSE POSTALE > Bibliothèque de la Manufacture | 1C avenue des Frères Lumière | CS 78242 - 69372 LYON CEDEX 08 Ligne directe : 33 (0)4 78 78 79 03 http://bu.univ-lyon3.fr<http://bu.univ-lyon3.fr/>| Suivez-nous > Facebook<https://www.facebook.com/bulyon3/> | Twitter<https://twitter.com/bulyon3>| Instagram<https://www.instagram.com/bu.lyon3/?hl=fr> --------------------------------------------------- L'Université Jean Moulin est membre de l'Université de Lyon

4 4

koha-testing-docker - a couple of questions
by David Nind 08 Oct '18

08 Oct '18

I've been getting to grips with using koha-testing-docker ( https://gitlab.com/koha-community/koha-testing-docker) since KohaCon 18. Thanks Kyle and Tomás for having a session on it at the HackFest! A couple of questions - apologies if the answers to these are obvious, I've not really used docker until now... I'm using docker on a Ubuntu 18.04 desktop. env/defaults.env and .env ==================== Is the copy you make of defaults.env only required because docker requires it (as instructed under Setup in the README.md file)? Anything I've updated in .env seems to be ignored in favour of what is in the env/defaults.env file, for example your Git user name and email. However, if you don't have the .env file you get this error when running docker-compose -p koha up : > WARNING: The KOHA_INTRANET_PREFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_INSTANCE variable is not set. Defaulting to a blank string. > WARNING: The KOHA_INTRANET_SUFFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_DOMAIN variable is not set. Defaulting to a blank string. > WARNING: The KOHA_OPAC_PREFIX variable is not set. Defaulting to a blank string. > WARNING: The KOHA_OPAC_SUFFIX variable is not set. Defaulting to a blank string. > WARNING: The RUN_TESTS_AND_EXIT variable is not set. Defaulting to a blank string. > WARNING: The COVERAGE variable is not set. Defaulting to a blank string. > ERROR: The Compose file './docker-compose.yml' is invalid because: > services.koha.networks.kohanet contains non-unique items, please remove duplicates from [u'', u''] For the moment I just make changes in env/defaults.env and copy this to .env UNIMARC support ============== Does koha-testing-docker support UNIMARC at this stage? Adding either UNIMARC or unimarc to the env/defaults.env file didn't seem to make any difference. Normally I would use MARC21, but I was trying to test a UNIMARC patch - the UNIMARC specific script said it only works on UNIMARC (surprisingly enough!). If I try reset_all_unimarc in the container it hangs at the last line: > Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/unimarc/mandatory/authorities_normal_unimarc.sql... > Inserting /kohadevbox/koha/installer/data/mysql/en/marcflavour/unimarc/mandatory/unimarc_framework_DEFAULT.sql... > Setting the MARC flavour on the sysprefs... > Setting Koha version to 18.0600035... > Running [sudo koha-shell kohadev -p -c 'PERL5LIB=/kohadevbox/koha:/kohadevbox/qa-test-tools perl /kohadevbox/misc4dev/create_superlibrarian.pl --userid koha --password koha ']... > Running [sudo koha-shell kohadev -c 'PERL5LIB=/kohadevbox/koha:/kohadevbox/qa-test-tools perl /kohadevbox/misc4dev/insert_data.pl --marcflavour UNIMARC']... > There is no records data for UNIMARC yet at /kohadevbox/misc4dev/ insert_data.pl line 50. Also, is there an easy way to tell if Koha is using UNIMARC? I assume you can tell by looking at the default cataloguing framework (if you know what you are looking for, which I don't). Rebuilding search indexes ===================== After docker is running you don't get any search reults when searching the catalogue. Is having to rebuild the search index manually once docker has started the normal behaviour? Is it possible to have the indexes created as part of docker starting up? Or is there a reason why this isn't done? (Depending on whether you want to use Zebra or Elastic.) Getting my head around docker ========================= I found this quick guide useful to get the concepts of docker https://vsupalov.com/6-docker-basics/ As well, the docker documentation is helpful after that https://docs.docker.com/get-started/ Are there any other useful guides or tutorials that you would recommend to people new to docker? Thanks for everyone's work that has made koha-testing-docker possible! David Nind | david.nind(a)gmail.com PO Box 12367, Thorndon, Wellington, New Zealand 6144 m. +64 21 0537 847

2 2

Koha 17.05.14 release
by Fridolin SOMERS 05 Oct '18

05 Oct '18

The Koha community is proud to announce the release of Koha 17.05.14. This is a maintenance release. Packages will be available in a few days. The full release notes are available at https://koha-community.org/koha-17-05-14-release/ Important /!\ This should be the last 17.05.x release. Please consider upgrading to 17.11.x, it will be maintained for at least the next 6 months. I have proposed to continue managing 17.11.x during next release cycle. Regards, -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> BibLibre, France - software and system maintainer

1 0

The libre Android application "Web Opac" is planning to integrate Koha
by Victor Grousset/tuxayo 04 Oct '18

04 Oct '18

Hi :) https://opac.app/en/ https://github.com/opacapp/opacclient https://f-droid.org/packages/de.geeksfactory.opacclient/ https://github.com/opacapp/opacclient/issues/101#issuecomment-425421264 > Status update: As Koha is becoming more popular in Germany (through LMSCloud, who offer Koha hosting), we are now starting to work on implementing full support for Koha OPACs, including account features. As the new Koha API will probably still use SRU for catalogue search, it will only work for Koha libraries that have SRU enabled. Is their analysis correct? (about SRU stuff) And could there be advice that would help them? -- Victor Grousset, dev support/maintenance BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Libre/Open Source software and services for libraries

2 1

Can't create new Jessie Kohadevbox
by David Cook 04 Oct '18

04 Oct '18

Hi all, I created a Jessie Kohadevbox at the Kohacon18 hackfest and it was all good, but when I've tried making one back at work, it's been failing. Josef pointed me to this issue opened by Owen: https://gitlab.com/koha-community/kohadevbox/issues/273, and I think that I've worked out what's going on. It looks like there was a recent update to the python-reportbug package and it triggers the download of python-openssl version 0.14-1, which seems to create fatal errors in pip and Ansible. The workaround is to remove python-openssl and then re-provision the kohadevbox. Obviously, that's not a great solution for a kohadevbox which should work "out of the box", but it's a solution for now. I haven't tried Stretch with the kohadevbox, but I have a feeling that it might be OK. Hopefully this info is helpful! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 4

KohaDevBox | Debian Stretch
by Tomas Cohen Arazi 03 Oct '18

03 Oct '18

We've shifted the default OS version in KohaDevBox to Debian Stretch. We will try to keep following stable. You can still run Debian Jessie by explicitly asking for it: $ vagrant up jessie $ vagrant ssh jessie and so on. If you already have a Jessie-based box running and update the kohadevbox code, please remember to add the trailing 'jessie' word to the commands you usually ask vagrant to run. Thanks! -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0