[Visual Refresh] behindText datavis and severity color cleanup#206061
Conversation
9fe0a01 to
a5ce42e
Compare
|
Pinging @elastic/eui-team (EUI) |
a5ce42e to
f47b5d6
Compare
|
Pinging @elastic/fleet (Team:Fleet) |
|
Pinging @elastic/obs-ux-management-team (Team:obs-ux-management) |
|
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
MiriamAparicio
left a comment
There was a problem hiding this comment.
Changes in obs-ux-infra_services LGTM, thanks for the cleanup 🌟
f47b5d6 to
e7478b0
Compare
criamico
left a comment
There was a problem hiding this comment.
I tested Fleet changes locally, LGTM
walterra
left a comment
There was a problem hiding this comment.
ML related changes LGTM, tested the colors on both themes for NER tests.
|
@elasticmachine merge upstream |
|
@elastic/obs-ux-management-team and @elastic/kibana-operations could you have a look as well please? 🙂 |
There was a problem hiding this comment.
This spot seems to have a different way of checking if the theme is indeed Amsterdam.
I can see how these could be equivalent, but it stands out, maybe it's worth following the pattern with others?
There was a problem hiding this comment.
Yeah they mean the same and both have been used, but I agree that it's better to align on one. I'll update to use themeName instead as it's more straight forward. 👍
- reverts Amsterdam colors of previously changed usages by using conditions; uses new available tokens
2ffb37a to
5b09b7d
Compare
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Async chunks
History
|
…ic#206061) ## Summary This PR adds cleanups to previously merged Borealis-related updates to usages of severity colors and/or `behindText` data vis colors as EUI provides matching tokens and initial guidance on usage by now (see point 5) in this [FAQ](elastic#199715 (comment)) for the guidance). These updates ensure that we keep parity for Amsterdam colors by using conditional updates while using semantic tokens for Borealis. >[!NOTE] Please let me know in case your team already made those changes or has other plans for the code. ℹ️ Management changes were done separately by the team itself [here](elastic#206026). --- ### 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/src/platform/packages/shared/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) - [ ] ...
Summary
This PR adds cleanups to previously merged Borealis-related updates to usages of severity colors and/or
behindTextdata vis colors as EUI provides matching tokens and initial guidance on usage by now (see point 5) in this FAQ for the guidance).These updates ensure that we keep parity for Amsterdam colors by using conditional updates while using semantic tokens for Borealis.
Note
Please let me know in case your team already made those changes or has other plans for the code.
ℹ️ Management changes were done separately by the team itself here.
Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
release_note:breakinglabel should be applied in these situations.release_note:*label is applied per the guidelinesIdentify 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.