I suggest you ...

Add a role for customers

We would like to allow customers in GitLab, only has a guest log too many permissions.

I would like a role which can create and read issues of a certain project. In addition, this user cannot read stuff about the status of the project or info about commits.

Perhaps also handy that you can add comments to issues that are not readable for customers, but only for project staff.

243 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…)
    Jelle shared this idea  ·   ·  Admin →

    18 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...
      • Anonymous commented  · 

        Guest would work.. but given they can't view code.. they also can't view the Readme..
        which might have information they need.

        The other issue I have with guest.. is it gives them the same interface so it looks like a Code repository.

        I would love to see something that is a Issues Poster only type role..But could give them access to certain files.. like the README or Wiki so they can see progress...

        When they login they should only see those projects that they have been given access too and all of the links like add projects should not be shown to them.

      • Nate commented  · 

        This would be great!

      • Colin Bennett commented  · 

        Why not let the GitLab role/permission matrix be customizable? Currently there is a fixed mapping between roles and the permissions granted them. It would be straightforward to provide the GitLab administrator a tabular user interface for this, and allow new roles to be created.

        On the Jenkins CI server, the Matrix authorization plugin does just this, in fact on both a global and per-project basis. Very powerful.

      • Ignacio Carrera commented  · 

        how about adding a "private" flag to issues and wiki pages, then making Guest unable to access private stuff?

      • Corey Gates commented  · 

        Excellent idea, Mitch. I've been looking for the same thing. Maybe then we could ditch this sub par bug tracker and have everything all in one place.

      • Not Marc commented  · 

        Agreed. A Customer is an entirely different kind of beast (in the nicest way possible, obviously).

      • Phil Baines commented  · 

        I would like to see this too!

        According to this post, it's done. But I don't think it's correct.
        http://feedback.gitlab.com/forums/176466-general/suggestions/4332972-guest-access-to-submit-issues-and-comments-only-wi

        I tried using the Guest account, and the user is still able to view commit messages on the Dashboard, and can also view Merge Requests, including the Code Diff.

        I think that "Customers" shouldn't be able to view any of this information.

      • Not Marc commented  · 

        A customer might need to edit wiki pages, too, or we might want guests to have even less access.

      • AdminGitLab team (Admin, Gitlab) commented  · 

        Mitch, are you above to use the guest role for this? Guests are able to open issues and comment on them but not to pull the code.

      • Mitch Dodge commented  · 

        This is exactly what I was looking for. I would like general users of our product to be able to submit and see issues, but not be able to see the source code, nor the commits.

      • Marc Hagen commented  · 

        Maybe a idee that this role cant login into the Gitlab CI either?

      • Andrew Meyer commented  · 

        Better yet, let us create our own roles with whatever permissions we want.

      • Rob commented  · 

        This sounds very usefull for our purposes, so also a yes here!

      • Robert Massa commented  · 

        Yes, we need this as well. Now the permissions are all-or-nothing, a more fine grained approach would be needed for our use-case.

        Customers would be able to create and view their issues, but not see commits and private issues.

      Feedback and Knowledge Base