Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Detection Engine] EUI Visual Refresh integration and QA #202052

Closed
7 tasks done
yctercero opened this issue Nov 27, 2024 · 7 comments
Closed
7 tasks done

[Detection Engine] EUI Visual Refresh integration and QA #202052

yctercero opened this issue Nov 27, 2024 · 7 comments
Assignees
Labels
8.18 candidate Team:Detection Engine Security Solution Detection Engine Area Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.18.0 v9.0.0

Comments

@yctercero
Copy link
Contributor

yctercero commented Nov 27, 2024

Original Epic: #199715

The EUI team is making updates to EUI that require updates and QA by all Kibana Codeowners. This issue defines the ask for teams and provides a means to track progress.

Key Points

  • Instructions to run Kibana with Borealis are below.
  • Make outlined changes to your codebase.
  • Make changes in main.
  • Label PRs with EUI VIsual Reresh.
  • Please test and ensure your UI looks good in both Borealis and Amsterdam.
  • Update your progress in this issue accordingly.
  • Work with your corresponding Design QA assignee on design questions and final approval.
  • When in doubt, reach out! Direct questions to #eui in Slack.

Requested Code Changes

We are asking all teams to make the following changes to their Kibana UI code. These are not necessarily blockers for the Borealis rollout. However, skipping ones marked as (Important) may result in bugs.

  • (Important) Review usage of "success" colors for positive, semantic intent.(details).
  • (Important) Review and update color palette usage. (details)
  • (Important) Replace vis colors used outside of visualizations with color tokens . (details)
  • (Important) Replace custom colors with semantic tokens (details)
  • (Important) Replace color calculation functions with semantic tokens. (details)
  • Update tokens to use the new naming scheme. (details)
  • Replace euiThemeVars and eui_theme_*.json usage with semantic tokens(details)
    The following

Note:
Throughout this section, tokens are referred to by their root name (e.g. primary). In practice, the primary token exists in Sass as $euiColorPrimary and in Emotion as colors.primary, or could even be passed as prop to an EUI component like color="primary" Keep this in mind for all tokens mentioned below.

💡 Tip:
Many of these changes requires searching for certain text in the code you own. To filter a search in VS Code to just the code you (i.e., a codeowner like security-detection-engine) own, you can try running the following command and then manually pasting it into the "include" box in the VS Code search:

cat .github/CODEOWNERS | grep "security-detection-engine" | cut -d" " -f1 | sed "s@^/@@" | uniq | paste -sd "," - | pbcopy

(Important) Review usage of "success" colors for positive, semantic intent.

(Important): This is marked as important because the "success" color has changed. Things that were meant to appear as teal previously will appear a dark vibrant green. This will likely cause unexpected results.

success and successText have been updated to use a semantic green color, rather than a more subtle teal color.

We would like to reserve the usage of success and successText for semantic use cases, meaning cases that are meant to convey something positive.

We are asking teams to review their usage of the success and successText colors to ensure that they are only using it to convey positive meaning.

Some possibilities to consider:

  • There were cases where success was used simply because it was teal, and teal is one of our brand colors. If that is the case, consider switching to accentSecondary, which is a new token that uses a similar teal. However, accentSecondary should be used sparingly, so consider taking it a step further and switching to something like primary.
  • For buttons, you're likely bet is to switch to primary, or text (gray). accentSecondary should generally not be used on a button.
  • Semantically, components like EuiHealth are never meant to convey anything other than health. Do not switch EuiHealth to use colors like accentSecondary

An example of an affirmative meaning would be this confirmation dialog. This would use the success color:

An example of a non-affirmative meaning would be the background of the "Security" badge. This would use the accentSecondary color, for the teal brand color.

Currently, This doc(Elastic Internal) is the best source for choosing a new token. Scroll down to the "Applying color tokens in product" table. This table can serve as a more comprehensive reference of what colors exist in Borealis: #199715 (comment)

The intent is to use "tokens" that match your intended use case. So rather than selecting an arbitrary color that matches what you had previously, select a "token" that matches how that color is used.

So for instance -- is the color used as a border? You can switch that to something from the borderBase or borderStrong collection -- i.e., euiTheme.colors.borderBase, euiTheme.colors.subdued, etc.

If you give us some more context on the colors you're trying to replace we can help ya pick.

