_This issue was drafted by an AI agent from an audit of the board code against the MVC 1 requirements. Please sanity-check the file references and the effort estimate before picking it up._ | Field | Value | |---|---| | **Wiki requirement** | [7.2 and 7.3 Empty States](https://gitlab.com/groups/gitlab-org/plan-stage/product-planning/-/wikis/Home/Product/Feature-Requirements/Boards-2.0/MVC-1) (enabler) | | **Priority (wiki)** | 1️⃣ | | **Estimated effort** | medium | ## Technical Description `board_view.vue`'s template (`:669-729`) only ever renders a loading icon, the horizontal column strip, and the create-work-item modal. Every empty state the list view shows — no results, no work items at all, no projects — is passed into `<list-view>` via slots from `planning_view.vue`, and `<list-view>` is only rendered with `v-if="viewMode !== VIEW_MODE_BOARD"` (`planning_view.vue:2267`). So none of those empty states can reach the board, whatever the condition. The practical effect today: a board with no matching results shows N columns each saying "No items", and a board in a namespace with no work items at all shows exactly the same thing. Neither tells the user what is going on. This issue is the structural fix that the other empty-state issues depend on. Two parts: 1. Pass the same empty-state slots that `<list-view>` receives into `<board-view>`, so the board can render them. 2. Give the board a way to know whether it has zero results across **all** columns, not just per column. This is the real work. Each column owns its own count-only query independently (`column_group.vue:187-231`, variables built in `board/utils.js:46-49`), so nothing today knows whether the whole board is empty. Either hoist the counts up to `board_view.vue` so it can sum them, or add a board-level count query that is not tied to a single column. The empty-state components already exist and are proven in list mode: `EmptyStateWithAnyIssues` and `EmptyStateWithoutAnyIssues`, wired at `planning_view.vue:2300-2363`. `hasWorkItems` and `hasProjects` are already computed on `planning_view.vue` and can be reused. While in this area, also fix one small related bug: the empty group message at `column_group.vue:350-356` is centred horizontally but sits at the top of the column instead of being vertically centred, which wiki 7.1 asks for. Small enough to bundle here. **Out of scope:** the actual conditional rendering of each empty state. Those are separate issues, and the all-groups-hidden state does not depend on this one at all. ## Acceptance Criteria, Requirements, and Resources - [ ] `<board-view>` receives the same empty-state slots that `<list-view>` receives from `planning_view.vue`. - [ ] There is a single, reliable way to determine whether the board has zero results across all visible columns combined, either hoisted counts in `board_view.vue` or a dedicated board-level count query. - [ ] The per-column count query (`column_group.vue:187-231`, `board/utils.js:46-49`) is not broken or needlessly duplicated by the chosen approach. - [ ] The empty group message at `column_group.vue:350-356` is vertically centred within the column, not just horizontally, per wiki 7.1. - [ ] This issue does not change what is rendered for empty or no-results cases yet. It only wires up the plumbing the follow-ups will use. - [ ] This work sits behind the existing `planning_view_boards` feature flag (WIP, default off). **Resources** - Requirements: https://gitlab.com/groups/gitlab-org/plan-stage/product-planning/-/wikis/Home/Product/Feature-Requirements/Boards-2.0/MVC-1 - Designs: https://www.figma.com/design/E97ewgAP2u7CiPSziOEmXs/Work-Items---Boards?node-id=5355-326796 - Prototype: https://need-fang-95158203.figma.site ## Dependencies Blocks the two issues that render the no-results and no-work-items states, both of which need the slots and the board-wide count added here. No backend input needed unless the board-level count requires a new GraphQL query, in which case check with a backend domain expert on the best way to fetch it. #### Is this issue ready? [Definition of Ready](https://handbook.gitlab.com/handbook/engineering/devops/dev/plan/product-planning/how-we-work/#definition-of-ready) - [] The work is described in sufficient detail. A reader without previous context or assumed knowledge is able to understand what work is to be undertaken. What we’re doing and why we’re doing it is described. - [] Acceptance Criteria or Requirements are clearly defined. This should help the assignee understand the scope of the work and verify the intended happy/sad paths are functional and tested. - [] Including the relevant license level and feature flags in the Acceptance Criteria or Requirements is also advised. - [] Other work that blocks or is blocked by the work is linked with the correct relationship. - [] Relevant resources such as designs, documents, and external links are attached. - [] Cross-functional dependencies are described; such as needing to ask for Technical Writing assistance. - [] Documentation that needs to be updated or added is linked. - [] In case of feature development, confirmed with at least one other engineer (preferably a domain expert). - [] In case an item larger than roughly 1 engineer/week, domain expert can provide guidance on breaking down this issue into separate issues (or tasks).