Reorganize okta variables to simplify UI and make agentless the default deployment model#17495
Reorganize okta variables to simplify UI and make agentless the default deployment model#17495
Conversation
…lt deployment model
andrewkroh
added
the
Team:Security-Service Integrations
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
efd6
left a comment
efd6
left a comment
There was a problem hiding this comment.
This is safe; the concern that I do have though is that users who upgrade will no longer see their OAuth2.0 settings because they are now hidden. This may cause them some temporary confusion, though will not be an actual configuration state problem.
@efd6 I am clearly not an expert of the okta integration, the idea was to provide a quickway for user to start and hide as many as possible options to advanced, but if you think oauth2 variables should stay very visible, in may make sense to show them to user, and reorder the variables so they are more visible. |
|
@nchaulet Thanks. I think maybe we want a PM's view. @cpascale43, do you have a view on this? |
|
@efd6 are there any fields that are compulsory? |
|
@nimarezainia I've taken another look and I have concerns about four of the fields being set to advanced, There is a trade-off here, default options that are not shown are unlikely to be revisited. When users hit problems caused by the defaults (in the case of My concern in #17495 (review) still stands, but this is less of an issue than the four fields above. |
thanks @efd6 so let's show these fields as well and not hide them. I think the order should be to have the compulsory fields first and then the rest. Please correct me
If you believe that all the options should be shown then perhaps we can re-arrange where the "Save & Continue" button could go so the average user doesn't have to sit through all the options. @nchaulet that "Change defaults" collapsable needs to be removed also. |
|
I think that order looks good. For the others, it was a flag more than anything. If we see that the concern actually comes about, we can revisit. |
|
@efd6 My concern is now how do we roll this out to other simple integrations in a programmatic fashion. Picking and choosing what fields to expose is very manual and will be different for each integration. Perhaps we are already doing that. is there any merit to do this:
|
|
If "we can re-arrange where the "Save & Continue" button could go" is an option, sure. |
I will do a follow up PR with that, so it will not be collapsable (and remove the label) for single input/datastream integration |
nchaulet
force-pushed
the
feature-okta-integrations-agentless-first
branch
from
417e808 to
d29b3f7
Compare
🚀 Benchmarks reportTo see the full report comment with |
|
@efd6 what it's looks like now 
|
|
@efd6 had a discussion with @jamiehynds about this. He had a good suggestion about modifying this further so that the user chooses how they want to authenticate. Just for illustrative purposes I am showing that below. So After they give us the URL, they click on the Authentication method, we show them the relevant fields for that Authentication method and every other config is hidden in the advanced section. For the most part the user won't change the default settings - at least we want to create efficiency in the happy path here for the user: 
Which fields should be shown for each authentication method? |
|
Just a heads up, with Nicolas out for the next few weeks on PTO, I will take over as the main point of contact and try to get this one across the line as needed. I've added myself as an additional assignee so I (hopefully) dont miss any notifications, but please tag me if needed! Thanks all. |
## Summary Closes elastic/ingest-dev#7185 Related: elastic/ingest-dev#6549 Depends on elastic/package-spec#1120 This PR makes `var_groups` usable everywhere, rather than just at the package root and streams level so that items can be rendered in their appropriate sections (input, etc) and take full advantage of grouping. This will unblock elastic/integrations#17495 and allow us to finalize a draft version of this integration as a poster-child that utilizes `var_groups` for a clean and minimal UI. WIP integration utilizing the var_groups at the input level for grouping based on chosen auth method: <img width="1709" height="1198" alt="image" src="https://github.com/user-attachments/assets/433307f4-dcd6-460f-a34f-2a5fa9dc6c3f" /> ## Testing instructions If you want to manually build an integration and test, please DM me and I will send you detailed instructions or walk you through how to set up a local package-spec and point your elastic-package at it, build it, etc. Im happy to do so, but in the sake of brevity, I will skip that here. The easiest way otherwise is to simply upload this pre-built integration that I built locally using the changes to package-spec: [okta-3.14.2.zip](https://github.com/user-attachments/files/26195499/okta-3.14.2.zip) ### 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) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ... --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
|
Here's how it looks now that the Kibana and spec changes have landed/will land to support If youd like to test this, the changes are in Kibana main, and you can use this package: Let me know if youd like me to spin up a deployment for you! |
…ithub.com/elastic/integrations into feature-okta-integrations-agentless-first
## Summary Closes elastic/ingest-dev#7185 Related: elastic/ingest-dev#6549 Depends on elastic/package-spec#1120 This PR makes `var_groups` usable everywhere, rather than just at the package root and streams level so that items can be rendered in their appropriate sections (input, etc) and take full advantage of grouping. This will unblock elastic/integrations#17495 and allow us to finalize a draft version of this integration as a poster-child that utilizes `var_groups` for a clean and minimal UI. WIP integration utilizing the var_groups at the input level for grouping based on chosen auth method: <img width="1709" height="1198" alt="image" src="https://github.com/user-attachments/assets/433307f4-dcd6-460f-a34f-2a5fa9dc6c3f" /> ## Testing instructions If you want to manually build an integration and test, please DM me and I will send you detailed instructions or walk you through how to set up a local package-spec and point your elastic-package at it, build it, etc. Im happy to do so, but in the sake of brevity, I will skip that here. The easiest way otherwise is to simply upload this pre-built integration that I built locally using the changes to package-spec: [okta-3.14.2.zip](https://github.com/user-attachments/files/26195499/okta-3.14.2.zip) ### 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) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ... --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
|
@Supplementing I got a new deployment and added the integration but don't see your changes there. Is there something else I should be doing to enable it? |
|
Thanks @Supplementing please see the small comments below: We need to remove this empty state all together. Users who need to add an agent have he chance to do so later on: I believe that the API url is mandatory for all options. If so can it be moved up to the top before the Authentication method. So that the user enters all the mandatory fields and can leave the optionals to their default value: 
Remove these extra lines: Granted I put in dummy creds I get this error which I don;t think is related to the creds: Polling interval details are common for all authentication types, can these be in their own section with a header. Just like we have a header for Authentication (see this comment): The other thing missing that was in the original changes by Nicolas, are the step (2) where the user has a back door to change it to Agent-based installation if needed. See the picture in this comment. |
Alright, I spent a little time working on the manifest seeing what was possible with manifest-only changes vs more kibana changes. With the way var_groups work, we cant move the API url above the selector. With the way Kibana renders var_groups, it renders the entire block first, then all the other vars after. We will need Kibana changes for this. As for removing the horizontal lines, same story. Its not controlled by the manifest but a side-effect of how Kibana renders sections for inputs. Finally, as for adding the header above the polling settings, we will also need Kibana changes. This isnt currently supported via the manifest. I explored using the existing header functionality that is exposed by using var_groups, but var_groups enforces a dropdown selector, which we dont want. We cant use just the title header without adding some dropdown. All this being said, I think we can make these changes in one swing in Kibana as just a "visual improvement" PR. I know this is very high priority, so Im happy to carve out a few hours and see if I can get it knocked out if @kpollich agrees. As for the missing section and error, you need to use the |
|
@nimarezainia I spoke with @kpollich a bit on the changes you mentioned and the findings I added above. I have filed a follow up issue here for polishing the UI, please add anything else you see fit there. In the meantime, if the functionality of the package is in line, I think we should move this PR forward so we can go ahead and hand it off to the security team. The Kibana changes/polish should not require any changes to the package, or very minimal at most (probably just the header if we decide to support those more generically). As far as grouping, etc goes, everything else should remain unchanged. We can finalize the UI while the security team decides how they want to structure their integrations. WDYT? |
|
thanks @Supplementing - I will look at the UI issue mentioned. What I ultimately need is a way to show others what we are doing with okta integration and get other teams members to review and agree with the direction before we can get that rolled out. To that end looks like there are some feature flags that need to be enabled. but I will wait fr you to provide a new integration with all the changes discussed. is that fair? |
I think there's a little confusion, the changes remaining will come from the Kibana side (https://github.com/elastic/ingest-dev/issues/7320), the integration in its current state will remain mostly unchanged and once the kibana changes from that issue land, it will just look as expected if that makes sense. The only change that we may need to the integration will be whatever implementation of a header we land on for the polling settings. If you prefer to wait until thats implemented, I understand. The intent was to try to move this PR towards closed if the only thing left was UI polish, but if thats a blocker, let me know. The follow up issue was added/will be added to next iteration, so we will be getting started on it shortly. I expect it to move quickly. |
@Supplementing thank you. let me know when we can show this to the other teams involved. |
|
Quick update, Ive opened another Kibana PR here which adds the section headers, divider toggling, and reorganizing as discussed. I still need to remove the empty state screen @nimarezainia but that is non-blocking and I can do that separately, just wanted to get this done before I go on PTO for the remainder of the week after today. Ive pushed the changes up here to the integration, Ive also uploaded the built integration on that Kibana PR if you prefer to use it directly that way. It doesnt block us, but I will also be opening a package-spec PR in a few minutes as it will be needed for integration developers so that as they develop integrations, they will pass validation. I think we are in pretty decent shape overall. If we need to move things around, that should be fairly trivial, everything we need should now be supported. Let me know what you think! cc @kpollich (adding screenshot here as well just to be safe) 
|
|
Another update, added another PR with some changes to the underlying way we handle rendering the section headers. Also added an updated integration to that PR and pushed up some changes to this PR for testing. Everything should be in sync now and ready for testing. I will also be pushing a commit to that PR in a few minutes that removes the empty state page @nimarezainia |
|
Can we make this a draft until it's ready and has a stack it can run on? |
Done. Ill move it back to ready once everything is finalized and we have a spec release so CI can pass, etc. Sorry for the noise! |
💔 Build Failed
Failed CI StepsHistory
|
…3552) ## Summary This PR goes along with the changes in elastic/integrations#17495 and elastic/package-spec#1133 and allows Kibana to utilize and render `sections` and `section` attributes from a package manifest which allows users to declare section headers with defined order, and then assign variables that belong under each header. Kibana will then render the variables under the headers. The headers are rendered as EuiTitles. We previously added `section_headers` in #262129, but those were deemed too flexible and mixed UI elements with vars, this makes UI elements and vars more distinct and helps keep layouts more intact when users move items around. You may wonder how this differs from the existing `var_groups`, those rely on a EuiSelect, which then renders fields based on the selected option, this allows users to group items that always render, regardless of selected options. If no section is passed, fields will be rendered outside of the section in the order in which they are added to the manifest, in the same way they work before this PR. NOTE: since this work is still underway, and there arent any integrations using any section_headers yet, there is no risk in making this change at this time. cc @jsoriano _Additional (small) change: Removed the 'add your first integration' splash screen for agentless default/preferred integrations. It doesnt make a ton of sense to recommend that the user install elastic agent when the integration is agentless preferred or default. We now check and dont render the splash screen if so_ ## Testing In order to test, simply install this test integration and view the layout [custom_okta-3.14.2.zip](https://github.com/user-attachments/files/26756006/custom_okta-3.14.2.zip) <img width="1708" height="1203" alt="image" src="https://github.com/user-attachments/assets/2e223f75-d9ee-4d2d-b260-2a0cfa32299a" /> ### 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) - [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels. ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ... --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>
#263552) (#265144) # Backport This will backport the following commits from `main` to `9.4`: - [[Fleet] Utilize new `sections` and `section` in integration form (#263552)](#263552) <!--- Backport version: 11.0.1 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Mason Herron","email":"46727170+Supplementing@users.noreply.github.com"},"sourceCommit":{"committedDate":"2026-04-17T20:13:56Z","message":"[Fleet] Utilize new `sections` and `section` in integration form (#263552)\n\n## Summary\n\nThis PR goes along with the changes in\nhttps://github.com/elastic/integrations/pull/17495 and\nhttps://github.com/elastic/package-spec/pull/1133 and allows Kibana to\nutilize and render `sections` and `section` attributes from a package\nmanifest which allows users to declare section headers with defined\norder, and then assign variables that belong under each header. Kibana\nwill then render the variables under the headers. The headers are\nrendered as EuiTitles.\n\nWe previously added `section_headers` in\nhttps://github.com//pull/262129, but those were deemed too\nflexible and mixed UI elements with vars, this makes UI elements and\nvars more distinct and helps keep layouts more intact when users move\nitems around.\n\nYou may wonder how this differs from the existing `var_groups`, those\nrely on a EuiSelect, which then renders fields based on the selected\noption, this allows users to group items that always render, regardless\nof selected options.\n\nIf no section is passed, fields will be rendered outside of the section\nin the order in which they are added to the manifest, in the same way\nthey work before this PR.\n\nNOTE: since this work is still underway, and there arent any\nintegrations using any section_headers yet, there is no risk in making\nthis change at this time. cc @jsoriano\n\n_Additional (small) change: Removed the 'add your first integration'\nsplash screen for agentless default/preferred integrations. It doesnt\nmake a ton of sense to recommend that the user install elastic agent\nwhen the integration is agentless preferred or default. We now check and\ndont render the splash screen if so_\n\n## Testing\n\nIn order to test, simply install this test integration and view the\nlayout\n\n[custom_okta-3.14.2.zip](https://github.com/user-attachments/files/26756006/custom_okta-3.14.2.zip)\n\n\n<img width=\"1708\" height=\"1203\" alt=\"image\"\nsrc=\"https://github.com/user-attachments/assets/2e223f75-d9ee-4d2d-b260-2a0cfa32299a\"\n/>\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [ ] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\n- [ ]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas added for features that require explanation or tutorials\n- [ ] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [ ] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [ ] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [ ] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [ ] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n- [ ] Review the [backport\nguidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)\nand apply applicable `backport:*` labels.\n\n### Identify risks\n\nDoes this PR introduce any risks? For example, consider risks like hard\nto test bugs, performance regression, potential of data loss.\n\nDescribe the risk, its severity, and mitigation for each identified\nrisk. Invite stakeholders and evaluate how to proceed before merging.\n\n- [ ] [See some risk\nexamples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)\n- [ ] ...\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>","sha":"934fead655127259b3eea067943cf19e2c3dd787","branchLabelMapping":{"^v9.5.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:Fleet","backport:version","v9.4.0","v9.5.0"],"title":"[Fleet] Utilize new `sections` and `section` in integration form","number":263552,"url":"https://github.com/elastic/kibana/pull/263552","mergeCommit":{"message":"[Fleet] Utilize new `sections` and `section` in integration form (#263552)\n\n## Summary\n\nThis PR goes along with the changes in\nhttps://github.com/elastic/integrations/pull/17495 and\nhttps://github.com/elastic/package-spec/pull/1133 and allows Kibana to\nutilize and render `sections` and `section` attributes from a package\nmanifest which allows users to declare section headers with defined\norder, and then assign variables that belong under each header. Kibana\nwill then render the variables under the headers. The headers are\nrendered as EuiTitles.\n\nWe previously added `section_headers` in\nhttps://github.com//pull/262129, but those were deemed too\nflexible and mixed UI elements with vars, this makes UI elements and\nvars more distinct and helps keep layouts more intact when users move\nitems around.\n\nYou may wonder how this differs from the existing `var_groups`, those\nrely on a EuiSelect, which then renders fields based on the selected\noption, this allows users to group items that always render, regardless\nof selected options.\n\nIf no section is passed, fields will be rendered outside of the section\nin the order in which they are added to the manifest, in the same way\nthey work before this PR.\n\nNOTE: since this work is still underway, and there arent any\nintegrations using any section_headers yet, there is no risk in making\nthis change at this time. cc @jsoriano\n\n_Additional (small) change: Removed the 'add your first integration'\nsplash screen for agentless default/preferred integrations. It doesnt\nmake a ton of sense to recommend that the user install elastic agent\nwhen the integration is agentless preferred or default. We now check and\ndont render the splash screen if so_\n\n## Testing\n\nIn order to test, simply install this test integration and view the\nlayout\n\n[custom_okta-3.14.2.zip](https://github.com/user-attachments/files/26756006/custom_okta-3.14.2.zip)\n\n\n<img width=\"1708\" height=\"1203\" alt=\"image\"\nsrc=\"https://github.com/user-attachments/assets/2e223f75-d9ee-4d2d-b260-2a0cfa32299a\"\n/>\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [ ] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\n- [ ]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas added for features that require explanation or tutorials\n- [ ] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [ ] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [ ] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [ ] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [ ] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n- [ ] Review the [backport\nguidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)\nand apply applicable `backport:*` labels.\n\n### Identify risks\n\nDoes this PR introduce any risks? For example, consider risks like hard\nto test bugs, performance regression, potential of data loss.\n\nDescribe the risk, its severity, and mitigation for each identified\nrisk. Invite stakeholders and evaluate how to proceed before merging.\n\n- [ ] [See some risk\nexamples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)\n- [ ] ...\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>","sha":"934fead655127259b3eea067943cf19e2c3dd787"}},"sourceBranch":"main","suggestedTargetBranches":["9.4"],"targetPullRequestStates":[{"branch":"9.4","label":"v9.4.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.5.0","branchLabelMappingKey":"^v9.5.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/263552","number":263552,"mergeCommit":{"message":"[Fleet] Utilize new `sections` and `section` in integration form (#263552)\n\n## Summary\n\nThis PR goes along with the changes in\nhttps://github.com/elastic/integrations/pull/17495 and\nhttps://github.com/elastic/package-spec/pull/1133 and allows Kibana to\nutilize and render `sections` and `section` attributes from a package\nmanifest which allows users to declare section headers with defined\norder, and then assign variables that belong under each header. Kibana\nwill then render the variables under the headers. The headers are\nrendered as EuiTitles.\n\nWe previously added `section_headers` in\nhttps://github.com//pull/262129, but those were deemed too\nflexible and mixed UI elements with vars, this makes UI elements and\nvars more distinct and helps keep layouts more intact when users move\nitems around.\n\nYou may wonder how this differs from the existing `var_groups`, those\nrely on a EuiSelect, which then renders fields based on the selected\noption, this allows users to group items that always render, regardless\nof selected options.\n\nIf no section is passed, fields will be rendered outside of the section\nin the order in which they are added to the manifest, in the same way\nthey work before this PR.\n\nNOTE: since this work is still underway, and there arent any\nintegrations using any section_headers yet, there is no risk in making\nthis change at this time. cc @jsoriano\n\n_Additional (small) change: Removed the 'add your first integration'\nsplash screen for agentless default/preferred integrations. It doesnt\nmake a ton of sense to recommend that the user install elastic agent\nwhen the integration is agentless preferred or default. We now check and\ndont render the splash screen if so_\n\n## Testing\n\nIn order to test, simply install this test integration and view the\nlayout\n\n[custom_okta-3.14.2.zip](https://github.com/user-attachments/files/26756006/custom_okta-3.14.2.zip)\n\n\n<img width=\"1708\" height=\"1203\" alt=\"image\"\nsrc=\"https://github.com/user-attachments/assets/2e223f75-d9ee-4d2d-b260-2a0cfa32299a\"\n/>\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [ ] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\n- [ ]\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\nwas added for features that require explanation or tutorials\n- [ ] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [ ] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [ ] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [ ] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [ ] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n- [ ] Review the [backport\nguidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)\nand apply applicable `backport:*` labels.\n\n### Identify risks\n\nDoes this PR introduce any risks? For example, consider risks like hard\nto test bugs, performance regression, potential of data loss.\n\nDescribe the risk, its severity, and mitigation for each identified\nrisk. Invite stakeholders and evaluate how to proceed before merging.\n\n- [ ] [See some risk\nexamples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)\n- [ ] ...\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>","sha":"934fead655127259b3eea067943cf19e2c3dd787"}}]}] BACKPORT--> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>
6 participants
Description
Reorganize okta variables to simplify UI and make agentless the default deployment model
Part of https://github.com/elastic/ingest-dev/issues/6979
Will close https://github.com/elastic/ingest-dev/issues/7534
How it's now rendered in Kibana