* [TSVB] Enable `dual mode`, support index patterns and strings
* modify UI
* add migration script
* refactoring
* fix CI
* prefill the index pattern name
* modify UI
* modify UI
* update UI
* fix functional test
* some work
* remove callouts
* fix rollup test
* update UI
* fix typo
* add some unit tests
* add functional test
* fix CI
* correct labels
* fix ci group 12
* cleanup interface
* fix CI
* cleanup API
* fix some of PR comments
* move index patterns into so references
* remove wrong logic
* fix JEST
* fix some ui issues
* update sample data
* indexPatternObject -> indexPatternValue
* fix comments
* I have a dashboard with two TSVB viz. One with the default (haven't applied it to the combobox) and one with the logs. The filter contains fields only from the logs index pattern
* When I am on the string mode and try to write my index, sometimes some of the chars are not added or they are deleted while typing, something with the denounce maybe?
* fix merge conflicts
* Does this PR also supports runtime fields? I created one from the editor and I see that I can select it
* fix UI issue
* If I create a viz with the string mode and a wildcard e.g. kibana_sample*, the index patterns are not communicated correctly to the dashboard.
* fix import/export refs for dashboard
* remove MigrationPopover
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Moves part of the exceptions UI out of the security solution plugin and into the lists plugin. In order to keep PRs (relatively) small, I am moving single components at a time. This should also then help more easily pinpoint the source of any issues that come up along the way.
The next couple PRs will focus on the exception builder. This one in particular is focused on moving over the `BuilderExceptionItem` which deals with rendering the individual exception items.
* [Alerts][Actions] Added missing telemtry mapping for a new alert and action types: geo-containment, es-query, teams
* fixed mappings
* fixed ML alert type telemetry mappings
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Split rule executors into different files
* Pass type-specific rule SOs to rule executor functions
* Genericize function to narrow ruleSO type
* Remove undefined return type from getExceptions
* Remove unintentional change to SIGNALS_TEMPLATE_VERSION
* Remove extra validation now covered by schemas
* Remove extra validation from ML rule executor
* Fix types
* syncs schemas
* Revert "syncs schemas"
This reverts commit b1dd59e3f0.
* Fix api test and move threshold executor test
* kinda adds eql test
* Refactor and fix unit tests
* fixes marshalls mistake
Co-authored-by: Davis Plumlee <davis.plumlee@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Addded test for Bytes processor.
* Broke out processor not selected section of tests to its own test and made edits per feedback in PR.
* Broke out processor data fetching to a separate reusable helper function.
* Broke out processor data fetching to a separate reusable helper function.
* Added functionality for toggling the ignore missing switch.
* ES lint fix.
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Beginning to move the exceptions UI out of the security solution plugin and into the lists plugin. In order to keep PRs (relatively) small, I plan to move single components at a time. This should also then help more easily pinpoint the source of any issues that come up along the way.
The next couple PRs will focus on the exception builder. This one in particular is focused on moving over the `BuilderEntryItem` which deals with rendering the individual exception item entries. An entry can be of type `match`, `match_any`, `list`, `exists`, or `nested`. The component makes use of the autocomplete fields which use the index patterns to display possible fields and field values.
One of the decisions made in this PR was to have consumers of the `BuilderEntryItem` pass through the autocomplete service as opposed to the `lists` plugin adding it as a dependency. The reason being that it is likely that plugins using the lists plugin will already be consuming either the data plugin or if alerting takes exceptions in, then they'll be consuming alerting. In an effort to avoid some possible icky circular dependency issues, though it best to make the service passed in, as we had already been doing with the hooks in the `lists` plugin.
* Rework panels to subdued style
* Fix button when source has been onboarded
* Update content_section test for EuiSpacer
* Update content_section test for EuiSpacer Length
* Lint fix for onboarding_card
* Remove spacer size due to default
Co-authored-by: Scotty Bollinger <scotty.bollinger@elastic.co>
* Remove test line for Spacer now that size=default
Co-authored-by: Scotty Bollinger <scotty.bollinger@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Update EuiPageHeaders with basic titles
* Update engine creation views
- meta engine - move to description
+ misc fix - non-heading EuiTitles that do not match the standalone UI
* Update EuiPageHeaders with simpler actions
* Update Documents page header
+ test reorg - move DocumentCreationButton tests to its own test block
* Update EnginesOverviewHeader (+ refactors)
- Switch from FormattedMessage to i18n to match rest of repo
- Switch to eslint-disbable instead of doing a buttonProps workaround (this will get deleted anyway post-migration)
* whoops
* [Task Manager] Fixed the behavior of the claiming tasks funtion failing, when inline scripts are disabled.
* added docs
* fixed test
* added tests
* fixed due to comments
* Fixed docs due to comments
* extended TM configuration changes message with the possible errors description
Currently we instantiate the Workplace Search app with server props passed in from the server on initial page load. This data includes the organization name. In our settings section, we poll the server to get update information, but once the data is change, the global state does not get updated on a route change. This is only a problem in the case where a user has changed their org name and returns to the overview page before reloading the page. When this happens, the onboarding step asking the user to change thier org name is still visible.