- 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
- pact.NavigationItem gains Visible func(ctx) bool (json:"-"); nil keeps the
entry always listed
- cabana.Registry.Metadata runs it after the permission check, drops a main
item (with its side menu) or a side item that answers false, and relinks a
parent whose controller is a hidden child's to its first visible openable
child
- TestNavigationHidesInvisibleItemsAndRepointsTarget covers the rules
- pact and cabana READMEs, users-and-permissions and admin-controllers docs
describe the hook
pact.SettingsItem gains an additive Controller field, the equivalent of a
WinterCMS registerSettings 'url' => Backend::url(...) entry. A link entry
declares no Model, Form or NewModel and needs no AdminFS; start-up fails
when it combines Controller with a singleton form or a model, or names an
unregistered controller. Settings codes stay one namespace.
GET /settings lists a link entry with its controller only when the
principal passes the item's permissions and may open the controller.
Registry.Setting never returns a link entry, so the singleton settings
endpoints answer 404 for its code. SettingsEntry carries controller,
empty for singletons; the OpenAPI document, generated SPA types and
settings fixture follow, and the pact and cabana READMEs and the
settings docs describe the link.
