## Summary
Since the new Kibana test framework has a strong dependency on
`@playwright/test`, moving it under appex-qa ownership
I had to update and explicitly specify types when extending the
pre-existing fixtures as there was a bug fix enforcing it
https://github.com/microsoft/playwright/pull/32066
- Closes https://github.com/elastic/kibana/issues/167582
## Summary
This PR removes the code related to the legacy doc table and 2 Advanced
Settings: `doc_table:legacy` and `truncate:maxHeight`.
The legacy table in Discover was replaced by the new data grid in v8.3.
The `doc_table:legacy` Advanced Setting was added to let users switch
back to the legacy table if necessary. The removal of the setting and
the legacy table entirely would allow us to reduce bundle size,
maintenance burden, and code complexity.
Also the legacy table does not support many new features which were
added to the grid only (e.g. comparing selected documents, context-aware
UI based on current solution project, column resizing, bulk row
selection, copy actions, new doc viewer flyout, and more).
Since v8.15 `doc_table:legacy` is marked as deprecated on Advanced
Settings page via https://github.com/elastic/kibana/issues/179899
Since v8.16 `truncate:maxHeight` is marked as deprecated too via
https://github.com/elastic/kibana/pull/183736
The removal of these 2 settings and the associated code is planned for
v9.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR aims to decouple the feature IDs from the `consumer` attribute
of rules and alerts.
Towards: https://github.com/elastic/kibana/issues/187202
Fixes: https://github.com/elastic/kibana/issues/181559
Fixes: https://github.com/elastic/kibana/issues/182435
> [!NOTE]
> Unfortunately, I could not break the PR into smaller pieces. The APIs
could not work anymore with feature IDs and had to convert them to use
rule type IDs. Also, I took the chance and refactored crucial parts of
the authorization class that in turn affected a lot of files. Most of
the changes in the files are minimal and easy to review. The crucial
changes are in the authorization class and some alerting APIs.
## Architecture
### Alerting RBAC model
The Kibana security uses Elasticsearch's [application
privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-put-privileges.html#security-api-put-privileges).
This way Kibana can represent and store its privilege models within
Elasticsearch roles. To do that, Kibana security creates actions that
are granted by a specific privilege. Alerting uses its own RBAC model
and is built on top of the existing Kibana security model. The Alerting
RBAC uses the `rule_type_id` and `consumer` attributes to define who
owns the rule and the alerts procured by the rule. To connect the
`rule_type_id` and `consumer` with the Kibana security actions the
Alerting RBAC registers its custom actions. They are constructed as
`alerting:<rule-type-id>/<feature-id>/<alerting-entity>/<operation>`.
Because to authorizate a resource an action has to be generated and
because the action needs a valid feature ID the value of the `consumer`
should be a valid feature ID. For example, the
`alerting:siem.esqlRule/siem/rule/get` action, means that a user with a
role that grants this action can get a rule of type `siem.esqlRule` with
consumer `siem`.
### Problem statement
At the moment the `consumer` attribute should be a valid feature ID.
Though this approach worked well so far it has its limitation.
Specifically:
- Rule types cannot support more than one consumer.
- To associate old rules with a new feature ID required a migration on
the rule's SOs and the alerts documents.
- The API calls are feature ID-oriented and not rule-type-oriented.
- The framework has to be aware of the values of the `consumer`
attribute.
- Feature IDs are tightly coupled with the alerting indices leading to
[bugs](https://github.com/elastic/kibana/issues/179082).
- Legacy consumers that are not a valid feature anymore can cause
[bugs](https://github.com/elastic/kibana/issues/184595).
- The framework has to be aware of legacy consumers to handle edge
cases.
- The framework has to be aware of specific consumers to handle edge
cases.
### Proposed solution
This PR aims to decouple the feature IDs from consumers. It achieves
that a) by changing the way solutions configure the alerting privileges
when registering a feature and b) by changing the alerting actions. The
schema changes as:
```
// Old formatting
id: 'siem', <--- feature ID
alerting:['siem.queryRule']
// New formatting
id: 'siem', <--- feature ID
alerting: [{ ruleTypeId: 'siem.queryRule', consumers: ['siem'] }] <-- consumer same as the feature ID in the old formatting
```
The new actions are constructed as
`alerting:<rule-type-id>/<consumer>/<alerting-entity>/<operation>`. For
example `alerting:rule-type-id/my-consumer/rule/get`. The new action
means that a user with a role that grants this action can get a rule of
type `rule-type` with consumer `my-consumer`. Changing the action
strings is not considered a breaking change as long as the user's
permission works as before. In our case, this is true because the
consumer will be the same as before (feature ID), and the alerting
security actions will be the same. For example:
**Old formatting**
Schema:
```
id: 'logs', <--- feature ID
alerting:['.es-query'] <-- rule type ID
```
Generated action:
```
alerting:.es-query/logs/rule/get
```
**New formatting**
Schema:
```
id: 'siem', <--- feature ID
alerting: [{ ruleTypeId: '.es-query', consumers: ['logs'] }] <-- consumer same as the feature ID in the old formatting
```
Generated action:
```
alerting:.es-query/logs/rule/get <--- consumer is set as logs and the action is the same as before
```
In both formating the actions are the same thus breaking changes are
avoided.
### Alerting authorization class
The alerting plugin uses and exports the alerting authorization class
(`AlertingAuthorization`). The class is responsible for handling all
authorization actions related to rules and alerts. The class changed to
handle the new actions as described in the above sections. A lot of
methods were renamed, removed, and cleaned up, all method arguments
converted to be an object, and the response signature of some methods
changed. These changes affected various pieces of the code. The changes
in this class are the most important in this PR especially the
`_getAuthorizedRuleTypesWithAuthorizedConsumers` method which is the
cornerstone of the alerting RBAC. Please review carefully.
### Instantiation of the alerting authorization class
The `AlertingAuthorizationClientFactory` is used to create instances of
the `AlertingAuthorization` class. The `AlertingAuthorization` class
needs to perform async operations upon instantiation. Because JS, at the
moment, does not support async instantiation of classes the
`AlertingAuthorization` class was assigning `Promise` objects to
variables that could be resolved later in other phases of the lifecycle
of the class. To improve readability and make the lifecycle of the class
clearer, I separated the construction of the class (initialization) from
the bootstrap process. As a result, getting the `AlertingAuthorization`
class or any client that depends on it (`getRulesClient` for example) is
an async operation.
### Filtering
A lot of routes use the authorization class to get the authorization
filter (`getFindAuthorizationFilter`), a filter that, if applied,
returns only the rule types and consumers the user is authorized to. The
method that returns the filter was built in a way to also support
filtering on top of the authorization filter thus coupling the
authorized filter with router filtering. I believe these two operations
should be decoupled and the filter method should return a filter that
gives you all the authorized rule types. It is the responsibility of the
consumer, router in our case, to apply extra filters on top of the
authorization filter. For that reason, I made all the necessary changes
to decouple them.
### Legacy consumers & producer
A lot of rules and alerts have been created and are still being created
from observability with the `alerts` consumer. When the Alerting RBAC
encounters a rule or alert with `alerts` as a consumer it falls back to
the `producer` of the rule type ID to construct the actions. For example
if a rule with `ruleTypeId: .es-query` and `consumer: alerts` the
alerting action will be constructed as
`alerting:.es-query/stackAlerts/rule/get` where `stackRules` is the
producer of the `.es-query` rule type. The `producer` is used to be used
in alerting authorization but due to its complexity, it was deprecated
and only used as a fallback for the `alerts` consumer. To avoid breaking
changes all feature privileges that specify access to rule types add the
`alerts` consumer when configuring their alerting privileges. By moving
the `alerts` consumer to the registration of the feature we can stop
relying on the `producer`. The `producer` is not used anymore in the
authorization class. In the next PRs the `producer` will removed
entirely.
### Routes
The following changes were introduced to the alerting routes:
- All related routes changed to be rule-type oriented and not feature ID
oriented.
- All related routes support the `ruleTypeIds` and the `consumers`
parameters for filtering. In all routes, the filters are constructed as
`ruleTypeIds: ['foo'] AND consumers: ['bar'] AND authorizationFilter`.
Filtering by consumers is important. In o11y for example, we do not want
to show ES rule types with the `stackAlerts` consumer even if the user
has access to them.
- The `/internal/rac/alerts/_feature_ids` route got deleted as it was
not used anywhere in the codebase and it was internal.
All the changes in the routes are related to internal routes and no
breaking changes are introduced.
### Constants
I moved the o11y and stack rule type IDs to `kbn-rule-data-utils` and
exported all security solution rule type IDs from
`kbn-securitysolution-rules`. I am not a fan of having a centralized
place for the rule type IDs. Ideally, consumers of the framework should
specify keywords like `observablility` (category or subcategory) or even
`apm.*` and the framework should know which rule type IDs to pick up. I
think it is out of the scope of the PR, and at the moment it seems the
most straightforward way to move forward. I will try to clean up as much
as possible in further iterations. If you are interested in the upcoming
work follow this issue https://github.com/elastic/kibana/issues/187202.
### Other notable code changes
- Change all instances of feature IDs to rule type IDs.
- `isSiemRuleType`: This is a temporary helper function that is needed
in places where we handle edge cases related to security solution rule
types. Ideally, the framework should be agnostic to the rule types or
consumers. The plan is to be removed entirely in further iterations.
- Rename alerting `PluginSetupContract` and `PluginStartContract` to
`AlertingServerSetup` and `AlertingServerStart`. This made me touch a
lot of files but I could not resist.
- `filter_consumers` was mistakenly exposed to a public API. It was
undocumented.
- Files or functions that were not used anywhere in the codebase got
deleted.
- Change the returned type of the `list` method of the
`RuleTypeRegistry` from `Set<RegistryRuleType>` to `Map<string,
RegistryRuleType>`.
- Assertion of `KueryNode` in tests changed to an assertion of KQL using
`toKqlExpression`.
- Removal of `useRuleAADFields` as it is not used anywhere.
## Testing
> [!CAUTION]
> It is very important to test all the areas of the application where
rules or alerts are being used directly or indirectly. Scenarios to
consider:
> - The correct rules, alerts, and aggregations on top of them are being
shown as expected as a superuser.
> - The correct rules, alerts, and aggregations on top of them are being
shown as expected by a user with limited access to certain features.
> - The changes in this PR are backward compatible with the previous
users' permissions.
### Solutions
Please test and verify that:
- All the rule types you own with all possible combinations of
permissions both in ESS and in Serverless.
- The consumers and rule types make sense when registering the features.
- The consumers and rule types that are passed to the components are the
intended ones.
### ResponseOps
The most important changes are in the alerting authorization class, the
search strategy, and the routes. Please test:
- The rules we own with all possible combinations of permissions.
- The stack alerts page and its solution filtering.
- The categories filtering in the maintenance window UI.
## Risks
> [!WARNING]
> The risks involved in this PR are related to privileges. Specifically:
> - Users with no privileges can access rules and alerts they do not
have access to.
> - Users with privileges cannot access rules and alerts they have
access to.
>
> An excessive list of integration tests is in place to ensure that the
above scenarios will not occur. In the case of a bug, we could a)
release an energy release for serverless and b) backport the fix in ESS.
Given that this PR is intended to be merged in 8.17 we have plenty of
time to test and to minimize the chances of risks.
## FQA
- I noticed that a lot of routes support the `filter` parameter where we
can pass an arbitrary KQL filter. Why we do not use this to filter by
the rule type IDs and the consumers and instead we introduce new
dedicated parameters?
The `filter` parameter should not be exposed in the first place. It
assumes that the consumer of the API knows the underlying structure and
implementation details of the persisted storage API (SavedObject client
API). For example, a valid filter would be
`alerting.attributes.rule_type_id`. In this filter the consumer should
know a) the name of the SO b) the keyword `attributes` (storage
implementation detail) and c) the name of the attribute as it is
persisted in ES (snake case instead of camel case as it is returned by
the APIs). As there is no abstraction layer between the SO and the API,
it makes it very difficult to make changes in the persistent schema or
the APIs. For all the above I decided to introduce new query parameters
where the alerting framework has total control over it.
- I noticed in the code a lot of instances where the consumer is used.
Should not remove any logic around consumers?
This PR is a step forward making the framework as agnostic as possible.
I had to keep the scope of the PR as contained as possible. We will get
there. It needs time :).
- I noticed a lot of hacks like checking if the rule type is `siem`.
Should not remove the hacks?
This PR is a step forward making the framework as agnostic as possible.
I had to keep the scope of the PR as contained as possible. We will get
there. It needs time :).
- I hate the "Role visibility" dropdown. Can we remove it?
I also do not like it. The goal is to remove it. Follow
https://github.com/elastic/kibana/issues/189997.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@elastic.co>
Co-authored-by: Paula Borgonovi <159723434+pborgonovi@users.noreply.github.com>
## Summary
This PR migrates the following FTR tests to `@kbn/scout`:
`x-pack/test/functional/apps/discover/error_handling.ts` =>
`x-pack/plugins/discover_enhanced/ui_tests/tests/error_handling.spec.ts`
`x-pack/test/functional/apps/discover/saved_search_embeddable.ts` =>
`x-pack/plugins/discover_enhanced/ui_tests/tests/saved_search_embeddable.spec.ts`
`x-pack/test/functional/apps/discover/saved_searches.ts` =>
`x-pack/plugins/discover_enhanced/ui_tests/tests/saved_searches.spec.ts`
`x-pack/test/functional/apps/discover/value_suggestions.ts` 2nd describe
block =>
`x-pack/plugins/discover_enhanced/ui_tests/tests/value_suggestions_use_time_range_disabled.spec.ts`
Some other changes to mention:
**packages/kbn-test-subj-selector**:
- support of `^foo` syntax similar to `CSS [attribute^=value] Selector`
**packages/kbn-scout**:
- new worker fixture `uiSettings` to wrap Advanced Settings set/unset
capability
- extend `ScoutPage` fixture with `typeWithDelay` method required for
many Kibana input fields
- extend `PageObjects` fixture with `DashboardApp` & `FilterBar`, also
extending existing ones.
How to test:
```bash
// ESS
node scripts/scout_start_servers.js --stateful
npx playwright test --config x-pack/plugins/discover_enhanced/ui_tests/playwright.config.ts --grep @ess
// Serverless
node scripts/scout_start_servers.js --serverless=es
npx playwright test --config x-pack/plugins/discover_enhanced/ui_tests/playwright.config.ts --grep @svlSearch
```
---------
Co-authored-by: Robert Oskamp <traeluki@gmail.com>
## Summary
The expression here violates [polynomial regular expression used on
uncontrolled
data](https://codeql.github.com/codeql-query-help/javascript/js-polynomial-redos/)
This PR replaces the problem regex with one that is not ambiguous about
when to start matching `-` sequences. This is done through using a
negative look-behind.
## Summary
Resolves#201442.
The underlying issue is that `isEnabledAtPath` validates the entire
config object when it only cares about `.enabled`. This PR performs that
check using `stripUnknownKeys: true`, as we'll perform the actual
validation later on.
### 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
## Summary
resolves https://github.com/elastic/kibana/issues/159454
Remove experimental message from saved objects import and export apis.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/191812
Adds ability to create ES|QL AST nodes from plain strings and compose
them.
Create an integer literal:
```js
const node = expr `42`;
```
Create any expression:
```js
const node = expr `nested.field = fn(123)`;
```
Compose AST nodes:
```js
const value = expr `123`;
const node = expr `nested.field = fn(${value})`;
```
## Usage
You can create an assignment expression AST node as simle as:
```ts
import { synth } from '@kbn/esql-ast';
const node = synth.expr `my.field = max(10, ?my_param)`;
// { type: 'function', name: '=', args: [ ... ]}
```
To construct an equivalent AST node using the `Builder` class, you would
need to
write the following code:
```ts
import { Builder } from '@kbn/esql-ast';
const node = Builder.expression.func.binary('=', [
Builder.expression.column({
args: [Builder.identifier({ name: 'my' }), Builder.identifier({ name: 'field' })],
}),
Builder.expression.func.call('max', [
Builder.expression.literal.integer(10),
Builder.param.named({ value: 'my_param' }),
]),
]);
// { type: 'function', name: '=', args: [ ... ]}
```
You can nest template strings to create more complex AST nodes:
```ts
const field = synth.expr `my.field`;
const value = synth.expr `max(10, 20)`;
const assignment = synth.expr`${field} = ${value}`;
// { type: 'function', name: '=', args: [
// { type: 'column', args: [ ... ] },
// { type: 'function', name: 'max', args: [ ... ] }
// ]}
```
Use the `synth.cmd` method to create command nodes:
```ts
const command = synth.cmd `WHERE my.field == 10`;
// { type: 'command', name: 'WHERE', args: [ ... ]}
```
AST nodes created by the synthesizer are pretty-printed when you coerce
them to
a string or call the `toString` method:
```ts
const command = synth.cmd ` WHERE my.field == 10 `; // { type: 'command', ... }
String(command); // "WHERE my.field == 10"
```
## Reference
### `synth.expr`
The `synth.expr` synthesizes an expression AST nodes. (*Expressions* are
basically any thing that can go into a `WHERE` command, like boolean
expression,
function call, literal, params, etc.)
Use it as a function:
```ts
const node = synth.expr('my.field = max(10, 20)');
```
Specify parser options:
```ts
const node = synth.expr('my.field = max(10, 20)', { withFormatting: false });
```
Use it as a template string tag:
```ts
const node = synth.expr `my.field = max(10, 20)`;
```
Specify parser options, when using as a template string tag:
```ts
const node = synth.expr({ withFormatting: false }) `my.field = max(10, 20)`;
```
Combine nodes using template strings:
```ts
const field = synth.expr `my.field`;
const node = synth.expr `${field} = max(10, 20)`;
```
Print the node as a string:
```ts
const node = synth.expr `my.field = max(10, 20)`;
String(node); // 'my.field = max(10, 20)'
```
### `synth.cmd`
The `synth.cmd` synthesizes a command AST node (such as `SELECT`,
`WHERE`,
etc.). You use it the same as the `synth.expr` function or template
string tag.
The only difference is that the `synth.cmd` function or tag creates a
command
AST node.
```ts
const node = synth.cmd `WHERE my.field == 10`;
// { type: 'command', name: 'where', args: [ ... ]}
```
### Checklist
Delete any items that are not applicable to this PR.
- [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
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
## Summary
Implements
https://github.com/elastic/logs-dev/issues/111#issuecomment-2446470635.
This adds a new "Saved Search component". The component is a wrapper
around the current Saved Search Embeddable, but uses
`ReactEmbeddableRenderer` directly to render the embeddable outside of
Dashboard contexts. It monitors changes to things like `index`,
`filters` etc and communicates these changes through the embeddable API.
For this PoC two locations were changed to use this component 1) Logs
Overview flyout 2) APM Logs tab (when the Logs Overview isn't enabled
via advanced settings).
The component itself is technically beyond a PoC, and resides in it's
own package. ~I'd like to get eyes from the Discover folks etc on the
approach, and if we're happy I can fix the remaining known issues (apart
from the mixing of columns point as I believe this exists on the roadmap
anyway) and we can merge this for the initial two replacement points.~
[Thanks Davis
👌](https://github.com/elastic/logs-dev/issues/111#issuecomment-2475350199).
`nonPersistedDisplayOptions` is added to facilitate some configurable
options via runtime state, but without the complexity of altering the
actual saved search saved object.
On the whole I've tried to keep this as clean as possible whilst working
within the embeddable framework, outside of a dashboard context.
## Known issues
- ~"Flyout on flyout" in the logs overview flyout (e.g. triggering the
table's flyout in this context).~ Fixed with `enableFlyout` option.
- ~Filter buttons should be disabled via pills (e.g. in Summary
column).~ Fixed with `enableFilters` option.
- Summary (`_source`) column cannot be used alongside other columns,
e.g. log level, so column customisation isn't currently enabled. You'll
just get timestamp and summary. This requires changes in the Unified
Data Table. **Won't be fixed in this PR**
- We are left with this panel button that technically doesn't do
anything outside of a dashboard. I don't *think* there's an easy way to
disable this. **Won't be fixed in this PR**
## Followups
- ~The Logs Overview details state machine can be cleaned up (it doesn't
need to fetch documents etc anymore).~ The state machine no longer
fetches it's own documents. Some scaffolding is left in place as it'll
be needed for showing category details anyway.
## Example
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
1. Show all packages owned by a specific team
```
node scripts/dependency_ownership -o <owner>
```
2. Identify owners of a specific dependency
```
node scripts/dependency_ownership -d <dependency>
```
3. List dependencies without an owner
```
node scripts/dependency_ownership --missing-owner
```
4. Generate a full dependency ownership report
```
node scripts/dependency_ownership
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
__Closes: https://github.com/elastic/kibana/issues/196767__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds Connector name and index_name auto-generation to ES3. This is taken
from the [ESS implementation
here](https://github.com/elastic/kibana/blob/main/x-pack/plugins/enterprise_search/server/lib/connectors/generate_connector_name.ts).
The ES3 implementation functions a little differently, because the ES3
Connector creation flow is different.
For ES3, the auto-generated Connector `name` and `index_name` are
automatically saved to the Connector document when a `service_type` is
selected. This is because the selection of a `service_type` already
creates the Connector record, so it made the most sense to piggyback on
that process.
If the user defines a name before selecting a service type, the
user-defined name is kept.
## Summary
Handles resolution for
- Notes fetching data for all Timeline Records which leads to
performance issues.
- https://github.com/elastic/kibana/issues/201330
## Issue - Notes fetching data for all Timeline Records
Currently, there was no way for consumer of `UnifiedDataGrid` to get the
current `pageIndex`. Security Solution needs to get the current
`pageIndex` so the items on the current page can be calculated.
@elastic/kibana-data-discovery , please let us know if you have any
opinion here.
This results in notes being fetched for all Timeline Records which means
minimum of 500 records and if user has queries 5000 records ( for
example ), a request will be made to query notes for all those 5000
notes which leads to performance issue and sometimes error as shown
below:
## 👨💻 Changes
This adds attribute `pageIndex` to timeline state.
```javascript
{
"pageIndex": number
}
```
`pageIndex` helps with getting the events for that particular page.
## 🟡 Caveat
- Currently this `pageIndex` is shared between Query and EQL tabs which
can lead to wonky behavior at time.
- Additionally, as of now table maintains its own page index and
consumer component cannot effect the `pageIndex` of the UnifiedDataGrid.
## Summary
This PR adds a `version` to the `formatRequest` test (found an
[issue](019372b6-1e4e-493f-b711-679457e765b2_b8be2ab240c3af76aa62e1fcad3ec562.html?response-content-type=text%2Fhtml&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAQPCP3C7LTUSWSE7V%2F20241129%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20241129T124819Z&X-Amz-Expires=600&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMv%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIQCBtHsxCwyPkjuXFut7cE0I%2FQ1SpDfwz%2BUL6ULSc0AbhwIge%2BVhDpL22YYe4fkrNwRadeobqd9oEHMVP6k5tJRJRCoq8QMIdBAAGgwwMzIzNzk3MDUzMDMiDLYAxitOg6M5AO4yOSrOA%2BXsP7JEfPo3AlXET%2FjR9qJi4AJxQZBGvP3HkWOKs8zEJoYXudxq06XmYw9T2Pk4Qovoy2Oghz7UjCzfb9AWJWr5wzAESxWQgfWnAmFTsR2CP81TVtGdHtrX%2FQd1ucHWCA58JFbNe4uG0IWWj4TrrqPUeKeKspvoYknZiFOMN9xIP6r4fMshpNDmz6zOzMWKzgTZGRlVq0%2Biy5sgpl8e039KNiJNde4jrFfx4CcxGEuzDZihApsV%2FKIG3%2B62mEohtK94OQvbR7%2FPPso2FTkA1ndUQHD2jc4woHaJx7cA0aV8Gw2%2FdGgnW2%2FvAX2F0LcBL%2FlPRTw%2BL0T7EDhcz0ldK8FzwCK3aeLBfVvlQaEdoWLBgMf%2FrHYZN4AtrUfCbi91RfpRW7%2B84lF9OqHEc%2Fi8%2FKaRm%2FZA6jyeODfk9gyTwLoCMY%2F1gC1sBgCM7pTS7U5EwK4%2BzPeTusZoLEkcd2zbwN6umOA54CfxeavUkH2uuxsr8ioLVpaCroHe%2FDlhqd%2BGb8CFBherH4pB3GQ0F8JuTbl4RQqY57AH7ahPvMH1Zl0NihqmAJvUNOFss5NUfqN4LNG2xZlqG9mUKpUFaHeUxptYiXf1H79Vyc7TjJ2sVzCCvKa6BjqlAbPc8CIZ5QdsweyEBVEesbmITDsjgiG%2FMlwqzmNf57BPecF%2FkhXgwgR3B%2BK8cg9h3apLMlUtVrTsLq3vPf7nlY8fEwPvLHTGVQoSYwL4AHGPHcZnpSrdI5HDkK0%2BuwTZMKjp1jQ5xbbami6ih2N2mnmFuz1a04SQHLogLBgyw%2BGUZwp%2Fa7jg9RHiSeSWiuCeo8iPVGbkGAe0vA2rr8BHO2tO4H1LPA%3D%3D&X-Amz-SignedHeaders=host&X-Amz-Signature=e18c6abd4208db972d3cdf975d8390de30502170e1ded9db52b5b1342a106d0e)
in the backport PRs: https://github.com/elastic/kibana/pull/202153 and
https://github.com/elastic/kibana/pull/202154 )
## Summary
Handles https://github.com/elastic/kibana/issues/191998
Follow up work:
- https://github.com/elastic/security-team/issues/11112
- https://github.com/elastic/kibana/issues/196667
This PR add below entity flyouts for below entities in One Discover:
- host.name
- user.name
- source.ip
- destination.ip
In this PR we re-use the security solution code by making use of below
model based on `discover-shared` plugin.
```mermaid
flowchart TD
discoverShared["Discover Shared"]
securitySolution["Security Solution"]
discover["Discover"]
securitySolution -- "registers Features" --> discoverShared
discover -- "consume Features" --> discoverShared
```
## How to Test
>[!Note]
>This PR adds `security-root-profile` in One discover which is currently
in `experimental mode`. All changes below can only be tested when
profile is activated. Profile can activated by adding below lines in
`config/kibana.dev.yml`
> ```yaml
> discover.experimental.enabledProfiles:
> - security-root-profile
> ```
>
1. As mentioned above, adding above experimental flag in
`kibana.dev.yml`.
2. Spin up Security Serverless project and add some alert Data.
3. Navigate to Discover and add columns `host.name` and `user.name` in
table. Now `host` and `user` flyouts should be available on clicking
`host.name`, `user.name`, `source.ip` & `destination.ip`.
4. Flyout should work without any error.
5. Below things are not working and will be tackled in followup PR :
- Security Hover actions
- Actions such as `Add to Timeline` or `Add to Case`
### Checklist
Delete any items that are not applicable to this PR.
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We've had some questions around legacy migrations that are flagged as
deprecated in the type. This updates the typescript doc comment to
hopefully clarify that.
## Summary
Fixes https://github.com/elastic/kibana/issues/197714
### Key Features
#### Responsiveness
1. Adds a responsive view controlled by the `accessMode` prop.
2. For the responsive version (in the `VIEW` mode), panels retain height
and are arranged based on screen order (left-to-right, top-to-bottom).
3. Interactivity (drag/resize) is disabled in `view` mode.
<img width="514" alt="Screenshot 2024-11-25 at 17 34 56"
src="https://github.com/user-attachments/assets/6a5a97aa-de9b-495a-b1de-301bc935a5ab">
#### Maximization
1. Supports expanded panel view using the `expandedPanelId` prop.
2. Interactivity (drag/resize) is disabled when a panel is expanded.
<img width="1254" alt="Screenshot 2024-11-25 at 17 35 05"
src="https://github.com/user-attachments/assets/c83014f6-18ad-435b-a59d-1d3ba3f80d84">
#### Considerations
1. CSS elements naming convention: Main component uses `kbnGrid` class,
with modifiers like `kbnGrid--nonInteractive`. For the drag handle of
`GridPanel` I used `kbnGridPanel__dragHandle` classname.
2. Classes vs. Inline Styles: I opted for using
`kbnGrid--nonInteractive` instead of adding one more subscription to
`GridPanel` to modify the styles inline. It's the first time in this
package that I used classes instead of inline styles for no-initial
styles setting.
3. Naming Convention: I opted for using the `expanded` word to describe
an expanded panel. Another one could be `maximized` as it's more used in
UI, but less in the legacy code.
4. Interactivity (drag/resize) is disabled in responsive mode but we
could consider to limit this to small viewports only (<768px).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Partially addresses:** https://github.com/elastic/kibana/issues/171520
## Summary
This PR adds is built on top of https://github.com/elastic/kibana/pull/193828 and https://github.com/elastic/kibana/pull/196948 and adds an ES|QL Query editable component for Three Way Diff tab's final edit side of the upgrade prebuilt rule workflow.
## Details
This PR extracts ES|QL Query edit component from Define rule form step and makes it reusable. The following changes were made
- ES|QL validator was refactored and covered by unit tests
- Query persistence was addressed and covered by tests (previous functionality didn't work out of the box and didn't have tests)
## How to test
The simplest way to test is via patching installed prebuilt rules (a.k.a. downgrading a prebuilt rule) via Rule Patch API. Please follow steps below
- Ensure the `prebuiltRulesCustomizationEnabled` feature flag is enabled
- Run Kibana locally
- Install an ES|QL prebuilt rule, e.g. `AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session` with rule_id `0cd2f3e6-41da-40e6-b28b-466f688f00a6`
- Patch the installed rule by running a query below
```bash
curl -X PATCH --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"rule_id":"0cd2f3e6-41da-40e6-b28b-466f688f00a6","version":1,"query":"from logs-*","language":"esql"}' http://localhost:5601/kbn/api/detection_engine/rules
```
- Open `Detection Rules (SIEM)` Page -> `Rule Updates` -> click on `AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session` rule -> expand `EQL Query` to see EQL Query -> press `Edit` button
## Screenshots
<img width="2550" alt="image" src="https://github.com/user-attachments/assets/f65d04d5-9fd9-4d3f-8741-eba04a3be8a6">
<img width="2552" alt="image" src="https://github.com/user-attachments/assets/dd0a2613-5262-44b2-bbeb-d0ed34d57d9c">
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Partially addresses https://github.com/elastic/kibana/issues/191812
Implements high-level APIs for working with `WHERE` command.
- `commands.where.list()` — lists all `WHERE` commands.
- `commands.where.byIndex()` — finds the Nth `WHERE` command in
the query.
- `commands.where.byField()` — finds the first `WHERE` command
which uses a specified field or a param.
### Checklist
Delete any items that are not applicable to this PR.
- [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
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
Closes https://github.com/elastic/kibana/issues/201626
## Summary
This PR makes it so that the grid layout will auto-scroll with the
following behaviour:
- Auto-scroll up when....
- the panel is dragged to the top 5% of the window **or above**
(including outside of the window)
- Auto-scroll down when....
- the panel is dragged to the bottom 5% of the window **or below**
(including outside of the window)
- the panel is being dragged and the resize handle is dragged to the
bottom 5% of the window **or below** (including outside of the window)
https://github.com/user-attachments/assets/6880fd14-e492-4cd9-81c6-3dfb30b80960
### Checklist
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
There are no risks to this PR, since all work is contained in the
`examples` plugin.
## Summary
Some code was added in [this
PR](https://github.com/elastic/kibana/pull/189633) to allow the
expandable flyout to be used in the OneDiscover context. Later on, [this
PR](https://github.com/elastic/kibana/pull/198294) reverted most of the
changes, but some files remained.
This PR cleans up all the files (that I could find) that are now
unnecessary and unused
## Summary
This PR reinstates the `featureId` parameter in requests to the
connector type API within the new stack management rule form.
### Checklist
- [ ] [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
### To verify
1. Create a connector with supportedFeatureIds that does not include
AlertingConnectorFeatureId (e.g., the SentinelOne connector).
2. Use the new rule form to create a rule.
3. Confirm that the SentinelOne connector is not displayed in the rule
form as an available option.
## Summary
After relocating modules (plugins and packages) to their new folders,
according to the _Sustainable Kibana Architecture_ design, their groups
will be inferred based on their path.
The logic was taking into account plugins' folders, but not packages'
folders. This PR fixes that.
## Summary
This PR introduces a new package, **kbn-scout**, designed to streamline
the setup and execution of Playwright tests for Kibana. The `kbn-scout`
package consolidates server management and testing capabilities by
wrapping both the Kibana/Elasticsearch server launcher and the
Playwright test runner. It includes:
- Test and worker-scoped fixtures for reliable setup across test suites
- Page objects combined into the fixture for Kibana UI interactions
- Configurations for seamless test execution in both local and CI
environments (`Cloud` execution is out of scope)
- This package aims to simplify test setup and enhance modularity,
making it easier to create, run, and maintain deployment-agnostic tests,
that are located in the plugin they actually test.
Tests example is available in `x-pack/plugins/discover_enhanced` plugin
under `ui_tests` folder
How to run:
1) As a single script (servers + tests):
```
node scripts/scout_test.js --config=x-pack/plugins/discover_enhanced/ui_tests/playwright.config.ts --serverless=es
```
2) Start servers first
```
node scripts/scout_start_servers.js --serverless=es
```
then run tests:
```
npx playwright test --config=x-pack/plugins/discover_enhanced/ui_tests/playwright.config.ts
```
if you have Playwright plugin in IDEA, just use it to run tests files
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves https://github.com/elastic/ingest-dev/issues/3933. For
deployments that support agentless, integrations with agentless
deployment mode enabled will allow the status of agentless integration
policies to be tracked.
### Key technical changes
- A new field `supports_agentless` was added to package policies. This
field already exists on agent policies. When an agentless integration is
created, `supports_agentless: true` is now added to both the package
policy and its parent agent policy.
- This allows easier filtering for agentless integrations as we avoid
having to retrieve & check against every parent agent policy.
- This also means existing agentless policies do not get this new status
tracking UI, only new ones created after this change. Since agentless is
not yet GA, I think this is okay.
- `/api/fleet/agent_status/data` now takes optional query params
`pkgName` and `pkgVersion`. When both are specified, the API will check
if agent(s) have ingested data for only that package's datastreams.
## UI walkthrough
<details>
<summary>🖼️ Click to show screenshots</summary>
1. **Integration policies** page now shows two tables for integrations
meeting the above condition, one for agentless policies and one for
agent-based policies:
2. Clicking the status badge in the agentless policies table opens a
flyout with two steps: confirm agentless enrollment and confirm incoming
data:
3. Confirm agentless enrollment polls for an agent enrolled into that
integration policy's agent policy. If that agent is reporting an
unhealthy status, the integration component UI is shown. This UI is the
same one used on Fleet > Agents > Agent details page and shows all
components reported by that agent:
4. Once a healthy agentless enrollment is established, confirm incoming
data starts polling for data for that integration ingested by that agent
ID in the past 5 minutes:
5. If data could not be retrieved in 5 minutes, an error message shows
while polling continues in the background:
6. If data is retrieved, a success message is shown:
</details>
## Testing
Easiest way to test is use the Cloud deployment from this PR. Enable
Beta integrations and navigate to CSPM. Add a CSPM integration using
`Agentless` setup technology. Then you can track the status of the
agentless deployment on the Integrations policies tab.
For local testing, the following is required to simulate agentless
agent:
1. Add the following to kibana.dev.yml:
```
xpack.cloud.id: 'anything-to-pass-cloud-validation-checks'
xpack.fleet.agentless.enabled: true
xpack.fleet.agentless.api.url: 'https://localhost:8443'
xpack.fleet.agentless.api.tls.certificate: './config/certs/ess-client.crt'
xpack.fleet.agentless.api.tls.key: './config/certs/ess-client.key'
xpack.fleet.agentless.api.tls.ca: './config/certs/ca.crt'
```
2. Apply [this
patch](https://gist.github.com/jen-huang/dfc3e02ceb63976ad54bd1f50c524cb4)
to prevent attempt to create agentless pod
3. Enroll a Fleet Server as usual
4. Enable Beta integrations and navigate to CSPM. Add a CSPM integration
using `Agentless` setup technology.
5. Enroll a normal Elastic Agent to the agent policy for that CSPM
integration by using the token from Enrollment tokens
## To-do
- [x] API tests
- [x] Unit UI tests
- [x] Manual Cloud tests
- [x] File docs request
- https://github.com/elastic/ingest-docs/issues/1466
- [ ] Update troubleshooting guide link once available
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/194489
PR adds new `PublishesRendered` interface. Embeddables can implement
this interface to provide feedback when rendering is complete.
PR updates ReactEmbeddableRender phase tracking logic to include check
for `PublishesRendered` value when interface is implemented.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
