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

Plugin Security, Plugin Repositories, etc
by dcook＠prosentient.com.au 22 May '20

22 May '20

Hi all, I was doing my morning reading, and noticed that Microsoft have a Windows Package Manager in the works (https://www.theverge.com/2020/5/20/21264739/microsoft-windows-package-manag er-preview-download). While that might not be newsworthy for many people interested in FOSS, you might reconsider when you look at what they're doing for a community metadata repository: https://github.com/microsoft/winget-pkgs Here's an example of a metadata file for 7-zip in that repository: https://github.com/microsoft/winget-pkgs/blob/master/manifests/7Zip/7Zip/19. 0.0.yaml. It includes a URL to the installer and a SHA256 hash for integrity checking. Now according to https://github.com/microsoft/winget-cli, it doesn't look like they're using that Github repository as *the* metadata source repository. Indeed after a bit of digging it appears that the actual default metadata source is https://winget.azureedge.net/cache/source.msix, which contains a SQLite database of metadata (index.db). I think that's an interesting model. We could use http://gitlab.com/koha-community/plugins like https://github.com/microsoft/winget-pkgs where people could submit pull requests to get plugin metadata added to the repository. That would enable there to be a basic level of curation. We could then use something like https://plugins.koha-community.org/ to serve actual metadata (in whatever standardish format we want) to either the Koha web UI (and a Debian package Koha CLI tool like "koha-plugin-get" which make plugin deployment and maintenance potentially easier for sysadmins). There could be an automated process for updating plugins.koha-community.org from http://gitlab.com/koha-community/plugins too. People would be free to point to other plugin metadata repositories (e.g. vendor-specific repos), but by default it would be set up for the Koha Community plugin metadata repository. In terms of security, we could mimic Debian's Apt model of signing the plugin metadata manifest. That way, when setting up a plugin metadata repository in Koha, all you need to do is import a public key/cert to get trusted access to the repo. With the Koha Community repository, we could bake that public key/cert into Koha releases, so it would be seamless for end users. The hardest part of this process would be settling on what metadata manifest format to use for https://plugins.koha-community.org/. Actually, the hardest part would be trying to maintain some kind of backward compatibility. Maybe that's best done by rebranding the current plugin model as "Legacy Plugins" or "Manual Plugins" and then just building a separate web UI for the Repository model. We could re-use the same internals. We could also have separate controls for enabling/disabling "Manual Plugins" vs "Repository Plugins", so that vendors could provide access to plugins via a repository but prevent people from uploading random plugins from the Internet. Anyway, food for thought. I'm happy to do a lot of this work (probably in my personal time rather than work time), but I'd want to make sure there is some buy-in from other vendors and Koha plugin creators first. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Koha release 19.11.06
by Joy Nelson 22 May '20

22 May '20

Greetings! The Koha community is proud to announce the release of Koha 19.11.06. It includes 23 enhancements and 122 bug fixes. The full release notes are available at https://koha-community.org/koha-19-11-06-release/ Debian packages will be updated within a few days. -- Joy Nelson President, Koha Division ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/>

1 0

Debian packaging problems for master and 19.11
by dcook＠prosentient.com.au 18 May '20

18 May '20

Hi all, You may or may not have noticed, but there are a few outstanding bugs for the Debian packaging for master and 19.11. I've contributed patches to all of them, so I can't really move them forward, but it would be great if other folk could take a look at these ASAP. I know packaging bugs are tough to test. I've spent almost a whole day writing code and testing. But here are some options: https://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way https://hub.docker.com/r/koha/koha-dpkg https://gitlab.com/minusdavid/koha-deb-builder-docker Bugs: master: Bug 25068 - koha-common build error caused by missing /etc/searchengine https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25068 19.11 (and possibly older versions although I haven't checked): Bug 25485 - TinyMCE broken in Debian package installs https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25485 Bug 25510 - Typo in koha-common.postinst causing shell errors https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25510 Bug 25524 - Debian packages always append to /etc/koha/sites/$site/log4perl.conf https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25524 Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Bug 19361 - Linking an authorised value category to a field can lose data
by Alex Buckley 18 May '20