(Important) Review and update color palette usage

(Important): This is marked as important because these colors are now theme aware. Not pulling them from the current them may cause bugs when switching between themes.

All usage of color palette tokens and functions should now be accessed from the EUI theme.

These were not previously part of the theme. This means that they would not change when the theme was changed, they were static. They are now part of the theme and should change when the theme is changed.

This includes any of the color tokens and functions mentioned here: https://eui.elastic.co/#/utilities/color-palettes

A simple test would be to locate your usage of these and use the provided Amsterdam/Borealis toggle to test this whether or not they change.

Vis color tokens (euiColorVis0, euiColorVis1, etc.) are now available through the EUI theme as tokens: euiTheme.colors.vis.*. Please update references to these variables to pull from the theme.

NOTE: _behindText variants of these tokens are no longer included in Borealis. For Borealis you can use the regular vis colors instead now. But for Amsterdam you should use the respective color from euiPaletteColorBlindBehindText() to ensure color parity.

The default visualization colors have been improved in Borealis to ensure the regular vis colors provide enough color contrast, which removes the need for _behindText variants.

theme.eui.euiColorVis0_behindText  -> isAmsterdam ? euiPaletteColorBlindBehindText()[0] : euiTheme.colors.vis.euiColorVis0

If you were using any of our color palette functions:

  • either ensure the color palette function is called inside a React component under the EuiProvider context and is hence connected to rerender (called on rerender or connected to a state)
  • otherwise if it’s used outside of the EuiProvider context you can use the new EUI_VIS_COLOR_STORE.subscribe() function to listen to changes and update usages manually
const storeId = EUI_VIS_COLOR_STORE.subscribe(
  VIS_COLOR_STORE_EVENTS.UPDATE,
  () => {
    setPalette(euiPaletteColorBlind());
  }
);

(Important) Replace vis colors used outside of visualizations with color tokens

(Important): This is marked as important because the visualization colors have changed. If you were using these colors for things outside of visualizations, you will likely now have unexpected results. For example, these are commonly used to show severity levels, if you had been doing this previously, your UI will no longer appear as expected.

Data visualization colors provided by EUI should be reserved for just that, data visualization. It is important to limit their usage so that we can iterate on these colors in the future without unintentionally affecting other UI.

https://eui.elastic.co/#/utilities/color-palettes

euiColorVis0
euiColorVis1
euiColorVis2
euiColorVis3
euiColorVis4
euiColorVis5
euiColorVis6
euiColorVis7
euiColorVis8
euiColorVis9

For example: A number of places in Kibana use euiColorVis0 to style something with a teal color. Please discontinue doing this and use accentSecondary instead. If you are using vis colors like this, please change to use another color token from EUI.

Currently, This doc(Elastic Internal) is the best source for choosing a new token. Scroll down to the "Applying color tokens in product" table. This table can serve as a more comprehensive reference of what colors exist in Borealis: #199715 (comment)

The intent is to use "tokens" that match your intended use case. So rather than selecting an arbitrary color that matches what you had previously, select a "token" that matches how that color is used.

So for instance -- is the color used as a border? You can switch that to something from the borderBase or borderStrong collection -- i.e., euiTheme.colors.borderBase, euiTheme.colors.subdued, etc.

If you give us some more context on the colors you're trying to replace we can help ya pick.

(Important) Replace custom colors with semantic tokens

(Important): This is marked as important because there is a high likelyhood that custom colors will no longer look correct in relation to the new Borealis color palette.

We are asking all teams to remove all hardcoded color values (i.e., any CSS color defined explicitly rather than using an EUI token) when adopting the color changes defined in this document. This could be a hex, rgb, hsl, etc.

To facilitate detecting instances where custom colors are used within the code an eslint rule as been prepared for this, it is currently set to provide warning to developers during development, this same rule can however be leverage to detect occurrences that declare custom colors at a go, by run lint targeting the directory of interest and setting the rule to raise it's report as an error like so;

yarn lint:es <path/to/directory/to/evaluate> --rule '@kbn/css/no_css_color: error'

Edit (@rylnd): I ended up doing:

for path in $(cd ${KIBANA_HOME} && cat .github/CODEOWNERS | grep "security-detection-engine" | cut -d" " -f1 | sed "s@^/@@" | uniq); do
  yarn lint:es $path --rule '@kbn/css/no_css_color: error'
