[UnifiedFieldList] Create high level wrapper components (tmp) #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jughosta
force-pushed
the
145162-ufl-building-block
branch
5 times, most recently
from
4dfe568 to
afdc5bb
Compare
jughosta
force-pushed
the
145162-ufl-building-block
branch
4 times, most recently
from
1c73104 to
7682612
Compare
…astic#160235) Fixes elastic#159879 ## Summary Summarize your PR. If it involves visual changes include a screenshot or gif. ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
# Summary The Stack Monitoring UI had a code path where, when the default alerts were being created it was meant to disable the Elasticsearch Watches that are installed when Internal Collection is enabled. However, a recent support escalation showed that Kibana was calling the wrong Elasticsearch API. Further investigation made the situation worse by highlighting that the API in question had to be invoked on the _**monitored**_ cluster(s), and not the monitoring cluster. To address this short coming, this PR pulls out the code that tried to disable the Watches and instead introduces a UI flow that guides the user to perform this migration before setting up the Kibana rules. The flow now includes a new modal with instructions for why and how to migrate. This modal is shown after the user confirms to create the default rules in the old modal or when clicking "Create default rules" in the top nav. Reworded landing screen modal: <img width="982" alt="Screenshot 2023-06-15 at 21 58 30" src="https://github.com/elastic/kibana/assets/2564140/9ffa3fdc-2c29-4113-938a-cd590e414cfd"> New modal can also be triggered from top nav: <img width="427" alt="Screenshot 2023-06-15 at 21 59 02" src="https://github.com/elastic/kibana/assets/2564140/9bfc8a71-e387-4682-9818-a1fa7474e038"> New modal with migration instructions: <img width="977" alt="Screenshot 2023-06-15 at 21 58 41" src="https://github.com/elastic/kibana/assets/2564140/a8437b23-9bb9-43e7-8ee7-51035c367b0c"> # How to test Start a local Elasticsearch instance, connect Kibana and collect some monitoring data (Internal Collection is quick and easy). Once data is available the modal should open automatically when visiting the Stack Monitoring app. It should be possible to close the modal and have it open again in the next session (tracked in session storage). If the user confirms both modals there should be a toast confirming the creation of the rules and the rules should appear under `Stack Management > Rules`
jughosta
force-pushed
the
145162-ufl-building-block
branch
from
7682612 to
63d0781
Compare
…eate unified field list container building block.
jughosta
force-pushed
the
145162-ufl-building-block
branch
from
63d0781 to
1043d3a
Compare
|
Closing in favor of elastic#160397 |
jughosta
pushed a commit
that referenced
this pull request
Sep 28, 2023
…oper wait logic (elastic#166936) ## Summary Hopefully closes elastic#167104 closes elastic#167130 closes elastic#167100 closes elastic#167013 closes elastic#166964 Fixing a few issues with login/logout: 1. Failed to login in "before" hook <img width="1336" alt="Screenshot 2023-09-25 at 12 37 45" src="https://github.com/elastic/kibana/assets/10977896/e3b2830e-7b0d-4467-9b90-261b385bf71e"> My theory is that we are loading `/login` route too soon while log out was not completed yet. When we navigate to `https://localhost:5620/logout` there are multiple url re-directions with final page being Cloud login form. This PR makes sure we wait for this form to be displayed + 2500 ms extra to avoid "immediate" /login navigation 2. Failed login on MKI: Updating login via UI for serverless to pass password valid for deployment: currently FTR uses `changeme` for both Kibana CI & MKI. 3. ES activate user profile call returning 500 We saw some login failures that are preceded with the following logs: ``` [00:03:27] │ debg Find.clickByCssSelector('[data-test-subj="loginSubmit"]') with timeout=10000 [00:03:27] │ debg Find.findByCssSelector('[data-test-subj="loginSubmit"]') with timeout=10000 [00:03:27] │ debg Find.waitForDeletedByCssSelector('.kibanaWelcomeLogo') with timeout=10000 [00:03:27] │ proc [kibana] [2023-09-19T07:08:26.126+00:00][INFO ][plugins.security.routes] Logging in with provider "basic" (basic) [00:03:27] │ info [o.e.x.s.s.SecurityIndexManager] [ftr] security index does not exist, creating [.security-profile-8] with alias [.security-profile] [00:03:27] │ proc [kibana] [2023-09-19T07:08:26.140+00:00][ERROR][plugins.security.user-profile] Failed to activate user profile: {"error":{"root_cause":[{"type":"validation_exception","reason":"Validation Failed: 1: this action would add [1] shards, but this cluster currently has [27]/[27] maximum normal shards open;"}],"type":"validation_exception","reason":"Validation Failed: 1: this action would add [1] shards, but this cluster currently has [27]/[27] maximum normal shards open;"},"status":400}. [00:03:27] │ proc [kibana] [2023-09-19T07:08:26.140+00:00][ERROR][http] 500 Server Error [00:03:27] │ warn browser[SEVERE] http://localhost:5620/internal/security/login - Failed to load resource: the server responded with a status of 500 (Internal Server Error) ``` User activation happens during `POST internal/security/login` call to Kibana server. ~~The only improvement that we can do from FTR perspective is to call this end-point via API to makes sure user is activated and only after proceed with UI login.~~ While working on issue #4 and talking to @jeramysoucy I believe retrying login via UI will work here as well. We are checking if we are still on login page (similar to incorrect password login), waiting 2500 ms and pressing login button again. 4. Failed to login with Kibana reporting UNEXPECTED_SESSION_ERROR and been re-directed to Cloud login page ``` proc [kibana] [2023-09-25T11:35:12.794+00:00][INFO ][plugins.security.authentication] Authentication attempt failed: UNEXPECTED_SESSION_ERROR ``` Temporary solution is to retry login from scratch (navigation to Kibana login page & re-login ) Flaky-test-runner for functional obtl tests 50x https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3215 This PR is not fixing random 401 response when user navigates to some apps with direct url --------- Co-authored-by: Kibana Machine <[email protected]>
jughosta
pushed a commit
that referenced
this pull request
Jan 16, 2025
…re replacements (elastic#206660) ## Summary Today, when a developer deprecates a feature and replaces its privileges with those of another feature, we reasonably assume that the new feature fully replaces the old one in all possible contexts - whether in role management UIs or in the Spaces feature toggles visibility UI. However, when deprecated privileges are replaced by the privileges of multiple features, such as in [this case](elastic#202863 (comment)) where the Discover/Dashboard/Maps feature privileges are replaced by the privileges of Discover_v2/Dashboard_v2/Maps_v2, respectively, **and** the privileges of the Saved Query Management feature, the choice is ambiguous. Which of these features should be treated as the replacement for the deprecated feature in contexts that deal with entire features (like the Spaces feature toggles visibility UI) rather than individual privileges (like in role management UIs)? Should all referenced features be considered replacements? Or just a subset - or even a single feature? If so, which one? Currently, we treat all referenced features as replacements for the deprecated feature, which creates problems, as described in detail in [this discussion](elastic#202863 (comment)). This PR allows developers to customize this behavior by specifying which features Kibana should treat as direct successors to deprecated features in contexts that deal with whole features rather than individual privileges: ```ts deps.features.registerKibanaFeature({ deprecated: { notice: 'The feature is deprecated because … well, there’s a reason.', --> replacedBy: ['feature_id_v2'], <-- }, id: 'feature_id' name: `Case #4 feature ${suffix} (DEPRECATED)`, … }); ``` ## How to test 1. Run test server ```bash node scripts/functional_tests_server.js --config x-pack/test/security_api_integration/features.config.ts ``` 2. Execute the following request from the Dev Tools (`case_4_feature_a` is a deprecated feature that is replaced by multiple features and **doesn't use** `deprecated.replacedBy`) ```http PUT kbn:/api/spaces/space/default?overwrite=true { "id":"default", "name":"Default", "description":"This is your default space!", "color":"#00bfb3", "disabledFeatures":["case_4_feature_a"], "_reserved":true, "imageUrl":"", "initials":"D" } ``` 3. Observe that in response deprecated `case_4_feature_a` is replaced by two features (you can also check http://localhost:5620/app/management/kibana/spaces/edit/default to see how it's reflected in UI) ```http { "id": "default", "name": "Default", "description": "This is your default space!", "color": "#00bfb3", "initials": "D", "imageUrl": "", "disabledFeatures": [ "case_4_feature_a_v2", "case_4_feature_c" ], "_reserved": true } ``` 4. Execute the following request from the Dev Tools (`case_4_feature_b` is a deprecated feature that is replaced by multiple features, but **uses** `deprecated.replacedBy` to set the conceptual feature-successor) ```http PUT kbn:/api/spaces/space/default?overwrite=true { "id":"default", "name":"Default", "description":"This is your default space!", "color":"#00bfb3", "disabledFeatures":["case_4_feature_b"], "_reserved":true, "imageUrl":"", "initials":"D" } ``` 5. Observe that in response deprecated `case_4_feature_b` is replaced by a single feature (you can also check http://localhost:5620/app/management/kibana/spaces/edit/default to see how it's reflected in UI) ```http { "id": "default", "name": "Default", "description": "This is your default space!", "color": "#00bfb3", "initials": "D", "imageUrl": "", "disabledFeatures": [ "case_4_feature_b_v2" ], "_reserved": true } ``` __Required by:__ elastic#202863 (comment) //cc @davismcphee
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Summarize your PR. If it involves visual changes include a screenshot or gif.
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers