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();
This fixes bucket span estimation for the machine learning admin user when security is enabled. The original issue was that the machine learning admin by default doesn't have the necessary permissions to call cluster.getSettings to get the settings search.max_buckets. This is now fixed by using callWithInternalUser() and additional permissions checks.
This adds support for autoprefixer which we have been using in Webpack.
Additionally, we have improved the watching functionality and now update builds based directly on their dependencies an not an assumption that the files are children.
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
* add polyfill for ChildNode remove
* call polyfill function
* add files as suggested by jbudz
* remove checks around polyfill
* just use polyfill that mozilla recommends
* add MIT license to file
* suffix file with polyfill, update copyright and link to repo
* update notice.txt
Right now the build process is running TypeScript code through a single transpilation process which produces the JS code that ships with the distributable. This process causes problems because when running the optimizer from source we use a slightly different config 33c6ade756/src/optimize/base_optimizer.js (L312-L313), which instructs typescript to build modules using ESM, which webpack understands, but in the build we transpile this TypeScript to commonjs, which does not support features that are important to the strategy we are using to maintain BWC with the legacy platform as we migrate to the new platform.
This implements a `tsconfig.browser.json` file at the root of the repository that extends the default `tsconfig.json` file and includes a `src/**/public/**/*` code, which the root `tsconfig.json` file now excludes. This new config file is added to the list of projects that we lint, is shared with webpack, and is built along with the default project in the build process to create JS code that uses esm for webpack to consume.
The debounce in ng-model-options was intended to avoid updating the
typeahead suggestions too often. It had the side effect of delaying
query input updates to the model on the angular scope. As a result, if
you typed quickly and hit enter within 100ms, you would submit an out of
date query. This moves the debounce from ng-model-options to the
updateSuggestions method itself.
Fixes https://github.com/elastic/kibana/issues/20099
I made the changes described by Tim at https://github.com/elastic/kibana/issues/20099 and everything seems to be working. I tried to update the typeahead in such a way that it can be made accessible anywhere it is used, even if there are multiple typeahead instances on a single page.
> (optional) an aria-label on the individual suggestions that should be read out to screen reader. By default the content will be used, and that should be fine (unless you figure out there is too much "noise" elements in it.
I did not do this bit since the text that is read seems reasonable to me, but I'm open to changing it if others feel differently.
* Show more of the name column in the Watcher watch table by making the table 100% width of the page, and by increasing the column width to 25%.
* Convert all title attributes to kbnTooltip.
* Add title attributes for columns which have tooltip content different from cell content.
* Add Guideline for i18n engine
* Update Guideline according to changes in i18n engine.
* Update examples in Guideline
* typo
* improve i18n guideline: add table for better view, use single quotes for js strings, fix description for testing, use uniq "message id" name
* fix readme description for guideline
Co-authored-by: maryia-lapata "mary.lopato@gmail.com"