18 May '20

Hi all, I'm interested to hear thoughts on bug 19361 ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19361 ). i.e. when a free entry MARC subfield contains data and you link an authorised value category to that subfield then upon editing the bibliographic record the data is lost. Do you think this behaviour should be kept (i.e. when a MARC subfield is linked to an authorised value category then the subfield value must thereafter be an authorised value) or should be fixed to keep the original value? Any thoughts much appreciated! Many thanks, Alex -- Alex Buckley Koha Developer Catalyst IT - Expert Open Source Solutions DDI: +64 4 803 2378 | Mob: +64 22 429 6157 | www.catalyst.net.nz CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267.

1 0

Call for news: April 2020 Koha Newsletter
by Koha Newsletter 14 May '20

14 May '20

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

Improving usability of Tools > Upload feature w/ Copy Link button
by dcook＠prosentient.com.au 14 May '20

14 May '20

Hi all, Just sharing that I've posted a patch that adds a "Copy link" button the Tools > Upload feature, which makes it easier to link to files that have been uploaded into Koha. For example, uploading a photo of the library via "Tools > Upload" and then copying the link and pasting it into OpacMainuserBlock in an img element. The patch shows the file URL in a modal so you can manually copy and paste, plus it uses feature detection to see if it can use the Clipboard API (available in modern browsers like Chrome, Firefox, Edge - but not newer IE) to just copy it directly to your browser clipboard. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25475 Would love to get some feedback on this one. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Maintenance Branches - String Freeze
by Joy Nelson 13 May '20

13 May '20

Hello all! String Freeze will go into effect on Friday, May 15, 2020 for the 19.11, 19.05, 18.11 branches. Monthly releases for those branches will be out on Friday, May 22, 2020. Thank you! -- Joy Nelson President, Koha Division ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/>

1 0

KTD: elasticsearch-icu images
by Tomas Cohen Arazi 13 May '20

13 May '20

The docker images that koha-testing-docker uses for Elastic were manually built until yesterday. >From now on, their build is handled through CI on this new Gitlab project: https://gitlab.com/koha-community/docker/koha-elasticsearch-icu Official base elastic images are not tagged like 5.x, but with specific versions like in 5.6.1. So if you feel some of the versions we handle has been left behind (5.x was 5.5.1 until yesterday) you should send a pull request for the specific branch or file am issue on the mentioned gitlab project. This also applies for other tweaks this images might need, as disabling x-pack or other 'features'. Pull requests and suggestions are welcome :-D Best regards -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0

KTD: ES6 as default, support for ES7
by Tomas Cohen Arazi 11 May '20

11 May '20

Hi. As discussed on today's dev meeting, I moved forward a pushed a series of patches for koha-testing-docker that: - Update the ES docker images we use (official+icu-analysis plugin) to the latest version - Create a koha/elasticsearch-icu:7.x image - Set ES 6 as the new default for KTD - Added an alias to be able to still test ES 5 - Added an alias to be able to test ES 7 That was my TODO from the dev meeting. Looking forward to address any issues this could cause. PS: The discussion involved setting SearchEngine to Elasticsearch on misc4dev by default, but I'm not sure there was consensus on that. People present on the meeting, please answer this email with your perceptions. -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

3 3

limit in subquery causing issues with SQL report?
by dcook＠prosentient.com.au 08 May '20

08 May '20

Hi all, I haven't investigated this deep enough to open a Bugzilla report, but has anyone else had the experience of a limit in a subquery causing issues with the surrounding SQL query? I had a subquery in the select statement with a limit of 1, and it was causing my output to only display 1 row, and broke the paging. This was on an older version of Koha. Haven't tried with a newer one yet. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0