add rake gitlab:import: all_users_to_all_groups and user_to_groups #5520

Merged
merged 1 commit into from Feb 12, 2014

Projects

None yet

6 participants

@gabetax
gabetax commented Nov 2, 2013

I opted for admins to be added as "owners" instead of "masters" because project masters can managers members, but only group owners can manage members.

@gabetax gabetax add rake gitlab:import: all_users_to_all_groups and user_to_groups
I opted for admins to be added as "owners" instead of "masters" because project masters can managers members, but only group owners can manage members.
1710503
@coveralls

Coverage Status

Coverage remained the same when pulling 1710503 on gabetax:rake_group_bulk_add_permissions into 4c47a89 on gitlabhq:master.

@jvanbaarsen

@dosire What do you think about this PR, wont this change intended behavior?

@dosire
Member
dosire commented Dec 9, 2013

@jvanbaarsen It seems to be new behaviour that is documented properly. @randx what do you think?

@jvanbaarsen

@randx Can you take a look?

@jvanbaarsen

@jacobvosmaer Can you take a look?

@jacobvosmaer
Member

Is this necessary? I thought admins can do what they want, whether they are 'Master' or 'Owner'.

@jvanbaarsen

@jacobvosmaer Well, if i remove your admin status, you wont be able to manage te users (I think thats the reason for this PR)

@gabetax
gabetax commented Feb 11, 2014

I wrote this for myself because I have 100+ "private" repos over 10 groups with 25+ users. I want most of my users to access most of my repositories, so I'd rather start with a mass grant, and then manually pare down access as necessary. I don't want to achieve access using the "internal" visibility setting, because I will inevitably have to add an account for an external vendor or consultant at some point. The current two ways for me to achieve this are:

  1. rake gitlab:import:all_users_to_all_projects - which is madness to maintain with that many repos and users. And frankly, when it comes to access control in general, I think it's smarter to encourage grants at the group level instead of at the entity level.
  2. Manually add all the users to the groups, which still adds up to 250 manual actions to make.

As for the "owner" flag given to admins, I did just confirm global admins can still manage group members (except for their own) even if their group-level access is only 'developer', so I'm open to whatever access level makes the most sense, but adding them as owners is not giving them any added permission they wouldn't otherwise have.

@randx randx merged commit 168e034 into gitlabhq:master Feb 12, 2014

1 check passed

Details default The Travis CI build passed
@jvanbaarsen

@gabetax Thanks!

@gabetax gabetax deleted the gabetax:rake_group_bulk_add_permissions branch Nov 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment