On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We are using Koha::Logger when it makes sense to keep the info,
otherwise we simply remove it
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Bug 28572: Replace missing occurrence in misc/admin/koha-preferences
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!
Test plan:
Confirm the assumption
Review the changes from this patch
Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl
git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the option to add Gitlab repositories to look for
Koha plugins. As with Github, plugin projects need to be named
koha-plugin-* and the release file needs to be named with the .kpz
extension.
To test:
1. Apply this patchset
2. Check either koha-conf.xml or koha-conf.site.xml.in for sample
configurations of gitlab targets.
3. Tweak your koha-conf.xml accordingly. You could have:
<plugin_repos>
<repo>
<name>ByWater Solutions</name>
<org_name>bywatersolutions</org_name>
<service>github</service>
</repo-
<repo>
<name>Theke Solutions</name>
<org_name>thekesolutions</org_name>
<service>gitlab</service>
</repo>
<repo>
<name>PTFS Europe</name>
<org_name>ptfs-europe</org_name>
<service>github</service>
</repo>
</plugin_repos>
4. Flush memcached and restart plack:
$ flush_memcached
$ koha-plack --restart kohadev
5. Open the plugins page, search for anything, like 'gobi' or 'a'
=> SUCCESS: You get Theke results!
6. Pick a gitlab plugin for install
=> SUCCESS: It is installed!
7. Sign off :-D
Sponsored-by: Theke Solutions
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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch fixes this nasty problem with how XML is parsed: if more than
one entry is found, repo => [] is generated. If only one, repo => {}.
To test:
1. Have more than one entries in the plugins_repo entry:
<plugin_repos>
<repo>
<name>ByWater Solutions</name>
<org_name>bywatersolutions</org_name>
<service>github</service>
</repo>
<repo>
<name>Theke Solutions</name>
<org_name>thekesolutions</org_name>
<service>github</service>
</repo>
<repo>
<name>PTFS Europe</name>
<org_name>ptfs-europe</org_name>
<service>github</service>
</repo>
</plugin_repos>
2. Search for plugins
=> SUCCESS: Searching works!
3. Leave only one entry
4. Restart all to refresh things
5. Try searching for plugins
=> FAIL: Fatal error
6. Apply this patch
7. Repeat 5
=> SUCCESS: It doesn't explode anymore!
8. Sign off :-D
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: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds handling for the newly introduced 'errors' option in
GetPlugins and reports erroroneos plugins to the user.
To test:
1 - Enable plugins in the koha-conf
2 - Install the kitchen sink plugin
3 - Your staff client should be orange now :-)
4 - The plugin should display as installed in the table at
tools/plugins.
5 - edit the plugin module
/var/lib/koha/kohadev/plugins/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm
6 - Add a line to break compilation, like:
this won't compile
7 - Restart all
8 - Your Koha is not broken, but is no longer orange (The plugin is not
loading).
9 - The plugin should display as unable to load in the table at
tools/plugins.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a .perlcriticrc (copied from qa-test-tools) and fixes
almost all perlcrictic violations according to this .perlcriticrc
The remaining violations are silenced out by appending a '## no critic'
to the offending lines. They can still be seen by using the --force
option of perlcritic
This patch also modify t/00-testcritic.t to check all Perl files using
the new .perlcriticrc.
I'm not sure if this test script is still useful as it is now equivalent
to `perlcritic --quiet .` and it looks like it is much slower
(approximatively 5 times slower on my machine)
Test plan:
1. Run `perlcritic --quiet .` from the root directory. It should output
nothing
2. Run `perlcritic --quiet --force .`. It should output 7 errors (6
StringyEval, 1 BarewordFileHandles)
3. Run `TEST_QA=1 prove t/00-testcritic.t`
4. Read the patch. Check that all changes make sense and do not
introduce undesired behaviour
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
As promised, I am commenting out the configuration for git repositories
to use for searches by default prior to release. To enable the feature,
simply uncomment the relevant github repositories or add your own.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Owen Leonard 2018-03-16 10:47:47 UTC :
<<
I don't think the system preference adds any security. There are already multiple permissions required for working with plugins:
- Configure plugins
- Manage plugins ( install / uninstall )
- Use report plugins
- Use tool plugins
And even with those permissions your server must be configured to allow the use of plugins.
>>
Test plan :
1) Install kitchen sink plugin https://github.com/bywatersolutions/koha-plugin-kitchen-sink
2) Run misc/devel/install_plugins.pl
3) Set config enable_plugins=1
4) Check all parts of the plugin are working
5) Set config enable_plugins=0
6) Check all parts of the plugin are disabled
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The `save_to` shortcut method was introduced to Mojolicious in version
8.02 but we still support 7.21 as our minimum dependancy and as such we
cannot yet use it.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
It would be nice to be able to search and install plugins directly from GitHub ( and GitLab if possible ). This would make it easier to verify the authenticity of plugins and make discovering new plugins easier as well as making installation of plugins simpler.
Test Plan:
1) Apply this patch
2) Add the new block for plugin_repos to your koha-conf.xml
3) Restart all the things!
4) Browse to the plugins home page
5) Try searching for 'patrons' in the new search box
6) Verify you get results!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
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>
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 this patch(es),
- launch an updatedabase,
- go to plugins/plugins-home.pl
and deal with enable/disable method
- install a plugin like KitchenSink
https://github.com/bywatersolutions/koha-plugin-kitchen-sink
- once installed, the plugin change the background color
of the staff client to orange.
- disable the plugin,
- background color should be set back to the original one
Rebased-on: 2019-03-25 Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Agustin Moyano <agustinmoyano@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test Plan:
- Check that it now says 'use Modern::Perl' and not 'use trict; use
warnings;' in the follwing plugins perl scripts
plugins-home.pl
plugins-uninstall.pl
plugins-upload.pl
run.pl
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
After uploading a plugin the error log indicates
use of uninitialized value in $op. This patch
silences the noise.
To test:
1) Set <enable_plugins> to 1 (one) in koha-conf.xml.
2) Set the UseKohaPlugins system preference to 'Enable'.
3) Navigate to Administration -> Manage plugins.
4) Install the test plugin KPZ file attached to this bug.
5) Notice the uninitialized value noise in the error log.
6) Uninstall the plugin (plack restart may be required if plack is
enabled).
7) Apply patch.
8) Install the plugin again.
9) Notice no noise in the error log.
10) Run qa tools.
11) Run prove t/db_dependent/Plugins.t
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
It would be helpful if we could find a plugin based on some metadata
tag as returned by the plugin. This extends the use of GetPlugins that
already supports searching on method.
GetPlugins is used in: admin/edi_accounts.pl, plugins/plugins-home.pl and
tools/stage-marc-import.pl. The changes in these three scripts are
minimal and just related to parameter passing.
Test t/db_dependent/Plugins.t includes another test for GetPlugins. In this
regard a metadata tag has been added to t/Koha/Plugins/Test.pm.
NOTE: This adjustment will also be used in a redesign for bug 15545.
Test plan:
Run t/db_dependent/Plugins.t.
Enable pref UseKohaPlugins and config var enable_plugins.
Go to plugins-home.pl. Verify that it still lists your plugins.
Bonus: Check edi_accounts or stage-marc-import.pl if you have a working
plugin for that.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.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>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.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>
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>
