I suggest you ...

More flexible permission system

The permission scheme is simple, but often not enough.

* Five permissions and the possibility to lock branches.

It would be great to give users/teams the possibility to commit on locked braches.

219 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Admin →

    21 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Michael Härtl commented  · 

        @gitlab I see that voting is closed. What does this mean? Why is there no more feedback on the status of this suggestion?

      • Michael Härtl commented  · 

        We also have the problem that the current permission system is not fine grained enough.

        We develop an application for a customer. The customer is the project owner and thus should be able to manage issues, assign them to milestones and attach and create labels. But customer should *not* have access to our source code.

        I know, there's a dirty workaround to create a dedicated separate repository only for issues. But this is ugly, because now you have to bloat your commit messages with full repo paths.

        So basically what we need is to be able to edit the matrix shown in the help page for permissions.

      • Toby Mole commented  · 

        I have a use case where I'd like to be able to grant a customer user the ability to create and comment on issue AND download the project but NOT close or manage issues.

      • fbender commented  · 

        Owners, masters, and developers (the latter can be activated via checkbox in the protected branches settings in at least 7.11) can push to protected branches. What else do you need?

      • Victor Seager commented  · 

        Agreed - massive must. Needed to give access to external outside of our company when working in collaboration on a project to be able to raise a MR without giving full developer rights. Custom roles would be ideal, but at minimum a 'Contributor' role would work.

      • Kyrill Poole commented  · 

        We're in the same situation as many other people - for "customers", the "Guest" permission set is enough, but for the next level down - Project Managers, etc, the "Reporter" set isn't enough as they also need to be able to modify and manage issues, labels, milestones and so on.

        To that end, I end up having to pull the relevant permissions out of the "Developer" set and stick them in "Reporter" on every Gitlab upgrade, which is sub-optimal.

        It would be great if the permissions could be moved into the DB and thus made more mutable.

      • Brian Vanderbusch commented  · 

        In my mind, the biggest problem is this:

        I have a group, with say 50 members. The only way to give group members the ability to create projects within the group namespace, also means they can push to protected branches in any of the groups projects.

        No bueno.

      • Andrey Andreev commented  · 

        This is a must IMO, and having it even at a configuration file level would be of great help.

        My immediate use case for it is described in the comment link below (*), but even that is just what I'm having as a problem and I, as much as everybody else, would deffinately enjoy the ability to have more refined permission levels.

        The current hard-coded set of permissions are nice for gitlab.com as an online service, but it's rather a compromise where it is run privately.
        Not all companies and workflows are the same, they all have specific needs and I'd argue that the lack of customizable permissions is a deal-breaker for many.
        It is also a must because of GitLab's greatest strength - the tight coupling between code repositories and issue tracking. Companies moving to GitLab would usually migrate from having the two as separate services and while commit permissions are straightforward to transfer, issue trackers are different beasts and basing issue/milestone on commit access levels is ... well, ugly.

        * https://github.com/gitlabhq/gitlabhq/pull/7285#issuecomment-48571710

      • Mike Bevi commented  · 

        UPDATE: Experiment is a success, I reccomend anyone with a similar issue to myself look at my earlier post.

      • AdminGitLab team (Admin, Gitlab) commented  · 

        Mike, good luck on your experiment. Making the permission system customization would have major consequences for the technical architecture, the ui, the security tests and the documentation.

      • Mike Bevi commented  · 

        I think that is a better idea than the "super branch" , (ツ), . hmmm, you last response got me thinking... I can have developers create new projects in their namespace. when they feel that they are at a spot that they woudl share it with the group they can request a fork. I can fork their project to the group where I would be owner and they are already desiganted as developers. At that point their work is no longer done from their namspace. It's not an elegant solution but I think it woudl fit my needs. Im going to try this approach out with the team, Ill share any success or drawbacks I see, but this might be a solution for some other folks posting here as well. Thanks so much for your time and sorry if I hijakced this suggestion for the past few days. I still do think that git lab might still benifit form a more flexible permisions system. Perhaps at the "help: Permission Help" page you could allow the user to interact with the permission table. Allow them to click on a cell to choose which permission would be associated with which level of users. Yes, there are not as many permission choices as some other hosts and potentially the admin coudl completely ruin a proper git hierarchy of users, but just allowing this flexibility might help many of us out. Thanks again

      • AdminGitLab team (Admin, Gitlab) commented  · 

        Why not let your developers fork the project to the personal namespace and have them send MR's from there to your upstream master branch?

      • katafrakt commented  · 

        After looking into the code I started to wonder if it woudn't be enough to move ability definitions to a separate YAML file, loaded at application start. An example file would contain current abilities but it would make it easy to add new roles and alter their permissions. Would that solution be acceptable by the core team?

      • Andrew Meyer commented  · 

        Agreed, a custom roles system would be great.

      ← Previous 1

      Feedback and Knowledge Base