[Fleet] Add support for section headers, divider toggling, and reorganization#1133
Merged
teresaromero merged 12 commits intoelastic:mainfrom Apr 21, 2026
Merged
Conversation
Supplementing
changed the title
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Fleet UI grouping features to manifests: a top-level ordered ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
test/packages/good_var_groups/manifest.yml (1)
1-1:⚠️ Potential issue | 🔴 CriticalBump this fixture’s
format_versionto 3.7.0.Line 1 declares
format_version: 3.6.0, but Line 18 (section_header) and Line 127 (show_divider) are introduced behind 3.7.0 gating in this PR. This makes agood_*fixture invalid for its declared version.Proposed fix
-format_version: 3.6.0 +format_version: 3.7.0Based on learnings: Version patches enable backward compatibility by removing features from older spec versions.
Also applies to: 17-19, 127-127
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/packages/good_var_groups/manifest.yml` at line 1, Update the manifest's declared spec version by changing the format_version value from 3.6.0 to 3.7.0 so the fixture matches the features used; specifically ensure the top-level format_version entry (format_version) is updated because this fixture uses 3.7-only elements like section_header and show_divider.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@test/packages/good_var_groups/manifest.yml`:
- Line 1: Update the manifest's declared spec version by changing the
format_version value from 3.6.0 to 3.7.0 so the fixture matches the features
used; specifically ensure the top-level format_version entry (format_version) is
updated because this fixture uses 3.7-only elements like section_header and
show_divider.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 49547d84-d358-4225-86c5-1957681aaae8
📒 Files selected for processing (4)
spec/changelog.ymlspec/integration/data_stream/manifest.spec.ymlspec/integration/manifest.spec.ymltest/packages/good_var_groups/manifest.yml
teresaromero
previously approved these changes
Apr 14, 2026
jsoriano
requested changes
Apr 14, 2026
Member
There was a problem hiding this comment.
Hey, sorry for chiming it a bit late.
I think current proposal is good, but I have some concerns, specially about section_header:
- It overloads the meaning of
type, it starts containing UI elements apart from actual data types. - How would it work once we start composing lists of variables (elastic/elastic-package#3279).
- It can be error prone, a developer may reorder some variable, without taking into account the section it belongs to. Sections depend too much on the order.
- In general we may be mixing too much variable definition with its representation.
What do you think about an alternative approach to solve this? Instead of a section_header variable type, we could:
- Add a top-level
sectionslist to define the section headers, with any specific metadata they may need, and their display order. - Add a
section: <section_name>attribute to individual variables to assign them to a specific group.
This would keep the type field strictly focused on data types rather than presentation, and would be more explicit on what variables belong to each section.
What do you think?
(Requesting changes only to discuss this alternative option, again, sorry for chiming in late 🙏)
Contributor
Author
Yeah, I agree with your points. In hindsight, I think the implementation is a bit to flexible and could allow the user to move things around without realizing what they are doing fully. I like the idea of a sections list and using the attributes on the variables to link them to the sections. However, the issue is now that the Kibana PR has been merged so we will need to circle back and open another PR to address the changes. Not a biggie though, and since all this is ongoing and packages havent been released anyway, theres no churn to really worry with. I can start working on making changes on this PR then open a follow up PR in Kibana to utilize the changes. |
Member
Yeah, I think it is worth to do it at this point as this hasn't been used yet in actual packages.
Great, thanks! |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@code/go/internal/validator/semantic/validate_sections.go`:
- Around line 70-77: The current semantic validator only checks sections/vars
within each Streams entry but skips top-level (root) sections/vars in data
stream manifests defined by sectionsDataStreamManifest, so undefined references
and duplicate section names at the root scope are not validated; update the
validator (the code that currently iterates streams[*].Sections and
streams[*].Vars — look for methods like validateSections/validateVars or the
loop processing Streams) to also process and validate the root-level Sections
and Vars fields on sectionsDataStreamManifest: treat them the same as per-stream
sections (check for duplicate manifestSection.Name and undefined section
references in sectionsVar.Section), and apply the same error reports and
handling used for stream-scoped validation (also ensure similar changes are
applied for the other occurrences noted around lines 101-116).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 30139830-6578-4e93-b26b-82fbac063932
⛔ Files ignored due to path filters (4)
test/packages/bad_sections_duplicate_name/img/sample-logo.svgis excluded by!**/*.svgtest/packages/bad_sections_duplicate_name/img/sample-screenshot.pngis excluded by!**/*.pngtest/packages/bad_sections_undefined_ref/img/sample-logo.svgis excluded by!**/*.svgtest/packages/bad_sections_undefined_ref/img/sample-screenshot.pngis excluded by!**/*.png
📒 Files selected for processing (17)
code/go/internal/validator/semantic/validate_sections.gocode/go/internal/validator/semantic/validate_sections_test.gocode/go/internal/validator/spec.gocode/go/pkg/validator/validator_test.gospec/changelog.ymlspec/input/manifest.spec.ymlspec/integration/data_stream/manifest.spec.ymlspec/integration/manifest.spec.ymltest/packages/bad_sections_duplicate_name/LICENSE.txttest/packages/bad_sections_duplicate_name/changelog.ymltest/packages/bad_sections_duplicate_name/docs/README.mdtest/packages/bad_sections_duplicate_name/manifest.ymltest/packages/bad_sections_undefined_ref/LICENSE.txttest/packages/bad_sections_undefined_ref/changelog.ymltest/packages/bad_sections_undefined_ref/docs/README.mdtest/packages/bad_sections_undefined_ref/manifest.ymltest/packages/good_var_groups/manifest.yml
✅ Files skipped from review due to trivial changes (8)
- test/packages/bad_sections_undefined_ref/docs/README.md
- test/packages/bad_sections_duplicate_name/docs/README.md
- test/packages/bad_sections_undefined_ref/changelog.yml
- code/go/pkg/validator/validator_test.go
- test/packages/bad_sections_duplicate_name/changelog.yml
- spec/changelog.yml
- test/packages/bad_sections_duplicate_name/manifest.yml
- test/packages/bad_sections_undefined_ref/manifest.yml
🚧 Files skipped from review as they are similar to previous changes (3)
- test/packages/good_var_groups/manifest.yml
- spec/integration/manifest.spec.yml
- spec/integration/data_stream/manifest.spec.yml
10 tasks
jsoriano
reviewed
Apr 17, 2026
…an be ignored, also dropped validator back and test packages
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
test/packages/good_var_groups/manifest.yml (1)
16-19:⚠️ Potential issue | 🟠 MajorVersion mismatch in this “good” fixture for new fields.
This manifest uses
sectionsandshow_dividerbut still declaresformat_version: 3.6.0(Line 1). If these features are intended for 3.7.0, this fixture should be bumped accordingly.Minimal fix
-format_version: 3.6.0 +format_version: 3.7.0Based on learnings, “Adjust
format_versionand modify manifest.yml in test packages to test specific fields after creation with elastic-package.”Also applies to: 26-49, 133-133
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/packages/good_var_groups/manifest.yml` around lines 16 - 19, The manifest declares format_version: 3.6.0 but uses newer fields like sections and show_divider that require 3.7.0; update the manifest's format_version value to 3.7.0 (and any other test fixtures flagged similarly) so the file’s format_version matches the used fields (look for format_version, sections, show_divider in manifest.yml to locate and change).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@spec/integration/manifest.spec.yml`:
- Around line 589-615: Add version-gating patches to remove the new "sections"
object and the "show_divider" property from older manifest versions (create a
"before: 3.7.0" removal entry under versions) so older formats won't accept
these fields; centralize the repeated "show_divider" schema into a single
reusable definition (e.g., a top-level "definitions" or "components" entry named
"show_divider") and replace all inline "show_divider" property blocks with a
$ref to that definition (update every occurrence referenced in the review: the
sections items, and the other locations flagged around the file). Ensure the
removal patches run before the definitions they depend on and reference the
exact property names "sections" and "show_divider" so the version patches and
$ref substitutions are applied consistently.
---
Duplicate comments:
In `@test/packages/good_var_groups/manifest.yml`:
- Around line 16-19: The manifest declares format_version: 3.6.0 but uses newer
fields like sections and show_divider that require 3.7.0; update the manifest's
format_version value to 3.7.0 (and any other test fixtures flagged similarly) so
the file’s format_version matches the used fields (look for format_version,
sections, show_divider in manifest.yml to locate and change).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f31aa247-f786-4e3a-9cf5-61c3d7beaa4d
📒 Files selected for processing (7)
code/go/internal/validator/spec.gospec/input/manifest.spec.ymlspec/integration/data_stream/manifest.spec.ymlspec/integration/manifest.spec.ymltest/packages/bad_sections_duplicate_name/manifest.ymltest/packages/bad_sections_undefined_ref/manifest.ymltest/packages/good_var_groups/manifest.yml
✅ Files skipped from review due to trivial changes (3)
- spec/input/manifest.spec.yml
- test/packages/bad_sections_duplicate_name/manifest.yml
- test/packages/bad_sections_undefined_ref/manifest.yml
🚧 Files skipped from review as they are similar to previous changes (2)
- code/go/internal/validator/spec.go
- spec/integration/data_stream/manifest.spec.yml
jsoriano
reviewed
Apr 17, 2026
| items: | ||
| $ref: "#/definitions/package_dependency" | ||
| show_divider: | ||
| description: When false, suppresses the automatic horizontal divider rendered after this section. |
Member
There was a problem hiding this comment.
Is this a property related to sections or to inputs?
Suggested change
| description: When false, suppresses the automatic horizontal divider rendered after this section. | |
| description: When false, suppresses the automatic horizontal divider rendered after the configuration UI for this input. |
Contributor
Author
There was a problem hiding this comment.
'Section' is used loosely here, it means section in terms of the section of inputs in the UI. If you look at this screenshot, its the divider(s) at the bottom after 'advanced options'
Co-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>
Co-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>
Supplementing
added a commit
to elastic/kibana
that referenced
this pull request
Apr 17, 2026
…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>
mrodm
reviewed
Apr 20, 2026
….com/Supplementing/package-spec into integration-form-layout-improvements
Supplementing
dismissed stale reviews from teresaromero and jsoriano
via
dbc6b1c
mrodm
approved these changes
Apr 20, 2026
💚 Build Succeeded
History
|
teresaromero
approved these changes
Apr 21, 2026
teresaromero
added a commit
that referenced
this pull request
Apr 21, 2026
Prepares the 3.6.1 package-spec release: finalizes spec/changelog.yml, points latest-stack compliance CI at spec 3.6.1, refreshes the Go patch in .go-version, and updates AGENTS.md examples to match. Follow-up commits on this branch also: Move the Fleet UI enhancements from PR #1133 into the 3.6.1 changelog (top-level sections / per-var section, and show_divider on inputs). Remove @Skip from the OTel dynamic_signal_types dataset compliance scenarios in compliance/features/dataset.feature so those scenarios run again.
Supplementing
added a commit
to elastic/kibana
that referenced
this pull request
Apr 22, 2026
#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>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
What does this PR do?
This PR is part of the Kibana changes in elastic/kibana#262129. It adds support for section headers (which allow Kibana to render arbitrary EuiTitles), support for divider visibility toggles, and better control over ordering of fields when using var groups
Why is it important?
With the introduction of var_groups, there was a lot of constraints around the layout, we needed to give the integration developers a little more control at the manifest level to impact how things show up at the Kibana level.
Checklist
test/packagesthat prove my change is effective.spec/changelog.yml.Related issues
Relates elastic/kibana#262129
Relates elastic/integrations#17495
commit message: added support for sections and divider toggling