https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matt.blenkinsop@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|It would be useful to |Add a fully fledged plugin |understand what plugins are |store to Koha |being used in the wild. | CC| |andrew.auld@ptfs-europe.com | |, | |jonathan.druart@gmail.com, | |katrin.fischer@bsz-bw.de, | |martin.renvoize@ptfs-europe | |.com, | |paul.derscheid@lmscloud.de, | |tomascohen@gmail.com Status|NEW |In Discussion --- Comment #2 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Hi all, updating this bug to plugin store and setting "In Discussion" for now as the project is currently an MVP and testers/discussion would be great. The store repo: https://github.com/PTFS-Europe/koha-plugin-store The koha client branch: https://github.com/PTFS-Europe/koha/commits/plugin_store/ We're currently hosting a dev environment for the store at: https://plugin-store.koha-ptfs.co.uk/ If you check out the Koha client branch above you should be able to test, or reach out if you're finding it hard or want to add to the discussion. -- 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=35837 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brendan@bywatersolutions.co | |m, | |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35837#c2 -- 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=35837 --- Comment #4 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- (In reply to David Cook from comment #3)

One question... why does the test environment show Email and Password in the Users List to anonymous users?

Dev work leftovers. Its initial purpose was to make it obvious that passwords are not stored in plain text. Users are not planned to be listed to others. -- 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=35837 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- Will there be a koha-conf.xml option to turn it off or will it be based off the configuration of repos? -- 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=35837 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- (In reply to Pedro Amorim from comment #7)

Or maybe possibly even by existing ones (eg manage_plugins)? I may have misunderstood the question! Let me know if this doesn't answer it.

What I mean is... even though I think it's a really cool idea and it would be helpful for many Koha instances around the world, we probably won't want to use it for most of our hosted Koha instances. From a security perspective with our servers, we require any plugin installed to first be reviewed by us, so we wouldn't want staff users to be able to install plugins on their own. I'm just curious if there will be a way to disable this plugin store feature, or if I'll need to do a local customization to disable it. -- 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=35837 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #10 from Jonathan Druart <jonathan.druart@gmail.com> ---

I also agree it should be enabled by default and let vendors deal with their preference regarding the store.

IMO it must be disabled by default, with a clear warning regarding the risks if you enable it and install plugins. -- 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=35837 --- Comment #12 from Andrew Auld <andrew.auld@openfifth.co.uk> --- This is a feature that has been discussed as a good step forward for several years. The discussion at the last hackfest in Marseille was very positive about it as an addition to Koha. Similarly at the DACH Koha hackfests I have attended and a Kohacon. We are really hoping to come to Marseille this year with the feature at a point where it is 'nearly ready to go' so we really welcome positive ideas and thoughts about how to get the feature to a stage where it will be as universally useful as possible, has any necessary and agreed upon safeguards (ability to turn off etc), and has a good number of people keen to support it and add to the features and functionality over time. As well as to test and sign it off at the hackfest. Really looking forward to a great new addition for the benefit of many in the community who currently struggle to find, implement and trust plugins. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

Plugin store Koha client:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #13 from Lisette Scheer <lisette@bywatersolutions.com> --- Discussed today with Pedro: Adding the following to the existing list: 9) Implement backend in Koha for communication And filed issued on the Github for these. The # on the list matches the issue number:

Plugin store mojo app: Immediate: 1) Implement plugin listing pagination/filtering on webpage 2) Implement plugin listing pagination/filtering on REST API 3) Add Github registration/authentication for users and drop previous traditional registration/authentication method 4) Users no longer submit a plugin through github URL, they should pick a repo from a list of their own, or from organizations they belong to 5) Make it possible for an authenticated user to delete a plugin or a plugin release 6) Remove display of users on webpage 7) Drop thumbnail functionality. Planned for later. 8) Add a contact link for developers to ask for login access 9) Add maximum_koha_version metadata check / make it recommendable i.e. does not block plugin submission

We also discussed some possible CI checks, similar to CPAN where it doesn't need to totally block it, but might warn of missing components. Some ideas included: - Use of plugin wrapper on .tt pages - Presence of a Development.MD and/or Contributing.MD - Presence of documentation - Presence of unit tests - Translatability Additionally, we discussed requiring signed commits, community QA badge, security checks (is it introducing security vectors/issues), and a cron to check for updates (though with GitHub oath we might be able to use webhooks to inform of updates) Added to the Dev agenda for the next meeting. -- 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=35837 --- Comment #15 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Lisette Scheer from comment #13)

