## Summary
Closes https://github.com/elastic/kibana-team/issues/1272
This PR adds implementation for eslint rules to help facilitate the
migration away from SASS files to leveraging the design tokens EUI
provides for styling.
The introduced rules in this PR are as follows;
- #### No CSS Color values
Consider;
```tsx
<EuiCode style={{ color: '#dd4040' }}>Hello World!</EuiCode>
```
this expression because it specifies the css color property, with a
valid [CSS color
value](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value),
when the aforementioned rule is enabled depending on the set report
level set the user would get a feedback, see screenshot below;
<img width="735" alt="Screenshot 2024-11-20 at 12 46 17"
src="https://github.com/user-attachments/assets/d2f608dc-782c-4d83-88e6-92dfdd8f6101">
This rule also works for variables defined elsewhere in the code and
referenced as a value to the style prop, see screenshot below;
<img width="1658" alt="Screenshot 2024-11-26 at 13 29 45"
src="https://github.com/user-attachments/assets/f8aadf6b-318b-4c6a-b7c9-bb44fb867b58">
feedback will also be provided when some variable that is a literal
value is specified as a value for any earmarked property that should not
specify literal values.
<img width="1730" alt="Screenshot 2024-11-28 at 19 00 08"
src="https://github.com/user-attachments/assets/bc3a8674-9469-4c7a-b0c9-7a2bfa7f08dc">
feedback will be provided for referencing a member prop of some object
defined elsewhere as a value to any earmarked property that we have
deemed to not specify literal values
<img width="1676" alt="Screenshot 2024-11-29 at 11 36 44"
src="https://github.com/user-attachments/assets/c4537fbf-b2d8-46bb-ad5f-8582e8c9a932">
Supports;
- object values
- object references
- template literals
- tagged templates
This approach does not penalize variable declarations, only the usages
of any said variable when it doesn't conform to expectation
- #### Prefer CSS attributes for EUI components (optional)
Consider;
```tsx
<EuiCode style={{ someCSSProperty: 'propertyValue' }}>Hello
World!</EuiCode>
```
A declaration like the one above, will be regarded as an error and can
be fixed, when it's fixed it will be re-written as
```tsx
<EuiCode css={{ someCSSProperty: 'propertyValue' }}>Hello
World!</EuiCode>
```
<!--
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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
- [ ] [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
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] 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.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_node:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes#201037
- unskipping search solution navigation tests
- removing canvas from checks
- canvas only renders if you have canvases, this seems to have broken
and make solution nav tests flakey. removing canvas from our checks
- removed ent-search apps these links were removed in another PR but I
missed updating this test because it was skipped
- added names for the test spaces
- added some expects when opening sections to ensure they are open
before moving on. I saw some flakes locally without these.
### 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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
* Auto-detect "upstream" and "origin" remotes (instead of assuming their
names).
* Allow relocating modules that are already in a "sustainable" folder.
* Filter out modules that are in the correct locations.
* Update the list of _modules to relocate_ to show only those modules
that are actually moved.
---------
Co-authored-by: Alejandro Fernández Haro <afharo@gmail.com>
## Summary
Introduces a loading state in the data views select popover and renders
a loading indicator when DVs are not available yet. This makes sure that
even if the `savedObjectsClient.find` call of the data views service
takes a long time, we don't show an empty popover in the meantime.
https://github.com/user-attachments/assets/5bbe0c68-3ceb-4d7f-91fd-357db4caa5c1
## References
Fixes#198502
## Release note
Fix race condition in alerting rules data view selector
## Summary
This PR is one of two, this one prepares for the new lookup join feature
by removing the inline parts in the prompts, and adding some basic
translation context in translate_rule.
Things that could be done in this PR or the next is:
1. Move square bracket replacement of missing resources to
process_query.
2. Add replace lookup index name to process_query.
3. Ensure LOOKUP JOIN context is added to NLtoESQL system prompts
sometime.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Clears deprecation warning triggered by maps file upload test.
The role used by the test user needs to now include `manage`
This should clear the `elastic/kibana-presentation` deprecation warnings
raised [here](https://github.com/elastic/kibana-team/issues/1173)
In addition to changes introduced by #201142
Reasoning:
This pull request includes changes to the
`packages/kbn-test/src/jest/setup/react_testing_library.js` file to
improve internal error logging suppression from react-testing-library.
In particular,
[this](1e01273374/src/core/console.ts (L1-L4))
suppression logic has been migrated to avoid breaking devUX
expectations.
Tested against https://github.com/elastic/kibana/pull/201142 code
changes
## Release Note
Adds RBAC to the Automatic Import APIs
## Summary
This PR adds RBAC privileges to Automatic Import APIs
It adds `all` access to the users having `fleet:all` `fleetv2:all`
`actions:all` UI access
This PR also adds a validation to the `integrationName` and
`dataStreamName`.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Authz API migration for unauthorized routes
This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
- If you have snapshot tests that include the route definition.
## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.
---------
Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
## Summary
Simply uses the ES Watcher API to load watches instead of a search query
against the `.watches` index. This appears to be the last direct query
against that index.
Part of https://github.com/elastic/kibana/issues/152142
## Summary
Fixes issues around handling groupIds in Anomaly Explorer:
[#198824](https://github.com/elastic/kibana/issues/198824)
* `UrlStateService` is now more generic, allowing for the creation of
`useGlobalUrlState` and `usePageUrlState` hooks based on it.
* New `useGlobalUrlState` hook: Responsible for managing global state
with proper typing.
* `id_badges.js` converted to typescript -> `id_badges.tsx`
* The use of `maps` in the `id_badges`, `job_selector` and
`job_selector_flyout` components has been removed. Now, selected group
and job ids are passed directly.
* Instead of manually setting the global state in `job_selector`, an
`onSelectionChange` callback is now expected. In the future, the
`Timeseries explorer` and `Anomaly Explorer` are expected to use a
(maybe) shared context to track selected jobs easily, eliminating the
need to manually update the global state for the `Timeseries explorer`.
* The `AnomalyExplorerCommonStateService` now listens for URL changes to
track properties derived from the URL. This replaces the `useUrlState`
hook, which lacked proper typing, and serves as the single source of
truth for selected jobs and groups.
* The `ExplorerDashboardService`, previously a hybrid of a "service" and
redux-like action handler, has been removed. The state is now managed
within `state_manager` component. In the future, data like `chartsData`
and `influencers` should be decoupled from `ExplorerState` and moved to
individual services.
1. Fix for all issues mentioned in #198824 as visible in the video:
- The initial group selection now results in the correct badge being
displayed.
- Creating an embeddable with a selected group properly propagates the
selected group instead of individual job ids.
- Navigating to the Anomaly Explorer from Dashboards now correctly uses
the selected group instead of individual job ids.
https://github.com/user-attachments/assets/82c641e0-d930-42eb-8627-fad4bdc417f6
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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
These changes allow `Partial<RuleResponse>` to be used as a parameter
for `RuleOverviewTab` component.
We re-use this component for "SIEM Migrations" feature to display
translated state of the rule which has just a few fields that represent
the `RuleResponse` object. The set of fields used in `RuleMigration`
object is a minimum set of fields enough for the rule creation.
Right now, `RuleOverviewTab` component requires the complete
`RuleResponse` object to be passed even though internally each section
(`RuleAboutSection`, `RuleDefinitionSection`, `RuleScheduleSection` and
`RuleSetupGuideSection`) of the rule's overview expects
`Partial<RuleResponse>`. To be able to use this component we force type
casting at the moment and would like to get rid of it.
@elastic/security-detection-rule-management do you have objects
regarding this change in `RuleOverviewTab` intefrace?
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- Rule management cypress tests ([100 ESS & 100
Serverless](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/7601))
## Summary
Closes https://github.com/elastic/kibana/issues/203793
This PR replaces the deprecated `access` tags with the new `security`
configuration.
All instances of `options: {tags: ['access:infra']}` are now updated to
`security: {authz: {requiredPrivileges: ['infra']}}`.
Fixes#203472
## Summary
|Rule|Group info|
|---|---|
||
@elastic/response-ops What sort of test do you suggest to add for this
case?
### 🧪 How to run test
#### Deployment agnostic
- [x] Test on MKI
```
// Server
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
// Test
node scripts/functional_test_runner --config=x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="ElasticSearch query rule"
```
**Partially addresses: #171520**
## Summary
This PR updates the tooltips for the ‘Diff view’ and ‘Final update’
sections in the prebuilt rule upgrade flyout. It also streamlines the
version picker by removing redundant options, making the UI simpler and
clearer for users.
## Changes
- Reduced the number of version picker items based on the diff outcome.
Updated item names for better clarity.
- Revised the tooltip text for the ‘Diff view’ section to better explain
the available dropdown options. The tooltip now describes only the
options in the dropdown to avoid overwhelming the user with unrelated
information.
- Updated the tooltip text for the ‘Final update’ section.
## Screenshots
<img width="922" alt="Schermafbeelding 2024-12-11 om 11 54 48"
src="https://github.com/user-attachments/assets/124e76a1-99dc-48d8-be54-f6c8f2079451">
<img width="640" alt="Schermafbeelding 2024-12-11 om 11 55 32"
src="https://github.com/user-attachments/assets/45655dd2-6503-46b7-b28b-0df7bf0e6fa3">
<img width="433" alt="Schermafbeelding 2024-12-11 om 11 55 58"
src="https://github.com/user-attachments/assets/d845ff52-4678-4245-8bdd-b9957f0c1d13">
Work started on 06-Dec-2024.
---------
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
## Summary
The PR fixes [this bug](https://github.com/elastic/kibana/issues/199303)
The issue happens with some of the locally setup LLMs (like
[Ollama](https://github.com/ollama/ollama)) which requires the correct
`model` to be passed as part of the [chat completions
API](https://github.com/ollama/ollama/blob/main/docs/api.md#generate-a-chat-completion).
We had a bug in our code when on new conversation creation we would not
pass all the connectors configuration and only `connectorId` and
`actionTypeId` would be passed. Here is the old code implementation:
```
const newConversation = await createConversation({
title: NEW_CHAT,
...(currentConversation?.apiConfig != null &&
currentConversation?.apiConfig?.actionTypeId != null
? {
apiConfig: {
connectorId: currentConversation.apiConfig.connectorId,
actionTypeId: currentConversation.apiConfig.actionTypeId,
...(newSystemPrompt?.id != null ? { defaultSystemPromptId: newSystemPrompt.id } : {}),
},
}
: {}),
});
```
and thus the new conversation would not have the complete connector
configuration which would cause to use default model (`gpt-4o`) as a
model we pass to the LLM.
Also, I updated the default body that we use on the Test connector page,
to make sure that we send a model parameter to the LLM in case of `Open
AI > Other (OpenAI Compatible Service)` kind of connectors.
### Testing notes
Steps to reproduce:
1. Install
[Ollama](https://github.com/ollama/ollama?tab=readme-ov-file#ollama)
locally
2. Setup an OpenAI connector using Other (OpenAI Compatible Service)
provider
3. Open AI Assistant and select created Ollama connector to chat
4. Create a "New Chat"
5. The Ollama connector should be selected
6. Send a message to LLM (for example "hello world")
Expected: there should be no errors saying `ActionsClientChatOpenAI: an
error occurred while running the action - Unexpected API Error: - 404
model "gpt-4o" not found, try pulling it first`
## Summary
* Added link to rebase guideline in PR description.
* Do not count `elasticmachine` commits as manual.
* Replace references in CODEOWNERS file manual section.
* Update README prerequisites.
## Summary
Resolves: https://github.com/elastic/kibana/issues/151463
Removes all reference to ephemeral tasks from the task manager plugin.
As well as unit and E2E tests while maintaining backwards compatibility
for `xpack.task_manager.ephemeral_tasks` flag to no-op if set. This PR
has some dependencies from the PR to remove ephemeral task support from
the alerting and actions plugin
(https://github.com/elastic/kibana/pull/197421). So it should be merged
after the other PR.
Deprecates the following configuration settings:
- xpack.task_manager.ephemeral_tasks.enabled
- xpack.task_manager.ephemeral_tasks.request_capacity
The user doesn't have to change anything on their end if they don't wish
to. This deprecation is made so if the above settings are defined,
kibana will simply do nothing.
### 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
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `ad2e15a` ->
`1b51ff6` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