done

This would return a familiar output of files that contain code that declares custom colors that needs to be attended to.

It's worth mentioning that instances where some component receives a prop that is then passed as a custom color will not be caught by this lint rule, the onus is on the developer to deter from such patterns.

Note that there are certain cases where it's totally acceptable to have custom color values. SVG source that you paste into a file, for instance.

NOTE: Kibana will soon include a lint rule for this: #200703

Currently, This doc(Elastic Internal) is the best source for choosing a new token. Scroll down to the "Applying color tokens in product" table. This table can serve as a more comprehensive reference of what colors exist in Borealis: #199715 (comment)

The intent is to use "tokens" that match your intended use case. So rather than selecting an arbitrary color that matches what you had previously, select a "token" that matches how that color is used.

So for instance -- is the color used as a border? You can switch that to something from the borderBase or borderStrong collection -- i.e., euiTheme.colors.borderBase, euiTheme.colors.subdued, etc.

If you give us some more context on the colors you're trying to replace we can help ya pick.


For some additional context on this change -- The EUI team hopes to iterate on color faster in the future. In order to do so, it is imperative teams strive to use EUI tokens for colors exclusively.

Hardcoded colors create issues when we iterate on the Kibana UI as a whole -- they break the system. By consistently using color tokens from the EUI library, we enable seamless updates and iterations on colors without requiring additional work from Kibana teams. With this approach, we can update a single token in EUI, and the color change will automatically apply across all of Kibana.

The EUI team is fundamentally changing the library by adding a comprehensive suite of Semantic Tokens. A semantic token is defined as such:

Semantic tokens in design systems are a type of design token that provide context and guidance on how to use them. They are named based on their purpose or meaning within the user interface (UI), rather than their appearance.

A practical example of this can be seen by looking at our shade colors. The naming of these tokens is based on their appearance -- dark. light, darkest, etc. We have deprecated many of these tokens in favor of tokens that are based on usage -- "border", "background", etc. This will be a key concept that allows us to iterate and evolve the Kibana UI over time -- cleanly and easily.

This same concept flows through to component customizations as well. In order for the EUI team to modernize UI at an atomic level (buttons, inputs, forms, layout, etc.), we will be asking teams to clean up CSS customizations to these elements as well. We realize that this is a big ask, but it is an important one. Simply put, if you are applying custom styles to our components, we are not able to update them without breaking UI.

(Important) Replace color calculation functions with semantic tokens

(Important): This is marked as important because there is a high likelyhood that these color calculation functions will no longer produce a result that will look correct in relation to the new Borealis color palette.

EUI provides color utility functions. Please discontinue use of these and replace them with an EUI color token. These will be deprecated as they create unpredictable results.

shade()
tint()
shadeOrTint()
tintOrShade()
transparentize()

Currently, This doc(Elastic Internal) is the best source for choosing a new token. Scroll down to the "Applying color tokens in product" table. This table can serve as a more comprehensive reference of what colors exist in Borealis: #199715 (comment)

The intent is to use "tokens" that match your intended use case. So rather than selecting an arbitrary color that matches what you had previously, select a "token" that matches how that color is used.

So for instance -- is the color used as a border? You can switch that to something from the borderBase or borderStrong collection -- i.e., euiTheme.colors.borderBase, euiTheme.colors.subdued, etc.

If you give us some more context on the colors you're trying to replace we can help ya pick.

Update tokens to use the new naming scheme

Many of our old tokens have been renamed, and we're asking folks to simply update their usage to use the new names.

Realistically, we could probably do one big find/replace PR, but if you're able to handle these while you're making other changes, that would be great. Otherwise, we'll probably do a follow up to catch everything in bulk afterwards.

# previous color token -> new color token
primaryText -> textPrimary
accentText -> textAccent
between this and textSuccess.
warningText -> textWarning
dangerText -> textDanger
text -> textParagraph
title -> textHeading
subduedText -> textSubdued
disabledText -> textDisabled
successText -> textSuccess

Replace euiThemeVars and eui_theme_*.json usage with semantic tokens

JSON tokens exported by EUI are being deprecated for usages in React components, and we need to start replacing them with semantic tokens from the EUI theme. We would appreciate it if teams could spend some time migrating away from these.