We also discussed some possible CI checks, similar to CPAN where it doesn't need to totally block it, but might warn of missing components. Some ideas included: - Use of plugin wrapper on .tt pages - Presence of a Development.MD and/or Contributing.MD - Presence of documentation - Presence of unit tests - Translatability

Additionally, we discussed requiring signed commits, community QA badge, security checks (is it introducing security vectors/issues), and a cron to check for updates (though with GitHub oath we might be able to use webhooks to inform of updates)

Please remember that I am currently working on a centralize Koha::QA module that will be used by a "QA script for plugins" (that could later become a Koha Plugin Certification Authority) See the announcement there: https://chat.koha-community.org/koha-community/pl/oxe85xkqsf858dpberf4t7h4uy I am trying to provide a POC before the end of the month. -- 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=35837 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Juliet Heltibridle <jheltibridle@rcplib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jheltibridle@rcplib.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #17 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206271 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206271&action=edit Bug 35837: Add a verified, restriction-aware install path for plugin-store plugins Adds Koha::Plugins::Store (queries the plugin-store's public discovery API by kpz_url or digest for a plugin's origin repo and certification level) and Koha::Plugins::Install (a single validate-then-install routine other code paths can share). Install.pm enforces, in order: * the existing plugins_restricted org-allowlist, exactly as the legacy plugins-upload.pl path already did -- closing a gap where the plugin-store path didn't apply the same restriction * PluginStoreMinimumLevel (new system preference): rejects a version below the site's chosen certification tier, when the plugin-store recognises it * Ed25519 signature verification against the store's public key (koha-conf.xml's new plugin_store_public_key_file), confirming the .kpz hasn't been altered since the store inspected it. An unsigned file (no plugin-store record at all -- a private/in-house plugin, or one published before the store supported signing) is rejected unless the caller explicitly confirms, via a new plugins_allow_unsigned koha-conf.xml flag plus a per-install confirm_unsigned flag Nothing calls this yet -- see the following commits for the REST API and UI that do. No standalone test plan: this is a library layer with no UI of its own. See `prove t/Koha/Plugins/Install.t t/Koha/Plugins/Store.t` for unit coverage, and the plugin manager UI test plan two commits over for end-to-end verification. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #19 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206273 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206273&action=edit Bug 35837: Add a Vue plugin manager replacing the old plugin pages Adds a single-page plugin manager (Administration > Plugins) built on the new REST API: * lists installed plugins, with enable/disable/uninstall/configure/ run actions, and flags any plugin running outside its declared minimum/maximum Koha version * "Search for new plugins" opens the plugin-store's discovery catalogue directly (search-gated, paginated, sortable by name/ author/last-updated, defaulting to a recently-updated browse list on open) and installs by kpz_url * "Upload plugin" installs a local .kpz file * "Check for updates" compares installed versions against the store and flags any that are behind * an unsigned-install rejection (previous commit) surfaces as a confirmation dialog rather than a silent failure; other install/ upload errors show inline in the relevant modal, not a global banner easy to miss All existing entry points into the plugin system (admin home, the tools/reports plugin listings, the staff-tool wrapper breadcrumb) now point at this page instead of the old plugins-home.pl. Test plan: 1. Enable the Plugins system preference (and log in as a user with plugin permissions) if not already on. 2. Administration > Plugins. Confirm any already-installed plugins list correctly, with working Configure/Run/Enable/Disable/ Uninstall actions. 3. Click "Search for new plugins" -- the search box should be focused immediately, and a short list of recently-updated plugins should appear without typing anything. Search by name/author/description; confirm results page and sort correctly, and that a plugin you've already installed shows greyed out with an "Already installed" badge instead of an Install button. 4. Install a plugin from the search results; confirm it appears in the main list afterwards. 5. Click "Upload plugin" and install a plugin from a local .kpz file. 6. Click "Check for updates"; if any installed plugin has a newer version in the store, it should show "Update available (x.y.z)". If nothing is out of date, confirm you get a clear "all plugins up to date" message rather than nothing happening. 7. Confirm the Administration home page, and the Tools/Reports plugin listings (if you have report/tool plugins installed), all link to this same page rather than a 404. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #21 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206275 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206275&action=edit Bug 35837: Fix a confirmation dialog rendering behind an open component dialog A confirmation triggered from inside an already-open component dialog (e.g. the plugin manager's unsigned-install confirmation, opened from SearchModal) rendered behind it: #confirmation and #component share the same z-index, and with equal z-index the later-in-DOM #component modal wins hit-testing regardless of which opened more recently. Its own buttons were consequently unclickable -- not a rendering glitch, real click coordinates land on the modal underneath. Giving #confirmation a higher z-index fixes both this and the pre-existing unsigned-install confirmation, which used the same pattern. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #23 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206277 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206277&action=edit Bug 35837: Fix "show unsupported plugins" checkbox rendering as a thin line Koha's legacy input[type="checkbox"] rule in staff-global.css has higher CSS specificity than Bootstrap 5's .form-check-input class, so it wins and collapses the checkbox to a 2px line. Match Bootstrap's own higher-specificity .form-check-input[type="checkbox"] pattern (already used elsewhere in the same stylesheet) to restore the box. Test plan: 1. Open the plugin manager and click "Search for new plugins". 2. Confirm the "Show plugins not marked as compatible with my Koha version" checkbox renders as a normal square checkbox, not a thin line, and toggles correctly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43581 Status|Failed QA |Needs Signoff Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43581 [Bug 43581] Replace the legacy plugin management pages with a Vue Installed plugins page -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #25 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206484 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206484&action=edit Bug 35837: Add a verified, restriction-aware install path for plugin-store plugins Adds Koha::Plugins::Install and Koha::Plugins::Store, the backend foundation for installing plugins discovered via a community plugin-store service. Given a downloaded .kpz file, install() runs a fixed set of checks before ever touching the plugins directory: * the file has a .kpz extension and the plugins directory is writable * its origin repository, if known, is on the configured allowlist (plugin_repos), when plugins_restricted is enabled * its Ed25519 signature, if the plugin store provided one, verifies against the configured verification key and matches this exact file's SHA-256 digest * an unsigned plugin is only installed once explicitly confirmed (plugins_allow_unsigned), and blocked outright if that's disabled * its certification tier, if the store knows one, meets the PluginStoreMinimumLevel system preference Nothing is extracted or installed unless every check passes. The Ed25519 verification key is resolved from koha-conf.xml's plugin_store_public_key_file, when a sysadmin has set one (e.g. for a self-hosted mirror or a scripted multi-instance deploy), falling back to the new PluginStorePublicKey system preference otherwise. With neither configured, a signed plugin is treated the same as an unsigned one rather than reported as a signature mismatch, since there's no key to check it against. Koha::Plugins::Store is a thin client for the plugin store's public discovery API, resolving a kpz_url or a file digest to its known repo_url, certification tier, and signed manifest/signature. Also adds the PluginStoreMinimumLevel and PluginStorePublicKey system preferences (installer/data/mysql/atomicupdate/), the CryptX dependency (for Crypt::PK::Ed25519), and sample koha-conf.xml entries documenting plugin_store_url, plugins_allow_unsigned and plugin_store_public_key_file. Test plan: 1. prove t/Koha/Plugins/Install.t t/Koha/Plugins/Store.t 2. Set the PluginStorePublicKey system preference to a store's real public key and confirm a correctly-signed plugin verifies. 3. Set koha-conf.xml's plugin_store_public_key_file and confirm it takes precedence over the system preference. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #27 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206486 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206486&action=edit Bug 35837: Add a Vue plugin store page for discovering and installing plugins Adds a staff-interface "Plugin store" page (Administration > Plugins) for browsing plugins published to a configured plugin-store service and installing them, alongside the existing manual upload path: * Search/filter the store's catalogue by name, description or author, with an option to include releases that don't declare support for this Koha version * Install directly from a search result, or upload a local .kpz file * A plugin already installed, but with a newer release available, shows an "Update available" badge and an Update action in place of Install -- reusing the same install flow, since the backend already overwrites in place and runs the plugin's own upgrade() hook * Unsigned-plugin and unsupported-Koha-version installs require explicit confirmation before proceeding, with the backend's error code driving which confirmation (if any) is shown * All plugin-store-supplied metadata (name, description, author, version strings) is HTML-escaped before rendering -- it's text from a remote, third-party service The search results table is fed by two independent fetches (the store's catalogue, and this Koha's installed-plugins list); a watcher on each refreshes the DataTable so a completed install/update is reflected immediately, without a page reload. Also wires the page into the admin menu and breadcrumbs, and extends the shared Vue HttpClient with postForm() (multipart uploads) and clearer error-message extraction for Mojolicious::Plugin::OpenAPI validation failures, both needed by the upload path. Test plan: 1. yarn build 2. Configure plugin_store_url in koha-conf.xml, pointing at a plugin-store instance with at least one published plugin. 3. Administration > Plugins > Plugin store: confirm the catalogue loads, search/filter works, and installing a plugin succeeds and is reflected in the table without reloading. 4. Upload a local .kpz file via the Upload plugin button and confirm it installs. 5. Downgrade an installed plugin's version on disk, restart, and confirm the row now shows "Update available" with a working Update action. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #29 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- If testing inside ktd, you will either want to run your own local plugin store to test against (https://github.com/openfifth/koha-plugin-store/blob/main/DEVELOPMENT.md#dock...) or use the openfifth hosted test server at https://plugin-store.koha-ptfs.co.uk (You'll need to add it appropriately to the koha-conf.xml in your ktd) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #31 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- (In reply to Lisette Scheer from comment #30)

