Convert blocking MR form params to booleans

What does this MR do and why?

Saving the merge request edit form deleted every blocking merge request the author has no access to. Nothing showed it happening — inaccessible dependencies only ever appear as an aggregate "N inaccessible merge requests" token — so there was no way to notice or undo it.

The form posts update_blocking_merge_request_refs and remove_hidden_blocking_merge_requests as the strings "true"/"false", and every String is truthy in Ruby, so the two guards in MergeRequests::UpdateBlocksService always read as true. Both now coerce with Gitlab::Utils.to_boolean(..., default: false). The GraphQL mutation already passes real booleans, so it is unaffected.

References

Screenshots or screen recordings

Before After

How to set up and validate locally

  1. Requires a Premium or Ultimate license and a non-admin user (an admin can read every merge request, so nothing is ever "hidden" for them).

  2. In a rails console, create a dependency from a merge request the user can edit onto a merge request in a private project the user is not a member of:

    blockee = Project.find_by_full_path('flightjs/Flight').merge_requests.find_by(iid: 3)
    blocker = Project.find_by_full_path('reviews/downstream-pipeline').merge_requests.opened.first
    
    MergeRequestBlock.create!(
      blocking_merge_request: blocker,
      blocked_merge_request: blockee,
      project: blockee.project
    )
  3. Sign in as that non-admin user and open the merge request's Edit page. The Merge request dependencies field shows a 1 inaccessible merge request token.

  4. Save the form without touching that field.

  5. Before this change the dependency is gone (MergeRequestBlock.where(blocked_merge_request: blockee).count, or reload the edit page). With this change it is still there.

  6. Removing the token on purpose and saving still deletes it.

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 Anna Vovchenko

Merge request reports

Loading
Loading