Please discontinue use of these and replace them with a token from our theme context.

ℹ If you're using the JSON tokens in a static non-react context (e.g. server-side), it is expected to keep using the JSON tokens and no update is needed.

JSON tokens are anything from:

@elastic/eui/dist/eui_theme_amsterdam_light.json
@elastic/eui/dist/eui_theme_amsterdam_dark.json
@elastic/eui/dist/eui_theme_borealis_light.json
@elastic/eui/dist/eui_theme_borealis_dark.json
import { euiThemeVars } from '@kbn/ui-theme'

For example:
https://github.com/elastic/kibana/blob/main/packages/kbn-visualization-ui-components/components/dimension_buttons/palette_indicator.tsx#L32

Before:

import { EuiIcon, EuiCode, EuiText, useEuiTheme } from '@elastic/eui';
...
height: ${euiThemeVars.euiSizeXS} / 2;

After:

import { useEuiTheme } from '@elastic/eui'
....
const { euiTheme } = useEuiTheme();
...
height: ${euiTheme.size.xs} / 2;

[!IMPORTANT]
See the tables in this comment when mapping from old tokens to new. (e.g. from euiSizeXS to size.xs)

A note for folks using the styled syntax

If you are replacing usage of euiThemeVars within the styled syntax from @emotion/styled, it may look something like this:

Before:

const LogStreamContainer = styled.div`
  display: flex;
  background-color: ${euiThemeVars.euiColorEmptyShade};
`;

After:

const LogStreamContainer = styled.div`
  display: flex;
  background-color: ${props => props.theme.euiTheme.colors.emptyShade};
`;

If you see type errors related to props.theme, you may have to set up an emotion.d.ts

Here's some guidance related to that, plucked from our Emotion FAQ:

Please note, that if you encounter type errors with the theme parameter inside of the css function, you'll need to make your Plugin is set up to use Kibana's emotion.d.ts file.

To do this, add in the aforementioned emotion.d.ts with it's path relative to location of the typings directory as the value of the include property for the tsconfig.json file that exists within your plugin.
file for your Kibana plugin for the parameter in css functions to be properly typed as EUI's theme. See the osquery plugin for an example of their tsconfig setup.

[!IMPORTANT]
Please use this table as point of reference when migrating import { euiThemeVars } from '@kbn/ui-theme' to the useEuiTheme() theme hook.

If a token might be missing or unfitting for your use case, please reach out to the EUI team in the #eui slack channel.
We'll update this list as needed.

@yctercero yctercero added 8.18 candidate Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Detection Engine Security Solution Detection Engine Area v8.18.0 v9.0.0 labels Nov 27, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detection-engine (Team:Detection Engine)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

@rylnd rylnd self-assigned this Dec 2, 2024
@rylnd
Copy link
Contributor

rylnd commented Dec 11, 2024

Okay, I've encountered my first ambiguity:

Image

On the MITRE ATT&CK® coverage page(s), the heatmap/main color is, correctly, accentSecondary. However, the (highlighted) "progress" indicators are success colored. From a "progression/gamification" perspective the success makes sense, but when the rest of the page is accentSecondary and success is only used on text, it looks more like an inconsistency than an indicator of progress.

cc @ARWNightingale would you be able to weigh in here? From the inciting epic's story, here's the EUI guideline:

Another question to ask yourself to make this determination could be -- "If I swap this for a blue or gray, would it still work?". If so, the you likely want accentSecondary. If being "green" is a key part of this UI, then you likely want success.

@dplumlee
Copy link
Contributor

@rylnd I believe this is how the designs were initially written out with the heatmapping colors being it's own style on the page (it's one color with differing levels of opacity). I do see what you're getting at though, I wonder if it's more prevalent here because most of the page uses the alternative color scheme - I don't really have a strong opinion one way or the other. @ARWNightingale would be able to give a more complete reason and potential solution.

@ARWNightingale
Copy link

Hey @rylnd thanks for looking at this, It was intentional to have these separated as EUI recommends. I agree it does look slightly odd, but Im not considering it harmful to the UX, my understanding is that we should keep text in that separate colour. It will be consistent with all other text too. In the Borealis theme I does look strange but we just need to keep copy consistent. Does that help?

