## Summary
This ticket is the initial implementation for the UI side for the
AI-driven custom integration creation.
This PR only contains the implementation of the UI, due to the tight
timing it will not include tests, everything will be tested manually for
8.15 FF. We'll implement the tests later.
#### Enable Feature
The new integration assistant plugin is disabled by default, to enable
it:
```
xpack.integration_assistant.enabled: true
```
#### Complete tasks
- [x] New integration button on the /integrations page
- [x] New integration "landing" page with buttons to upload zip and
assistant
- [x] Upload zip page to install integration
- [x] Integration assistant:
- [x] Connector selection step
- [x] Integration details step
- [x] Data stream step
- [x] Review and install
#### Follow-ups (will be implemented in separate PRs)
- [ ] Add RBAC
- [ ] Add telemetry
- [ ] Documentation
- [ ] Add license/productType controls
- [ ] Add links to the create integration page
- [ ] Improve package name retrieval:
https://github.com/elastic/kibana/issues/185932
- [ ] Add time estimation on the generation stage
- [ ] Add support for multi-valuated "input type"
- [ ] Enable Langsmith tracing using AI assistant settings
#### Demo
b04c21c6-09cf-49bb-be8f-bf4b9d3feb8e
## Files by Code Owner
### elastic/docs
* packages/kbn-doc-links/src/get_doc_links.ts
* packages/kbn-doc-links/src/types.ts
### elastic/fleet
* x-pack/plugins/fleet/kibana.jsonc
*
x-pack/plugins/fleet/public/applications/integrations/hooks/use_breadcrumbs.tsx
*
x-pack/plugins/fleet/public/applications/integrations/layouts/default.tsx
*
x-pack/plugins/fleet/public/applications/integrations/sections/epm/index.tsx
*
x-pack/plugins/fleet/public/applications/integrations/sections/epm/screens/create/index.tsx
* x-pack/plugins/fleet/public/components/header.tsx
* x-pack/plugins/fleet/public/constants/page_paths.ts
* x-pack/plugins/fleet/public/plugin.ts
* x-pack/plugins/fleet/tsconfig.json
### elastic/kibana-core
* x-pack/plugins/fleet/kibana.jsonc
* x-pack/plugins/integration_assistant/kibana.jsonc
### elastic/kibana-operations
* packages/kbn-optimizer/limits.yml
### elastic/security-solution
* x-pack/plugins/integration_assistant/**/*
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes a display bug on the Endpoint List where the Policy name column
value was wrapping and causing the row to be miss-aligned. Changes
include:
- Moved components pieces that display the Policy Revision and the
"Out-of-date" message to the `<EndpointPolicyLink>` component
- this component now handles on displaying all of this information in
one place via input Props
- The component also dues Authz checks and ensures that if the user does
not have Authz to read the Endpoint Policy Management section, the
component will display the policy name as plain text (no link)
- It will truncate the Policy name if not enough width is available to
display its full value
- Replaced the Policy List column component for Policy Name with the use
of `<EndpointPolicyLink>`
- Replaced the Policy Details flyout component to also use
`<EndpointPolicyLink>` to display the policy name
> [!NOTE]
> Its still possible for the Policy Name column on the Endpoint list to
display across two lines - when the Policy that the Endpoint host last
reported is not longer available in Kibana. In this case/flow, the
second line will display a message indicating that. See screen captures
below.
**Addresses:** https://github.com/elastic/kibana/issues/183661
## Summary
This PR adds missing OpenAPI specs for the Alert Index API endpoints available in ESS
- `POST /api/detection_engine/index`
- `GET /api/detection_engine/index`
- `DELETE /api/detection_engine/index`
Closes https://github.com/elastic/kibana/issues/184813
## Summary
This PR adds a role-based login in the advanced settings functional
tests for security serverless project instead of using normal login
where we use operator privileges. It also moves the test file to a more
appropriate folder.
Closes https://github.com/elastic/kibana/issues/186610
## Summary
This PR adds `data-test-subj` attributes to the doc links in the Rollup
deprecation warning callout and the deprecation empty callout so that
clicks on these links can be tracked on Fullstory. The links on the
deprecation callout have test subjects with a prefix depending on
whether they are on the list view page or the create form page so that
we can differentiate the clicks from the different pages.
## Summary
Add new `Dataview picker` component and some initial redux setup to feed
it with data.
Dont expect this to work just like the original timeline sourcerer does
just yet.
### 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
### Testing
Do `localStorage.setItem('EXPERIMENTAL_SOURCERER_ENABLED', true)` in the
browser console, reload the page,
then open new timeline.
You should see the new dataview picker (colored in red temporarily),
that should allow data view switching.
Known issues: dataview editor is showing behind the picker (to be fixed
in subsequent PR).
## Summary
Closes https://github.com/elastic/kibana/issues/66716
Improves code editors in Anomaly detection, Data frame analytics and
Transform wizards with autocomplete, data types validation and inline
documentation from elasticsearch specification.
Adds a package with JSON schemas extracted from the [openapi output of
elasticsearch-specification](https://github.com/elastic/elasticsearch-specification/tree/main/output/openapi).
Schema file is generated per editor/endpoint, keeping only relevant
components.
To test the script locally, execute
```
yarn run jsonSchema
```
from `/x-pack/packages/ml/json_schemas`.
By default it assumes that your `elasticsearch-specification` folder is
located next to the `kibana` repo, but you can also provide a path to
`openapi` file as a parameter, e.g. `yarn run jsonSchema
/Users/my_user/dev/elasticsearch-specification/output/openapi/elasticsearch-serverless-openapi.json`
#### How JSON files are served
JSON files are asynchronously imported at the React component level and
passed to the `CodeEditor` instances on mount.
Initially I tried different approaches to take advantage of CDN, but
unfortunately it didn't work out:
##### Using static assets
I made an attempt to retrieve a URL to the JSON schema file as a static
asset using Kibana service
```typescript
const schemaJsonAsset = http?.staticAssets.getPluginAssetHref('my_schema.json') ?? '';
```
and passing it as part of the schema definition, but the browser was
blocking a request 🤔
##### Using raw loader
Approach with a raw loader also didn't succeed.
```typescript
import mySchema from '!!raw-loader!./my_schema.json';
```
<details>
<summary>See error </summary>
```
ERROR in
./public/app/sections/create_transform/components/advanced_pivot_editor/my_schema.json
(/Users/dimaarnautov/Repos/kibana/node_modules/raw-loader/dist/cjs.js!./public/app/sections/create_transform/components/advanced_pivot_editor/my_schema.json)
│ Module parse failed: Unexpected token 'e', "export def"... is not
valid JSON while parsing 'export default "{\n \"type\": \"object\'
│ File was processed with these loaders:
│ * ../../../node_modules/raw-loader/dist/cjs.js
│ You may need an additional loader to handle the result of these
loaders.
│ SyntaxError: Unexpected token 'e', "export def"... is not valid JSON
while parsing 'export default "{\n \"type\": \"object\'
│ at JSON.parse (<anonymous>)
│ at parseJson
(/Users/dimaarnautov/Repos/kibana/node_modules/json-parse-better-errors/index.js:7:17)
│ at JsonParser.parse
(/Users/dimaarnautov/Repos/kibana/node_modules/webpack/lib/JsonParser.js:16:16)
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/webpack/lib/NormalModule.js:482:32
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/webpack/lib/NormalModule.js:358:12
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:373:3
│ at iterateNormalLoaders
(/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
│ at iterateNormalLoaders
(/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:236:3
│ at runSyncOrAsync
(/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
│ at iterateNormalLoaders
(/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:205:4
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:85:15
│ at processTicksAndRejections (node:internal/process/task_queues:77:11)
```
</details>
### 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
## Summary
- update api tests in
`x-pack/test_serverless/api_integration/test_suites/common/reporting/`
- update one ui test in
`x-pack/test_serverless/functional/test_suites/common/reporting/management.ts`
- update snapshot
`x-pack/test_serverless/api_integration/test_suites/common/reporting/__snapshots__/generate_csv_discover.snap`
- update shared service in
`x-pack/test_serverless/shared/services/svl_reporting.ts`
Contributes to: https://github.com/elastic/kibana/issues/180834
---------
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/184941
## Summary
Adds integration test to verify that restarting Kibana with a different
task claim strategy does not break anything and tasks are claimed as
expected.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
**Partially addresses: https://github.com/elastic/kibana/issues/184364**
## Summary
This PR is a follow-up to [PR
#185748](https://github.com/elastic/kibana/pull/185748) and it converts
the remaining `DetectionRulesClient` methods to return `RuleResponse`.
Changes in this PR:
- These methods now return `RuleResponse` instead of internal
`RuleAlertType` type:
- `updateRule`
- `patchRule`
- `upgradePrebuiltRule`
- `importRule`
This PR includes changes related to displaying semantic_text based on
the ml operations capacity of the users. The PR includes the following
changes:
- Display a banner based on the user's capacity to run ML operations.
- Display semantic_text if the user has the capacity to run ML
operations; otherwise, hide the semantic_text field.
### Trial License
<img width="1052" alt="Screenshot 2024-06-10 at 4 06 16 PM"
src="56a492db-c181-44ca-a77d-ea14a54ed0a3">
### Basic License
<img width="1456" alt="Screenshot 2024-06-10 at 4 00 56 PM"
src="aa9e0e6c-7a5f-4637-896b-9c2c2a1e152a">
### Serverless
<img width="1083" alt="Screenshot 2024-06-10 at 3 52 19 PM"
src="bd1fe21d-aacb-4b6a-98d9-489fab62e506">
# How to test
- Enable semantic_text in config/kibana.yml.
`xpack.index_management.dev.enableSemanticText: true`
- For Basic license, we can run elastic_search using: `yarn es snapshot`
- For Trial license, we can run elastic_seach using: `yarn es snapshot
--license trial`
- For serverless, we can run elastic_search using: `yarn es serverless
--projectType es`
Fixes https://github.com/elastic/kibana/issues/186365
## SLO Group Overview Embeddable
- `Edit criteria` appears on top
- Edit criteria does not appear under `More` actions
- Inline Edit criteria is removed from the panel
4b322361-08dd-4f3f-8440-2d4380efa2bd
## SLO Alerts Embeddable
- `Edit configuration` appears on top
- Edit configuration does not appear under `More` actions
- `X SLOs included` within the panel still opens the Edit configuration
c609fa70-4c1f-4aa5-aa17-4e765456f7e6
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR tags the saved_object_management API integration test suite with
`esGate` to include it in the verification checks that run as part of
the Elasticsearch on-merge process.
Closes https://github.com/elastic/kibana/issues/186388
## Summary
This PR covers some of the pre-work required to modernize role
management in Kibana. It convert the older Class component to a
functional component. It also breaks up the EUI in-memory table into
it's component parts of EUI Search Bar, Filters and EUI Basic table.
### Checklist
- [x] Since there's no change to the functionality, tests are expected
to continue passing
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of #181111.
Fixes the regression where the text field icon margins in the log rate
analysis results table were not rendered. It turned out the css applied
to `EuiIconTip` was not picked up correctly. Wrapping it in a `span`
applies it correctly.
Before:
<img width="1094" alt="image"
src="fd1a3e09-1815-490c-9c6a-ded3af71cf15">
After:
<img width="1098" alt="image"
src="4522f85a-82b5-4009-9ac5-ad207ac7b3e3">
### 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
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
Added perf metrics for es queries !!
Fixes https://github.com/elastic/synthetics-dev/issues/351
Started reporting query time for exploratory based visualizations used
in Synthetics
Test data can be seen on staging telemetry cluster !!
<img width="1698" alt="image"
src="120d9ea6-0162-4f56-8168-001b749d31e8">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
closes [186450](https://github.com/elastic/kibana/issues/186450)
## Summary
Add tests for aggregate critical path and service map endpoints to
serverless test suite
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
**Unit:**
This PR introduces an additional unit test to validate the behavior of
"paginated" ES.search() when using a default batch size of 1000. It
ensures that the data is appropriately passed down to the API through
three subsequent requests. The underlying logic can be summarized as
follows:
1. Fetch all documents with a timestamp greater than or equal to 15
minutes in batches of 1000.
2. Perform internal transformations.
3. Transmit transformed documents to an external API.
Since this process occurs server-side within a managed task running at
regular intervals, it is not feasible to conduct integration testing
using FTR or Cypress, as these requests cannot be intercepted in a
browser environment. However, I believe that the Jest test included in
this PR adequately addresses our responsibility. In this test, I mock
esClient.search() responses in a loop to ensure that all fetched items
are correctly sent to the API.
**Cypress:**
The Cypress integration test added with this PR is based on an actual
task run. Steps taken:
1. Create an environment with the task interval set to 1 minute and a
local API URL for usage reporting.
2. Load 2001 documents into ES, ensuring they have all the required
heartbeat fields.
3. Start transparent API proxy on a local API URL
4. Wait for the task to run.
5. Intercept the task API call to the usage reporting API.
6. Verify that the API request contains a payload of all 2001 documents
stored in ES.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/185873
## Summary
Added more granular APM spans during rule execution.
## To Verify
Add the following to your kibana config:
```
elastic.apm:
active: true
environment: 'ying-test-185873'
transactionSampleRate: 1.0
breakdownMetrics: true
spanStackTraceMinDuration: 10ms
# Disables Kibana RUM
servicesOverrides.kibana-frontend.active: false
```
This will push APM transaction information to
`https://kibana-cloud-apm.elastic.dev/` where you can see what the new
spans look like. Create an alerting rule that will generate alerts and
add some actions and summary actions to the rule. Let it run and then
check out the transactions in the cloud APM cluster. Make sure the
correct environment is selected and then view the transaction for
`Execute Alerting Rule ${ruleName}`.
<img width="1380" alt="Screenshot 2024-06-20 at 10 09 30 AM"
src="519b06eb-0b5f-4550-9f32-c71559d61757">
<img width="1347" alt="Screenshot 2024-06-20 at 10 09 38 AM"
src="c3b7242e-9930-4bbe-b392-82bc3732c0a8">
Closes: https://github.com/elastic/observability-dev/issues/3358
## Description
The Obs Alert Rules view has a `State` dropdown menu that cannot be
accessed by keyboard. I've included a MOV file that shows the keypress
events I tried to interact with the menu.
### Steps to recreate
1. Open the [Obs Alerts
Rules](https://keepserverless-qa-oblt-b4ba07.kb.eu-west-1.aws.qa.elastic.cloud/app/observability/alerts/rules)
table
2. Tab to the `State` button
3. Press `Enter` to open the menu
4. Click `Tab` and `Down_Arrow` to verify no action is being taken
5. Hover over the menu options and click one with a mouse to verify
action is being taken
### What was changed?:
1. EuiSelectableListItem was replace to EuiSelectable
### Screen:
befc9c75-9313-416a-be64-cc0b67f97a84
## Summary
fixes https://github.com/elastic/kibana/issues/183012
- Rename `assets` to `entities`
- Update entities index: `.entities-observability.latest-*` The index
where the data transform writes the summaries
- Show a search field to filter by service name. This will allow the
user to filter the table without knowing the entities index and the
fields.
- Use the same template and path for the service inventory`/services` .
- `throughput` remains the initial sorting field
- Merge the entities with the the same service name and calculates the
averages in the front end
2dbc07e9-3086-4d32-a98e-5dc364f59554
### How to test
1. Add the config to your kibana.yml
```
xpack.assetManager:
alphaEnabled: true
```
2. Enable `observability:apmEnableMultiSignal` in advansted settings
<details>
<summary>3. Run the entities definition in the dev tools</summary>
```
POST kbn:/internal/api/entities/definition
{
"id": "apm-services-with-metadata",
"name": "Services from logs and metrics",
"displayNameTemplate": "test",
"history": {
"timestampField": "@timestamp",
"interval": "5m"
},
"type": "service",
"indexPatterns": [
"logs-*",
"metrics-*"
],
"timestampField": "@timestamp",
"lookback": "5m",
"identityFields": [
{
"field": "service.name",
"optional": false
},
{
"field": "service.environment",
"optional": true
}
],
"identityTemplate": "{{service.name}}:{{service.environment}}",
"metadata": [
"tags",
"host.name",
"data_stream.type",
"service.name",
"service.instance.id",
"service.namespace",
"service.environment",
"service.version",
"service.runtime.name",
"service.runtime.version",
"service.node.name",
"service.language.name",
"agent.name",
"cloud.provider",
"cloud.instance.id",
"cloud.availability_zone",
"cloud.instance.name",
"cloud.machine.type",
"container.id"
],
"metrics": [
{
"name": "latency",
"equation": "A",
"metrics": [
{
"name": "A",
"aggregation": "avg",
"field": "transaction.duration.histogram"
}
]
},
{
"name": "throughput",
"equation": "A / 5",
"metrics": [
{
"name": "A",
"aggregation": "doc_count",
"filter": "transaction.duration.histogram:*"
}
]
},
{
"name": "failedTransactionRate",
"equation": "A / B",
"metrics": [
{
"name": "A",
"aggregation": "doc_count",
"filter": "event.outcome: \"failure\""
},
{
"name": "B",
"aggregation": "doc_count",
"filter": "event.outcome: *"
}
]
},
{
"name": "logErrorRate",
"equation": "A / B",
"metrics": [
{
"name": "A",
"aggregation": "doc_count",
"filter": "log.level: \"error\""
},
{
"name": "B",
"aggregation": "doc_count",
"filter": "log.level: *"
}
]
},
{
"name": "logRatePerMinute",
"equation": "A / 5",
"metrics": [
{
"name": "A",
"aggregation": "doc_count",
"filter": "log.level: \"error\""
}
]
}
]
}
```
</details>
4. Generate data with synthrace
1. logs only: `node scripts/synthtrace simple_logs.ts`
2. APM only: `node scripts/synthtrace simple_trace.ts`
### Checklist
- [ ] There is a issue with the `SearchBar` that causing the gap between
the search field and the timerange. I need to check it
## Summary
This PR adds endpoints for managing builtin entity discovery:
- `GET /internal/api/entities/managed/enablement`: check if stored API
key exists and is valid, then checks whether builtin definitions are
installed and running
- `PUT /internal/api/entities/managed/enablement`: creates API key if
none exists, then installs and kickoff the builtin definitions
- `DELETE /internal/api/entities/managed/enablement`: stops and
uninstalls builtin definitions, then delete API key
- `GET /internal/api/entities/definition`: returns the definitions
installed and their corresponding state `{ installed: bool, running:
bool }`
The API key is stored in an encrypted saved object, and has only the
permissions required to manage the transforms/ingest pipelines, and read
the source data.
Built in definitions are stored in code and have hardcoded IDs with a
special prefix `builtin_`.
The change also includes an `entityClient` that can be consumed by
public plugins and exposes methods that proxy the http endpoints listed
previously.
### Testing
- verify entity discovery is not enabled with `GET
kbn:/internal/api/entities/managed/enablement`
- setup entity discovery with `PUT
kbn:/internal/api/entities/managed/enablement`
- verify builtin definitions are installed and running `GET
kbn:/internal/api/entities/definition?builtIn=true`
- verify entity discovery is enabled with `GET
kbn:/internal/api/entities/managed/enablement`
- disable entity discovery with `DELETE
kbn:/internal/api/entities/managed/enablement`
- verify builtin definitions are not installed anymore `GET
kbn:/internal/api/entities/definition?builtIn=true`
- verify entity discovery is disabled with `GET
kbn:/internal/api/entities/managed/enablement`
---------
Co-authored-by: Kevin Lacabane <kevin.lacabane@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We want to have a preview for alert/events. Currently alert reason and
rule overview are embedded in the same preview. This PR separate them
into their own panels, so that they can be called outside of document
details if needed in the future. The `DocumentDetailPreviewPanelKey`
reference is removed, but will be used again when setting the preview
for alerts/events.
No functionality changed in this PR.
This PR is part 1 of refactoring document details code for alert
preview:
1️⃣➡️ separating the alert reason and rule overview into their own
panels
2️⃣ refactor left and right context to share
`DocumentDetailsPanelContext`, which will reduce the duplication for
alert preview
3️⃣ set up preview context for the actual alert/event details preview
### Checklist
- [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)
- [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
Closes https://github.com/elastic/kibana/issues/184394
Added agent policy selection to Edit integration policy page.
There is a lot of duplication between Create and Edit integration policy
pages, I'll see if I can refactor to extract the common logic: steps
components and managing its state.
I extracted the steps to a hook, it would be a bigger refactor to use
this in Create package policy page, so I might create a follow up issue
for that.
## To verify
- enable the `enableReusableIntegrationPolicies` experimental feature in
`kibana.dev.yml`
- Create a few agent policies
- Add an integration
- Go to Edit integration, and modify the linked agent policies
- Verify that the existing agent policies are populated correctly in the
Existing hosts combo box
- Verify that the modified agent policy list is reflected in the
`Preview API Request`, `policy_ids` list.
- Verify that when submitting the form, the package policy linkages are
updated to the selected ones (add/remove agent policies)
- The agent count should update below the combo / in the submit modal
window
- It's not allowed to submit the form after removing all agent policies
- If a new agent policy is selected, it will be created first and then
assigned to the integration policy
<img width="995" alt="image"
src="0a7163c6-154e-49b1-b73c-19ed024f6dc3">
<img width="993" alt="image"
src="ad470a27-90fa-40f5-b394-a93a08c95e06">
<img width="535" alt="image"
src="3b0ddc29-abf8-4e0d-8beb-300634c245b3">
<img width="1758" alt="image"
src="e8b976fe-3e53-439c-9b23-803deaf3e0aa">
### Create agent policy
<img width="1737" alt="image"
src="6f2a7f65-981a-487d-87c4-2dbb7ecd1835">
Preview API request contains the POST agent policy request
<img width="896" alt="image"
src="109140ab-13f2-42c9-9bbc-fb64859c4f62">
After submit, the updated integration policy is assigned to the new
agent policy too
<img width="2552" alt="image"
src="4027b47b-8d20-4153-b7ec-ed3500f08c9a">
## Open questions
- Currently the namespace placeholder of the package policy is set to
show the namespace of the first selected agent policy (if not set by the
package policy). I have to check what happens on the backend, if the
inherited namespace is changed if the agent policies change. The
behaviour should be consistent in the backend and UI.
Currently on the Agent policy details UI, the same integration policy
might show different inherited namespace if its shared by multiple agent
policies with different namespace.
<img width="1498" alt="image"
src="567800a8-2dcb-4b18-af89-f6e902889092">
<img width="1326" alt="image"
src="b59d131e-314c-4d5a-81e3-ab8fe0fa6e1f">
<img width="1318" alt="image"
src="69b54a63-f7c1-4f0f-8041-74b1774f1e9e">
- When the Edit integration was started from the Agent policy details
UI, the navigation goes back to the same agent policy after submitting
the page. Is this okay? Might be somewhat unexpected if creating a new
agent policy, though it is getting complex to decide where to navigate
in case of multiple agent policies.
### 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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: criamico <mariacristina.amico@elastic.co>
## Summary
<img width="1478" alt="Screenshot 2024-06-18 at 6 10 05 PM"
src="f095591d-f0ee-41bd-8b7d-07880bcf61d9">
Currently we have an issue where if user already has localStorageKey
from previous version where we still use Update for our Column Label and
then proceed to upgrading to version where we no longer use that, the
column name in Findings table will show field name (it shows resource.id
instead of Resource ID)
also because we changed the logic and not allow users to change the
column headers in the data grid, option to **edit data view field** is
removed for Cloud Security Table
<img width="741" alt="Screenshot 2024-06-19 at 9 16 06 AM"
src="df1ec765-89de-4f43-a723-daf9558af135">
This patch fixes that issues
Related to #184295
## Summary
As part of the PR, i have rewritten 4 of the test files for both
serverless and stateful for Dataset Quality Project
- `/dataset_quality/dataset_quality_summary.ts`
- Closes - https://github.com/elastic/kibana/issues/178874
- Closes - https://github.com/elastic/kibana/issues/178884
- Closes - https://github.com/elastic/kibana/issues/186354
- `/dataset_quality/dataset_quality_table.ts`
- Closes - https://github.com/elastic/kibana/issues/183940 (Possibly,
not guaranteed)
- Closes - https://github.com/elastic/kibana/issues/182353
- `/dataset_quality/dataset_quality_table_filters.ts`
- Closes - https://github.com/elastic/kibana/issues/183861
- Closes - https://github.com/elastic/kibana/issues/182320
- Closes - https://github.com/elastic/kibana/issues/184852
- `/dataset_quality/dataset_quality_flyout.ts`
- Closes - https://github.com/elastic/kibana/issues/184438
- Closes - https://github.com/elastic/kibana/issues/183851
- Closes - https://github.com/elastic/kibana/issues/183771
- Closes - https://github.com/elastic/kibana/issues/183525
- Closes - https://github.com/elastic/kibana/issues/183312
- Closes - https://github.com/elastic/kibana/issues/183129
- Closes - https://github.com/elastic/kibana/issues/182154
## Why are the tests re-written
- Most of the `it` were loading its own data, which add 2 problems, 1.
Makes our tests slower, 2. Data cleanup becomes challenging. Now the
tests simply load one master set of data and all the Functional tests
can be executed on that master data. This makes our tests leaner and
more functional.
- Every `it` resets the page state after the tests. Like when a `it`
blocks opens the Flyout, it should also close the flyout which was
missing. In order to refresh the page, the `navigate` API was used,
which is not good. Navigate API should only be used once to navigate to
the page in the starting and then refresh events should be used if a
refresh is required, or the action should be un-done in order to get the
same state as previous. For ex - Sorting make update the state of the
whole page. At the end of the sorting test, sorting should be reset.
With these changes `it` block now only focus on pure functional testing.
This means the `it` blocks can be moved around, skipped without
impacting other tests
- We had too much of generic tests, which could be combined into 1 `it`
block and be checked together. Idea to split 1 `it` block into another
is when we test for a completely different scenario. For eg - Writing a
single `it` for testing different columns of a table is much more
cleaner than multiple `it` for testing various columns of the same
table.
- Removed usage of `retry.try`. (Personal Opinion, please read it with a
pinch of salt) - The retry service seems like an escape hatch (read
workaround) when we don't have control over the rendering of UI
elements. Better alternative is to use `retry.tryforTime` as the last
resort.
Also the only time i found using the whole `retry` package was when we
use the `browser` package for getting URL value of refreshing page. I
cannot prove yet the problem with the `browser` package but somehow it
breaks the sync behaviour causing elements to be not available hence
requiring these retries.
I have removed `browser.refresh` completely from our code in favour of
better refresh handlers using DateTimePicker Refresh action
Linked Issued - https://github.com/elastic/kibana/issues/184145
# Pull Request Overview
This pull request (PR):
1. Enables Product Types for FTR API Integration Test Suites in
Serverless MKI:
- Previously, the test suites ignored product types entirely. With this
PR, scripts to run the tests have been relocated to
x-pack/test/security_solution_api_integration/scripts.
- Users can now run tests from the API Integration tests directory for
security solutions by using the command:
TARGET_SCRIPT={script_from_package_json} node
./scripts/mki_start_api_ftr_execution. This will execute the following
steps:
1. Create a security serverless project, respecting the product types
specified in the serverless configuration found in the config folder of
the relevant test suite.
2. Reset credentials.
3. Wait for Elasticsearch (ES) and Kibana to be ready and available.
4. Execute the tests.
5. Delete the project upon completion.
2. Adds Proxy Services Organizations to .ftr Role Users Files:
- This PR updates the .ftr role_users files to include all proxy
services organizations, ensuring they have the necessary permissions for
the tests.
# Implementation Details
Product Types
- Previous Setup:
- A project was created and handed over to the test suite to run the API
tests against, without considering product types.
- Changes Introduced:
- The script execution for tests has moved to
x-pack/test/security_solution_api_integration/scripts.
- Tests can be initiated using the command from the API Integration
tests folder where package.json exists:
```
TARGET_SCRIPT={script_from_package_json} node
./scripts/mki_start_api_ftr_execution
```
- The mki_start_api_ftr_execution script performs several steps to run
the tests, including creating a security serverless project with
specified product types, resetting credentials, ensuring ES and Kibana
readiness, executing tests, and cleaning up the project afterward.
- The script reads extra configuration (currently only product types are
supported) in the specific format as is, from the following file :
[api_configs.json](https://github.com/elastic/kibana/pull/184309/files#diff-1122baffe7ff843b1f486cee95468bed5851a9a4934be747f540bd42dc9a07daR2).
The key for the JSON file is the name of the script in
[package.json](https://github.com/elastic/kibana/pull/184309/files#diff-c6af1c81947b3a77bed431c688c7ad38c8969bd52e1c3ea92d643f09d422eb61R296)
- If a specific configuration is not required and the default complete
project is needed for the test to run, the key and configuration in the
`api_configs.json` file can be ommitted.
# Summary
This PR enhances the flexibility and functionality of the FTR API
integration test suites for serverless MKI by incorporating product type
considerations and updating the role_users configuration to include
proxy services organizations.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Towards: https://github.com/elastic/kibana/issues/169867
This PR onboards the Synthetics Monitor Status rule type with FAAD.
### To verify
I can't get the rule to alert, so I modified the status check to report
the monitor as down. If you know of an easier way pls let me know 🙂
1. Create a [monitor](http://localhost:5601/app/synthetics/monitors), by
default creating a monitor creates a rule.
2. Click on the monitor and grab the id and locationId from the url
3. Go to [the status check
code](https://github.com/elastic/kibana/blob/main/x-pack/plugins/observability_solution/synthetics/server/queries/query_monitor_status.ts#L208)
and replace the object that is returned with the following using the id
and locationId you got from the monitor.
```
{
up: 0,
down: 1,
pending: 0,
upConfigs: {},
pendingConfigs: {},
downConfigs: {
'${id}-${locationId}': {
configId: '${id}',
monitorQueryId: '${id}',
status: 'down',
locationId: '${locationId}',
ping: {
'@timestamp': new Date().toISOString(),
state: {
id: 'test-state',
},
monitor: {
name: 'test-monitor',
},
observer: {
name: 'test-monitor',
},
} as any,
timestamp: new Date().toISOString(),
},
},
enabledMonitorQueryIds: ['${id}'],
};
```
5. Your rule should create an alert and should saved it in
`.internal.alerts-observability.uptime.alerts-default-000001`
Example:
```
GET .internal.alerts-*/_search
```
6. Recover repeating step 3 using
```
{
up: 1,
down: 0,
pending: 0,
downConfigs: {},
pendingConfigs: {},
upConfigs: {
'${id}-${locationId}': {
configId: '${id}',
monitorQueryId: '${id}',
status: 'down',
locationId: '${locationId}',
ping: {
'@timestamp': new Date().toISOString(),
state: {
id: 'test-state',
},
monitor: {
name: 'test-monitor',
},
observer: {
name: 'test-monitor',
},
} as any,
timestamp: new Date().toISOString(),
},
},
enabledMonitorQueryIds: ['${id}'],
};
```
8. The alert should be recovered and the AAD in the above index should
be updated `kibana.alert.status: recovered`.
Closes https://github.com/elastic/sdh-kibana/issues/4739
## Summary
Fixes an issue with process chart query where it was fetching only for 1
minute while the chart was expecting data for 15 minites.
The issue was that `query` was filtering the documents by the latest 1
minute while `date_histogram` is using `extended_bounds` to cover the
last 15 minutes (relative the to provided `to` date). `extended_bounds`
ensures that we return buckets for 15 minutes range even if some buckets
are empty, but it does not expand the filter range from the `query`
which is set to 1 minute, meaning the first 13 buckets were always
empty.
This change expands the `filter` query for the chart to 15 minutes.
**After the change**
This PR, a follow-up to #186375, adds a new column for Asset Criticality
to the "All hosts" tab in the Explore/Hosts page.
If any of the hosts has criticality data assigned, it will be displayed
in the new column. If no criticality has been assigned, the field is
left blank.
<img width="1530" alt="Screenshot 2024-06-19 at 13 46 52"
src="054d0bb0-8858-40ae-ab20-7fe6f31e5858">
### How to test
1. Make sure you have test data with Asset Criticality.
- Either use the [datagen
tool](https://github.com/elastic/security-documents-generator) or just
make sure to assign criticality to already existing hosts
2. Enable Asset Criticality settings in `Stack Management > Kibana >
Advanced Settings`
3. Navigate to `Explore > Users > All Users`
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/183887
<img width="959" alt="Screenshot 2024-06-09 at 21 11 33"
src="950a92cb-a70a-4413-9358-f4a8a5b7da5d">
<img width="513" alt="Screenshot 2024-06-09 at 21 11 38"
src="36d8fe9d-fa40-4721-ac24-db0599076b9c">
- [x] popover width = 500 px
- [x] new combobox legend values component added
- [x] switch show value removed
- [x] location and alignment is in a single for row
- [x] auto legend width option to allow users to have the legend
automatically size based its contents - not there yet
- [x] no limit imposed of the number of values
- [x] when a value is selected, list or table appears
- [x] when the list is selected, label truncations is not offered and
legend items should be forced to have truncation on and clamped to a
single line.
- [x] adds telemetry too - adds events on save if the legend statistics
change:
`lens_legend_stats`- triggered if any stats is in legend
`lens_legend_stats_${TYPE}` - triggered for specific types, if user has
2 statistics (eg. AVG and MIN) two events are triggered.
and counting how many they use
`lens_legend_stats_amount_1`
`lens_legend_stats_amount_2`
`lens_legend_stats_amount_3`
`lens_legend_stats_amount_4_7`
`lens_legend_stats_amount_above_8`
---------
Co-authored-by: Nick Partridge <nicholas.partridge@elastic.co>
Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
