Bug 28499 - Add support for no-UI / administrative plugins
Summary: Add support for no-UI / administrative plugins
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Plugin architecture (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-01 14:49 UTC by Nick Clemens
Modified: 2023-08-20 23:08 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens 2021-06-01 14:49:23 UTC
It would be helpful for support to have the ability to add plugins that configure/affect the syste, but are not accessible by the users (cannot be removed, edited, etc)
Comment 1 David Cook 2021-06-02 02:52:02 UTC
Oooh I like the sound of this. 

Ideally, I'd like to not allow libraries to install their own plugins (similar to Bug 25672), but I would like to be able to install plugins on their system from the CLI.
Comment 2 David Cook 2021-06-02 02:55:14 UTC
One question:

Would the plugin itself denote itself as non-accessible to users, or would it be a flag used when installing via the CLI?
Comment 3 Tomás Cohen Arazi 2021-06-02 03:00:51 UTC
(In reply to David Cook from comment #2)
> One question:
> 
> Would the plugin itself denote itself as non-accessible to users, or would
> it be a flag used when installing via the CLI?

I think both use cases are valid and interesting. I was pointing more to the first one in an initial approach, as the second one has interesting edge cases, like users installing a new version, etc.

What do you think it would be best?
Comment 4 David Cook 2021-06-02 03:21:20 UTC
(In reply to Tomás Cohen Arazi from comment #3)
> (In reply to David Cook from comment #2)
> > One question:
> > 
> > Would the plugin itself denote itself as non-accessible to users, or would
> > it be a flag used when installing via the CLI?
> 
> I think both use cases are valid and interesting. I was pointing more to the
> first one in an initial approach, as the second one has interesting edge
> cases, like users installing a new version, etc.
> 
> What do you think it would be best?

I think the first one is probably the most realistic. Like you say, the second one has too many edge cases I think.
Comment 5 David Cook 2023-07-24 05:45:29 UTC
Bug 34335 could be used for interacting with the plugin. 

We'd still need something to prevent the plugin from being affected by web users though.
Comment 6 David Cook 2023-08-17 00:23:31 UTC
(In reply to Tomás Cohen Arazi from comment #3)
> (In reply to David Cook from comment #2)
> > Would the plugin itself denote itself as non-accessible to users, or would
> > it be a flag used when installing via the CLI?
> 
> I think both use cases are valid and interesting. I was pointing more to the
> first one in an initial approach, as the second one has interesting edge
> cases, like users installing a new version, etc.
> 
> What do you think it would be best?

Actually, I think it would need to be a flag, because you might want to distribute a third-party plugin via a shared directory to many Koha instances and not want 1 Koha admin to be able to uninstall it for everyone...
Comment 7 David Cook 2023-08-17 00:40:33 UTC
(In reply to David Cook from comment #6)
> Actually, I think it would need to be a flag, because you might want to
> distribute a third-party plugin via a shared directory to many Koha
> instances and not want 1 Koha admin to be able to uninstall it for
> everyone...

But the problem with the flag is that often plugins are installed from the CLI like this:

koha-shell kohadev -c "/usr/share/koha/bin/devel/install_plugins.pl"

So there would need to be some other way of preventing uninstall...
Comment 8 Kyle M Hall 2023-08-17 10:55:40 UTC
(In reply to David Cook from comment #7)
> (In reply to David Cook from comment #6)
> > Actually, I think it would need to be a flag, because you might want to
> > distribute a third-party plugin via a shared directory to many Koha
> > instances and not want 1 Koha admin to be able to uninstall it for
> > everyone...
> 
> But the problem with the flag is that often plugins are installed from the
> CLI like this:
> 
> koha-shell kohadev -c "/usr/share/koha/bin/devel/install_plugins.pl"
> 
> So there would need to be some other way of preventing uninstall...

Perhaps a "--read-only" switch that would add an additional "_ReadOnly" key to the plugin_data table? That would be easy enough to code a check for.
Comment 9 David Cook 2023-08-18 00:03:49 UTC
(In reply to Kyle M Hall from comment #8)
> Perhaps a "--read-only" switch that would add an additional "_ReadOnly" key
> to the plugin_data table? That would be easy enough to code a check for.

I was thinking adding a key to the plugin_data table was the way to go as well.

The only thing about the "--read-only" switch is "/usr/share/koha/bin/devel/install_plugins.pl" can install 0+ plugins, so it's not 100% clear which plugins it will affect ahead of running it.

I was thinking about keeping a configurable list of plugin names but then that seems cumbersome...
Comment 10 David Cook 2023-08-18 00:05:24 UTC
I did have another thought...

What about adding a method to Koha::Plugins::Base, and then invoking it on a per-plugin basis using bug 34335?
Comment 11 Kyle M Hall 2023-08-18 11:18:31 UTC
(In reply to David Cook from comment #9)
> (In reply to Kyle M Hall from comment #8)
> > Perhaps a "--read-only" switch that would add an additional "_ReadOnly" key
> > to the plugin_data table? That would be easy enough to code a check for.
> 
> I was thinking adding a key to the plugin_data table was the way to go as
> well.
> 
> The only thing about the "--read-only" switch is
> "/usr/share/koha/bin/devel/install_plugins.pl" can install 0+ plugins, so
> it's not 100% clear which plugins it will affect ahead of running it.
> 
> I was thinking about keeping a configurable list of plugin names but then
> that seems cumbersome...

It's starting to feel like we need a koha-plugin tool to go along with all the other "koha-" tools. Something that could take a kpz as an argument ( or even a URL ) and install it from there.

That being said, I think it would be pretty easy to add an option to install_plugins that takes a namespace ( e.g. Koha::Plugin::Com::Company::BellsAndWhistles ) and skips over any plugins that don't match that namespace.
Comment 12 David Cook 2023-08-20 23:08:46 UTC
(In reply to Kyle M Hall from comment #11)
> It's starting to feel like we need a koha-plugin tool to go along with all
> the other "koha-" tools. Something that could take a kpz as an argument ( or
> even a URL ) and install it from there.

I was thinking the same thing back in 2020 but my code got lonely on bug 25671
 
> That being said, I think it would be pretty easy to add an option to
> install_plugins that takes a namespace ( e.g.
> Koha::Plugin::Com::Company::BellsAndWhistles ) and skips over any plugins
> that don't match that namespace.

I think so too