* Add support for static files
* Use url-loader in single css setup
* Add postcss setup
* Expose emotion to plugins and externalise it in toolkit
* Add readme note about emotion
* Add SAML configuration options
* Add crewjam/saml as a depdency
Needed as part of the enterprise SAML integration.
* Vendor github.com/stretchr/testify/require
The package require implements the same assertions as the `assert` package but stops test execution when a test fails.
* feat: AzureMonitor implements legend key on backend
To be able to remove the duplicated query logic on the
frontend, the backend code needs to implement alias
patterns for legend keys as well as allowing the default
list of allowed time grains to be overridden. Some metrics
do not support all the time grains and the auto timegrain
calculation can be incorrect if the list is not overridden.
* feat: AzureMonitor - removes duplicate query logic on frontend
* AzureMonitor small refactoring
Extracted method and tidied up the auto time grain
code.
* azuremonitor: support for auto time grains for alerting
Converts allowed timegrains into ms and saves in dashboard json.
This makes queries for alerting with an auto time grain work in
the same way as the frontend.
* chore: typings -> implicitAny count down to 3413
* azuremonitor: add more typings
* Explore: Adds datasource plugin config option 'modesSupportingTextEdit'
This allows one to specify which modes support toggling query text edit on and off
Closes#17904
* Explore: Restricts query text edit toggle to metrics mode
In 4281344 the loadPluginCss util was migrated to @grafana/runtime package. This made SystemJS to fail loading the css files for a plugin. Root cause was that core and runtime used different SystemJS instances.
To solve the issue, I am exposing SystemJS from @grafana/runtime package to make sure we are always using the same instance. Also, the SystemJS dependency was moved to runtime.
* ChangePassword to React, created PasswordInput component, attempting UserProvider wrapper component, adding flex to btn row
* UserAPI interface, force classes on PasswordInput, remove api call from ChangePassword
* refactored out form
* clean up
* removed unnecessary bind, added loading state and loading component to change password form
* should be OR
* arrow funcs instead of binds, inline-block instead of flex, isSaving instead of isLoading, disabled button instead of spinner
* inline-flex on the react btn
* change state instatiatiation
* Explore: Adds support for toggling text edit mode in explore
Also modifies query-row-status css to use relative position instead of absolute
Closes#16770
* Explore: Defines State interface for <QueryRow /> and removes unnecessary constructor
* LDAP: Divide the requests
Active Directory does indeed have a limitation with 1000 results
per search (default of course).
However, that limitation can be workaround with the pagination search feature,
meaning `pagination` number is how many times LDAP compatible server will be
requested by the client with specified amount of users (like 1000). That feature
already embeded with LDAP compatible client (including our `go-ldap`).
But slapd server has by default stricter settings. First, limitation is not 1000
but 500, second, pagination workaround presumably (information about it a bit
scarce and I still not sure on some of the details from my own testing)
cannot be workaround with pagination feature.
See
https://www.openldap.org/doc/admin24/limits.htmlhttps://serverfault.com/questions/328671/paging-using-ldapsearchhashicorp/vault#4162 - not sure why they were hitting the limit in
the first place, since `go-ldap` doesn't have one by default.
But, given all that, for me `ldapsearch` command with same request
as with `go-ldap` still returns more then 500 results, it can even return
as much as 10500 items (probably more).
So either there is some differences with implementation of the LDAP search
between `go-ldap` module and `ldapsearch` or I am missing a step :/.
In the wild (see serverfault link), apparently, people still hitting that
limitation even with `ldapsearch`, so it still seems to be an issue.
But, nevertheless, I'm still confused by this incoherence.
To workaround it, I divide the request by no more then
500 items per search
* Teams: show proper label for each auth provider
Teams: don't sore AuthModule in team_member table, use JOIN to get it instead
* Teams: fix AddTeamMember after last changes
* Teams: add more auth provider labels
* Teams: show external sync badge if LDAP is not enabled
* Teams: tests for getting auth module
* Build: use golangci-lint as a make command
* Since gometalinter was deprecated in favor of golangci-lint so it was
replaced by it. Responsibilities held by the gometalinter was moved to
golangci-lint
* There was some changes in implementation (that was also mentioned in
the code comment) between the tools, which uncovered couple errors
in the code. Those issues were either solved or disabled by
the inline comments
* Introduce the golangci-lint config, to make their
configuration more manageable
* Build: replace backend-lint.sh script with make
* Docs: correct link to the Grafana build-container.
* Docs: documents usage on the gopath when upgrading deps.
* Dev docs: info for upgrading deps only in one location.
* Add LDAP config instead sed use
* Add container name
* Add SizeLimit option to client and to server.
Probably useless at this point, but it's better to have it then otherwise
* OAuth: github team sync POC
* OAuth: minor refactor of github module
* OAuth: able to use team shorthands for github team sync
* support passing a list of groups via auth-proxy header
* TimePicker: Restore time picker settings
* CleanUp: removed unuused angular-ui (calendar) components
* Fix angular boot dependency list
* TimePicker: set time to 23:59:00 when setting To time using calendar
Elasticsearch v7.0 changed the behavior of max concurrent shard
requests and the default to 5. v5.6 and before 7.0 the default
is 256. This adds some additional behavior given certain
version is selected when configure the datasource to set
default max concurrent shard requests.
Changing from a version pre-v7.0+ to v7.0+ sets max
concurrent shard requests to 5.
Changing from a version v7.0+ to a pre-v7.0 sets max
concurrent shard requests to 256.
Fixes#17454
