* 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
Adds version note for alert rule tags.
Adds version note for graph data links.
Adds information about secret_key and encryption format in use
Fixes#17815Fixes#17803
* Add test that expects a POST request
* Change graphite /metric/find request to POST
Query parameter can become large enough
to exceed GET URI limits.
* Fix requests with time range
Initialise httpOptions.params
* Fix for supporting queries referencing template variable
* Move cli to grafana-toolkit
* Moving packages, fixing ts
* Add basics of plugin build task
* Add toolkit build task
* Circle - use node 10 for test-frontend
* Prettier fix
* First attempt for having shared tsconfig for plugins
* Add enzyme as peer depencency
* Do not expose internal commands when using toolkit from npm package
* Introduce plugin linting
* Fix missing file
* Fix shim extenstion
* Remove rollup typings
* Add tslint as dependency
* Toolkit - use the same versions of enzyme and tslint as core does
* Remove include property from plugin tsconfig
* Take failed suites into consideration when tests failed
* Set ts-jest preset for jest
* Cleanup tsconfig.plugins
* Add plugin:test task
* Rename file causing build failute
* Fixing those missed renames
* Add ts as peer dependency
* Remove enzyme dependency and tweak test plugin task
* Allow jest options overrides via package.json config
* Improvements
* Remove rollup node packages
* TMP : Fix ts errors when linked
* use local tslint if it exists
* support coverage commands
* Fix merge
* fix build
* Some minors
* Make jest pass when no tests discovered
Adds URL support for mode state (Metrics/Logs). It's important
to be able to share a link to logs when a data source supports
both metrics and logs.
Closes#17101
