Add SectionHeader as a panel-level section to the dashboard framework

What does this MR do and why?

Adds a SectionHeader — a section heading that separates groups of panels within a dashboard. It is not a dashboard header, which is why it was renamed from Header / HeaderVisualization to SectionHeader partway through.

A panels entry in a dashboard config can now be either a normal Panel or a SectionPanel. A SectionPanel is rendered by its own section_header.vue component in place of analytics_dashboard_panel.vue, so it gets no panel border, no horizontal padding, and its own popover.

Design notes:

  • Panel-level section rather than a visualization type. The alternative was declaring visualization: { type: SectionHeader } on a normal panel. Rejected because the border and horizontal padding come from the panel and can't be removed without changing GlDashboardPanel in gitlab-ui, and because a section's config would end up split across two levels — title and tooltip as panel fields, description as a visualization option.
  • Cost of this approach: panels now holds two shapes, so consumers have to branch on panel.section. Today that's the loader and the #panel slot in details.vue. SectionGridAttributes also duplicates GridAttributes with a different required list.
  • Section grid attributes only require xPos, yPos and height. A section always spans the full dashboard width, so its config omits a width and dashboard_loader.vue's assignPanelIds fills in the new FULL_DASHBOARD_WIDTH constant.
  • Found a GlPopover bug while building this: :target="() => $refs.tooltipIcon?.$el" never resolves, because children mount before parents, so the ref is undefined when the popover evaluates it. Fixed by giving the icon a string id built with uniqueId(...) in data() — unique because one dashboard can render several sections — and targeting the popover at that id. Covered by a spec asserting findPopover().props('target') === findTooltipIcon().attributes('id').

No built-in dashboard declares a section yet. The change wiring one into ee/lib/gitlab/analytics/dashboards/system/duo_and_sdlc_trends.yaml was deliberately reverted out of this MR so it stays framework-only — see the YAML snippet below to try it locally.

References

Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/605725

Screenshots or screen recordings

How to set up and validate locally

  1. Storybook: yarn storybook:start, open the SectionHeader stories under analytics/analytics_dashboards/components/section_header, and step through them. Check the heading renders with no border and no horizontal padding, and that the tooltip icon's popover opens.

  2. In-dashboard check: add the following to the top of the panels: list in ee/lib/gitlab/analytics/dashboards/system/duo_and_sdlc_trends.yaml, then increment every existing panel's gridAttributes.yPos in that file by 1 — the section occupies row 0, so without the bump the section and the first row of panels overlap:

    - section:
        title: "Adoption tiers"
        description: "How platform engagement is distributed across all users in the last 30 days"
        tooltip:
          title: "Adoption tiers"
          description: "All Duo users grouped by their total sessions across every activity in the period: Light 1–4, Regular 5–24, Heavy 25–99, Power 100+. A session is any agentic session, regardless of capability."
      gridAttributes:
        yPos: 0
        xPos: 0
        height: 1

    Load the GitLab Duo and SDLC trends dashboard and confirm the section renders full width above the first row of panels, with no panel chrome around it.

  3. Jest: VUE_VERSION=3 yarn jest spec/frontend/analytics/analytics_dashboards/components/section_header_spec.js spec/frontend/explore/analytics_dashboards/pages/details_spec.js

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Ezekiel Kigbo

Merge request reports

Loading
Loading