Add importing collaborators to the list of additional items to import (#398154) · Issues · GitLab.org / GitLab

Add importing collaborators to the list of additional items to import

### Release notes In GitLab 15.10 we started mapping GitHub repository collaborators as GitLab project members during GitHub project imports. We received feedback, that this addition led users to confusion and that some GitHub collaborators were unexpectedly added as paid members. We iterated on that changed and added importing collaborators to the list of [additional items to import](https://docs.gitlab.com/ee/user/project/import/github.html#select-additional-items-to-import). This helps users to better understand the implications and choose not to import the collaborators. The checkbox is checked by default. Leaving it checked might result in new users using a seat in the namespace, and being granted permissions [as high as project owner](https://docs.gitlab.com/ee/user/project/import/github.html#collaborators-members). Only direct collaborators are imported. Outside collaborators will never be imported. ## Problem This was initially reported as bug, that uninvited GitHub repository Collaborators were added as members to a private project/namespace on GitLab.com. I leave the bug description below, starting from "Summary" to preserve all the information, but will change the issue to feature enhancement, as after investigation we agreed that importing GitHub collaborators works as intended. However, it's also true that the current bahavior can lead users to confusion and that GitHub collaborators would be added as paid members. ## Proposed solution Solution was proposed by @cervols-ext [here](https://gitlab.com/gitlab-org/gitlab/-/issues/398154#note_1326589002), copying below: We should add importing collaborators to the list of [additional items to import](https://docs.gitlab.com/ee/user/project/import/github.html#select-additional-items-to-import). In the UI it would look like an additional checkbox in the `Advanced import settings` list: ![advanced_import](/uploads/d3757aad9ae2a267bcf8b1498095087c/advanced_import.png) We should have the additional checkbox in the `Advanced import settings` list checked by default. In this case, we will import collaborators by default, but the warning that new users will use a seat in the namespace will still be displayed. And if one doesn't want to import collaborators, they will uncheck the checkbox before importing GitHub repository. Specify the `affiliation` parameter when calling the [List repository collaborators](https://docs.github.com/en/rest/collaborators/collaborators?apiVersion=2022-11-28#list-repository-collaborators) GitHub API endpoint to import only **direct** collaborators who are **not** outside collaborators. This alone would have prevented the original issue described below (in short, the customer was surprised because the additional seats were taken by users outside the organization), and I do not think that outside collaborators should be imported anyway. ## Documentation Make clear in docs and in `Advanced import settings` list next to new checkbox, that leaving this checkbox check will result is new users using a seat in the namespace, and them rights granted can be [as high as project owner](https://docs.gitlab.com/ee/user/project/import/github.html#collaborators-members). Specify that outside collaborators will **not** be imported. ## Technical details When fetching collaborators we should call the GitHub API twice: 1. with specifying the `{ affiliation: 'direct' }` parameter 1. with specifying the `{ affiliation: 'outside' }` parameter and exclude `outside` collaborators from `direct` ones. ------------------------------------------------------ ### Summary A GitLab.com customer raised a ticket as they found uninvited users had been added to their namespace, and were `using a seat`. The root cause was found to be that a project had been imported from GitHub.com, and the importer had automatically mapped GitHub users via public email addresses on Github and on GitLab. ### Steps to reproduce My assumption is: - these accounts had created PRs or issues on GitHub - they had GitLab and GitHub accounts - both accounts had the same email, set public on both platforms The importing user was a owner, but from the docs it seems maintainer would suffice? ### Example Project  ### What is the current *bug* behavior? Users get created and seats taken. Folks could do this by accident by importing a public project with the intent of forking the repository. They're then going to add a bunch of collaborators to their namespace, who I assume will get notified? ### What is the expected *correct* behavior? Customers on GitLab.com expect more control over membership of projects in private groups - both for reasons for security and also because they pay for them. ### Relevant logs and/or screenshots  ### Output of checks    #### Results of GitLab environment info  <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check  <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes

issue