* refactor(pluginhelp): rewrite as functional component with useAsync
* mimic old behaviour
* feat(pluginhelp): display message if backend returned an empty string
Co-authored-by: Jack Westbrook <jack.westbrook@gmail.com>
update datasource details url
My ultimate goal is to make the cloud-onboarding plugin link to
datasource details page inside Connections.
I tried to do that, so that it linked to
`/connections/connect-data/datasources/:id`, but it didn't work. Details
below:
We have a problem with the datasources details page url:
If the plugin is not present, then the
`/connections/connect-data/datasources/:id` url is finely served by Grafana.
However, when the plugin is present, we register a Route entry like this:
`<Route exact=false path='/connections/connect-data' component={AppPlugin} />`
And this entry will be higher in the routes list than the datasources Route.
This means that every path under `/connections/connect-data` will be served
by the plugin. That's why exact is false. Otherwise the plugin couldn't
serve integrations details at `connect-data/infrastructure/:id`.
So `exact=false` is needed.
What can we do?
1. Put Grafana's Connection routes higher in the list of routes.
2. Find a different URL for datasources details page
Unfortunately, we can't do 1., because:
Routes roughly look like this (in this order):
- exact: false, path: connections/connect-data, component: AppPlugin
- exact: false, path: connections/your-connections/infrastructure,
component: AppPlugin
- exact: false, path: connections, component: Connections
So if a request comes for `/connections` or `/connections/your-connections`
or `/connections/your-connections/datasources`, it will be served by
Connections.
Therefore, we can't really put the route for Connections higher in the list
of routes, because then it will match all routes beginning with
`/connections`, and the plugin's routes will have no effect.
So the only alternative left is to find another path :/
Since we set the DataSourceDetailsPage's navId explicitly to
`connections-connect-data`, the breadcrumbs will continue to show the
data source page as a child item of the Connect Data page :)
* Track usages of completion items in TraceQL query editor
* Change back traceID reportInteraction() name to avoid breaking dashboards
* Filter out TAG_VALUE labels from feature tracking to avoid exposing sensitive data
* AuthN: Add basic auth client boilerplate
* AuthN: Implement test function for basic auth client
* AuthN: Implement the authentication method for basic auth
* AuthN: Add tests for basic auth authentication
* ContextHandler: perform basic auth authentication through authn service
if feature toggle is enabled
* AuthN: Add providers for sync services and pass required dependencies
* add max item text
* add tests
* add selected log groups counter label
* cleanup
* fix styling in selector fields
* remove unused imports
* move selected log groups to a new component
* add confirm dialog
* remove not used import
* set max logs groups to 6
* add margin bottom
* Set width of common columns between trace and span rows
* Better syntax highlighting for non string constants
* Apply variables to traceql query
* Fix test
* Alerting: Prevent short uid collision in legacy migration when db is case-insensitive
Two factors come into play that cause sporadic uid conflicts during legacy alert migration:
- MySQL and MySQL-compatible backends use case-insensitive collation.
- Our short uid generator is not a uniform RNG and generates uids in such a way that generations in quick succession have a higher probability of creating similar uids.
Normally we would be guaranteed unique short uid generation, however if the source alphabet contains
duplicate characters (for example, if we use case-insensitive comparison) this guarantee is void.
Generating even ~1000 uids in quick succession is nearly guaranteed to create a case-insensitive
duplicate.
* allow DatasourceOnboarding title and cta text customization
* Explore: use Datasource Onboarding page when visiting without any datasource set up
* move & rename DatasourceOnboarding
* Rename component
chore (dashboardversion service): remove (one) join from store implementations
We return the userID from the dashboardservice store; the service (or api) layer can use that to get the user's login when needed.
The DashboardVersion struct is the database object; the DashboardVersionDTO is the object that should be sent to the API layer.
In the future I'd like to move DashboardVersion to dashverimpl and un-export it, but there are a few places that Insert directly into that table, not all of which are test fixtures, so that should wait until we clean up at least the DashboardService's use of it.