Image

@rylnd
Copy link
Contributor

rylnd commented Dec 16, 2024

@ARWNightingale yes, 100%, thank you for the response!

rylnd added a commit that referenced this issue Jan 23, 2025
## Summary

This is the first batch of work involving
#202052. It includes the
following tasks:

- [x] (Important) Review usage of "success" colors for positive,
semantic
intent.([details](#202052 (comment))).
- [x] (Important) Review and update color palette usage.
([details](#color-palettes))
- [x] (Important) Replace vis colors used outside of visualizations with
color tokens .
([details](#202052 (comment)))
- [x] (Important) Replace custom colors with semantic tokens
([details](#202052 (comment)))
- [x] (Important) Replace color calculation functions with semantic
tokens.
([details](#202052 (comment)))
- [x] Update tokens to use the new naming scheme.
([details](#202052 (comment)))

### What changed?
Broadly, these changes involve two main areas: Exception Lists and the
Rule Creation form (specifically: the EQL query bar and the "time"
inputs (Suppression Duration, Interval, Lookback)).

I also found an unused component, and fixed a minor UI bug with
Exception Comments.

Screenshots (before and after, and with both themes) are included below.

Also: as a majority of these components' usage of theme variables is
done with `@styled-components`, and we are transitioning away from that
toward `@emotion`, I also opted to remove usages of `@styled-components`
wherever possible, as that change was negligible in comparison with the
theming changes. If a file being changed included references to static
eui theme variables, e.g. `euiThemeVars`, those were removed as well
(but many are still outstanding).


### Screenshots

__NOTE__: Most of the "Before" screenshots were taken from a cluster
using the Borealis theme.

<details>
  <summary>
    <h3>Rule Exceptions Tab</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Rule Exceptions - Before"
src="https://github.com/user-attachments/assets/56feb5e8-b5ec-4bdc-9372-968056e6bca3"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Rule Exceptions - After (Amsterdam)"
src="https://github.com/user-attachments/assets/a6ab3d47-acc7-4eb6-8a0c-bd9ccafc2021"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Rule Exceptions - After (Borealis)"
src="https://github.com/user-attachments/assets/9fbd8a17-0afb-4ccc-95ea-5bab4da5b254"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>Shared Exception Lists</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Shared Exception Lists - Before"
src="https://github.com/user-attachments/assets/b2a69f9c-4892-4732-a2e1-e167461680d1"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Shared Exception Lists - After (Amsterdam)"
src="https://github.com/user-attachments/assets/1aea0dff-97ee-4482-9a66-38c4be2baea8"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Shared Exception Lists - After (Borealis)"
src="https://github.com/user-attachments/assets/76be9446-17fb-451d-b15a-99166cb1f588"
/>
  </kbd>
</details>

<details>


  <summary>
    <h3>Shared List Details</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Shared List Details - Before"
src="https://github.com/user-attachments/assets/5eeec91d-ea96-4e3c-8c7d-b5e6bb8bf35a"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Shared List Details - After (Amsterdam)"
src="https://github.com/user-attachments/assets/5229b850-356c-40e7-80f1-d32156f97a56"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Shared List Details - After (Borealis)"
src="https://github.com/user-attachments/assets/81219613-c329-48f8-8fd3-857207d0ada0"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>EQL Query Input</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="EQL Bar - Before"
src="https://github.com/user-attachments/assets/b19cf18b-a5d2-4001-bebc-9154af8e9b43"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="EQL Bar - After (Amsterdam)"
src="https://github.com/user-attachments/assets/70911ad2-9e52-4b65-b305-cd90a6be1fd2"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="EQL Bar - After (Borealis)"
src="https://github.com/user-attachments/assets/92a789d0-fffa-483c-bcb2-fc02b5e8ce10"
/>

  </kbd>
</details>


<details>
  <summary>
    <h3>Suppression Fields</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="Suppression Fields - Before"
src="https://github.com/user-attachments/assets/458c3464-0eba-47d4-abbe-8de0b333b8ec"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="Suppression Fields - After (Amsterdam)"
src="https://github.com/user-attachments/assets/b6fb67b0-7908-4fe8-9e02-d9e14c8f97c5"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="Suppression Fields - After (Borealis)"
src="https://github.com/user-attachments/assets/f48c24a5-50ea-41fd-af45-b3d32f20921b"
/>

  </kbd>

</details>

<details>
  <summary>
    <h3>Suppression Fields (Disabled)</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="Suppression Fields (Disabled) - Before"
src="https://github.com/user-attachments/assets/e60aa561-d8ce-4b23-8694-e6443ad37c16"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="Suppression Fields (Disabled) - After
(Amsterdam)"
src="https://github.com/user-attachments/assets/45277962-482d-484c-b8bd-3a587b7c16d1"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="Suppression Fields (Disabled) - After (Borealis)"
src="https://github.com/user-attachments/assets/69f6217b-a2c2-4c6a-be9e-80dfd0a4e5f1"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>Exception Comments UI Bug</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="805" alt="Comments UI Bug - Before"
src="https://github.com/user-attachments/assets/652d35fa-8ff2-4850-a9a4-79cec3b4b698"
/>

  </kbd>
  <kbd>
    <h3>After</h3>
<img width="805" alt="Comments UI Bug - After"
src="https://github.com/user-attachments/assets/a8cc1cd6-b25f-4694-a479-c35f45eae6aa"
/>

  </kbd>
</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

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
qn895 pushed a commit to qn895/kibana that referenced this issue Jan 23, 2025
## Summary

This is the first batch of work involving
elastic#202052. It includes the
following tasks:

- [x] (Important) Review usage of "success" colors for positive,
semantic
intent.([details](elastic#202052 (comment))).
- [x] (Important) Review and update color palette usage.
([details](#color-palettes))
- [x] (Important) Replace vis colors used outside of visualizations with
color tokens .
([details](elastic#202052 (comment)))
- [x] (Important) Replace custom colors with semantic tokens
([details](elastic#202052 (comment)))
- [x] (Important) Replace color calculation functions with semantic
tokens.
([details](elastic#202052 (comment)))
- [x] Update tokens to use the new naming scheme.
([details](elastic#202052 (comment)))

### What changed?
Broadly, these changes involve two main areas: Exception Lists and the
Rule Creation form (specifically: the EQL query bar and the "time"
inputs (Suppression Duration, Interval, Lookback)).

I also found an unused component, and fixed a minor UI bug with
Exception Comments.

Screenshots (before and after, and with both themes) are included below.

Also: as a majority of these components' usage of theme variables is
done with `@styled-components`, and we are transitioning away from that
toward `@emotion`, I also opted to remove usages of `@styled-components`
wherever possible, as that change was negligible in comparison with the
theming changes. If a file being changed included references to static
eui theme variables, e.g. `euiThemeVars`, those were removed as well
(but many are still outstanding).


### Screenshots

__NOTE__: Most of the "Before" screenshots were taken from a cluster
using the Borealis theme.

<details>
  <summary>
    <h3>Rule Exceptions Tab</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Rule Exceptions - Before"
src="https://github.com/user-attachments/assets/56feb5e8-b5ec-4bdc-9372-968056e6bca3"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Rule Exceptions - After (Amsterdam)"
src="https://github.com/user-attachments/assets/a6ab3d47-acc7-4eb6-8a0c-bd9ccafc2021"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Rule Exceptions - After (Borealis)"
src="https://github.com/user-attachments/assets/9fbd8a17-0afb-4ccc-95ea-5bab4da5b254"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>Shared Exception Lists</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Shared Exception Lists - Before"
src="https://github.com/user-attachments/assets/b2a69f9c-4892-4732-a2e1-e167461680d1"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Shared Exception Lists - After (Amsterdam)"
src="https://github.com/user-attachments/assets/1aea0dff-97ee-4482-9a66-38c4be2baea8"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Shared Exception Lists - After (Borealis)"
src="https://github.com/user-attachments/assets/76be9446-17fb-451d-b15a-99166cb1f588"
/>
  </kbd>
</details>

<details>


  <summary>
    <h3>Shared List Details</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Shared List Details - Before"
src="https://github.com/user-attachments/assets/5eeec91d-ea96-4e3c-8c7d-b5e6bb8bf35a"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Shared List Details - After (Amsterdam)"
src="https://github.com/user-attachments/assets/5229b850-356c-40e7-80f1-d32156f97a56"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Shared List Details - After (Borealis)"
src="https://github.com/user-attachments/assets/81219613-c329-48f8-8fd3-857207d0ada0"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>EQL Query Input</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="EQL Bar - Before"
src="https://github.com/user-attachments/assets/b19cf18b-a5d2-4001-bebc-9154af8e9b43"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="EQL Bar - After (Amsterdam)"
src="https://github.com/user-attachments/assets/70911ad2-9e52-4b65-b305-cd90a6be1fd2"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="EQL Bar - After (Borealis)"
src="https://github.com/user-attachments/assets/92a789d0-fffa-483c-bcb2-fc02b5e8ce10"
/>

  </kbd>
</details>


<details>
  <summary>
    <h3>Suppression Fields</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="Suppression Fields - Before"
src="https://github.com/user-attachments/assets/458c3464-0eba-47d4-abbe-8de0b333b8ec"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="Suppression Fields - After (Amsterdam)"
src="https://github.com/user-attachments/assets/b6fb67b0-7908-4fe8-9e02-d9e14c8f97c5"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="Suppression Fields - After (Borealis)"
src="https://github.com/user-attachments/assets/f48c24a5-50ea-41fd-af45-b3d32f20921b"
/>

  </kbd>

</details>

<details>
  <summary>
    <h3>Suppression Fields (Disabled)</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="Suppression Fields (Disabled) - Before"
src="https://github.com/user-attachments/assets/e60aa561-d8ce-4b23-8694-e6443ad37c16"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="Suppression Fields (Disabled) - After
(Amsterdam)"
src="https://github.com/user-attachments/assets/45277962-482d-484c-b8bd-3a587b7c16d1"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="Suppression Fields (Disabled) - After (Borealis)"
src="https://github.com/user-attachments/assets/69f6217b-a2c2-4c6a-be9e-80dfd0a4e5f1"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>Exception Comments UI Bug</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="805" alt="Comments UI Bug - Before"
src="https://github.com/user-attachments/assets/652d35fa-8ff2-4850-a9a4-79cec3b4b698"
/>

  </kbd>
  <kbd>
    <h3>After</h3>
<img width="805" alt="Comments UI Bug - After"
src="https://github.com/user-attachments/assets/a8cc1cd6-b25f-4694-a479-c35f45eae6aa"
/>

  </kbd>
</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

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
JoseLuisGJ pushed a commit to JoseLuisGJ/kibana that referenced this issue Jan 27, 2025
## Summary

This is the first batch of work involving
elastic#202052. It includes the
following tasks:

- [x] (Important) Review usage of "success" colors for positive,
semantic
intent.([details](elastic#202052 (comment))).
- [x] (Important) Review and update color palette usage.
([details](#color-palettes))
- [x] (Important) Replace vis colors used outside of visualizations with
color tokens .
([details](elastic#202052 (comment)))
- [x] (Important) Replace custom colors with semantic tokens
([details](elastic#202052 (comment)))
- [x] (Important) Replace color calculation functions with semantic
tokens.
([details](elastic#202052 (comment)))
- [x] Update tokens to use the new naming scheme.
([details](elastic#202052 (comment)))

### What changed?
Broadly, these changes involve two main areas: Exception Lists and the
Rule Creation form (specifically: the EQL query bar and the "time"
inputs (Suppression Duration, Interval, Lookback)).

I also found an unused component, and fixed a minor UI bug with
Exception Comments.

Screenshots (before and after, and with both themes) are included below.

Also: as a majority of these components' usage of theme variables is
done with `@styled-components`, and we are transitioning away from that
toward `@emotion`, I also opted to remove usages of `@styled-components`
wherever possible, as that change was negligible in comparison with the
theming changes. If a file being changed included references to static
eui theme variables, e.g. `euiThemeVars`, those were removed as well
(but many are still outstanding).


### Screenshots

__NOTE__: Most of the "Before" screenshots were taken from a cluster
using the Borealis theme.

<details>
  <summary>
    <h3>Rule Exceptions Tab</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Rule Exceptions - Before"
src="https://github.com/user-attachments/assets/56feb5e8-b5ec-4bdc-9372-968056e6bca3"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Rule Exceptions - After (Amsterdam)"
src="https://github.com/user-attachments/assets/a6ab3d47-acc7-4eb6-8a0c-bd9ccafc2021"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Rule Exceptions - After (Borealis)"
src="https://github.com/user-attachments/assets/9fbd8a17-0afb-4ccc-95ea-5bab4da5b254"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>Shared Exception Lists</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Shared Exception Lists - Before"
src="https://github.com/user-attachments/assets/b2a69f9c-4892-4732-a2e1-e167461680d1"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Shared Exception Lists - After (Amsterdam)"
src="https://github.com/user-attachments/assets/1aea0dff-97ee-4482-9a66-38c4be2baea8"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Shared Exception Lists - After (Borealis)"
src="https://github.com/user-attachments/assets/76be9446-17fb-451d-b15a-99166cb1f588"
/>
  </kbd>
</details>

<details>


  <summary>
    <h3>Shared List Details</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1594" alt="Shared List Details - Before"
src="https://github.com/user-attachments/assets/5eeec91d-ea96-4e3c-8c7d-b5e6bb8bf35a"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="805" alt="Shared List Details - After (Amsterdam)"
src="https://github.com/user-attachments/assets/5229b850-356c-40e7-80f1-d32156f97a56"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="805" alt="Shared List Details - After (Borealis)"
src="https://github.com/user-attachments/assets/81219613-c329-48f8-8fd3-857207d0ada0"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>EQL Query Input</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="EQL Bar - Before"
src="https://github.com/user-attachments/assets/b19cf18b-a5d2-4001-bebc-9154af8e9b43"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="EQL Bar - After (Amsterdam)"
src="https://github.com/user-attachments/assets/70911ad2-9e52-4b65-b305-cd90a6be1fd2"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="EQL Bar - After (Borealis)"
src="https://github.com/user-attachments/assets/92a789d0-fffa-483c-bcb2-fc02b5e8ce10"
/>

  </kbd>
</details>


<details>
  <summary>
    <h3>Suppression Fields</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="Suppression Fields - Before"
src="https://github.com/user-attachments/assets/458c3464-0eba-47d4-abbe-8de0b333b8ec"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="Suppression Fields - After (Amsterdam)"
src="https://github.com/user-attachments/assets/b6fb67b0-7908-4fe8-9e02-d9e14c8f97c5"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="Suppression Fields - After (Borealis)"
src="https://github.com/user-attachments/assets/f48c24a5-50ea-41fd-af45-b3d32f20921b"
/>

  </kbd>

</details>

<details>
  <summary>
    <h3>Suppression Fields (Disabled)</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="1085" alt="Suppression Fields (Disabled) - Before"
src="https://github.com/user-attachments/assets/e60aa561-d8ce-4b23-8694-e6443ad37c16"
/>

  </kbd>
  <kbd>
    <h3>After (Amsterdam)</h3>
<img width="1085" alt="Suppression Fields (Disabled) - After
(Amsterdam)"
src="https://github.com/user-attachments/assets/45277962-482d-484c-b8bd-3a587b7c16d1"
/>

  </kbd>
  <kbd>
    <h3>After (Borealis)</h3>
<img width="1085" alt="Suppression Fields (Disabled) - After (Borealis)"
src="https://github.com/user-attachments/assets/69f6217b-a2c2-4c6a-be9e-80dfd0a4e5f1"
/>

  </kbd>
</details>

<details>
  <summary>
    <h3>Exception Comments UI Bug</h3>
  </summary>
  <kbd>
    <h3>Before</h3>
<img width="805" alt="Comments UI Bug - Before"
src="https://github.com/user-attachments/assets/652d35fa-8ff2-4850-a9a4-79cec3b4b698"
/>

  </kbd>
  <kbd>
    <h3>After</h3>
<img width="805" alt="Comments UI Bug - After"
src="https://github.com/user-attachments/assets/a8cc1cd6-b25f-4694-a479-c35f45eae6aa"
/>

  </kbd>
</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

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
@rylnd
Copy link
Contributor

rylnd commented Feb 13, 2025

I'm closing this now that all of the required work is complete. I've created #211119 to capture the remaining references to styled-components, but besides a final QA of 9.0 this should be complete.

@rylnd rylnd closed this as completed Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.18 candidate Team:Detection Engine Security Solution Detection Engine Area Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.18.0 v9.0.0
Projects
None yet
Development

No branches or pull requests

5 participants