959ebf82da
* Folders: Show folders user has access to at the root level * Refactor * Refactor * Hide parent folders user has no access to * Skip expensive computation if possible * Fix tests * Fix potential nil access * Fix duplicated folders * Fix linter error * Fix querying folders if no managed permissions set * Update benchmark * Add special shared with me folder and fetch available non-root folders on demand * Fix parents query * Improve db query for folders * Reset benchmark changes * Fix permissions for shared with me folder * Simplify dedup * Add option to include shared folder permission to user's permissions * Fix nil UID * Remove duplicated folders from shared list * Folders: Fix fetching empty folder * Nested folders: Show dashboards with directly assigned permissions * Fix slow dashboards fetch * Refactor * Fix cycle dependencies * Move shared folder to models * Fix shared folder links * Refactor * Use feature flag for permissions * Use feature flag * Review comments * Expose shared folder UID through frontend settings * Add frontend type for sharedWithMeFolderUID option * Refactor: apply review suggestions * Fix parent uid for shared folder * Fix listing shared dashboards for users with access to all folders * Prevent creating folder with "shared" UID * Add tests for shared folders * Add test for shared dashboards * Fix linter * Add metrics for shared with me folder * Add metrics for shared with me dashboards * Fix tests * Tests: add metrics as a dependency * Fix access control metadata for shared with me folder * Use constant for shared with me * Optimize parent folders access check, fetch all folders in one query. * Use labels for metrics |
||
---|---|---|
.. | ||
apierrors | ||
avatar | ||
datasource | ||
dtos | ||
frontendlogging | ||
pluginproxy | ||
response | ||
routing | ||
static | ||
webassets | ||
accesscontrol.go | ||
admin_encryption.go | ||
admin_provisioning_test.go | ||
admin_provisioning.go | ||
admin_test.go | ||
admin_users_test.go | ||
admin_users.go | ||
admin.go | ||
alerting.go | ||
annotations_test.go | ||
annotations.go | ||
api.go | ||
apikey.go | ||
basic_auth_test.go | ||
basic_auth.go | ||
common_test.go | ||
dashboard_permission_test.go | ||
dashboard_permission.go | ||
dashboard_snapshot_test.go | ||
dashboard_snapshot.go | ||
dashboard_test.go | ||
dashboard.go | ||
dataproxy.go | ||
datasources_test.go | ||
datasources.go | ||
fakes.go | ||
featuremgmt_test.go | ||
featuremgmt.go | ||
folder_bench_test.go | ||
folder_permission_test.go | ||
folder_permission.go | ||
folder_test.go | ||
folder.go | ||
frontend_logging_test.go | ||
frontend_logging.go | ||
frontend_metrics.go | ||
frontendsettings_test.go | ||
frontendsettings.go | ||
grafana_com_proxy.go | ||
health_test.go | ||
health.go | ||
http_server_test.go | ||
http_server.go | ||
index.go | ||
login_oauth_test.go | ||
login_oauth.go | ||
login_test.go | ||
login.go | ||
metrics_test.go | ||
metrics.go | ||
org_invite_test.go | ||
org_invite.go | ||
org_test.go | ||
org_users_test.go | ||
org_users.go | ||
org.go | ||
password.go | ||
playlist.go | ||
plugin_dashboards_test.go | ||
plugin_dashboards.go | ||
plugin_metrics_test.go | ||
plugin_metrics.go | ||
plugin_proxy_test.go | ||
plugin_proxy.go | ||
plugin_resource_test.go | ||
plugin_resource.go | ||
plugins_test.go | ||
plugins.go | ||
preferences_test.go | ||
preferences.go | ||
quota_test.go | ||
quota.go | ||
README.md | ||
render.go | ||
search.go | ||
short_url_test.go | ||
short_url.go | ||
signup.go | ||
swagger_responses.go | ||
swagger_tags.json | ||
swagger.go | ||
user_test.go | ||
user_token_test.go | ||
user_token.go | ||
user.go | ||
utils.go |
OpenAPI specifications
Since version 8.4, HTTP API details are specified using OpenAPI v2. Starting from version 9.1, there is also an OpenAPI v3 specification (generated by the v2 one using this script).
OpenAPI annotations
The OpenAPI v2 specification is generated automatically from the annotated Go code using go-swagger which scans the source code for annotation rules. Refer to this getting started guide for getting familiar with the toolkit.
Developers modifying the HTTP API endpoints need to make sure to add the necessary annotations so that their changes are reflected into the generated specifications.
Example of endpoint annotation
The following route defines a PATCH
endpoint under the /serviceaccounts/{serviceAccountId}
path with tag service_accounts
(used for grouping together several routes) and operation ID updateServiceAccount
(used for uniquely identifying routes and associate parameters and response with them).
// swagger:route PATCH /serviceaccounts/{serviceAccountId} service_accounts updateServiceAccount
//
// # Update service account
//
// Required permissions (See note in the [introduction](https://grafana.com/docs/grafana/latest/developers/http_api/serviceaccount/#service-account-api) for an explanation):
// action: `serviceaccounts:write` scope: `serviceaccounts:id:1` (single service account)
//
// Responses:
// 200: updateServiceAccountResponse
// 400: badRequestError
// 401: unauthorisedError
// 403: forbiddenError
// 404: notFoundError
// 500: internalServerError
The go-swagger
can discover such annotations by scanning any code imported by pkg/server
but by convention we place the endpoint annotations above the endpoint definition.
Example of endpoint parameters
The following struct defines the route parameters for the updateServiceAccount
endpoint. The route expects:
- a path parameter denoting the service account identifier and
- a body parameter with the new values for the specific service account
// swagger:parameters updateServiceAccount
type UpdateServiceAccountParams struct {
// in:path
ServiceAccountId int64 `json:"serviceAccountId"`
// in:body
Body serviceaccounts.UpdateServiceAccountForm
}
Example of endpoint response
The following struct defines the response for the updateServiceAccount
endpoint in case of a successful 200
response.
// swagger:response updateServiceAccountResponse
type UpdateServiceAccountResponse struct {
// in:body
Body struct {
Message string `json:"message"`
ID int64 `json:"id"`
Name string `json:"name"`
ServiceAccount *serviceaccounts.ServiceAccountProfileDTO `json:"serviceaccount"`
}
}
OpenAPI generation
Developers can re-create the OpenAPI v2 and v3 specifications using the following command:
make swagger-clean && make openapi3-gen
They can observe its output into the public/api-merged.json
and public/openapi3.json
files.
Finally, they can browser and try out both the OpenAPI v2 and v3 via the Swagger UI editor (served by the grafana server) by navigating to /swagger
.