Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
tails
tails
Commits
d7689ee9
Commit
d7689ee9
authored
Mar 29, 2020
by
intrigeri
Browse files
GitLab: specify projects/repositories access control management
parent
daf0f383
Changes
1
Hide whitespace changes
Inline
Side-by-side
wiki/src/blueprint/GitLab.mdwn
View file @
d7689ee9
...
...
@@ -405,6 +405,29 @@ Properties:
- [forking workflow](https://docs.gitlab.com/ce/user/project/merge_requests/authorization_for_merge_requests.html#forking-workflow)
- regular Tails contributors have "Reporter" access
## Management
With Redmine + Gitolite, we centrally manage, in 1-2 single places, team
membership and the corresponding access level. For example, when someone gets
commit access or joins a team, we add them to the corresponding Gitolite group
and Redmine role. That's very convenient.
If we don't do anything special, to implement the access control specified
above, we would need to:
* During the migration to GitLab: give dozens of users "Reporter", "Maintainer"
or "Developer" access on dozens of project.
* Day-to-day operations: occasionally, give someone "Reporter", "Maintainer" or
"Developer" access on dozens of project.
I don't think we want to do any of this manually.
It seems we could maintain user groups via the GitLab web interface and [share
the relevant projects with these user
groups](https://docs.gitlab.com/ce/user/project/members/share_project_with_groups.html).
These groups would not contain any project themselves: their sole purpose is to
manage access to projects in batch.
# Wiki
It's out of scope for the first iteration but at some point, we might
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment