Summary
apps/info.xsd does not allow a <permission> child element on <navigation> inside <navigations>. Adding one causes occ app:enable to fail with "appinfo file cannot be read" on Nextcloud 32 (current dev).
This makes it impossible for an app to declare a permission identifier that admins can grant to groups in the standard NC admin UI specifically for top-bar visibility — separate from the broader app-level group restriction (occ app:enable openbuilt --groups).
Reproduce
Add to any app's appinfo/info.xml:
<navigations>
<navigation>
<id>myapp</id>
<name>My App</name>
<route>myapp.dashboard.page</route>
<icon>app.svg</icon>
<permission>myapp.use</permission>
</navigation>
</navigations>Run:
occ app:enable myapp --force
Result:
App "myapp" cannot be installed because appinfo file cannot be read.
Why this matters
OpenBuilt's RBAC spec (openbuilt-rbac REQ-OBRBAC-006) calls for a navigation-entry permission openbuilt.use independent of the per-object RBAC enforced inside the app. Today the workaround is the coarser app-level group restriction (occ app:enable openbuilt --groups team-alpha), which restricts the whole app, not just the top-bar entry.
This pattern would benefit any app where an admin wants to expose some functionality (e.g. a contributor surface registered as a separate <navigation>) to a wider group while restricting top-bar visibility of the management surface.
Suggested change
Extend apps/info.xsd so <navigation> accepts an optional <permission> child carrying a string permission identifier. The runtime middleware that resolves navigation entries (OC\NavigationManager / IPermissionAwareNavigation) would then check the identifier against the current user's permissions before emitting the entry.
If this already exists under a different element name, a docs pointer would unblock us immediately.
References
Summary
apps/info.xsddoes not allow a<permission>child element on<navigation>inside<navigations>. Adding one causesocc app:enableto fail with "appinfo file cannot be read" on Nextcloud 32 (current dev).This makes it impossible for an app to declare a permission identifier that admins can grant to groups in the standard NC admin UI specifically for top-bar visibility — separate from the broader app-level group restriction (
occ app:enable openbuilt --groups).Reproduce
Add to any app's
appinfo/info.xml:Run:
Result:
Why this matters
OpenBuilt's RBAC spec (openbuilt-rbac REQ-OBRBAC-006) calls for a navigation-entry permission
openbuilt.useindependent of the per-object RBAC enforced inside the app. Today the workaround is the coarser app-level group restriction (occ app:enable openbuilt --groups team-alpha), which restricts the whole app, not just the top-bar entry.This pattern would benefit any app where an admin wants to expose some functionality (e.g. a contributor surface registered as a separate
<navigation>) to a wider group while restricting top-bar visibility of the management surface.Suggested change
Extend
apps/info.xsdso<navigation>accepts an optional<permission>child carrying a string permission identifier. The runtime middleware that resolves navigation entries (OC\NavigationManager/IPermissionAwareNavigation) would then check the identifier against the current user's permissions before emitting the entry.If this already exists under a different element name, a docs pointer would unblock us immediately.
References