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)
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.
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?
(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?
(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.
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.
(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...
(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...
(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.
(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...
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?
(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.
(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