[Bug 28499] New: Add support for no-UI / administrative plugins
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 Bug ID: 28499 Summary: Add support for no-UI / administrative plugins Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs@lists.koha-community.org Reporter: nick@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org 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) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au, | |jonathan.druart+koha@gmail. | |com, | |katrin.fischer@bsz-bw.de, | |kyle@bywatersolutions.com, | |martin.renvoize@ptfs-europe | |.com, tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=25672 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #3 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=34335 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (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... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (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... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #8 from Kyle M Hall <kyle@bywatersolutions.com> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (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... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #11 from Kyle M Hall <kyle@bywatersolutions.com> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28499 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- (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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org