* 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.
- Create new ctxLogProviders for each scenario to support
go test -count=n for n>1. Currently, it just kept adding providers for
every new run, which would make it add way more key-value pairs to
the provider than necessary.
- Adding a helper method to the scenario to make it easier to set up tests
for logging and easier to read the tests. I also flattened the test file, to
reduce the complexity of each test function.
idafurjes
Hamas Shafiq
Will BrowneandJack Westbrook
mikkancso
Alex Khomenko
Sonia Aguilar
Andre Pereira
Joao Silva
Joey Tawadrous
Erik Sundell
renovate[bot]andrenovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Jo
Karl Persson
sam boyer
Timur OlzhabayevandChristopher Moyer
Dominik Prokop
Michael Mandrus
Todd Treece
ying-jeanne
MeanMina
Matthew Jacobson
Giordano Ricci
ismail simsek
Sandro
Emil Tullstedt
Joan López de la Franca Beltran
Ivan Ortega Alba
Kristin Laemmert