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…)
    JelleJelle 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.

      • NateNate commented  · 

        This would be great!

      • Colin BennettColin 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 CarreraIgnacio Carrera commented  · 

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

      • Corey GatesCorey 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 MarcNot Marc commented  · 

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

      • Phil BainesPhil 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 MarcNot Marc commented  · 

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

      • GitLab teamAdminGitLab 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 DodgeMitch 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 HagenMarc Hagen commented  · 

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

      • Andrew MeyerAndrew Meyer commented  · 

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

      • RobRob commented  · 

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

      • Robert MassaRobert 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