https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43666 --- Comment #9 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Full test plan: pluggable STI registration end to end, using the WebDAV companion plugin This walks through the whole feature from a clean KTD instance: bringing up an instance with the plugin mounted, pointing it at a WebDAV server, enabling the registration through the Plugin management UI, and creating a file transport that dispatches to the plugin's class. A bonus final section uses a second, unrelated plugin (Transport Browser) to show that a plugin-contributed transport type is a first-class citizen to any code that consumes Koha::File::Transport generically, not just this bug's own admin screen. The companion plugin (koha-plugin-file-transport-webdav) is a separate repository, not part of this bug's own patch series: https://github.com/openfifth/koha-plugin-file-transport-webdav 1. Get a WebDAV server to point Koha at Option A, self-hosted with Docker (recommended - repeatable, and you control it): docker run -d --name webdav-test \ -e AUTH_TYPE=Basic -e USERNAME=koha -e PASSWORD=koha \ -p 8090:80 \ bytemark/webdav Note: this image's SSL_CERT=selfsigned option is currently broken (confirmed against a matching upstream issue on the image's own repo), so this uses plain HTTP rather than HTTPS with a self-signed cert. That is fine for this test - the plugin's TLS-verification-skip code path (see step 5) simply won't be exercised this way, only via mocked unit tests. Option B, a public test WebDAV account, for a quick manual check without running anything locally: https://www.dlp-test.com/webdav_pub/ (Note: a public, third-party service - fine for a one-off manual look, but not something to rely on for repeatable testing, and not something this plan builds the rest of these steps around.) The rest of this plan assumes Option A, reachable at http://localhost:8090/ from the host, and at http://webdav:80/ from inside a KTD container if you add the same server as a docker-compose service on the KTD instance's own network instead of running it standalone (see compose/webdav.yml in the plugin's repo for a ready-made fragment that does this). 2. Get the plugin git clone https://github.com/openfifth/koha-plugin-file-transport-webdav For KTD development testing, mount it directly rather than packaging it: ktd --proxy --name kohadev \ --single-plugin "$(pwd)/koha-plugin-file-transport-webdav" \ up -d ktd --name kohadev --wait-ready 180 (Use your own instance name in place of "kohadev" throughout. --proxy is required for the instance to be reachable at the usual <instance>-intra.kohadev.home / <instance>.kohadev.home hostnames - without it you'll get a 404 from the shared proxy, not a connection error, which can be confusing.) If testing against a packaged install instead of KTD, no .kpz release has been cut yet - download the repository as a zip from GitHub and upload it via Administration > Plugins > Upload plugin. 3. Turn on the kill-switch The enable_plugin_sti_registration key in koha-conf.xml defaults to 0 (off) and is a full kill-switch: nothing in this bug does anything at all while it's off, regardless of any other setting. In your instance's koha-conf.xml (for a KTD instance, /etc/koha/sites/<instance>/koha-conf.xml inside the container): <enable_plugin_sti_registration>1</enable_plugin_sti_registration> placed alongside the existing <enable_plugins> entry, then: ktd --name kohadev --shell --run 'restart_all' 4. Confirm the plugin is installed and enabled Log in to the staff interface, go to Administration > Plugins. Confirm "File Transport: WebDAV" is listed. If its status isn't already "Enabled", enable it from the actions menu. 5. Allow the plugin to register its class Still in Administration > Plugins, open the actions menu for "File Transport: WebDAV" again. You should see an entry reading: Allow registering classes for Koha::File::Transports Click it. The entry should flip to read "Forbid registering classes for Koha::File::Transports" - this is the per-plugin-per-target-class permission toggle, off by default, independent of the kill-switch in step 3 (both must be on for anything to actually appear). 6. Confirm no visible change until this point Go to Administration > File transports. With everything above done, this should look exactly as it did before this bug - the point of the gating is that installing and even permitting a plugin has zero effect on any existing instance unless every gate above is deliberately opened. 7. Create a WebDAV file transport Administration > File transports > New file transport. "WebDAV" should now appear as a Transport option (it will not appear if any of steps 3-5 were skipped). Fill in: Transport: WebDAV Host: http://webdav/ (from inside a KTD container, if you added the WebDAV server as a compose service on the same network - see compose/webdav.yml in the plugin's repo) or http://<your-docker-host-ip>:8090/ if reaching it via the host's own published port instead User name: koha Password: koha Note the host field needs an explicit http:// or https:// prefix - a bare hostname defaults to HTTPS, and this test server has no working TLS (see step 1). Save. This triggers an automatic background connection test; refresh the list after a few seconds and confirm the row shows "Tests passing". If it shows "Tests failing", the most common causes are: host missing its http:// prefix, wrong host/port, or (if testing from outside Docker) a typo in the IP address. 8. Exercise it From the row's actions menu, or via the "Files" view for that transport, list, upload, download and rename a file against the WebDAV server, and confirm each operation succeeds and is reflected on the server (e.g. via a WebDAV client pointed at the same server, or docker exec into the container and looking at the filesystem directly). 9. Confirm the permission actually gates behaviour, not just the option list Go back to Administration > Plugins and click "Forbid registering classes for Koha::File::Transports" to toggle the permission back off. Return to Administration > File transports: - "WebDAV" should no longer be offered as a Transport option when creating a new one. - The already-created WebDAV row from step 7 should still be listed, and should fall back to generic Koha::File::Transport behaviour (e.g. attempting to use it should fail gracefully, not throw an unhandled error) rather than erroring. Toggle the permission back on afterwards if you want to keep testing. 10. Confirm the kill-switch overrides everything Set enable_plugin_sti_registration back to 0 in koha-conf.xml and restart_all again. Confirm that even with the per-plugin permission still on from step 5, "WebDAV" is no longer offered anywhere - the kill-switch is the final word regardless of any other toggle. Set it back to 1 if you want to keep testing further. 11. Optional: confirm a plugin-contributed transport is a first-class Koha::File::Transport to other code, not just this bug's own screen Install a second, unrelated plugin, Transport Browser (https://github.com/openfifth/koha-plugin-transport-browser), the same way as step 2 (note: --single-plugin only mounts one plugin directory at a time - to run both together, use --plugins instead, which mounts your whole local plugins folder and enables everything found in it, or add a second docker volume manually). Its tool page lists every configured file transport generically and lets you browse it - open it and confirm the WebDAV transport from step 7 appears alongside any FTP/SFTP ones and can be browsed the same way, with no special-casing needed for it to work. (Its badge colouring only has CSS defined for SFTP/FTP today, so the WebDAV badge will show unstyled/plain - a cosmetic gap in that plugin, not a defect in this bug.) -- You are receiving this mail because: You are watching all bug changes.