mirror of
https://github.com/grafana/grafana.git
synced 2026-06-10 09:01:30 -04:00
b005fb3c2a
* Folders: Set default permissions via the resource-permission API path In embedded/monolith mode the folder API was registered with the legacy folderPermissionsSvc (SQL + GetSignedInUser), whose default-permission step runs inside the apiserver create hook where there is no web request context. For root folders this failed with "user not found", so the folder was created but its default permissions were never written. When kubernetesAuthzResourcePermissionApis is enabled, register the folder API with the App Platform path instead: build a loopback ResourcePermission dynamic client (lazily, from the eventual rest config) and leave folderPermissionsSvc unwired so the legacy folderStorage wrapper isn't installed. Default permissions are then written as a ResourcePermission (Editor/Viewer) which goes to unified storage and syncs to Zanzana — no legacy SQL and no GetSignedInUser. Creator-admin continues to come from the basic Admin role. Also set the grafana.app/grant-permissions=default annotation on root-folder creation in the unified store, since the legacy /api/folders path (still used by the frontend) does not set it and the App Platform permission setter is driven by that annotation. Nested folders are unaffected — they inherit from the parent via the Zanzana folder hierarchy. Regenerates the wire graph. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Folders: Fix data race and sticky-error in lazy resource-permission client Replace sync.Once with a mutex in resourcePermissionsClient: - The Once approach read resourcePermissionsSvc on the fast path outside any synchronization while the Once body wrote it, racing on concurrent first-time folder creates (go test -race would flag it). - sync.Once also cached a transient failure (e.g. a cancelled request context in GetRestConfig) permanently, poisoning all later creates. Branch on restConfigProvider first so the MT path (client injected, field never mutated) reads without locking, and the monolith path always builds under the mutex and only caches on success. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Folders: Trim verbose comments Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Add comment for agents * Folders: Use resourcePermissionsClient in afterDelete hook In embedded mode the ResourcePermission client is built lazily and the field is nil until the first create, so afterDelete reading the field directly would skip permission cleanup. Route through resourcePermissionsClient so the lazy-build path is used. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Folders: Request default permissions for root folders in resource-permission integration test The integration tests create root folders directly via /apis, bypassing the folderimpl layer that requests default permissions on the legacy /api/folders path. Default permissions are opt-in via the grant-permissions annotation, so without it no default ResourcePermission was created and createRootFolderWithoutDefaultPermissions failed when trying to delete one. Set the grant-permissions=default annotation when the helper creates a root folder, mirroring the production folder-creation flow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Folders: Request default permissions for root test folders in dashboard API test The dashboard integration test created its root test folder without the grant-permissions annotation, so Editors/Viewers never received default access via the resource-permission path and dashboard creation in the folder was denied. Set the annotation for root folders, matching the resource-permission integration test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Folders: set default permissions as a service identity with creator admin When an editor (or any non-admin) created a root folder, setDefaultFolderPermissions wrote the ResourcePermission through the loopback API server using the requester's identity. The creator does not yet hold set-permissions on the brand-new folder, so the ResourcePermission authorizer's parent fetch was denied and folder creation failed with 500 "create root permissions". Setting the default permissions is a system operation triggered by folder creation, not an action the requester performs directly. Run it under a service identity (mirroring the dashboard path and MT, where the injected client uses a service token), and grant the creator admin on the new folder in addition to the default basic-role permissions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Folders: add default case to identity type switch for exhaustive lint Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| doc.go | ||
| health.go | ||
| health_test.go | ||
| instrumentation_service.go | ||
| instrumentation_service_test.go | ||
| memberlist.go | ||
| module_registerer.go | ||
| module_runner.go | ||
| module_server.go | ||
| module_server_test.go | ||
| operator.go | ||
| ring.go | ||
| runner.go | ||
| search_server_distributor_test.go | ||
| server.go | ||
| server_test.go | ||
| service.go | ||
| test_env.go | ||
| wire.go | ||
| wire_gen.go | ||
| wireexts_oss.go | ||