(In reply to Martin Renvoize (ashimema) from comment #29)

...

If testing inside ktd, you will either want to run your own local plugin store to test against (https://github.com/openfifth/koha-plugin-store/blob/main/DEVELOPMENT. md#docker-development) or use the openfifth hosted test server at https://plugin-store.koha-ptfs.co.uk (You'll need to add it appropriately to the koha-conf.xml in your ktd)

Can you add to the test plan:

Inside ktd: vi /etc/koha/sites/kohadev/koha-conf.xml and add <plugin_store_url>https://plugin-store.koha-ptfs.co.uk</plugin_store_url>

Sure

I liked it better when it was on one screen with existing plugins.

Interesting, I found the modal restrictive and felt the split made the use case clearer (and gave us more option for the future to improve the storefront.

At the very least the plugin store shouldn't show if none are configured.

Agreed, but the intention is to ship a url by default.. preferable plugins.koha-community.org

Being able to filter results by class, installed with updates available, installed not compatible would be helpful.

It feels like you should be able to open the plugin from the store if you've installed it.

Ideally seeing available updates and compatibility issues on the regular plugin page would be helpful, or even a 'check for updates' option in the actions.

See "Bug 43581 - Replace the legacy plugin management pages with a Vue Installed plugins page". I deliberately split us into two submissions to try and smooth the testing and qa process. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #206484|0 |1 is obsolete| | Attachment #206485|0 |1 is obsolete| | Attachment #206486|0 |1 is obsolete| | Attachment #206487|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #33 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206521 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206521&action=edit Bug 35837: Add a REST API for installing plugin-store plugins Adds Koha::REST::V1::Plugins, exposing plugin discovery and install over /api/v1/plugins: * GET /plugins -- list installed plugins, with the fields the Plugin store's own "already installed"/"update available" checks need * POST /plugins -- install a plugin from a kpz_url * POST /plugins/upload -- install a plugin from a locally uploaded .kpz file * GET /plugins/config -- the current user's plugin permissions add() and upload() both delegate to Koha::Plugins::Install for the actual verification/extraction; this controller's job is fetching the file, mapping Koha::Plugins::Install's error codes to HTTP responses (a fixed priority order picks one code to report when several checks fail at once, since Perl hash order can't be relied on), and permission enforcement (plugins: manage for both install routes). add()'s download deliberately goes through Mojo::UserAgent with redirects enabled rather than a simpler fetch -- GitHub and GitLab release-asset URLs, the common case for a real kpz_url, always 302 to a signed, time-limited storage URL. The repo-origin restriction check runs before that fetch, not after: checking it only once the file is already downloaded would mean the restriction could never actually prevent the request, only the install. Test plan: 1. prove t/db_dependent/api/v1/plugins.t 2. As a user with only the plugins "manage" sub-permission (not the full plugins block flag), confirm both POST /plugins and POST /plugins/upload succeed. 3. With plugins_restricted enabled and a kpz_url whose origin isn't on the plugin_repos allowlist, confirm the request is rejected with RESTRICTED and that the server never actually fetches the URL. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35837 --- Comment #35 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206523 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206523&action=edit Bug 35837: Add Cypress tests for the plugin store page Covers the Plugin store search page end-to-end against a mocked backend (both the local Koha REST API and the plugin-store's own cross-origin catalogue endpoint): listing and searching the catalogue, flagging a release outside this Koha version's supported range, installing a plugin and seeing the row update to "Already installed" without a page reload, offering an Update action once a newer release is available, the unsigned-plugin and unsupported-version confirmation dialogs, and uploading a local .kpz file. Test plan: 1. yarn cypress run --spec t/cypress/integration/PluginStore_spec.ts Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -- You are receiving this mail because: You are watching all bug changes.