## Summary
Unskip test that was previously failing in MKI.
These tests have been run against MKI.
Background on the test
--
The test confirms that synthetics integration policies auto update when
the package version is updated. It attempts to install an older version
of the package and then run fleet setup to install a newer version of
the package and trigger auto upgrade
Why it failed
--
The test expected a lower version of the package to be installed, but a
more recent version was already installed. Therefore, when we went to
create synthetics integration policies they were installed with the most
recent version.
How we fixed it
--
Before this test, we now uninstall the Synthetics integration to ensure
we can force install an earlier version.
Closes https://github.com/elastic/kibana/issues/205024
We add utility functions to access nested fields in Painless in a safe
way and modify the existing ECS generation logic to use them.
This access happens using the `object?.get("field")` syntax for complex
cases, while falling back to the familiar `ctx.field` for the cases
where `field` is a valid Painless identifier and `ctx` is known to be
non-nullable.
This takes care of the compile-time correctness of field accesses. Note
that it is still possible for generated pipelines to fail in runtime on
unexpected input, e.g. accessing a nested field `a.b` fails for the
document of the form `{"a": "string"}`.
See the PR for more details, release note and test results.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
A bug with the search bar configuration allows for a page that does not
have auto-refresh enabled to inherit the auto-refresh state from another
page that had previously enabled it. This PR fixes that by fully
resetting the state for the page's search bar to ensure auto-refresh is
not active for Hosts page (as it should be).
Closes#205414
## How to test
- Go to Alerts page
- Click on the Date Quick Selector, enable the auto-refresh feature.
Confirm the refresh icon is on the datepicker now.
- Navigate to Hosts page
- The auto-refresh icon on the Hosts page search bar datepicker should
no longer be visible, and opening the date quick selector should not
show any auto-refresh feature/toggle.
Follow up to https://github.com/elastic/kibana/pull/205285
This uses renovate instead of backport tooling on a few more of
operation's groups. These were selected because they have not required
any code changes to date.
Part of https://github.com/elastic/kibana/issues/199664
## Summary
As part of the work of the `Remote clusters: UX improvements` project
I've changed a bit the folder structure and moved some files that are
going to be used by more than one step. Since the PR will be large, I
decided to create a PR only for the structure changes to avoid much
noise in the main PR. The new structure will be as follows:
```
|-- x-pack/platform/plugins/private/remote_clusters/public/application/sections/components/
|-- remote_cluster_config_steps [new folder]
|-- components [will be used for the common components for all the steps]
|-- request_flyout.tsx [existing but moved here]
|-- remote_cluster_form
|-- remote_cluster_setup_trust
```
## Summary
<!-- ### DONT MERGE, THIS PR DEPENDS ON AN UPDATE TO EUI, THAT'S IN
FLIGHT -->
Closes https://github.com/elastic/kibana/issues/202782
This PR reworks how custom themes used within the kibana code editor for
the default visual look and ones specific to supported languages are
defined to accomodate the upcoming visual refresh, the approach here
leverages the `euiTheme` object value returned from the `useEuiTheme`
hook, now a single theme declaration is all that is required such that
using either the `colorMode `value or the `euiTheme` from the provided
`UseEUITheme` value it's possible to craft a theme that's in the context
of kIbana, color mode aware and the editor would be able to resolve the
appropriate colors depending on the user's color mode.
This required some modification to monaco itself; now when defining
languages if the `CustomLanguageType` specification is being followed, a
function that resolves to a standard monaco theme can be provided on the
property `languageThemeResolver` which will be passed the `euiTheme`
when registering this theme. It's worth mentioning that this can also be
done manually by leveraging the custom method
`registerLanguageThemeResolver` added on the monaco editor object, like
so
```tsx
monaco.editor.registerLanguageThemeResolver(LanguageID, languageThemeResolver);
```
However one should take note that when calling this method directly, the
ID passed must correlate to a registered language ID, else the theme
will not be available for use after Monaco is initialised, hence the
theme name must equal an existing language ID if it's to be used for a
specific language.
## How to test
- Enable borealis, like so;
- in your `kibana.dev.yml` file include the following config;
```yml
uiSettings.experimental.themeSwitcherEnabled: true
```
- start kibana using the following command;
`KBN_OPTIMIZER_THEMES="borealislight,borealisdark,v8light,v8dark" yarn
start --run-examples`
- Tryout all downstream of the code editor to ascertain the code editor
colors are as should be for both Amsterdam and Borealis; downstreams
include;
- ES|QL editor, navigate to discover and click the "try ES|QL" button
- Dev tools, on clicking the nav hamburger menu under the management
menu group there's a menu item that links to all dev tools
- Index Management use cases; navigate to stack management, under Index
management select any existing index, then navigate to it's settings
this should load up the code editor.
- Saved Object use case; navigate to stack management, under saved
objects attempt inspecting any saved object we'd be presented with the
code editor etc.
<!--
### 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_note:*` 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: ek-so <eksomail@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Persist flyout mode settings (docked and/or open/closed) across page
refreshes. I.e., if a user selects docked mode while the flyout is open,
and refreshes the page, the flyout will open on page load, in docked
mode.
Connected with #195187
## Summary
- Moved params of duration anomaly rule type to
`/response-ops/rule_params/uptime_duration_anomaly/`
- Moved params of monitor status rule type to
`/response-ops/rule_params/uptime_monitor_status/`
- Moved params of TLS rule type to
`/response-ops/rule_params/uptime_tls/`
- **Did not move anything related to the legacy TLS rule type.**
I ran into a similar issue to #205207 for the monitor status rule type.
It doesn't block this PR but some follow up work might be needed for
`x-pack/solutions/observability/plugins/uptime/public/legacy_uptime/lib/alert_types/lazy_wrapper/validate_monitor_status.ts`.
We will probably decide after the new year.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Connected with #195187
## Summary
- Moved params of synthetic status monitor rule type to
`/response-ops/rule_params/synthetics_monitor_status/`
- Moved params of TLS rule type to
`/response-ops/rule_params/synthetics_tls/`
I created a follow-up issue to handle the places where io-ts is used for
params validation in `observability/plugins/synthetics`. #205207
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes: #204498
## Description
The time input interval box for timeperiod input for suppressing alerts
is missing form label
Preconditions: Security -> Rules->Detection Rules(SIEM) page is open
## Changes made:
`aria-label` attribute was added for mentioned place
## Screen:
## Summary
This PR enables default execution context tracking (which was added in
this [PR](https://github.com/elastic/kibana/pull/204547)) for the
following plugins:
- SLO
- Infra
- Synthetics
|Plugin|Before|After|
|---|---|---|
|SLO||
|Synthetics||
|Infra >
Inventory||
|Infra >
Hosts||
Starting with an upgrade before backporting to make sure we're running
the same version on 8.x (which is on 13.6.3).
We want to make sure this dependency is cached due to the download size,
and that browser testing is aligned on all branches.
Closes https://github.com/elastic/kibana/issues/191306
## Summary
This PR updates the collision resolution algorithm to handle the edge
case described in the linked issue.
In the old algorithm, we checked each panel for collisions a **single
time** - however, this caused a bug where panels could get re-ordered
depending on the order that we pushed panels down + how much distance we
were pushing them down by. While this algorithm was extremely efficient
(approximately $`O \left({ { n^2 + n } \over 2 }\right)`$ before
compaction where `n` is the number of panels), it was not as simple as
"fixing" the bug because, no matter what, there was always an edge case
that could not be handled without adding some sort of backtracking -
instead, we had to come up with a new algorithm.
### Example of Edge Case
To better understand how the old and new algorithms compare (and how
they work), consider a scenario where the grid layout has 8 columns and
the panels are laid out as follows:
Now, what happens when panel 4 (yellow) is dragged to the left so that
it overlaps both panel 3 (red) and panel 4 (blue)?
<details>
<summary><b>Old Algorithm</b></summary>
With the old algorithm, we get the following behaviour:
This is because we are **only** pushing the collided panels down
**once**. So, to describe what happens in detail, we start by gathering
up the panels **in order** (top-bottom, left-right, where dragged panels
take priority when rows are equal) - this results in an order of
`[panel4, panel3, panel1, panel2]`.
We start checking for collisions in this order - starting with panel 4
(yellow), we determine that it is colliding with panel 3 (red) and panel
2 (blue). We start with panel 3 (since we are once again doing this "in
order"), and we push it down by 5 rows (since this is the overlap of the
panel 3 and panel 4). Then, to "resolve" the second collision with panel
4, we push down panel 2 by 3 rows. This leaves the layout in the
following state:
Now, since panel 4 (yellow) is "resolved", we move on to the next panel
in the `[panel4, panel3, panel1, panel2]` order - panel 3 (red). Panel 3
now collides with panel 2, so we push panel 2 down by two rows. This is
the only collision with panel 3, so we check panel 1 and panel 2,
neither of which report collisions at this point. So the layout ends in
the following state:
So, what's the problem here? Well, panel 1 (green) is now "out of sync"
with the old panel ordering because it got "left behind" in the
collision resolution. Instead, we should have moved panel 1 by the same
amount as panel 2.
</details>
<details>
<summary><b>New Algorithm</b></summary>
With the new algorithm, we get the expected behaviour:
If we run through the algorithm, we identify that the **first**
collision in the layout (based on left to right, top to bottom ordering,
with priority being the panel being dragged) is panel 4 (yellow) - so,
we enter the `while` loop and recurse to resolve all collisions with
panel 4 via `resolvePanelCollisions`. The recursion within
`resolvePanelCollisions` works as follows - get **all** collisions with
panel 4 (which, at this point, returns panel 3 (red) and panel 2 (blue))
and push them down by a single row, then recurse on **those** panels to
resolve any of the resulting collisions.
It's difficult to describe recursion, but let me try my best :) During
the collision resolution on panel 4, we start by pushing panel 3 down
and then recursively resolving the collisions on panel 3. Since pushing
panel 3 causes collisions with panel 1 and 2 (in order), we push them
both down by one row - starting with panel 1. We recurse to resolve the
collisions on panel 1, which has no collisions - then we do the same for
panel 2, which also reports no collisions. The collisions with panel 3
are "resolved" (i.e. we can "back out" of the recursion on panels 1 and
2), so we go back to resolving panel 4, push panel **2** down, and then
resolve the collisions on panel 2 - which reports no collisions. In
summary:
Therefore, after the first iteration of the `while` loop, this results
in the following layout, where panel 3 (red) has been pushed down by one
row, panel 1 (green) has been pushed down by one row, and panel 2 (blue)
has been pushed down by two rows:
We then return to the `while` loop and check if the layout has any other
collisions - and panel 4 is still our "first" collision! So we repeat
the process above and push both panel 4 and panel 2 down and recurse to
resolve the resulting collisions on those panels. This continues as
follows:
| Steps | Resulting Layout |
|--------|--------|
| <img width="400"
src="https://github.com/user-attachments/assets/d2691a1c-5f0b-4333-bfd4-3cc57e1a3098"/>
| <img width="400"
src="https://github.com/user-attachments/assets/85325df3-7fbf-46fa-af98-10bbd883cf8d"/>
|
| <img width="400"
src="https://github.com/user-attachments/assets/e31a400f-d0d1-408d-baec-efa708ad0c52"/>
| <img width="400"
src="https://github.com/user-attachments/assets/c81762d4-443b-451c-b8fc-dabaf4e32ba1"/>
|
| <img width="400"
src="https://github.com/user-attachments/assets/4292e4a9-4157-4d77-9b69-b0f6a07338ac"/>
| <img width="400"
src="https://github.com/user-attachments/assets/bdd2dad5-6531-4d56-b8c2-dfb121fb6b5b"/>
|
| <img width="400"
src="https://github.com/user-attachments/assets/6d194a89-3ed6-46a6-9dcc-2b3fa0de9942"/>
| <img width="400"
src="https://github.com/user-attachments/assets/7e0b0fb5-bacb-49ad-ac86-02665a779b59"/>
|
And so, after our fifth iteration of the `while` loop, the layout is
**no longer** reporting collisions - so, our layout is now fully
resolved!
</details>
### Performance Comparison
This algorithm is more-or-less the same as the algorithm used in
`react-grid-layout` - however, instead of running on **every frame**,
our layout engine only resolves collisions **as they happen** (hence why
the while loop is necessary). This results in much better rendering
performance.
To test this, I opened the Logs sample dashboard in both the example app
(which is obviously using `kbn-grid-layout`) and Dashboard (which is
still using `react-grid-layout`) and performed various drag actions on
both while recording their performance. For example, consider the
following capture of a drag that doesn't cause **any** collisions:
| `kbn-grid-layout` | `react-grid-layout` |
|--------|--------|
|
|
|
You can see that, even with no collisions, the performance is slightly
better with `kbn-grid-layout` because we don't **ever** recurse on
collisions in this scenario. But it gets even better when actual
collisions happen - for example, consider the performance when the
dragged panel only causes a **single** collision:
| `kbn-grid-layout` | `react-grid-layout` |
|--------|--------|
|
|
|
Versus when the dragged panel causes multiple collisions at the top of
the dashboard that causes a chain reaction of panels needing to be
pushed down:
| `kbn-grid-layout` | `react-grid-layout` |
|--------|--------|
|
|
|
In all of the above scenarios, performance is improved overall **and**
there are fewer red "spikes" / bottlenecks due to [forced
reflow](https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing?utm_source=devtools#avoid-forced-synchronous-layouts)
along the way. Most of the time saved is caused by significant
reductions to both `rendering` and `painting` time in `kbn-grid-layout`
when compared to `react-grid-layout`. While some of this improvement may
be explained by differences in the example grid plugin versus the
Dashboard plugin, this is enough proof that performance of
`kbn-grid-layout` is **at least as good as** `react-grid-layout` and so
swapping out the layout engine should not cause any performance
regressions.
### Other Notable Algorithm Attempts
I tried a few **drag/resize event specific** algorithms that **only
work** when an interaction event is happening - i.e. they rely on
information from the panel that is being interacted with in order to
function.
Note that, if we decided to go this route, we would still need some
generic collision resolution algorithm (such as the one proposed in this
PR) that we could use to resolve a layout when **no** interaction event
is happening. After all, we cannot assume that the grid layout that is
sent as a prop is valid (i.e. it **could** have overlapping panels **at
the start**, before any dragging and/or resizing has occurred) and we
need a way to verify + resolve it.
Unfortunately, both of the "interaction-event necessary" collision
resolution algorithms that I tried suffered from bugs so, while it might
be **possible** to make a more efficient algorithm for this, I
ultimately threw them away in favour of using the "generic" collision
resolution algorithm proposed in this PR.
That being said, I figured it was worth documenting the things that I
tried and why they failed.
<details>
<summary><b>Algorithm 1</b></summary>
I tried a modification of the **original** collision resolution
algorithm where, instead of **just** moving the colliding panels down by
the `rowOverlap` amount, we move **all** panels in or below the targeted
grid row down by the **height** of the panel being dragged. However, due
to the compaction algorithm ignoring **all** panels that have
collisions, you can end up in an infinite "push panels down" loop like
so:
This is because panel 3 is **always** colliding with panel 1 and 4, so
they never get pushed up to "close" the gaps. To try and get around
this, I modified the collision detection used for panel compaction so
that collisions only "stop" compaction if the collision occurs on a
panel **above** the given panel we are trying to compact. However, this
caused a **different** bug:
In the above GIF, consider what happens when panel 3 (red) targets row
3. As expected, we move all other panels (1, 2, and 4) down by a single
row. Then, when we reach the compaction step, we start by trying to push
panel 1 up (since it is now the top-left-most panel) - and, since we are
filtering out the collision with panel 3 (since it occurs "below" panel
1), it gets pushed all the way to the top. Then, we push panel 4 all the
way to the top (because it is also ignoring the collision with panel 3),
followed by pushing panel 2 up until it would collide with panel 3.
Unfortunately though, we didn't account for the full height of panel 4 -
so panel 3 is now stuck colliding with panel 4.
I modified this algorithm **further** to move the panels down by the
"row overlap" with the dragged panel rather than the dragged panel's
height - but this also suffers from a bug:
At which point, I abandoned this approach becase it felt like there were
too many edge cases that could not all be accounted for. It's possible
we could explore this further but, given the limitations of this
algorithm **only working** for resolving collisions given an interaction
event, I opted to move on.
</details>
<details>
<summary><b>Algorithm 2</b></summary>
I tried an algorithm where, similar to the algorithm proposed in this
PR, I recorded the panel IDs in each cell that a given panel occupied -
however, instead of moving things down row by row and handling the
resulting collisions, we moved **every** panel that was **below** the
targetted row down by the **height** of the panel being dragged. In
theory, the compaction algorithm would then take control of closing all
the resulting gaps.
Unfortunately, this didn't quite work in practice. Consider the
following:
According to the algorithm defined above, panel 2 (blue) and panel 4
(yellow) both need to move down when panel 3 (red) is dragged to target
row 4 (remember that row **zero** is the first row), since they both
occupy this row - so we push both of them down by 1 (the height of panel
3). However, once we start compacting the layout in order to finish our
collision resolution, we hit a snag with panel 4 (yellow) - when we
start trying to compact panel 4, `getAllCollisionsWithPanel` returns
that **panel 3** is colliding with panel 4 and so we **break out** of
the compaction - hence why panel 4 continues to float. This then has a
snowball effect on all other panels as they report collisions and
therefore do not get pushed up.
</details>
<details>
<summary><b>Algorithm 3</b></summary>
This was the algorithm we **almost** went with, because it works! But it
suffered from two things - one, the code was complicated and difficult
to maintain and two, the collision resolution behaviour felt less
natural because it **always** favoured the dragged panel. This made it
too sensitive to pushing items down; so even if a panel was targeting
the bottom row of a different panel, it would push that panel down to
make room for the dragged panel.
In the simplest terms, this algorithm worked as follows: after creating
a 3D array representing the current grid (a 2D array of panel ID
arrays), for each row, while there are collisions, push panels down in
**reverse order** (bottom right to top left); continue until all rows
have no collisions. This algorithm hd an efficiency of approximately
$`O\left(r * c \right)`$ to set up the 3D array and $`O \left( c * h * n
\right)`$ to resolve the conflicts, where `r` is the number of rows, `c`
is the number of columns (minus 1), `h` is the height of the dragged
panel, and `n` is the number of panels. This results in an overall speed
of about $`O \left( (r * c) + (c * h * n) \right)`$
To better understand how this algorithm works, consider how it handles
the edge case described above:
<details>
<summary>Algorithm 3 - Edge Case Example</summary>
Rather than checking every **panel** for collisions a single time, we
check and resolve each **row** for collisions and resolve them. This
gives the following behaviour:
We start by creating a 3D array representing the grid - at the **first**
point of collision, it looks like:
| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|--------|--------|--------|--------|--------|--------|--------|--------|--------|
| **0** | `[panel3]` | `[panel3]` | `[panel3]` | `[panel3, panel4]` |
`[panel4]` | `[panel4]` | `[panel4]` | `[]` |
| **1** | `[panel3]` | `[panel3]` | `[panel3]` | `[panel3, panel4]` |
`[panel4]` | `[panel4]` | `[panel4]` | `[]` |
| **2** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2, panel4]` |
`[panel4]` | `[panel4]` | `[panel4]` | `[]` |
| **3** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2, panel4]` |
`[panel4]` | `[panel4]` | `[panel4]` | `[]` |
| **4** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2, panel4]` |
`[panel4]` | `[panel4]` | `[panel4]` | `[]` |
Then, we start checking and resolving collisions, row by row. Starting
with row 0, we see that column 3 has a collision between panel 3 and
panel 4 - we **ignore** the panel being dragged (panel 4), so we push
down panel 3 by one row. Row 0 has no more collisions, so we move on to
row 1 and, following the same logic as above, we push down panel 3
again. This leaves the grid in the following state:
| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|--------|--------|--------|--------|--------|--------|--------|--------|--------|
| **0** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **1** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **2** | `[panel1, panel3]` | `[panel1, panel3]` | `[panel2, panel3]` |
`[panel3, panel2, panel4]` | `[panel4]` | `[panel4]` | `[panel4]` | `[]`
|
| **3** | `[panel1, panel3]` | `[panel1, panel3]` | `[panel2, panel3]` |
`[panel3, panel2, panel4]` | `[panel4]` | `[panel4]` | `[panel4]` | `[]`
|
| **4** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2, panel4]` |
`[panel4]` | `[panel4]` | `[panel4]` | `[]` |
Now, on row 2, we have collisions in columns zero through three, so we
push the panels in **reverse order** (i.e from the bottom right to the
top left) - this results in pushing panel 2 down, then panel 1, and
finally panel 3. We have to add a row in order to accomplish this
because otherwise we "lose" the bottom of panel 2, so our layout now
looks like this and row 2 has no more collisions:
| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|--------|--------|--------|--------|--------|--------|--------|--------|--------|
| **0** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **1** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **2** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **3** | `[panel1, panel3]` | `[panel1, panel3]` | `[panel2, panel3]` |
`[panel3, panel2, panel4]` | `[panel4]` | `[panel4]` | `[panel4]` | `[]`
|
| **4** | `[panel1, panel3]` | `[panel1, panel3]` | `[panel2, panel3]` |
`[panel3, panel2, panel4]` | `[panel4]` | `[panel4]` | `[panel4]` | `[]`
|
| **5** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2]` | `[]` |
`[]` | `[]` | `[]` |
Continuing this behaviour, we push panel 2, panel 1, and panel 3 down in
row 3; then again in row 4. Once we reach and resolve row 5 (i.e. get
row 5 to the point where there are no collisions with panel 3), our
layout looks like so:
| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|--------|--------|--------|--------|--------|--------|--------|--------|--------|
| **0** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **1** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **2** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **3** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **4** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **5** | `[panel3]` | `[panel3]` | `[panel3]` | `[panel3]` | `[]` |
`[]` | `[]` | `[]` |
| **6** | `[panel3, panel1]` | `[panel3, panel1]` | `[panel2, panel3]` |
`[panel2, panel3]` | `[]` | `[]` | `[]` | `[]` |
| **7** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2]` | `[]` |
`[]` | `[]` | `[]` |
| **8** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2]` | `[]` |
`[]` | `[]` | `[]` |
At this point, all collisions on panel 4 have been resolved. So, in row
6, we see that panels 2 and 1 are now colliding with panel 3 - so, we
push both of them down. At that point, row 6 does not have collisions so
we **don't** push panel 3 down any further - and our layout is resolved!
| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|--------|--------|--------|--------|--------|--------|--------|--------|--------|
| **0** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **1** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **2** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **3** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **4** | `[]` | `[]` | `[]` | `[panel4]` | `[panel4]` | `[panel4]` |
`[panel4]` | `[]` |
| **5** | `[panel3]` | `[panel3]` | `[panel3]` | `[panel3]` | `[]` |
`[]` | `[]` | `[]` |
| **6** | `[panel3]` | `[panel3]` | `[panel3]` | `[panel3]` | `[]` |
`[]` | `[]` | `[]` |
| **7** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2]` | `[]` |
`[]` | `[]` | `[]` |
| **8** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2]` | `[]` |
`[]` | `[]` | `[]` |
| **9** | `[panel1]` | `[panel1]` | `[panel2]` | `[panel2]` | `[]` |
`[]` | `[]` | `[]` |
</details>
</details>
### 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] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
There are no risks to this PR, since all work is contained in the
`examples` plugin.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes: #204206
## Description
Dialog modal visible title should be announced for the users, especially
using assistive technology to know what dialog modal, flyout opened.
## Changes made:
1. The `aria-labelledby` attribute has been added for the mentioned
EuiModal. This change is recommended by the EUI team, see:
https://eui.elastic.co/#/layout/modal for more details
## Screen
<img width="1652" alt="image"
src="https://github.com/user-attachments/assets/28ee1893-3a1e-4a01-af4d-c67b841c12bc"
/>
Part of embeddable rebuild clean-up.
Removes legacy Embeddable class and types from embeddable plugin.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Switch to one matcher w/ all code owner patterns rather than separate
matchers for each code owner pattern. Reduces the run time of
`scripts/check_ftr_code_owners.js` by ~10x.
### Before
```console
▶ node scripts/check_ftr_code_owners.js
info Reading CODEOWNERS file
info Checking ownership for 8653 test files (this will take a while)
info Ownership check complete (took 18.89 s)
succ All test files have a code owner. 🥳
```
#### After
```console
▶ node scripts/check_ftr_code_owners.js
info Checked 8653 test files in 1.59s
succ All test files have a code owner 🥳
```
> A follow-up to #203879
## Summary
This PR integrates the new Assistant Icon, Beacon, and Avatar into
solutions and packages owned by Security. In most cases this was a 1:1
replacement, but in a few, Icon was replaced with Beacon for
consistency, (e.g. welcome screens, upsells, etc)
Note: the scaling of the icon/avatar _before_ was one different from
EUI. The new components match EUI directly and represent a 2x scale
change (e.g. 's' becomes 'l', 'm' becomes 'xl', etc).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of #140695.
We defined the hex codes for anomaly detection severity colors in
several places. This PR consolidates this and makes sure the hex codes
are defined in just one place. Note this PR doesn't change any of the
colors or styling related to anomaly detection, it is pure refactoring
to make future updates to these colors more easy.
- Renames `BLANK` to `UNKNOWN` to be in line with severity labels.
- Uses `ML_SEVERITY_COLORS.*` in test assertions so future color changes
won't need updating every assertion.
- Migrates all SCSS that made use of severity colors to emotion so it
can reuse `ML_SEVERITY_COLORS`. Therefor the SCSS based severity colors
get removed in this PR.
### Checklist
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
Renames `assetInventoryStoreEnabled` -> `assetInventoryUXEnabled`
Follow-up of this PR:
- https://github.com/elastic/kibana/issues/201705
### Motivation
Deviate from `assetInventoryStoreEnabled` which is also used for backend
changes. This gives us more fine-grained control about changes and the
new `assetInventoryUXEnabled` will only be responsible of showing/hiding
the interface.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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)
### Risks
No risk whatsoever
Closes https://github.com/elastic/enhancements/issues/22091
## Summary
The ServiceNow ITSM and SecOps connector for cases now supports the
`Additional fields` JSON field. This is an object where the keys
correspond to the internal names of the table columns in ServiceNow.
## How to test
1. Cases with an existing ServiceNow connector configuration should not
break.
2. The additional fields' validation works as expected.
3. Adding additional fields to the ServiceNow connector works as
expected and these fields are sent to ServiceNow.
Testing can be tricky because ServiceNow ignores additional fields where
the key is not known or the value is not accepted. You need to make sure
the key matches an existing column and that the value is allowed **on
ServiceNow**.
### SecOps
The original issue concerned the fields `Configuration item`, `Affected
user`, and `Location` so these must work.
An example request **for SecOps** with these fields' keys is the
following:
```
{
"u_cmdb_ci": "*ANNIE-IBM",
"u_location": "815 E Street, San Diego,CA",
"u_affected_user": "Antonio Coelho"
}
```
This should result in:
<img width="901" alt="Screenshot 2024-11-27 at 12 52 37"
src="https://github.com/user-attachments/assets/6734a50b-b413-4587-b5e2-2caf2e30ad67">
**The tricky part here is that they should be the names of existing
resources in ServiceNow so the values cannot be arbitrary.**
### ITSM
ITSM fields are different than the ones in SecOps. An example object is:
```
{
"u_assignment_group": "Database"
}
```
This results in:
<img width="1378" alt="Screenshot 2024-11-27 at 13 46 56"
src="https://github.com/user-attachments/assets/8064f882-2ab5-4fd6-b123-90938ab3bb83">
## Release Notes
Pass any field to ServiceNow using the ServiceNow SecOps connector with
a JSON field called "additional fields".
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
