Add a welcome screen to Kibana home if this is a new Kibana instance.
New is determined by whether or not there are any index patterns
defined. Local storage is used to retain the user's decision to hide
the welcome screen.
* [DOCS] New tutorial for exploring Kibana with sample data set
* [DOCS] Incorporated review comments into sample tutorial
* [DOCS] GS: Edits for consistency
* Fix heatmap colors to depend on existing number of ranges
If we custom ranges are enabled, depends on number of labels configured, if not depends on configured colorsNumber value
* Fix wrong test descriptions
* Add functional tests for heatmap custom ranges
* Relay on labels.length as valid number of ranges
Instead of check if we have a set of custom ranges or the default ones, we just relay on the labels returned by getHeatmapLabels that already compute the right number of labels depending on the vis config.
In #19916 we inadvertently began directly returning the data from the Keystore when the Kibana server expects a structured object.
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
* Remove unused refreshInterval file.
* Use warning toast to indicate failure to reload the indices.
* Close tag in main.html.
* Add comment about $http service dependency.
A couple times while debugging failures in `functional_tests(_servers)` with people I've asked for stack traces and received responses like "that's all there is", and it turns out that's right, because the cli's are passing the error object directly to `chalk.red()`, which converts it into a string that only includes the message. This pr moves the common operations from `run_tests/cli.js` and `run_servers/cli.js` into `lib/run_cli` and includes test for the common functionality there, as well as a common error printing logic that still includes the red message, but also includes a stack trace that will help out a lot in debugging.
This PR implements the `uiSettings.overrides` setting which [when stored in kibana.yml or passed as config args when starting Kibana] allows forcing some uiSettings to always have a specific value. This setting accepts a map of uiSetting keys to values that will always be used to override whatever is stored in the config saved object.
When users view the settings in the advanced settings UI they are disabled and describe why they can't be changed.
Attempting to change these values from the uiSettings client/service/api is also prevented, causing a 400 error to be thrown and/or sent as the response.
* [typescript] continue to use the default config in development
In #21865 we tried to make a separate config file that would be used for
browser TS files by excluding them from the default config file and
adding a second that included them. This works fine in the build, but
IDE integrations rely on being able to automatically discover a
`tsconfig.json` file in a parent directory of the file being edited,
which doesn't work when the tsconfig.json file is found, but excludes
the file being edited. In this situation IDE integrations silently
fallback to the default TSConfig settings, which don't show the types of
compiler errors that will become issues in CI, like implicit any
warnings.
This implements the original strategy we tried in #21865 of mutating the
tsconfig.json file before we run the tsc in the build so that the config
files select the right files at build time.
* [tslint] remove browser config from default projects list since it is empty
* [build/ts] fix typo
We currently use the `retry` service to call a function over and over in a loop, waiting for it to run without throwing an error, and ultimately failing if it does not succeed before a timeout is exceeded. This is the easiest way to get certain interactions to work, either because we don't know when we should be able to execute the interaction successfully, or because the timing is just too tricky to plan out correctly. Another place where we are using the `retry` service, which I don't think is appropriate, is when we need to wait for a certain condition to be met. This is where `retry.waitFor()` comes in:
```js
await retry.waitFor('dashboard search to be enabled', async () => {
const searchInput = await testSubjects.find('savedObjectFinderSearchInput');
return await searchInput.isEnabled();
})
```
The `retry.waitFor()` method behaves much like the `retry.try()` method behind the scenes, calling a function over and over, but instead of waiting for it to run without throwing an error it waits for it to return a "truthy" value. It also requires a description string that is used to make rather nice log output and a more descriptive error message than something like https://github.com/elastic/kibana/blob/master/test/functional/apps/dashboard/_data_shared_attributes.js#L61-L67
Fixes#20698
As part of the transition of APIs necessary for migrating the Chrome to the new platform, this moves the core logic for the toastNotifications out of `ui/notify` and into the new platform as the `core.notifications.toasts` service. I chose to use the `notifications` namespace here as I plan for the [`banners` service](494c267cd9/src/ui/public/notify/banners/banners.js) from `ui/notify` to eventually live at `core.notifications.banners`. If you disagree with this strategy and would prefer that we use something like `core.toastNotifications` let me know.
For the most part this service just does the same thing as the ui service did, so functionality should be exactly the same. To test the notifications I suggest using the testbed like so: https://gist.github.com/spalger/81097177c88dee142700fab25de88932
This commit moves the large majority of the mappings library previously in src/server/mappings into src/core/server/saved_objects/mappings, since mappings should be owned by saved_objects. The kibanaIndexMappingsMixin remains in src/server, but is moved into src/server/saved_objects/mappings, keeping the same folder structure for consistency.
While debugging failures I saw in #21772 I found myself encountering failure messages like `Error: expected undefined to sort of equal true`, and other more cryptic errors caused by methods like `PageObjects.dashboard.saveDashboard()` not ensuring that the dashboard was actually saved before resolving. As part of the debugging effort I noticed that the `saveDashboard()` method does have some awareness of the success condition, but rather than asserting success within the method it returns a success boolean for the caller to check, which was only being done in a handful of tests in `test/functional/apps/dashboard/_dashboard_time.js` but was ignored the vast majority of the time.
I think that most of the time we are calling `PageObjects.dashboard.saveDashboard()` we correctly assume that if the dashboard couldn't be saved for some reason the promise will be rejected and the test would fail. If the method was called `maybeSaveDashboard()` or `tryToSaveDashboard()` there might be a signal to consumers that they should check for success conditions, but that would also lead to the same checks all over the place. Instead, this PR reverses the responsibility of checking for success so that code calling `PageObjects.dashboard.saveDashboard()` can continue to assume that if something went wrong their test will fail. It also improves the error message by not using `expect(boolean).to.equal(boolean)`, instead implementing a basic `if()` statement and throwing an error with a meaningful message when something goes wrong.
```js
const isDashboardSaved = await testSubjects.exists('saveDashboardSuccess');
expect(isDashboardSaved).to.eql(true);
```
is now
```js
if (!await testSubjects.exists('saveDashboardSuccess')) {
throw new Error('Expected to find "saveDashboardSuccess" toast after saving dashboard');
}
```
---
I think this type of change could be made to a lot of methods, and would make failures a lot easier to debug and possibly a lot less flaky if we were checking for success conditions in nearly every method we put in our PageObjects. I think it's safe to say that most of the methods we have in PageObjects do not check for actual success criteria, and sometimes that's okay: a method called `clickButton()` can safely resolve once the click method has been called, but a method like `addSampleDataSet()` should be verifying that the sample data set it set out to add was actually added.
* Beginning to work on the role management APIs. Added docs for GET
* Adding PUT docs
* Adding PUT details
* Adding delete docs
* Fixing linking
* Adding Kibana privileges section
* Fixing dashboard only mode docs
* Fixing a few more references to managing roles
* Beginning to work on authorization docs, might be moving some to
stack-docs
* Collapsing authorization description in the kibana privileges page
* Adding audit logging section
* Revising the language on the Kibana role management section
* Splitting back out the auth/privileges and adding legacy fallback
details
* Revising language around impact of disabling security
* Changing Kibana to {kib} and Elasticsearch to {es}
* Beginning to work on developer centric docs
* Fixing some formatting, adding some diagrams
* Adding note about the role management APIs
* Adding overview, fixing small syntax issues
* Fixing chunk name for transitioning to application privileges
* Adjusting tone for the authorization introduction
* Changing the tone and structure of the RBAC docs
* Deleting blog stuff after refactoring
* Addressing first round of peer review comments
* Fixing endpoints links
* Peer review suggested edits
* Addressing other PR feedback
add support for extracting default messages from code strings like:
formatMessage();
intl.formatMessage();
props.intl.formatMessage();
this.props.intl.formatMessage();
