[Feature flag] Cleanup homepage_merge_requests_widget

Summary

This issue tracks cleaning up the homepage_merge_requests_widget feature flag once it has been enabled at 100% on GitLab.com for an appropriate period.

The feature will be productized, not removed. The merge requests widget stays and becomes the default for all users, and the four count cards it replaced get deleted.

Owners

  • Team: Growth (Activation)
  • Most appropriate Slack channel to reach out to: #s_growth
  • Best individual to reach out to: TBD
  • Product Manager: TBD

Stakeholders

  • Support Team: this changes what every signed-in user sees on the homepage at /, so Support should be aware before the flag is removed.
  • Designer: should confirm the final layout once the count cards are gone (see the open question below).

Expectations

What might happen if this goes wrong?

This is the first point at which the change becomes visible to users who never had the flag enabled, because removing the flag makes the widget the default for everyone.

There is no data-loss risk: all of the affected code is read-only rendering.

Once the flag is deleted, rollback is no longer a flag toggle — it would mean reverting the cleanup merge request.

The widget has known latency costs documented in the rollout issue (#631474 (closed)), so the rollout should be confirmed healthy at 100% before the flag is removed.

Cleaning up the feature flag

  • Note that this feature is productized rather than removed: the merge requests widget becomes the default and the four count cards are deleted.
  • Verify there are no external API consumers depending on the flag. This flag is only pushed to the frontend via push_frontend_feature_flag, so this is expected to be a no-op, but confirm.
  • Create a merge request removing the flag: remove all references, remove the YAML definition, and add a changelog entry.
  • Ensure the cleanup merge request is deployed to production and canary: /chatops gitlab run auto_deploy status <merge-commit-of-cleanup-mr>
  • Close the feature issue: #627724 (closed)
  • Delete the flag from all environments: /chatops gitlab run feature delete homepage_merge_requests_widget --dev --pre --staging --staging-ref --production
  • Close the rollout issue: #631474 (closed)

Code to remove

All paths below were verified against master.

Feature flag plumbing

  • config/feature_flags/gitlab_com_derisk/homepage_merge_requests_widget.yml
  • The push_frontend_feature_flag(:homepage_merge_requests_widget, current_user) call in app/controllers/root_controller.rb
  • The same call in app/controllers/dashboard_controller.rb
  • In app/assets/javascripts/homepage/components/homepage_app.vue: the showCountCards computed property, the v-if that uses it, and the skip() handler on both Apollo queries
  • The flag-state describe blocks in spec/frontend/homepage/components/homepage_app_spec.js
  • The flag stubbing in spec/requests/dashboard/homepage_spec.rb

The four count cards, now unreachable

  • In app/assets/javascripts/homepage/components/homepage_app.vue: the four <user-items-count-widget> usages together with their props, the reviewRequestedData / assignedMergeRequestsData / assignedWorkItemsData / authoredWorkItemsData computed properties, the four click handlers, the mergeRequestsHaveError and workItemsHaveError data properties, reloadUserCounts and handleUserCountsVisible, and the two error-text i18n strings
  • app/assets/javascripts/homepage/components/user_items_count_widget.vue and spec/frontend/homepage/components/user_items_count_widget_spec.js — homepage_app.vue is the only consumer
  • app/assets/javascripts/homepage/graphql/queries/merge_requests_widget_metadata.query.graphql and app/assets/javascripts/homepage/graphql/queries/work_items_widget_metadata.query.graphql — also only consumed there
  • The createUserCountsManager, useCachedUserCounts and fetchUserCounts calls in the created() hook. Warning: verify first that the super sidebar's app/assets/javascripts/super_sidebar/components/user_counts.vue still covers this, since it runs the same block independently.
  • The four path keys review_requested_path, assigned_merge_requests_path, assigned_work_items_path and authored_work_items_path in app/controllers/concerns/homepage_data.rb, plus the matching props in homepage_app.vue. Note that merge_requests_dashboard_path then has no remaining caller in that concern.
  • Update spec/controllers/concerns/homepage_data_spec.rb, spec/views/root/_index.html.haml_spec.rb and ee/spec/views/root/_index.html.haml_spec.rb, which assert on those keys.
  • app/views/root/index.html.haml needs no change, because it simply spreads the whole @homepage_app_data hash.

Tracking constants — check before deleting

Only some of these are safe to remove, and this is easy to get wrong. In app/assets/javascripts/homepage/tracking_constants.js:

  • Safe to delete: TRACKING_PROPERTY_AUTHORED_BY_YOU and TRACKING_LABEL_WORK_ITEMS, which only homepage_app.vue uses
  • Must keep: TRACKING_LABEL_MERGE_REQUESTS, TRACKING_PROPERTY_REVIEW_REQUESTED and TRACKING_PROPERTY_ASSIGNED_TO_YOU, because the widget itself still uses them in merge_requests_widget.vue and merge_requests_widget_list.vue

Finally: the translation file locale/gitlab.pot needs regenerating, since the removed cards' strings go away, and the cleanup merge request needs a Changelog: added trailer because this is the change that actually releases the feature to users.

Open question

The page layout was deliberately left alone when the cards were hidden. With the card row gone, the left column now begins at the pick-up, to-do and activity widgets. Whether the grid should change is a design question against the Figma reflow frames, and it should be settled with the designer as part of this cleanup or split into its own issue.

Figma: https://www.figma.com/design/hPe0yrIe65SUQQLkaclkmy/Personal-homepage-near-term-improvements?node-id=1-2