* Added spans to trace.go
* Added spans to search_stream.go
* Added spans to parca datasource
* Added spans for pyroscope
* Fix tests
* Fix another test
* Lint
* Revert "Fix another test"
This reverts commit a1639049e3.
* Use grafana-sdk-go tracing
* moved themecontext to data
* chore(grafana-ui): re-export ThemeContext from grafana/data for backwards compatibility
* Moved icon bundling to core.
* feat(plugins): share react-inlinesvg with plugins for grafana/ui bundling
* chore(codeowners): add generate-icon-bundle.js to file
* chore(storybook): update path to iconBundle file for theme
* feat(plugins): share i18n dependency via systemjs
* Make sure that icon bundle is initialized for tests.
* Removed comment.
* added tests for icon root.
* Removing the need of having an init variable.
* feat(grafana-ui): add icon svgs to bundle for projects that don't rely on grafana
---------
Co-authored-by: Marcus Andersson <marcus.andersson@grafana.com>
* Add role mapping support for Google OIDC
* Added note about entry already being in on-prem
* Add line
* Fixed version syntax
* Fixed typo
* Removed index.md from link
* Added release date
* Fix migration of custom dashboard permissions
Dashboard alert permissions were determined by both its dashboard and
folder scoped permissions, while UA alert rules only have folder
scoped permissions.
This means, when migrating an alert, we'll need to decide if the parent folder
is a correct location for the newly created alert rule so that users, teams,
and org roles have the same access to it as they did in legacy.
To do this, we translate both the folder and dashboard resource
permissions to two sets of SetResourcePermissionCommands. Each of these
encapsulates a mapping of all:
OrgRoles -> Viewer/Editor/Admin
Teams -> Viewer/Editor/Admin
Users -> Viewer/Editor/Admin
When the dashboard permissions (including those inherited from the parent
folder) differ from the parent folder permissions alone, we need to create a
new folder to represent the access-level of the legacy dashboard.
Compromises:
When determining the SetResourcePermissionCommands we only take into account
managed and basic roles. Fixed and custom roles introduce significant complexity
and synchronicity hurdles. Instead, we log a warning they had the potential to
override the newly created folder permissions.
Also, we don't attempt to reconcile datasource permissions that were
not necessary in legacy alerting. Users without access to the necessary
datasources to edit an alert rule will need to obtain said access separate from
the migration.
Remove legacy form from InfluxConfigEditor
With this commit, legacy form components are remvoed from influxdb
config eidtor page. Form is now using FieldSet instead.
There is a sentence in the [Built-in query](https://grafana.com/docs/grafana/latest/dashboards/build-dashboards/annotate-visualizations/#built-in-query) section of the page that could use a "the" (emphasis added by me 😄) :
> When you copy a dashboard using the Save As feature it will get a new dashboard id, **so annotations created on source dashboard** will no longer be visible on the copy. You can still show them if you add a new Annotation Query and filter by tags. However, this only works if the annotations on the source dashboard had tags to filter by.
This PR adds "the" so the phrase reads "so annotations created on the source dashboard"
* Manage service account secrets
* Wip
* WIP
* WIP
* Revert to keep a light interface
* Implement SaveExternalService
* Remove unecessary functions from the interface
* Remove unused field
* Better log
* Leave ext svc credentials out of the extsvcauth package for now
* Remove todo
* Add tests to SaveExternalService
* Test that secret has been removed from store
* Lint
* Nit.
* Rename commands and structs
Co-authored-by: Kalle Persson <kalle.persson@grafana.com>
* Account for PR feedback
Co-authored-by: Andres Martinez Gotor <andres.martinez@grafana.com>
* Linting
* Add nosec comment G101 - this is not a hardcoded secret
* Lowercase kvStoreType
---------
Co-authored-by: Kalle Persson <kalle.persson@grafana.com>
Co-authored-by: Andres Martinez Gotor <andres.martinez@grafana.com>
