Migrate Project#owner to have OWNER membership
With !78193 (merged), new personal project owners will have OWNER
membership. We need to migrate members
records for existing personal projects too.
See https://gitlab.com/gitlab-org/gitlab/-/issues/351986#note_831687602 for numbers as of 2022/02/04.
Overall strategy
- Get all personal namespaces and their memberships
- Create a membership for any users that are OWNER via owner_id
- Change MAINTAINER memberships to OWNER
Designs
- Show closed items
Is blocked by
Activity
-
Newest first Oldest first
-
Show all activity Show comments only Show history only
- Imre Farkas added devopsmanage featureenhancement + 1 deleted label
added devopsmanage featureenhancement + 1 deleted label
- Imre Farkas added to epic &7405
added to epic &7405
- 🤖 GitLab Bot 🤖 added typefeature label
added typefeature label
- Imre Farkas marked this issue as related to #219299 (closed)
marked this issue as related to #219299 (closed)
- Imre Farkas mentioned in merge request !78193 (merged)
mentioned in merge request !78193 (merged)
- Imre Farkas mentioned in issue gitlab-org/manage/general-discussion#17453
mentioned in issue gitlab-org/manage/general-discussion#17453
- 🤖 GitLab Bot 🤖 added sectiondev label
added sectiondev label
- Imre Farkas mentioned in issue gitlab-org/manage/general-discussion#17406
mentioned in issue gitlab-org/manage/general-discussion#17406
- charlie ablett assigned to @cablett
assigned to @cablett
- Developer
This is blocked by !78193 (merged) but I reckon it's good to have it ready. WDYT @ifarkas?
Collapse replies - Author Maintainer
Good idea!
- Developer
A strategy could look something like:
- Find all namespaces with
owner_id
- (do we want to filter by namespaces without a group? Or just mass migrate them all? The issue description does say
personal namespaces
)
- (do we want to filter by namespaces without a group? Or just mass migrate them all? The issue description does say
- Create a membership record for the
owner_id
as long as:- they are not blocked
- the ID exists as a user
- they are already not an Owner of the group via membership record
- if they are already a lower-ranking member, we can still add another record AFAIK
And then, maybe as part of this MR/migration or a separate MR:
- clear the
owner_id
column and drop it from the DB.
- Find all namespaces with
Collapse replies - Author Maintainer
do we want to filter by namespaces without a group? Or just mass migrate them all? The issue description does say
personal namespaces
Yeah, this is specific to personal namespaces.
they are not blocked
I think we should create the record regardless. Membership is independent of the user's status.
they are already not an Owner of the group via membership record
We probably don't need to check this as we don't deal with groups in this case.
- Developer
I think we should create the record regardless. Membership is independent of the user's status.
Agreed, they can be unblocked at a later time. Great point (and simplifies things nicely). Is there anything else we need to consider?
- Developer
Strategy Questions -
- Do we want to create the membership record and risk that we'll have a double-up for a while? Is the existing logic OK with such a scenario or is there any prep work needed? (I can check &7405 (comment 814394291))
- Does
owner_id
get set anywhere in our modern code, or is this a legacy column? - Do we want to sync these up at all, or simply "migrate, drop DB column and move on with our lives"?
Collapse replies - Author Maintainer
Do we want to create the membership record and risk that we'll have a double-up for a while?
@cablett, I think there are 2 possibilities:
- either the member record exists with
MAINTAINER
access level: in this case we want to upgrade toOWNER
- the record does not exist -> we want to create an
OWNER
member record
Does
owner_id
get set anywhere in our modern code, or is this a legacy column?I suspect it's legacy. I might be wrong, but I think the evolution of this feature included steps where we had a single owner of the project, and members could have
REPORTER
up toMAINTAINER
access. Then it was extended for groups to also includeOWNER
access level for all members, leaving a bit of ~"technical debt" behind.Do we want to sync these up at all, or simply "migrate, drop DB column and move on with our lives"?
Dropping
#owner
completely is a great idea! - either the member record exists with
- Developer
- charlie ablett changed the description
Compare with previous version changed the description
- charlie ablett changed the description
Compare with previous version changed the description
- charlie ablett mentioned in merge request !80003 (closed)
mentioned in merge request !80003 (closed)
- charlie ablett mentioned in merge request !80146 (merged)
mentioned in merge request !80146 (merged)
- Imre Farkas mentioned in issue #352239
mentioned in issue #352239
- Imre Farkas changed milestone to %14.9
changed milestone to %14.9
- charlie ablett changed the description
Compare with previous version changed the description
- charlie ablett changed the description
Compare with previous version changed the description
- Developer
Closing as !80146 (merged) is merged.
- charlie ablett closed
closed
- Manoj M J mentioned in merge request !84460 (merged)
mentioned in merge request !84460 (merged)
- Manoj M J mentioned in issue #219299 (closed)
mentioned in issue #219299 (closed)
- Michelle Gill added namespace label
added namespace label
- 🤖 GitLab Bot 🤖 added devopsdata stores grouptenant scale sectioncore platform labels and removed devopsmanage sectiondev + 1 deleted label
added devopsdata stores grouptenant scale sectioncore platform labels and removed devopsmanage sectiondev + 1 deleted label
- Suzanne Selhorn mentioned in merge request gitlab-docs!3607 (closed)
mentioned in merge request gitlab-docs!3607 (closed)
- 🤖 GitLab Bot 🤖 added devopstenant scale grouporganizations sectioninfrastructure platforms labels and removed devopsdata stores grouptenant scale [DEPRECATED] sectioncore platform labels
added devopstenant scale grouporganizations sectioninfrastructure platforms labels and removed devopsdata stores grouptenant scale [DEPRECATED] sectioncore platform labels