With a framework version that is not a release (a devel build, an empty
FrameworkVersion) every plugin with a minimum was marked as needing a
newer framework, and Compatible looked only at the newest release, so a
plugin whose older release fits was marked although plugin:install
would install that release. An unknown framework now gives no marker
(and no needs-framework note on the Installed tab), and a plugin whose
newest release is too new is looked up (cached, four at a time) and
counts as compatible when an older release fits.
pluginCatalog.lists was keyed by every distinct query and category and
never dropped an expired entry, so searching distinct strings grew the
process without limit (each entry can hold a 4 MiB answer). Storing a
search into a full cache now drops the expired searches and then the
ones that expire first, keeping at most 256.
plugin:update dropped a go.mod require that was not a strict vX.Y.Z and
treated it as v0.0.0, so a module at a commit after v0.4.0
(v0.4.1-0.<ts>-<hash>) was moved back to v0.4.0. kiosk.Newer now places
a release against a release, a git describe string or a pseudo-version
(by the tag it builds on, in Go's version order); plugin:update and the
admin Plugins screen badge share it. A pseudo-version with no tag before
its commit is left alone with a note naming go get <module>@<tag>.
- TestPluginsEndpoints: 401/403/200 for both endpoints, the update rule
table, cache hit and expiry on an injected clock, failure caching, at
most 4 version lookups at once, call timeout, marketplace validation,
markers, https-only icons, disabled registry making no call
- fix: marketplace categories come only from plugins the screen offers,
not from registry entries dropped for an invalid ID
- check-phase34.sh: TestPluginsEndpoints and useSettings.test.ts required
- GET /plugins looks up each versioned plugin's releases through
kiosk.Client and applies plugin:update's rule (NewestCompatible above
the BaseVersion), with the update command and the framework a newer
release needs
- GET /plugins/marketplace forwards q and category (validated like the
registry), marks installed and incompatible plugins and returns the
install command; ids outside the plugin ID shape are dropped
- 4 s per-call timeout, at most 4 lookups at once, in-process cache
(searches 5 min, releases 15 min, failures 1 min); a failing registry
gives status unavailable, an empty plugins.registry_url sends nothing
- SPA: update badges and Marketplace tab with copy buttons (clipboard
fallback), hidden when the registry is disabled; no install button
- OpenAPI, SPA types, inventories, conformance case, en/pl strings, docs
- GET /plugins (backend.view_plugins, superusers always pass) lists the
plugins from party.Installed, or party.Activated IDs for older builds,
with the built framework version and whether the registry is configured
- Settings -> System -> Plugins entry with the new SettingsEntry.path,
added only for principals allowed to open it
- PluginsView at /system/plugins with an Installed tab (reka-ui Tabs);
settings panel, rail, breadcrumbs and page title know the route
- OpenAPI and SPA types regenerated; contract, token-class and
conformance inventories list the route; en/pl strings; docs
