https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43666 Bug ID: 43666 Summary: Allow plugins to register additional Single Table Inheritance subclasses Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org Target Milestone: --- This patch adds Koha::Objects::Mixin::SingleTableInheritance::Pluggable, an extension of the Koha::Objects::Mixin::SingleTableInheritance mixin added in bug 43663. It lets an installed and enabled Koha Plugin register additional Single Table Inheritance (STI) subclasses against a Koha::Objects plural class, provided all of the following are true: 1. The plural class itself opts in at the code level, by composing this mixin instead of the base one. This is a core developer decision, not overridable at runtime. 2. The contributing plugin has been explicitly permitted, for that specific target plural class, via a new per-plugin, per-target toggle in the Plugin management UI. Off by default for every (plugin, target) pair. 3. A new koha-conf.xml entry, enable_plugin_sti_registration, is enabled. Off by default; a full kill-switch overriding both of the above when off, for hosts who want to forbid the capability outright. Discovery reuses Koha's existing Koha::Plugins::GetPlugins({ method => ... }) capability-declaration mechanism (the same approach Koha::SuggestionEngine and Koha::RecordProcessor already use for their own plugin discovery) - no new registry, no filesystem scanning, no Module::Pluggable. A permitted plugin declares its contributions via one public method, additional_sti_classes, returning a hash keyed by target plural class name; each named class self-declares its own dispatch key exactly like a core STI subclass does (see bug 43663), so that key is never duplicated between the plugin and core. A core-registered dispatch key always wins over any plugin contribution. An invalid contribution (fails to load, isn't a subclass of the target's own base class, or doesn't implement the dispatch-key method) is dropped with a logged warning, never a fatal error, so one misbehaving plugin cannot break dispatch for any other row or any other plugin. Koha::File::Transports (already migrated onto the base mixin in bug 43663) is opted into this new capability as the proving-ground consumer, with no other behaviour change - confirmed by the full existing File::Transport test suite passing unmodified with the new capability left at its default (off). This is designed to let a plugin trial a new subclass (for example, an additional file transport backend) without requiring a core patch first; if it proves itself, promoting it into core is a small, two-line change (move the file, add it to the plural class's own reviewed subclass list) with no data migration, since dispatch is driven purely by the persisted column value, not by which mechanism supplied the class. Depends on bug 43663 (Koha::Objects::Mixin::SingleTableInheritance), which this bug builds directly on top of. Test plan: 1. Apply the patches and restart_all. 2. Confirm Administration > File transports behaves identically to before this patch, with everything left at its defaults (no visible change is the expected result at this step). 3. Set enable_plugin_sti_registration to 1 in koha-conf.xml, restart_all. 4. Install and enable a plugin implementing additional_sti_classes for Koha::File::Transports (a companion example plugin will be linked from this bug's comments). 5. In the Plugin management UI's actions menu for that plugin, confirm an option to allow registering classes for Koha::File::Transports appears, and toggle it on. 6. Go to Administration > File transports, create a new file transport using the plugin-contributed transport type, and confirm it dispatches to the plugin's class. 7. Toggle the permission back off. Confirm the plugin-contributed transport type is no longer offered, and any already-created row of that type falls back to generic behaviour rather than erroring. 8. Set enable_plugin_sti_registration back to 0. Confirm re-toggling permission on in the Plugin management UI has no effect while the kill-switch is off. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.