## Problem The Geo Sites dashboard shows one row per replicable, per site. Today all uploads are one `Uploads` row. &20933 replaced the single upload replicator with 23 per-partition replicators. When #589924 enables their feature flags, that one row becomes 23 rows per site, multiplied by the number of secondary sites. This is not visible yet because #591685 hides disabled replicables, and the 23 flags are still off. The problem appears when the flags are enabled, so it is a direct consequence of #589924. The dashboard was already considered too crowded at 17 replicables, tracked in #415837. Adding 22 more makes it hard for an administrator to read the state of a site at a glance. The number of database tables does not have to match the number of rows an administrator sees. Splitting the tables was an internal change. Administrators still think in terms of "uploads". ## Proposal Group the upload partitions into one `Uploads` row in the dashboard, expandable to show the individual partitions. Do the grouping in the frontend. Do not aggregate anything in the backend. This keeps the backend unchanged, so rollout and rollback stay per replicator. Disabling one partition flag removes it from `Gitlab::Geo.replication_enabled_replicator_classes`, its counts stop being emitted, and the group simply renders one fewer child. There is no derived state and no server-side sum that can disagree with the per-partition numbers. ## Implementation notes **Backend, one small change.** The frontend needs to know which replicables belong together. The existing `data_type` key is too coarse, because all blob replicables share it. Add a field such as `replicable_group` to `replicable_class_data` in `ee/app/helpers/ee/geo_helper.rb`. Derive it from the replicator rather than a hardcoded list of names. The upload partition replicators all include `Geo::Concerns::UploadReplicatorBehavior`, so that inclusion can drive the value. This keeps the field correct if partitions are added or removed later. This change is stateless. No summing, and no new notion of "enabled". **Frontend.** Extend the existing store and reuse the existing components. The dashboard already has a two-level grouping concept for `data_type`, in `ee/app/assets/javascripts/geo_sites/store/getters.js` (`dataTypes`, `replicationCountsByDataTypeForSite`), so this follows an established pattern rather than introducing a new one. Compute the group figures client-side from the enabled children. Reuse the existing presentation components: - `geo_site_progress_bar.vue` and `stacked_progress_bar.vue` for the rolled-up figure - `geo_site_replication_sync_percentage.vue` for the percentage - `geo_site_replication_details_responsive.vue`, `geo_site_replication_status.vue` and `geo_site_replication_status_mobile.vue` for the row layout No new visual design is needed. This issue deliberately reuses existing patterns so it does not depend on design capacity. **No backend reporting changes.** `GeoNodeStatus`, the Geo Node Status API, GraphQL, and `geo:status` keep their current per-partition output. Support engineers and scripts keep full granularity. ## Dual-run behaviour, needs a decision During #589924 Phase 1 the legacy `Upload` replicator and the partitions are enabled at the same time. Running both is supported, see #594675. The legacy replicable is also titled `Uploads`, so during dual-run the page would show a legacy `Uploads` row and an `Uploads` group. That is confusing. Two options: 1. Hide the group until the legacy replicator is disabled. 1. Give the group a distinct title while the legacy replicator is enabled. Option 1 is simpler and matches the hide-disabled behaviour already in place. Worth confirming before implementation. ## Acceptance criteria - [ ] The Geo Sites page shows one `Uploads` row per site, collapsed by default. - [ ] Expanding the row shows the individual upload partitions with their existing per-partition figures. - [ ] Group figures are calculated from the enabled partitions only. - [ ] Disabled partitions stay hidden, preserving the behaviour from #591685. - [ ] If no upload partitions are enabled, no `Uploads` group is shown. - [ ] Works on the primary and secondary site views, and on desktop and mobile. - [ ] Resync and reverify remain available on the individual partitions. - [ ] No changes to `GeoNodeStatus`, the Geo Node Status API, GraphQL, or `geo:status`. - [ ] `Gitlab::Geo.replication_enabled_replicator_classes` is unchanged and still returns all 23. - [ ] Dual-run behaviour matches whichever option is chosen above. ## Out of scope - Grouping any replicables other than the upload partitions. - Any change to backend reporting or aggregation. - The full dashboard redesign (#415837, &16588). ## Follow-up to note Each partition keeps its own replicable detail page, so per-partition detail stays reachable. But once the legacy `Upload` replicator is disabled, `/admin/geo/sites/:id/replication/uploads` no longer resolves, because that route is generated from `replicable_name_plural` of an enabled replicator. Bookmarked links would break. Decide whether to redirect it to one of the partitions, or accept the change. This does not block this issue.