Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Right now, to check if a plugin is functional and what methods it exposes we load the module and test for a given method at run time. This is highly inefficient. It makes far more sense to do this at install time and store the data in the db. I believe we should store a table of methods that each plugin exposes and check that instead. Then, at install time we can test that a) the plugin can be loaded and b) add the available methods to the plugin_methods table.
Test Plan:
1) Apply this patch
2) Restart all the things
3) Run updatedatabase.pl
4) Verify you can use existing plugins
5) Verify you can install new plugins
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
TEST PLAN
---------
-- apply first patch
git grep "C4::Plugin"
-- still two references
perldoc Koha::Plugins::Base
perldoc Koha::Plugins::Handler
-- apply this patch
git grep "C4::Plugin"
-- no references
perldoc Koha::Plugins::Base
perldoc Koha::Plugins::Handler
-- should look fixed
Please enter the commit message for your changes. Lines starting
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
It would be very useful to be able to define multiple plugin directories
in the Koha conf file. This would allow for ease of plugin development
so that each plugin installed can live in its own git repository. For
compatibility, the first plugindir instance defined should be the one
used for uploading plugins via the web interface.
Test Plan:
1) Apply this patch
2) Define a second pluginsdir line in your koha-conf.xml
3) Clone the kitchen sink plugin to this new path like this:
git clone https://github.com/bywatersolutions/koha-plugin-kitchen-sink.git /path/to/new/plugins/dir
4) Restart memcached if you are running it
5) The Kitchen Sink plugin should now appear in your list of plugins!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
I rebased it against master and tested it on a kohadevbox
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
To Test
1/ Try using a plugin
2/ Apply patch
3/ Test plugin still works
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
If you run Plugin.t, the above table will still be present (when you
did not enable UseKohaPlugins). This would trigger a warning when
running the test a second time.
Why? The uninstall call does its work not completely due to a small
inconsistency in Koha::Plugins::Handler::delete when calling run
without the enable_plugins parameter.
This patch resolves that inconsistency and also removes an unneeded skip
in Plugin.t in case the KitchenSink module already exists.
Note: This is a small fix. But I wonder if the Handler routines run and
delete should not have been implemented in Koha::Plugins::Base.
Also note that plugins/plugins-uninstall.pl will not be affacted by this
change, since it checks whether the pref is enabled before calling the
delete method.
Test plan:
[1] Do not yet install this patch.
[2] Verify that plugins are enabled in koha-conf.xml.
[3] Disable UseKohaPlugins in System Preferences!
[4] Run t/db_dependent/Plugins.t.
[5] Verify that table koha_plugin_com_bywatersolutions_kitchensink_mytable
still exists. (It should have been deleted.) Remove it manually.
[6] Apply this patch.
[7] Run the test again.
[8] Verify that the table does not exist.
[9] Run the test again (without warnings).
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Srdjan <srdjan@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Many libraries would like to be able to import various types of files as
MARC records ( citations, csv files, etc ). We can add a new function to
the plugins system to allow that kind of behavior at a very custom
level.
Test Plan:
1) Ensure you have plugins enabled and configured correctly
2) Installed the attached version 2.00 of the Kitchen Sink plugin
3) Download the attached text file
4) Browse to "Stage MARC records for import"
5) Select the downloaded text file for staging
6) After uploading, you should see a new area "Transform file to MARC:",
select "Example Kitchen-Sink Plugin" from the pulldown menu
7) Click 'Stage for import"
8) Click 'Manage staged records"
9) You should now see two new MARC records!
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described - interesting new feature.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
* Add "Plugins disabled" screen instead of error
* Allow plugins to return a value, add a test run that checks the return value
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Tests Ok
~/kohaclone$ perl t/db_dependent/Plugins.t
1..15
ok 1 - use Koha::Plugins;
ok 2 - use Koha::Plugins::Handler;
ok 3 - use Koha::Plugins::Base;
ok 4 - use Koha::Plugin::Test;
ok 5 - Test can_load
ok 6 - Test plugin class isa Koha::Plugin::Test
ok 7 - Test plugin parent class isa Koha::Plugins::Base
ok 8 - Test plugin can report
ok 9 - Test plugin can tool
ok 10 - Test plugin can configure
ok 11 - Test plugin can install
ok 12 - Test plugin can install
ok 13 - Test $plugin->get_metadata()
ok 14 - Test $plugin->get_qualified_table_name()
ok 15 - Test $plugin->get_plugin_http_path()
(and all others as well)
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Adds support for custom plugins. At the moment the Plugins
feature supports two types of plugins, reports and tools.
Plugins are installed by uploading KPZ ( Koha Plugin Zip )
packages. A KPZ file is just a zip file containing the
perl files, template files, and any other files neccessary
to make the plugin work.
Test plan:
1) Apply patch
2) Run updatedatabase.pl
3) Create the directory /var/lib/koha/plugins
4) Add the lines
<pluginsdir>/var/lib/koha/plugins</pluginsdir>
<enable_plugins>1</enable_plugins>"
to your koha-conf.xml file
5) Add the line
Alias /plugin/ "/var/lib/koha/plugins/"
to your koha-httpd.conf file
6) Restart your webserver
7) Access the plugins system from the "More" pulldown
8) Upload the example plugin file provided here
9) Try it out!
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Tomas Cohen Arazi
Agustin Moyano
Kyle M Hall
Mark Tompsett
Jonathan Druart
Chris Cormack
Marcel de Rooy
Jonathan Druart
Kyle M Hall