paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

docs: simplify visibilityPermission docs to match type constraints

Browse Source 
Since visibilityPermission is typed as BasicPermission and authorize()
returns DefinitivePolicyDecision (ALLOW/DENY only), remove misleading
references to CONDITIONAL decisions which can never occur.

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Made-with: Cursor
This commit is contained in:
Patrik Oldsberg
2026-03-17 10:55:51 +01:00
parent 7bc798c069
commit 54f30c6c91
1 changed files with 2 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/backend-system/core-services/actions-registry.md
+2 -7
View File
@@ -160,14 +160,9 @@ export const myPlugin = createBackendPlugin({
## Permissions
Actions can optionally declare a `visibilityPermission` to control visibility and access through the Backstage permissions framework. This permission is evaluated without any resource context and is intended for unconditional (non-resource) permissions only. When such a permission is set, the action is only visible in listings and accessible by users who are authorized.
Actions can optionally declare a `visibilityPermission` to control visibility and access through the Backstage permissions framework. The `visibilityPermission` must be a `BasicPermission` (not a resource permission). When set, the action is only visible in listings and accessible by callers who are authorized.
When accessed via the Actions Service or the `/.backstage/actions/v1/...` HTTP endpoints, actions that are not authorized by the permission policy are filtered from list results and return a `404 Not Found` on invocation, as if they don't exist. In particular:
- `ALLOW` decisions make the action visible and invokable.
- `DENY` and `CONDITIONAL` decisions are both treated as not authorized, so the action is hidden from listings and returns `404 Not Found` when invoked.
Because `visibilityPermission` is evaluated without resource context, resource-based or otherwise conditional permissions (that may normally return `CONDITIONAL` decisions) are not supported here and will effectively behave as denied.
When accessed via the Actions Service or the `/.backstage/actions/v1/...` HTTP endpoints, actions that are denied by the permission policy are filtered from list results and return a `404 Not Found` on invocation, as if they don't exist.
Permissions declared on actions are automatically registered with the `PermissionsRegistryService` so they appear in the permission policy system.