Hi, with the inclusion of a plugin system we provide a convenient way of injecting functionalities to Koha. I was about to write one myself for implementing some cute graphics (jqPlot) and circulation statistics we had in our 3.0.x fork prior to our 3.8 upgrade. Then I came to think this should indeed be proposed as a new Koha feature (for which there's even a bug). I ended up thinking: - Plugins provide a convenient way to deploy some stuff early (which I need for our 3.12 move), like stuff won't make it into a specific release. - If I succeed I should post it somewhere so people can use it. - There's not a convenient way for it to get QAed so we cannot provide any warranty (not legal but in terms of confidence on Koha as a product) it won't break sensitive stuff (a reports plugin sounds harmless but what limits are imposed to plugins? I guess none). So, I belive we should discuss the creation of a sort of "Official plugins repository" where QAed plugins could be uploaded. I'm thinking out loud and not an native english speaker, so I'm sorry if this is not understandable. Just let me know :-D Regards To+
Hi, On Thu, May 30, 2013 at 9:00 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
So, I belive we should discuss the creation of a sort of "Official plugins repository" where QAed plugins could be uploaded.
If it turns out that a lot of folks are writing plugins or are planning to, I think we should encourage them to go through a QA process, and creating an official plugin repository would move us toward that. One of my long-standing concerns about the plugin mechanism is that it provides a way for developers to bypass the QA process. Bypassing the normal release process is one thing -- sometimes you really, really want to deploy a new feature quickly, but the timing may be such that it won't be included in a release soon. Plugins allow developers to manage such situations while reducing the temptation to maintain a local fork. But wanting or needing to release functionality sooner than the normal release schedule permits is of course no excuse for not doing QA. What would QA mean for a plugin? I suggest that at minimum, a plugin suitable for inclusion in the official repository must meet the following conditions: - It doesn't break core Koha functionality - It doesn't do any damage to the server. - It doesn't (as far as can be tested) create any additional security vulnerabilities. - It doesn't *change* core Koha functionality, it just supplies additional functionality. To expand on that last point, a plugin that adds a new report or a dashboard obviously doesn't change core functionality. A plugin that adds support for an added content supplier would fall into that category as well. What I don't think we should be allowing as official plugins are ones that modify deep internal or external behavior. For example, a plugin that completely changed how circulation rules are represented could easily turn into a support nightmare. Imagine a discussion like this on the general mailing list: "My loans aren't getting the correct due dates." "OK, what version of Koha are you using? What circ rules have you defined". "3.14, and thus and such." "Hmm, looks like it should be working." "But it's not working." "OK, I've set up your circ policies on my test database, and it works for me." "But it's not working." "..." "Oh, did I forget to mention that I'm using the EvergreenStyleCircPolicies plugin?" "*sigh*" On the other hand, the QA barrier for plugins can be lower than for core code, since there are some things that are required for core code but can reasonably be considered just good ideas for plugins. These include: - Functioning correctly for all MARC flavors supported by Koha - Supporting I18N/L10N - Supporting library workflows that vary by country - Obeying all of our stylistic conventions for code. - Having complete unit test coverage One thing that just occurred to me is that in addition to distributing KPZs, we should encourage plugin authors to lay out their plugins in such a way that they can be readily converted to Debian packages. Another thing we could do is set up a koha-plugins Git repository and encourage folks to use it for version control. We could also consider adding "products" to BugZilla for popular plugins. I have a couple general questions: what plugins have folks written to date? What plugins do folks have firm plans to write? Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
If it turns out that a lot of folks are writing plugins or are planning to, I think we should encourage them to go through a QA process, and creating an official plugin repository would move us toward that.
That's pretty awesome! I didn't know there were that many people interested writing plugins!
One of my long-standing concerns about the plugin mechanism is that it
provides a way for developers to bypass the QA process. Bypassing the normal release process is one thing -- sometimes you really, really want to deploy a new feature quickly, but the timing may be such that it won't be included in a release soon. Plugins allow developers to manage such situations while reducing the temptation to maintain a local fork.
I totally agree, that was basically the primary reason for adding a plugin system.
What would QA mean for a plugin? I suggest that at minimum, a plugin suitable for inclusion in the official repository must meet the following conditions:
- It doesn't break core Koha functionality - It doesn't do any damage to the server. - It doesn't (as far as can be tested) create any additional security vulnerabilities. - It doesn't *change* core Koha functionality, it just supplies additional functionality.
This is a fine and sensible list of requirements.
To expand on that last point, a plugin that adds a new report or a dashboard obviously doesn't change core functionality. A plugin that adds support for an added content supplier would fall into that category as well. What I don't think we should be allowing as official plugins are ones that modify deep internal or external behavior. For example, a plugin that completely changed how circulation rules are represented could easily turn into a support nightmare. Imagine a discussion like this on the general mailing list:
"My loans aren't getting the correct due dates."
"OK, what version of Koha are you using? What circ rules have you defined". "3.14, and thus and such." "Hmm, looks like it should be working." "But it's not working." "OK, I've set up your circ policies on my test database, and it works for me." "But it's not working." "..." "Oh, did I forget to mention that I'm using the EvergreenStyleCircPolicies plugin?" "*sigh*"
The plugins system isn't capable of this kind of functionality, so I don't think we'll have to worry about that.
On the other hand, the QA barrier for plugins can be lower than for core code, since there are some things that are required for core code but can reasonably be considered just good ideas for plugins. These include:
- Functioning correctly for all MARC flavors supported by Koha
That is good and sound.
- Supporting I18N/L10N
That certainly seems reasonable. I don't know what would be involved with plugin translation, but the plugins do process templates using Koha's internal templating system.
- Supporting library workflows that vary by country
I'm not sure what this means, but I don't see any problem with it ; )
- Obeying all of our stylistic conventions for code.
Yes, that is good and sensible. Since plugins are 'wrapped' in the standard Koha header and footer, it would just be bad ui design not to leverage what Koha already offers as far as the ui toolkit goes.
- Having complete unit test coverage
For plugins that have unit test-able subroutines, this is quite sensible. I look forward to seeing what plugins everyone comes up with!
One thing that just occurred to me is that in addition to distributing KPZs, we should encourage plugin authors to lay out their plugins in such a way that they can be readily converted to Debian packages.
This is something I hadn't thought of. So, my interpretation would be if you are running Koha from a debian package, you could install Koha plugins from packages as well? This is certainly a cool idea.
Another thing we could do is set up a koha-plugins Git repository and encourage folks to use it for version control. We could also consider adding "products" to BugZilla for popular plugins.
Also a great idea! I was able to modify git-web's snapshot utility to allow downloading KPZ files directly from our git reposity.
I have a couple general questions: what plugins have folks written to date? What plugins do folks have firm plans to write?
Here's what I've done so far: http://git.bywatersolutions.com/koha-plugins.git It's really not much. MARC Checker - This plugin runs each record in the Koha database through MARC::Lint and tells you how terrible your marc records are ; ) Force Delete Record - Sometimes a record gets corrupted so you cannot even view the record in Koha ( and thus cannot delete it ). This plugin allows you to forcefully delete a record by biblionumber. Rolling Hard Due Dates - This is by far my most complicated plugin, and has undergone rigorous testing. It allows you to schedule updates to the hard due dates for circulation rules, and update the due dates for items checked out that those rules apply to. This was written for a university where they change the due dates on checkouts near the end of each semester. Kyle
Hi, On Fri, May 31, 2013 at 8:30 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
That's pretty awesome! I didn't know there were that many people interested writing plugins!
Well, there's clearly at least one. :) More seriously, I don't know how much interest there is overall, but for the plugin feature to be maintainable in the long term, I think it needs relatively broad use.
The plugins system isn't capable of this kind of functionality, so I don't think we'll have to worry about that.
Plugins have unrestricted access to the database, right? Even if one couldn't readily write one that interjects itself into the loan rules calculating, unrestricted database access means that plugins have the potential to intermingle with core functionality.
- Supporting library workflows that vary by country
I'm not sure what this means, but I don't see any problem with it ; )
What I meant by this is that a plugin could be all about the American workflow, or all about the French workflow, and not care about implementing a broadly usable feature.... and that would be OK.
One thing that just occurred to me is that in addition to distributing KPZs, we should encourage plugin authors to lay out their plugins in such a way that they can be readily converted to Debian packages.
This is something I hadn't thought of. So, my interpretation would be if you are running Koha from a debian package, you could install Koha plugins from packages as well? This is certainly a cool idea.
Right. For example, Debianized plugins could take advantage of APT dependency management.
Here's what I've done so far: http://git.bywatersolutions.com/koha-plugins.git
Thanks for the link.
MARC Checker - This plugin runs each record in the Koha database through MARC::Lint and tells you how terrible your marc records are ; )
This looks like a good example of where I think a plugin shines: running reports that need special handling beyond what SQL gives you. It would, of course, be nice if MARC linting were available directly in the Koha MARC editor, but the existence of the plugin doesn't preclude developing that in the future.
Force Delete Record - Sometimes a record gets corrupted so you cannot even view the record in Koha ( and thus cannot delete it ). This plugin allows you to forcefully delete a record by biblionumber.
I'm getting a bit of a twitch here -- I see the utility of this as a workaround, but I hope that this plugin has a very short life on account of the underlying bugs getting fixed.
Rolling Hard Due Dates - This is by far my most complicated plugin, and has undergone rigorous testing. It allows you to schedule updates to the hard due dates for circulation rules, and update the due dates for items checked out that those rules apply to. This was written for a university where they change the due dates on checkouts near the end of each semester.
I have stronger reservations about this one -- not about the functionality it implements, but that it exists as a plugin. Adjusting due dates at the end of a semester strikes me as something that a number of academic libraries might want; I hope this get submitted for consideration as a core feature. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Plugins have unrestricted access to the database, right? Even if one couldn't readily write one that interjects itself into the loan rules calculating, unrestricted database access means that plugins have the potential to intermingle with core functionality.
Yes, that is correct.
MARC Checker - This plugin runs each record in the Koha database through MARC::Lint and tells you how terrible your marc records are ; )
This looks like a good example of where I think a plugin shines: running reports that need special handling beyond what SQL gives you.
It would, of course, be nice if MARC linting were available directly in the Koha MARC editor, but the existence of the plugin doesn't preclude developing that in the future.
Agreed. Most plugin logic would make for a very good basis for an Koha patch. I'm no GPL expert, but I believe all plugins must be GPL'ed because they link to Koha code, which is itself GPL. So, anyone should be able to take any Koha plugin and use that code as part of a patch, even if the plugin author isn't interested in doing so.
Force Delete Record - Sometimes a record gets corrupted so you cannot even view the record in Koha ( and thus cannot delete it ). This plugin allows you to forcefully delete a record by biblionumber.
I'm getting a bit of a twitch here -- I see the utility of this as a workaround, but I hope that this plugin has a very short life on account of the underlying bugs getting fixed.
Agreed. This utility is a workaround for an as-of-yet unidentified bug.
Rolling Hard Due Dates - This is by far my most complicated plugin, and has undergone rigorous testing. It allows you to schedule updates to the hard due dates for circulation rules, and update the due dates for items checked out that those rules apply to. This was written for a university where they change the due dates on checkouts near the end of each semester.
I have stronger reservations about this one -- not about the functionality it implements, but that it exists as a plugin. Adjusting due dates at the end of a semester strikes me as something that a number of academic libraries might want; I hope this get submitted for consideration as a core feature.
If I had known this would be of interest to more users, I would have started with a patch instead of a plugin. I'd be more than happy to patch-ify this plugin when I have the time. In general, I'd say a patch is always better than a plugin, as plugins will have to be maintained actively in case the database schema changes or some of the internal Koha functions the plugin uses are altered or removed, Kyle
On Fri, May 31, 2013 at 1:02 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Rolling Hard Due Dates - This is by far my most complicated plugin, and has undergone rigorous testing. It allows you to schedule updates to the hard due dates for circulation rules, and update the due dates for items checked out that those rules apply to. This was written for a university where they change the due dates on checkouts near the end of each semester.
I have stronger reservations about this one -- not about the functionality it implements, but that it exists as a plugin. Adjusting due dates at the end of a semester strikes me as something that a number of academic libraries might want; I hope this get submitted for consideration as a core feature.
If I had known this would be of interest to more users, I would have started with a patch instead of a plugin. I'd be more than happy to patch-ify this plugin when I have the time. In general, I'd say a patch is always better than a plugin, as plugins will have to be maintained actively in case the database schema changes or some of the internal Koha functions the plugin uses are altered or removed,
This sort of thing has been asked for before and discussed IIRC. I think it was waiting on a circ rule re-write due to the undue complexity (read "poor coding") of the original feature. Kind Regards, Chris
On 1 June 2013 05:24, Christopher Nighswonger <chris.nighswonger@gmail.com> wrote:
On Fri, May 31, 2013 at 1:02 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This sort of thing has been asked for before and discussed IIRC. I think it was waiting on a circ rule re-write due to the undue complexity (read "poor coding") of the original feature.
That was my recollection also, but I do agree this sounds like core functionality Chris
On Fri, May 31, 2013 at 4:28 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
On 1 June 2013 05:24, Christopher Nighswonger <chris.nighswonger@gmail.com> wrote:
On Fri, May 31, 2013 at 1:02 PM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
This sort of thing has been asked for before and discussed IIRC. I think it was waiting on a circ rule re-write due to the undue complexity (read "poor coding") of the original feature.
That was my recollection also, but I do agree this sounds like core functionality
Definitely core functionality IMHO as well. And IIRC the circ rule code could very much indeed use a rewrite. I do like Kyle's plugin as a stop-gap, though. I hate having to do the "SQL thing" twice a year... :-) Kind Regards, Chris
On 1 June 2013 05:02, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Plugins have unrestricted access to the database, right? Even if one couldn't readily write one that interjects itself into the loan rules calculating, unrestricted database access means that plugins have the potential to intermingle with core functionality.
Yes, that is correct.
Yep, I think this is why the QA and disclaimer of warranty are important. Chris
participants (5)
-
Chris Cormack -
Christopher Nighswonger -
Galen Charlton -
Kyle Hall -
Tomas Cohen Arazi