Support #7804
closed
Les permissions associées à un rôle sont-elles configurables ?
0%
Description
Comme indiqué dans #7801, quand on fait un projet privé, on est obligé de configurer "à la main" les permissions des membres du groupe sur les forks privés. A cet occasion, je me suis rendu compte qu'avec les permissions standards attachées aux différents rôles, il faut donner le rôle développeur à quelqu'un pour qu'il puisse créer un merge request sur le fork privé. Et du coup, il a aussi le droit de l'accepter, de créer des branches...
Est-il possible de changer la configuration par défaut pour qu'un reporter puisse faire un merge request sur un fork privé (un repo pour lequel il a le rôle reporter) sans pour autant pouvoir l'accepter ou écrire quoi que ce soit dans ce repo. Le use case est le suivant, lié au workflow "peer review" :
- X fait un développement et créé un merge request pour le repo du projet
- Y fait un peer review du merge request et souhaite y apporter des modifications significatives, pour lesquelles le commentaire n'est pas approprié : il récupére donc la branche source du merge request, fait des modifs (ajoute des commits).
- Pour que ses modifs soient intégrées au MR original (celui créé par X), il fait un merge request sur le fork privé de X (vers la branche correspondant à la source du MR).
- X analyse le MR de Y (sur sa branche privée) et l'accepte
- Les modifs de Y font maintenant partie du merge request de X contre le repo du projet.
Related issues
Updated by Brétel Foudil over 10 years ago
- Related to Support #7801: Le fork privé d'un projet appartenant à un groupe n'est pas accessible en lecture aux membres du groupe added
Updated by Brétel Foudil over 10 years ago
- Status changed from New to Closed
Pour répondre directement à la question: non, les permissions ne sont pas configurables
Je comprends l'utilisation des MR comme un système de code review. Et je comprends aussi mieux la motivation de #7801.
Le workflow que tu décris ressemble à celui-ci.
On voit bien le conflit entre:
- chacun forke le dépôt de référence, on peut alors utiliser les MR, mais pas voir les forks des copains
- ou bien travailler tous sur le dépôt de référence, avec plusieurs branches, mais sans pouvoir faire de MR.
Pour travailler sur un code commun, sur lequel tous les membres du groupe peuvent intervenir, tout en bénéficiant du code review, peut-être qu'une solution est d'utiliser un seul repo, plusieurs branches, les commentaires sur les commits, et les feeds (https://gitlab.in2p3.fr/dashboard.atom).
Peut-être aussi que ce genre de problématiques se posera moins avec des plusieurs niveaux de projets: VOTE!
N'hésite pas à ré-ouvrir le ticket si nécessaire.
Updated by Jouvin Michel over 10 years ago
Désolé d'une réaction si tardive... C'est un peu compliqué de débattre du modèle DVCS contre repository unique avec des branches par développeur. Mais en résumé, pour moi le modèle proposé par GitLab d'un repo avec des branches cachées est un hack qui enlève essentiellement tous les bénéfices d'un DVCS. En particulier associé à un outil comme GitHub ou GitLab... A savoir qu'on a pas besoin de donner un accès en écriture au repo principal à tous les contributeurs. Et que personne ne travaille directement dans le repo principal : on y fait que des merges via GitLab donc cela réduit bcp les risques de fausses manips.
Michel
Updated by Brétel Foudil over 10 years ago
Je me demande si le problème n'est pas inhérent à la nature privée des dépôts dont on parle.
Oui sur github notre expérience est différente parce que tous les dépôts sont publics.
Il faudrait en fait permettre une sorte d'héritage des droits du projet d'origine vers les projets forkés.
Je crois que c'est ce dont il est question dans:
http://feedback.gitlab.com/forums/176466-general/suggestions/5760385-forks-should-inherit-permissions-from-parent-proje
Vote!
Je crois aussi que c'est dépendant de la gestion des orgqnisations/teams. Cf. http://feedback.gitlab.com/forums/176466-general/suggestions/3867903-allow-project-groups-to-be-organized-in-a-hierarch