* WIP: Separate signature package
* Add some unit tests
* Test factory
* Finish unit test coverage signature package
* Fix register
* Add FIXME
* Add more coverage
* Add more coverage
* Fix migrate tests
* Fix unit tests
* create permissions
* add key
* lint
* structure as a delayed callback
* legacy API hook
* merge main
* wired up
* and folders
* watch repos
* missing return statement
* Set the correct permissions
* add TestAfterCreatePermissionCreator
* do not add perms on folder create
* fix tests
* add annotation on create
* lint
* lint
* ensure we set permissions when the FT is disabled
* remove custom folder_storage
* fix lint
* change default
* lint
* lint
* fix: annotation
* ensure permissions are added on folder legacy
* remove folderstorage again
* fix tests
* add FT
* undo change to folder
* dashboard on create
* remove annotation for folder
* fix tests
* fix prepare after rebase
* fix tests
* fix tests
* fix tests
* lint
* address comments
* add test for prepareObjectForStorage
* add again skipIfMode as per comment
---------
Co-authored-by: Georges Chaudy <chaudyg@gmail.com>
What is this feature?
This change adds properties and known annotations to store them in for recording resource manager information, such as:
The type (kind) of the manager (ex. Terraform / kubectl / etc.)
The identity of the manager (ex. grafana/terraform-provider-grafana)
Whether the managers allows the resource to be edited by others.
Whether a resource is temporarily excluded from the manager's control.
These annotations are inspired by Kubernetes field management API (https://kubernetes.io/docs/reference/using-api/server-side-apply/#field-management) and known Kubernetes annotations
(https://kubernetes.io/docs/reference/labels-annotations-taints/#app-kubernetes-io-managed-by).
It also adds annotations for storing information about the source of a provisioned resource, such as path, checksum & timestamp.
Why do we need this feature?
To make it possible to mark resources as managed by specific managers, modifying how these resources appear in the UI and are treated in the backend APIs.
For example, we'd like to make managed resources read-only, or show specific docs / workflows based on the tool which is used to manage resources and so on.
The identity is required for ensuring that managers of the same kind can still be told apart.
Who is this feature for?
For as-code practitioners and API users.
---------
Signed-off-by: Igor Suleymanov <igor.suleymanov@grafana.com>
Co-authored-by: Ryan McKinley <ryantxu@gmail.com>
* Support getting full path of UIDs
* Use full path to set parents field
* Update get folder test
* Add folder store test for getting with full path UIDs
* Add test for parsing parent titles
* Test nested folder create payload
Ryan McKinley
Roberto Jiménez Sánchez
Mariell Hoversholm
Stephanie Hingtgen
Igor Suleymanov
Arati R.
Todd Treece