License Management MR widget looks at the forks licenses

  1. Given you have a Project A
  2. And you have a fork of the Project: B
  3. If you create a MR from B to A, the license MR widget will use the license management API of the fork.

This video demonstrates the bug:

bug-complete

The fix is rather simple, as we just have to change this line:

- api_v4_projects_managed_licenses_path(id: merge_request.source_project.id)
+ api_v4_projects_managed_licenses_path(id: merge_request.target_project.id)

and write some regression test for it!


The following discussion from !7411 (merged) should be addressed:

  • @nick.thomas started a discussion: (+2 comments)

    Are we sure the source project is correct? Don't merge requests normally take the settings of the target project as canonical?

    How does this behave at present in the forked-project case, where I'm looking to add something licensed under, say, WTFPL, with an MR from nick.thomas/gitlab-ce to gitlab-org/gitlab-ce ?

    As the submitter of the merge request, can I make WTFPL an approved license for nick.thomas/gitlab-ce, then submit the MR, and so hide the license (which would violate gitlab-org/gitlab-ce requirements) from the acceptor?

Edited Apr 21, 2023 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading