## Summary
Enables caching in our application by setting the default date time of our application to be `from: now/d` and `to: now/d`. When users go to the advanced settings they will see this now:
<img width="1243" alt="Screen Shot 2021-03-04 at 11 53 08 AM" src="https://user-images.githubusercontent.com/1151048/110014626-43fb6700-7ce0-11eb-94ee-0c4cc7a8a10f.png">
In their date time bars on page loads they will see today instead of 24 hours:
<img width="556" alt="Screen Shot 2021-03-04 at 11 50 18 AM" src="https://user-images.githubusercontent.com/1151048/110015216-dac82380-7ce0-11eb-935d-2d71078c1170.png">
When before they used to have `from: now-24` and `to: now`. This new date time frame plays well with Elastic caches and no longer "busts" them for users on each page request. Now users will send the same date time frame on each query which will cache the views as the default.
This also fixes a small bug with the URL's where the "to" was not being rounded up when it was a dynamic date time on first load. For example if you went to the URL, `/app/security/hosts/allHosts` with no additional state information but have a default of `from: now/d` and `to: now/d` it would not round up the date time. Now it rounds it up through the date math utilities which only rounds when it sees that it is a dynamic date math.
When requests are being sent, expect to see this where you have `from` rounded down and `to rounded up. This should be a consistent non-sliding date time math for caching to operate:
<img width="608" alt="Screen Shot 2021-03-04 at 11 33 11 AM" src="https://user-images.githubusercontent.com/1151048/110015357-01865a00-7ce1-11eb-8580-efacf791b573.png">
If you change the `to` to be another date math such as `now+1d/d` expect to see it also rounded up. This behavior mirrors that of discover:
<img width="608" alt="Screen Shot 2021-03-04 at 11 33 11 AM" src="https://user-images.githubusercontent.com/1151048/110015440-17941a80-7ce1-11eb-832d-e826962829ed.png">
You can manually verify this behavior by setting the same now dates in discover as well as security solutions and both should work as is even when you remove the URL state from the right side of a `?`
### Checklist
- [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
* Use ReplaySubject and amend date comparisons
* Assess date range expressions separately
* Only add dataset filter to view in stream links if one exists
* Added data-test-subj for ILM policies row and added a functional UI test to create a new ILM policy.
* Removed .only from test to allow entire test suite to run again.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* remove stathood deps. not used anymore
* remove direct deps on @hapi/statehood
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* wip
* Moving catchError so observable stream does not complete. Adding retry on failure
* Using retryWhen. Updating unit tests
* PR fixes
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Documentation for scaling Kibana alerting, what configurations can change, what impacts they have, etc.
Scaling Alerting relies heavily on scaling Task Manager, so these docs also document Task manager Health Monitoring and scaling.
Before we removed environment from the UI filters (#89647), the environment query parameter would be undefined if "All" was selected. Now we send ENVIRONMENT_ALL in as the query parameter.
Changes in https://github.com/elastic/kibana/blob/master/x-pack/plugins/apm/server/lib/service_map/get_service_map_from_trace_ids.ts made it so no connections would be returned if ENVIRONMENT_ALL was selected, rather than all connections. Since no connections were being returned, no elements except the selected service would be returned in the API response.
This changes it so if ENVIRONMENT_ALL is selected, the connection will always be returned, just like what used to be the case when environment was undefined.
Add an API test for this case.
Fixes#93385.
resolves https://github.com/elastic/kibana/issues/90006
For task manager, adds a note about the fact that the max_workers will be
limited to 100 starting in 8.0. Currently we allow any value (because we
always have), but do print a "deprecation" warning that the limit cannot
be exceeded starting in 8.0
For alerting, adds note about the JSON expansion of action variables which are objects.
* Escape quotes in list ids and quote the id in KQL query
* Remove decodeURIComponent because too many KQL queries don't handle quotes
* Add quotes to user supplied IDs for other KQL queries
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [Discover] Fix link from dashboard saved search to Discover
* Fix tests that weren't fully testing the navigation
* Fix snapshot
* Fix test navigation to context app by reverting to previous
* Unskip functional test and fix issue in data grid
* Respond to review comments
* WIP analytics polish
* Working on tests.
* Finishing up tests.
* Updating the engine overview page.
* eslint fixes
* i18n fixes
* Icons feedback
- Remove unused svg file
- Add TODO comment
- Add test coverage
* linting - unnecessary ternaries
* EnginesOverview feedback
TotalCharts
- adjust chart height
- tests: simplify / convert back to shallow
RecentApiLogs
- switch to DataPanel
* DataPanel feedback
Component
- move CSS table bg override out from being an AnalyticsTable concern to a DataPanel concern
+ bem naming, todo comment
- add responsive={false} for better mobile UX
- add className and data-test-subj prop passing
- change title to pass full heading tags rather than a string
- move subtitle below title for better screen reader order
- add index.ts export
Tests
- capitalization for consistency, ordering/describe
- remove data-test-subjs on source code (simpler to grab & inspect tags directly so we can more easily call .text() on passed content)
- add new tests for props (fliled/className/data-test-subj)
Usage
- update other files using DataPanel to start passing heading tags + use index export
- fix RecentApiLogs tests
- change RecentQueries section to use a DataPanel (per Davey)
* Analytics tags - updates & responsive tweaks
Tags
- Rename to more general tags.tsx file
- Add CSS limiting width of variable length tags
- Break up into two separate components for easier readability & testing
- Split up tags column constants so that the wider tables can use the old tags list component
Tables
- add isSmall flag to AnalyticsTable to use new tag count component
- reduce actions column width
- revert unnecessary table test changes
Analytics
- add custom CSS that switches tables/panels into full-width earlier
* AnalyticsSection fixes
- fix responsive behavior with icon
- add missing AnalyticsSection branch coverage
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Constance Chen <constance.chen.3@gmail.com>
## Problem
Blocks of 10-15 `import`s are common in the plugin and there a few places which have ~50 lines of `import`s. It makes it more difficult to understand the where/why of what's being imported.
We've had instances while files import from the same module in different lines. i.e.
```ts
import { a } from './file';
... 5-10 lines later
import { b } from './file';
```
## Proposed solution
Add a lint rule to enforce a convention on the module `import` order. This can help in the same way Prettier & ESLint help to format type signatures or other code. It makes it easier to understand or notice any changes in the code. It's also able to be fixed automatically (`node scripts/eslint.js --fix` or any existing "format on save" in an editor).
## This PR
replaces #92980 (based on https://github.com/elastic/kibana/pull/92980#pullrequestreview-601070556)
### Lint rule
f9be98d Add eslint rule to enforce/autofix import group order. Use the same rule as a few other plugins. Groups `import` statements by type as shown in the [lint rule docs](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/order.md#importorder-enforce-a-convention-in-module-import-order
). The order is:
1. node "builtin" modules
2. "external" modules
3. "internal" modules
4. modules from a "parent" directory
5. "sibling" modules from the same or a sibling's directory, "index" of the current directory, everything else
e.g.
```typescript
import fs from 'fs';
import path from 'path';
import _ from 'lodash';
import chalk from 'chalk';
import foo from 'src/foo';
import foo from '../foo';
import qux from '../../foo/qux';
import bar from './bar';
import baz from './bar/baz';
import main from './';
```
The [lint rule](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/order.md#importorder-enforce-a-convention-in-module-import-order) is relatively light handed. It only ensures the `imports` are groups together in the given order. It doesn't alphabetize or otherwise sort the order of the files.
e.g. imports aren't rewritten to be in alphabetical order. This is fine
```ts
import from './c';
import from './a';
import from './b';
```
The [docs show other options](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/order.md#options) and 2831f02bc7/.eslintrc.js (L1138-L1168) uses many of them
### Newlines option
The newlines settings means a change from something like
```typescript
import fs from 'fs';
import path from 'path';
import _ from 'lodash';
import chalk from 'chalk';
import foo from 'src/foo';
import foo from '../foo';
import qux from '../../foo/qux';
import bar from './bar';
import baz from './bar/baz';
import main from './';
```
to
```typescript
import fs from 'fs';
import path from 'path';
import _ from 'lodash';
import chalk from 'chalk';
import foo from 'src/foo';
import foo from '../foo';
import qux from '../../foo/qux';
import bar from './bar';
import baz from './bar/baz';
import main from './';
```
Added it as a separate commit 2831f02 in case we want to avoid it, but I believe it's an improvement overall. Especially on the files with 25+ lines of imports. Even the "worst case" of something like this isn't bad (IMO). Especially since it's an automatic reformat like anything else in prettier
```typescript
import fs from 'fs';
import _ from 'lodash';
import foo from '../foo';
import main from './';
```
* Writing failing test for duplicate ids
* Test is correctly failing prior to bug fix
* Working jest tests
* Adding more jest tests
* Fixing jest tests
* Adding await and gzip
* Fixing type errors
* Updating log message
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
