I’ve been thinking about this more today, and I think that I’m coming around to 
the plugin idea. 

 

I still think it would be a good idea to have an event-driven messaging system, 
but it seems to me that adding that system will take a lot more 
work/discussion/thinking/experimenting than just improving plugin security and 
plugin tooling…  so I might return to looking at some of the following:

 

Bug 28499 - Add support for no-UI / administrative plugins

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499

 

Bug 25672 - Administrators should be able to disable client-side plugin upload

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25672

 

Bug 25370 - Create allowlist of plugins allowed to be installed by Web UI

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25370

 

Bug 24632 - Plugins should support simple signing for security/verifiability

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24632

 

Bug 25671 - Install 1 Koha plugin for X Koha instances using the CLI

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25671

Bug 28498 - Add CLI counterpart for plugin actions

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28498

 

At the moment, I’m more concerned with security than logistics I think.

 

I think the most feasible option with the least amount of work is probably 
going to be Bug 25370. I’ll default to allowing all plugins to be loaded, and 
then locally I’ll just make sure that all instances have a restricted list. 
That should make everyone happy… 

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-boun...@lists.koha-community.org> On Behalf Of 
dc...@prosentient.com.au
Sent: Friday, 3 December 2021 9:59 AM
To: 'Marcel de Rooy' <m.de.r...@rijksmuseum.nl>; 'koha-devel' 
<koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] [Changed topic] Action hooks

 

That’s cool to hear, Marcel! Happy to share my thoughts.

A couple reasons I don’t want to use plugins:

1.      I don’t want to turn on Koha plugins for 100+ different Koha instances 
around the world.

a.      Overall, I think the Koha plugin system is insecure, and allows library 
staff too much control over the system. I typically keep it disabled with only 
a few exceptions. (I’ve opened a few bugs and provided a few patches for 
improving plugin security but they haven’t gone anywhere yet on Bugzilla.)
b.      I also wouldn’t want library staff to potentially meddle with the 
plugin I install. I think this plugin is really a system plugin rather than a 
user plugin. It should be invisible to library staff.

2.      I’d be looking to install/upgrade plugin code on 100+ different Koha 
instances which presents a maintenance challenge

a.      While I think some vendors use Ansible to do this, I’m not currently 
satisfied with the CLI plugin tooling for install/upgrade/downgrade/uninstall. 
(I’ve done some work on this as well on Bugzilla but the work hasn’t progressed 
and it’s dropped down my priority list.)

                                                               i.      Using an 
Ansible push also isn’t an option in some security/operational contexts. In 
some contexts, you provide artifacts and leave deployment/operations up to a 
different team

b.      I rather install this “system plugin” 1 time on a server rather than X 
times. (I think this is something some other vendors have struggled with and 
worked around as well.)
c.      I’d need to change the instance creation process to install this plugin 
as well. (Not the end of the world but a bit annoying and introduces more room 
for errors.)

 

That said, the hooks already exist, so I can see the appeal, and I can see how 
they’d work well for other people, especially with fewer Koha instances to 
manage. 

 

I suppose it mostly comes down to control, security, and 
maintenance/management. 

 

Also, other systems like Dspace and Fedora write out to message queues out of 
the box, and it makes it easy to add integrations to them without touching the 
core application at all. It would be great if Koha could do the same without 
needing a plugin. (If it were core functionality, we could use it for indexing 
as well and replace the “zebraqueue”.)

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-boun...@lists.koha-community.org 
<mailto:koha-devel-boun...@lists.koha-community.org> > On Behalf Of Marcel de 
Rooy
Sent: Thursday, 2 December 2021 6:15 PM
To: 'koha-devel' <koha-devel@lists.koha-community.org 
<mailto:koha-devel@lists.koha-community.org> >
Subject: Re: [Koha-devel] [Changed topic] Action hooks

 

> I also have a use case where I want to send Koha biblio data elsewhere on 
> create/update/delete, but Koha plugins won't be suitable. I've been thinking 
> that it would be good to publish a message to a RabbitMQ topic on biblio 
> create/update/delete. In fact, that could potentially replace the existing 
> C4::Biblio::_after_biblio_action_hooks and 
> Koha::Item::_after_item_action_hooks functions, and then the 
> background_jobs_worker.pl or some other work could invoke the plugins.

 

I am running plugins to do the same for some time already. They are pushing 
these crud actions to a message queue. Works fine for me. Could you tell what 
makes plugins not suitable for that task?

 



 ​


 <https://www.rijksmuseum.nl/nl/zien-en-doen/tentoonstellingen/vergeet-me-niet> 



​Ook in het Rijksmuseum:
​ <https://www.rijksmuseum.nl/nl/zien-en-doen/tentoonstellingen/henk-wildschut> 
Document Nederland 2021: Afstand. Henk Wildschut fotografeert corona
​ <https://www.rijksmuseum.nl/nl/zien-en-doen?filter=familiemaand> 
​

        


 <https://www.instagram.com/rijksmuseum/> 


x

 <https://www.facebook.com/rijksmuseum> 

x

 <https://www.linkedin.com/company/rijksmuseum/> 

x

 <https://twitter.com/rijksmuseum> 



​Please think before you print

 

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Reply via email to