User groups (that can be assigned as approvers)
Zendesk issue: https://gitlab.zendesk.com/agent/tickets/13653
Somewhat related to #179 (closed), the customer has different groups of people that are responsible for a release branch. It would be nice to be able to reference a user group in the approver's list instead of having to type out each name separately. The approvers changes for each release so it's updated often.
This is also somewhat related to the discussion in gitlab-org/gitlab-ce#2772 where we discuss whether teams are a good fit again.
Activity
In my mind, the user groups within a project is an interesting idea. It would be so handy to reference groups of people within a project. For example,
@ developersor@ operations, etc. If we have some group concept that meets the customer's request above, what I describe should be possible.@JobV Interesting as in compelling or confusing?
@dblessing you can already create groups now, which can have users that can be referenced. I think we can start by building support for having a group responsible for approvers. We don't need teams for that.
@JobV That may work. To be clear, this would be a group of users other than the group the project is in? So we'll have to assume the project is shared with this other group of users? If that all sounds good, I think this sounds reasonable.
mentioned in commit d1fa13d7
This was requested by https://na34.salesforce.com/00161000004xP1B who are seriously considering using Gerrit instead if GitLab MR's. Other related Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/15234
re:the customer @Haydn linked to above, this would be an admin group of some kind -- with members maintained via LDAP group sync.
-
This feature is also important for: https://na34.salesforce.com/00161000004bZPD?srPos=0&srKp=001
Milestone changed to %Backlog
@xyzzy if we implement this on the short term, we'd have to leverage current GitLab structures, so:
- the group would have to be a GitLab group
- you'd have to have access to that group to assign it
We're also doing this for branch permissions.
I think the feature request makes sense. I'll try to fit it in a nearby milestone.
@JobV Does that mean the group membership could or could not be maintained via LDAP Group Sync? Based on what I know of the customers, I'd say that is very highly desirable.
@xyzzy could!
@job - what is the status of this? Neither of the above-mentioned issues seem to address it. Both of the two customers referenced above is very important to us and one (largest customer) is considering implementing Gerrit because we lack this functionality. We really need this in the product.
Edited by Reb@vsizov if this is not a lot of work, do you think you can squeeze it into 8.12?
@JobV Weighted as 4, especially as we can hopefully reuse some of the frontend for branch permissions.
Milestone changed to %8.12
As long as this reuses existing GitLab groups you will get LDAP group sync for free. On Thu, Aug 25, 2016 at 5:09 PM Régis Freyd (GitLab) gitlab@mg.gitlab.com wrote:
@DouweM https://gitlab.com/u/DouweM @JobV https://gitlab.com/u/JobV @xyzzy https://gitlab.com/u/xyzzy @vsizov https://gitlab.com/u/vsizov So everyone is one the same page: apart from the standard group management, can we consider that group membership will also be maintained via LDAP Group Sync? This is the most important remaining question.
— Reply to this email directly or view it on GitLab https://gitlab.com/gitlab-org/gitlab-ee/issues/180#note_14478185. You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can unsubscribe https://gitlab.com/sent_notifications/REDACTED/unsubscribe from this thread or adjust your notification settings.
-- Drew Blessing Sr. Service Engineer GitLab, Inc.
@regisF I don't see how this is related to the LDAP group sync. The approvers would just be whomever would be in the group, independent of the mechanisms that those users end there.
Reassigned to @vsizov
@regisF Why did you assign it to me? I can't pick this task up this week. So to not prevent it to be picked up by someone else I would leave it unassigned... UPDATE: Anyway I've put it to my TODO list
Edited by Valery SizovReassigned to @vsizov
-
Will we have time to do this for 8.12?
Most probably - No. But we'll see.
Edited by Valery Sizov Milestone changed to %8.13
Mentioned in commit 8916d4fd
Mentioned in commit 2f1f58c4
Mentioned in commit 554e2f89
Mentioned in commit b393b78c
Mentioned in commit 397f2328
Mentioned in commit 1b80e058
Mentioned in merge request !743 (merged)
-
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/743
I've made a dropdown for groups with existing UI tools. To me it looks good, but maybe UI team want to improve it or reimplement.
Edited by Valery Sizov 
@awhildy perhaps one designer could help here, just in case.
@pedroms: Would you step in here and make sure it all makes sense from an UX perspective? Thanks!
@awhildy thanks for the mention. Will see what I can help with
Mentioned in commit 858e7601
Mentioned in commit 0c6728c5
Mentioned in issue #580
Mentioned in commit 10427618
@pedroms I saw you were working on this only after I had already done some work on: https://gitlab.com/gitlab-org/gitlab-ce/issues/13411#note_16762679
cc'd you there ;)
@dimitrieh I didn't do much besides giving some suggestions to @vsizov on his MR !743 (merged). If you have a chance to look at it, the first iteration will have two separate fields: one for searching users and another for groups. The second iteration will probably merge these two (it's what makes sense).
PS: On the other issue you misspelled my handle (
@pedroinstead of@pedroms) so I'm glad you mentioned me hereStatus changed to closed by merge request !743 (merged)
Mentioned in merge request !792 (closed)
Mentioned in commit d1fa13d7
