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. 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.
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, copying below:
We should add importing collaborators to the list of additional items to import. In the UI it would look like an additional checkbox in the Advanced import settings
list:
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 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.
Specify that outside collaborators will not be imported.
Technical details
When fetching collaborators we should call the GitHub API twice:
- with specifying the
{ affiliation: 'direct' }
parameter - 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
Expand for output related to GitLab environment info
(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`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(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)