Loading
Add the Policy Store Build step's building blocks
What does this MR do and why?
Adds the components the Build policy step composes, each with a focused spec — extracted ahead of the step itself so the step's MR reviews as wiring rather than five components at once:
| Piece | Job |
|---|---|
serializer.js |
Form state { type, value }, actions flat — matching what EE::Ci::ProcessBuildService reads back |
catalog_group.vue |
One category of the drawer's catalog; owns the hover state for the info affordance |
builder_section.vue |
One section of the policy being built: entries with joiner badges and expandable configuration, or an add button when empty. Selection and expansion state stay with the caller, so the step's "newly added entries auto-expand" behaviour remains possible |
utils.js (groupCatalogItems) |
Pure function grouping a catalog for the drawer: search (via searchInItemsProperties), category order, label resolution, and a Custom fallback. A category the order does not know sorts last with its raw id as label rather than disappearing |
BUILD_TAB_* |
Tab ids join editor/constants.js |
Nothing mounts any of this yet — no behaviour change on master until the step lands.
Second of a three-MR chain extracted from !247891 (merged):
- !248392 (merged) — catalog categories (this MR's target; retarget to
masterwhen it merges) - This MR — building blocks
- !247891 (merged) — the Build policy step itself (all UI, screenshots there)
References
Screenshots or screen recordings
No UI change. These components are unreachable until !247891 (merged) wires them into the wizard.
How to set up and validate locally
yarn jest ee/spec/frontend/policy_store/components/editor35 tests across the four new suites.
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.