<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
</div>If it turns out that a lot of folks are writing plugins or are<br>
planning to, I think we should encourage them to go through a QA<br>
process, and creating an official plugin repository would move us<br>
toward that.</blockquote><div><br></div><div style>That's pretty awesome! I didn't know there were that many people interested writing plugins!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
One of my long-standing concerns about the plugin mechanism is that it<br>
provides a way for developers to bypass the QA process.  Bypassing the<br>
normal release process is one thing -- sometimes you really, really<br>
want to deploy a new feature quickly, but the timing may be such that<br>
it won't be included in a release soon.  Plugins allow developers to<br>
manage such situations while reducing the temptation to maintain a<br>
local fork.<br></blockquote><div><br></div><div style>I totally agree, that was basically the primary reason for adding a plugin system.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

What would QA mean for a plugin?  I suggest that at minimum, a plugin<br>
suitable for inclusion in the official repository must meet the<br>
following conditions:<br>
<br>
- It doesn't break core Koha functionality<br>
- It doesn't do any damage to the server.<br>
- It doesn't (as far as can be tested) create any additional security<br>
vulnerabilities.<br>
- It doesn't *change* core Koha functionality, it just supplies<br>
additional functionality.<br></blockquote><div><br></div><div style>This is a fine and sensible list of requirements.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
To expand on that last point, a plugin that adds a new report or a<br>
dashboard obviously doesn't change core functionality.  A plugin that<br>
adds support for an added content supplier would fall into that<br>
category as well. What I don't think we should be allowing as official<br>
plugins are ones that modify deep internal or external behavior.  For<br>
example, a plugin that completely changed how circulation rules are<br>
represented could easily turn into a support nightmare.  Imagine a<br>
discussion like this on the general mailing list: <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

"My loans aren't getting the correct due dates."<br>
"OK, what version of Koha are you using?  What circ rules have you defined".<br>
"3.14, and thus and such."<br>
"Hmm, looks like it should be working."<br>
"But it's not working."<br>
"OK, I've set up your circ policies on my test database, and it works for me."<br>
"But it's not working."<br>
"..."<br>
"Oh, did I forget to mention that I'm using the<br>
EvergreenStyleCircPolicies plugin?"<br>
"*sigh*"<br></blockquote><div><br></div><div style>The plugins system isn't capable of this kind of functionality, so I don't think we'll have to worry about that. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

On the other hand, the QA barrier for plugins can be lower than for<br>
core code, since there are some things that are required for core code<br>
but can reasonably be considered just good ideas for plugins.  These<br>
include:<br>
<br>
- Functioning correctly for all MARC flavors supported by Koha<br></blockquote><div style><br></div><div style>That is good and sound.</div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

- Supporting I18N/L10N<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Supporting library workflows that vary by country<br></blockquote><div><br></div><div style>I'm not sure what this means, but I don't see any problem with it ; )</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

- Obeying all of our stylistic conventions for code.<br></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Having complete unit test coverage<br></blockquote><div><br></div><div style>For plugins that have unit test-able subroutines, this is quite sensible. I look forward to seeing what plugins everyone comes up with!</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
One thing that just occurred to me is that in addition to distributing<br>
KPZs, we should encourage plugin authors to lay out their plugins in<br>
such a way that they can be readily converted to Debian packages.<br></blockquote><div><br></div><div style>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.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Another thing we could do is set up a koha-plugins Git repository and<br>
encourage folks to use it for version control.  We could also consider<br>
adding "products" to BugZilla for popular plugins.<br></blockquote><div><br></div><div style>Also a great idea! I was able to modify git-web's snapshot utility to allow downloading KPZ files directly from our git reposity.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I have a couple general questions: what plugins have folks written to<br>
date?  What plugins do folks have firm plans to write?<br></blockquote><div><br></div><div style>Here's what I've done so far: <a href="http://git.bywatersolutions.com/koha-plugins.git">http://git.bywatersolutions.com/koha-plugins.git</a></div>
<div style><br></div><div style>It's really not much.</div><div style><br></div><div style>MARC Checker - This plugin runs each record in the Koha database through MARC::Lint and tells you how terrible your marc records are ; )</div>
<div style>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.</div><div style>
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.</div>
<div style> </div><div style>Kyle</div></div></div></div>