<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">Plugins have unrestricted access to the database, right?  Even if one</span><br>
</div>
couldn't readily write one that interjects itself into the loan rules<br>
calculating, unrestricted database access means that plugins have the<br>
potential to intermingle with core functionality.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>Yes, that is correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">

> MARC Checker - This plugin runs each record in the Koha database through<br>
> MARC::Lint and tells you how terrible your marc records are ; )<br>
<br>
</div>This looks like a good example of where I think a plugin shines:<br>
running reports that need special handling beyond what SQL gives you.<br>
<br>
It would, of course, be nice if MARC linting were available directly<br>
in the Koha MARC editor, but the existence of the plugin doesn't<br>
preclude developing that in the future.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Force Delete Record - Sometimes a record gets corrupted so you cannot even<br>
> view the record in Koha ( and thus cannot delete it ). This plugin allows<br>
> you to forcefully delete a record by biblionumber.<br>
<br>
</div>I'm getting a bit of a twitch here -- I see the utility of this as a<br>
workaround, but I hope that this plugin has a very short life on<br>
account of the underlying bugs getting fixed.</blockquote><div><br></div><div style>Agreed. This utility is a workaround for an as-of-yet unidentified bug. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> Rolling Hard Due Dates - This is by far my most complicated plugin, and has<br>
> undergone rigorous testing. It allows you to schedule updates to the hard<br>
> due dates for circulation rules, and update the due dates for items checked<br>
> out that those rules apply to. This was written for a university where they<br>
> change the due dates on checkouts near the end of each semester.<br>
<br>
</div>I have stronger reservations about this one -- not about the<br>
functionality it implements, but that it exists as a plugin.<br>
Adjusting due dates at the end of a semester strikes me as something<br>
that a number of academic libraries might want; I hope this get<br>
submitted for consideration as a core feature.<br></blockquote><div><br></div><div style>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,</div>
<div style><br></div><div style>Kyle</div><div style><br></div></div></div></div>