## Summary
Part of: https://github.com/elastic/security-team/issues/10667
Implementation of the Onboarding card to create migrations using the
flyout
> [!NOTE]
> This feature needs `siemMigrationsEnabled` experimental flag enabled
to work. Otherwise only the default topic will be available and the
topic selector won't be displayed.
<img width="1547" alt="image"
src="https://github.com/user-attachments/assets/f43c60a0-0631-44d8-ba82-7f16971ecc24">
#### To do in part 2:
- Complete implementation of migration finished panel: chart and stats
- Improve implementation of migration ready panel: should only allow
open the flyout
- Implement missing steps in the flyout: Macros and Lookups
### Test
Enable experimental flag
Use file:
[1733135547_1420.json](1733135547_1420.json)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes the areas where we display the Web Crawler naming bearing
in mind these agreements :
- We should be capitalizing when referring to the product name: Elastic
Web Crawler / Web Crawler /Elastic Open Web Crawler
- We can use lower case when referring to the feature or concept of web
crawler( crawler in short): "Use the web crawler to ..."
ESS:
ES3:
Notes: Also fixing buttons that take users to the Open Web Crawler repo
to open the links in a new tab and don't lose the product focus.
## Summary
Closes#191939
Closes https://github.com/elastic/kibana/issues/175220
Adds various optimizations for the Trained Models page:
---
- Creates a new Kibana `/trained_models_list` endpoint responsible for
fetching complete data for the Trained Model UI page, including
pipelines, indices and stats.
Before the Trained Models page required 3 endpoints. The new
`trained_models_list` replaces them, reducing the overall latency.
<img width="715" alt="Screenshot 2024-12-02 at 16 18 32"
src="https://github.com/user-attachments/assets/34bebbdc-ae80-4e08-8512-199c57cb5b54">
---
- Optimized fetching of pipelines, indices and stats, reducing the
number of API calls to ES
Several issues with the old endpoint stemmed from the with_indices flag.
This flag triggered a method designed for the Model Map feature, which
involved fetching a complete list of pipelines, iterating over each
model, retrieving index settings multiple times, and obtaining both
index content and a full list of transforms.
The new endpoint solves these issues by fetching only the necessary
information for the Trained Model page with minimal calls to
Elasticsearch.
#### APM transaction with a new endpoint
<img width="1822" alt="image"
src="https://github.com/user-attachments/assets/55e4a5f0-e571-46a2-b7ad-5b5a6fc44ceb">
#### APM transaction with an old endpoint
https://github.com/user-attachments/assets/c9d62ddb-5e13-4ac1-9cbf-d685fbed7808
---
- Improves type definitions for different model types
### 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
Part of https://github.com/elastic/kibana-team/issues/1082
Selects certain Sass files to replace with styles declared with Emotion.
This PR does not include any changes that would be noticeable by
end-users. It changes the internals to use a different technology for
styling components.
~~Some `className` attributes have been kept, because they are
referenced in JS and tests.~~ Update: all classNames that are no longer
needed for styling purposes have been removed.
* If the className was needed for tests, it has been replaced with a
test-subj.
* If the className was used as a selector in production code, it has
been replaced with alternative JS.
## References
1. https://emotion.sh/docs/globals
2. https://emotion.sh/docs/best-practices
3.
https://github.com/elastic/eui/discussions/6828#discussioncomment-10825360
---------
Co-authored-by: Jatin Kathuria <jatin.kathuria@elastic.co>
## Summary
This PR discontinues Reporting from having dual models for determining
the privilege to generate a report, and uses Kibana feature privileges
as the single model that controls those privileges.
### Changes
1. Removes all logic that is based on following settings:
* `xpack.reporting.roles.enabled`
* `xpack.reporting.roles.allow`
The settings are still supported, but any features that use the settings
are removed.
2. Removes the detection of the settings from the Upgrade Assistant
integration
### Release note
The default system of granting users the privilege to generate reports
has changed. Rather than assigning users the `reporting_user` role,
administrators should create a custom role that grants report-creation
privileges using Kibana application privileges.
### 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
- [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.
Correlates with https://elasticco.atlassian.net/browse/ES-9856: assign
the built-in `reporting_user` role the necessary Kibana application
privileges, and make the role not marked as deprecated.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
This PR introduces two internal API routes:
1. `/internal/api/endpoint/workflow_isnights`
2. `/internal/api/endpoint/workflow_isnights/{insightId}`
### Details
- The first route (`/internal/api/endpoint/workflow_isnights`) will be
used with the `securityWorkflowInsightsService.fetch` method to retrieve
stored insights.
- The second route
(`/internal/api/endpoint/workflow_isnights/{insightId}`) will work with
the `securityWorkflowInsightsService.update` method to update existing
insights.
---------
Co-authored-by: Joey F. Poon <joey.poon@elastic.co>
## Summary
Fixes https://github.com/elastic/kibana/issues/197650
Also fixes an issue where user has `cases: all ` and `edit case
settings: false`, user was able to edit settings.
Used `permissions.settings` instead of `permissions.update` and
`permissions.create` for custom fields and templates.
### How to test
- Verify by creating a user with different combinations of cases and
edit case settings privileges
### 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
This PR adds example of tests, that doesn't meet deployment-agnostic
criteria. I also added steps explaining how to migrate existing tests to
DA.
## Summary
This PR adds:
* Some basic features and privileges for the EEM app
* A function that sets up an index with a template for the new
definitions
* 4 API endpoints to read and create entity types and sources
* `POST /internal/entities/v2/definitions/types`
* `GET /internal/entities/v2/definitions/types`
* `POST /internal/entities/v2/definitions/sources`
* `GET /internal/entities/v2/definitions/sources`
* Some v2 shuffling around of code
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
**Resolves: https://github.com/elastic/kibana/issues/202812**
## Summary
This PR fixes a problem in the MKI Serverless periodic pipeline that was
introduced in #201825. The issue happened because the test tried to
delete prebuilt rule assets stored in .kibana_security_solution, but you
can’t access this index in Serverless MKI.
The fix makes sure this call only runs in non-Serverless MKI
environments.
## Summary
Part of https://github.com/elastic/kibana-team/issues/1271
This PR introduces the first set of end to end integration test for the
inference APIs, and the tooling required to do so (see issue for more
context)
- Add a dedicated pipeline for ai-infra GenAI tests. pipeline is
triggered when:
- genAI stack connectors, or ai-infra owned code is changed
- when the `ci:all-gen-ai-suites` label is present on a PR
- on merge
- adapt the `ftr_configs.sh` script to load GenAI connector
configuration from vault when a specific var env is set
- create the `@kbn/gen-ai-functional-testing` package, which for now
only contains utilities to load the GenAI connector configuration in FTR
tests
- Add FTR integration tests for the `chatComplete` API of the
`inference` plugin
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Provide support for suppressing EQL sequence alerts.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marshall Main <55718608+marshallmain@users.noreply.github.com>
## Summary
Part of #195211
Moves Rule Form code out of `@kbn/alerts-ui-shared` and into a new
package called `@kbn/response-ops-rule-form`.
Some types and hooks that are used by multiple features or solutions are
still in `@kbn/alerts-ui-shared` and have been rerouted. The bulk of
Rule Form-specific code is in this new package.
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Kevin Delemme <kevin.delemme@elastic.co>
## Summary
[Internal link](https://github.com/elastic/security-team/issues/10820)
to the feature details
With these changes we add pagination functionality for the rules
migration table. This way we will improve the performance within the
page.
Also, added as part of these PR:
* moved `install` and `install_translated` routes to the `rules/api`
folder; before those were located in `rules/api/rules` and made
confusion
* a new `translation_stats` route to return stats for the specific
migration about the translated rules, like `total` number of the rules,
and number of `prebuilt`, `custom` and `installable` rules
* add `Updated` table column
* small UI fixes:
* use correct icon for "SIEM rule migration"
* do not remove "Install translated rules" button and rather disable it
when there are no installable rules
* do not allow user to update translation status via UI
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The `faker` library is[ not maintained
anymore](https://fakerjs.dev/about/announcements/2022-01-14.html#i-heard-something-happened-what-s-the-tldr)
and is replaced by a community fork `@faker-js`.
This PR migrates all the usages of faker to the new library, trying to
use the same methods (even if they have slight differences in results
like `faker.random.number()` has a max of 99999 where instead
`faker.number.int()` have a MAX_SAFE_INTEGER as max).
## Summary
This PR adds a baseline for FTR API tests for Automatic Import.
- Relates https://github.com/elastic/kibana/issues/196063
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Resolves: https://github.com/elastic/kibana/issues/201632**
## Summary
When the rule customization feature flag is disabled, we should always
return `isCustomized: false`, regardless of any changes introduced to a
rule. This ensures that we do not accidentally mark prebuilt rules as
customized in 8.16 with the feature flag off. For more details, refer to
the related issue: https://github.com/elastic/kibana/issues/201632
### Main Changes
- The primary change in this PR is encapsulated in the
`calculateIsCustomized` function
- Other changes involve passing the feature flag to this function
- Added integration tests to cover all API CRUD operations that can be
performed with rules
- 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
Issue: https://github.com/elastic/kibana/issues/151461
Removes all reference to ephemeral tasks in the alerting and actions
plugin. As well as unit and E2E tests while maintaining backwards
compatibility for `xpack.alerting.maxEphemeralActionsPerAlert` flag.
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
- [x] Fix UA currently failing to return upgrade status
- [x] Support surfacing `data_streams` migrations in UA under the ES tab
- [x] Refactor code for better readablity
- [x] Add more test cases across the board for all the es migrations
status feature in UA
- [x] Add a `featureSet.migrateDataStreams` to enable surfacing data
streams migrations
- [x] Surface data streams in UA UI
- [x] Take screenshots for a product review discussions
- [x] Unskip api_integration test cases
### Imporant Notes
ES deprecations are hidden behind the `featureSet` flag and will only be
shown in `8.last` for users.
This gives us time to review the copy and implement the corrective
action for reindexing data streams which is still pending implementaiton
from ES side.
For now we will merge this to unblock upgrades in `8.17` and support
surfacing data_streams deprecations and add tests.
Follow up work for `8.18`
- Add integration Tests
- Update copy of flyout and documentation link
- Reindexing data streams corrective action
closes https://github.com/elastic/kibana-team/issues/1293
## Screenshots
#### Overview Page
<img width="683" alt="image"
src="https://github.com/user-attachments/assets/246d89ac-02cd-4813-ba38-e2e28df00c8d">
#### Elasticsearch deprecation issues Page
<img width="1453" alt="image"
src="https://github.com/user-attachments/assets/b5fd5f15-fa44-4acb-b7ff-4973593dcfbb">
#### Data streams deprecation details flyout
<img width="778" alt="image"
src="https://github.com/user-attachments/assets/af343f69-7e76-4c91-a6e3-cff29e26df59">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Kibana roles with only `manage_enrich` or `monitor_enrich` will now have
access to the Enrich Policy tab in Index Management.
---
The `registerElasticsearchFeature` api is too restrictive to use for
index management as it only allows a single set of privileges to
determine whether a given management app is shown AND any stated
privilege is combined in an `AND` logic statement. We need `OR` - index
management may cover a number of different privileges that don't
overlap. The solution - use an observable to subscribe to the
capabilities api and register the management app based on that.
This pr focuses on Enrich Policies and removes UI elements as
appropriate based on `manage_enrich` or `monitor_enrich` and leaves
other index management tabs alone as these will be addressed in follow
up PRs.
Part of https://github.com/elastic/kibana/issues/178654
## Summary
Fixes https://github.com/elastic/kibana/issues/200899
Added Synthetics Sub-feature for managing private locations !!
User can configure a sub feature in a role under synthetics to allow
managing private locations ,
with role API it will be with
```
{
kibana: [
{
feature: {
uptime: [
'minimal_all',
'can_manage_private_locations',
],
},
spaces: ['*'],
},
],
}
```
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/f842da22-9c82-43d0-ad34-c6e19ea187c6">
Create/delete actions on UI will be disabled
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/1a164d85-357b-42f3-ae15-0682b2db6c75">
## Release note
If you have already modified sub feature for the synthetics/uptime
feature to disable user access for using elastic managed location,
addition of this feature means, they will also will not be able to
manage(add/delete) private locations. Though this will not impact usage
of private locations in monitors. If you want those users to have
ability to add/delete new private locations, you can enable that by
toggle this feature in role ui or via api.
I noticed that I was not able to clear the user-specific system prompt.
I had initially entered "Please speak in Swedish" and saved. Afterwards
I wanted to clear this but the save button is disabled if the text
content is empty.
## Summary
[Internal link](https://github.com/elastic/security-team/issues/10820)
to the feature details
With these changes we two new routes:
* `/internal/siem_migrations/rules/install`: allows to install a
specific set of migration rules
* `/internal/siem_migrations/rules/install_translated`: allows to
install all translated rules in specified migration
Also we connect these two new API calls with the "Install" button within
the "migration rules" table and the "Install translated rules" button on
the "SIEM migration rules" page.
### Screenshots
https://github.com/user-attachments/assets/29390d07-eab5-4157-8958-1e3f8459db09
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Sergi Massaneda <sergi.massaneda@gmail.com>
