GitLab Manage: Access Group, 7 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Customizable permissions sync with the Govern team

Description

We discuss allowing an admin to prevent group maintainers from changing branch protections with a customized role.

A

B

There we go, it seems like.

A

um So yeah, you were saying how you have a situation where um maintainers can still um change Branch protections, and you want to find a way to prevent that. Yes,.

B

A

With the new proposal of our customizable roles, the idea is that you would be able to create a custom uh role. We see here across the top guest reporter developer, maintainer and owner as the five default that.

B

A

um Our current implementation will only be additive permissions, so an example being that I can't subtract or remove that permission from the ability for that maintainer. So in this case, you would need to create a custom developer role with the maintainer permissions that you want that do not have that permission um now in the future. uh The way this is supposed to work or the way that we want this to work for um the rest of the groups is that you will be able to then customize or create changes within this permission table.

A

So one of the things we're doing is we are unifying or merging permissions as sort of the MVC, um so the first one we merged was uh to view um uh you Branch details or view pipeline details uh and edit pipeline details. So in this example of merging these permissions, your team would be able to do something similar in regards to perhaps making changes to this particular permission, um but that's something that you'll need a test first, obviously, but you'd want to go through the standard process of just like.

A

How is this going to work um in the larger environment and that's sort of what I'm trying to work on a process to allow all the other groups and stages to go and create and customize the permissions table to make them more um I, don't want to say individualized but more um appropriate for their feature. So in this case for your feature, you want to prevent that particular permission, but we don't have that ability to remove that permission.

A

So the First NBC of that proposal would be to create the developer role and then add the permissions from maintaining that you want minus that um that one branch protection permission. So then they won't have the ability to enable disable permissions yeah that might be quite a bit down the road in the future. So I don't know if the The Proposal you had made with the check boxes. If you want to show that um if that would be the faster proposal.

B

A

At least for the custom permissions that we're trying to do at some point in time, we'd a lot we'd hope that you would be able to make whatever change the permission that you would need in order to allow for any sort of features like this right.

B

Yeah, so I was thinking if that's possible in the future. So now what we can do is like we can just do this like, for example, create a new policy, and it says overwrite settings so, for example, like uh um like this is like the one I showed you before, like with those checkbox is like in each policy. You enable that so I can also create a new policy uh which says like uh for overwrite. This settings is enable what product.

A

B

I think in the future it could be easier. It's not size project who says row it's like uh if they create a new row. It's like um on a row.

B

Another like maintainer, cannot do this anymore right. So then, like this policy is not like Project Specific policy overwrite for select role, then this policy will like set like basically this um permission table here. It's not in the setting, but is in a policy.

A

Right exactly so yeah both ways would work, um but once we have more um once the customization of the permissions and roles is more mature, then we can definitely get to that better permission. You showed of just like security uh role and can do that and then you'll have that customized uh permission or that customized role for that yeah.

B

So our like, you think, maybe it's ease like you said down in the row, so maybe the first is like uh uh remove this position like remove this um permission, for certain laws could also be it's like uh no developer like allowed to do this. I will do that later, but it's like for this show no developer can do this.

A

B

That's maybe like faster compared to giving rights to create a new role like in a policy we can prevent this. Do you think that's faster.

A

uh uh I think in the meantime, yes, like I, said because the customization of this might take a while, where, like I said, we're just doing that first MVC right now to see how that works, um but at some Future Point, yes, I just don't know how long so. Arguably the plan is that once we have like a process to create and manage and edit custom roles um and then you as a designer can say, okay I have a requirement for my feature where I need to make a change to a particular permission.

A

Behavior um to allow for this sort of condition, then I can now create an issue or um a task for the rest of the team to go back and engineer that change in the permissions.

B

A

To allow for this or to create that customization ability to where then the user can create or uh create their own customized permission for that.

B

Yeah I think, there's probably like really in the future. That's like the policy, maybe is generalized, it's not like a security policy, but there's a policy for roles like the new role. What the things need to do. It could be like a if we have a pattern now in the future. We can like have a just reuse, this security permission and things for all the roles.

B

Okay, I will explore more of this option. I think there's more like um future are rented thing. If we create a new policy right, yeah.

A

um But but, like I said the ideas that once we have our first iteration and the foundation laid down for this process, then you can take ownership and push the change. You need for your permission and your feature faster right without having to rely on somebody else to prioritize it.

A

So the the big thing about the customizable permissions is that we want every group and Stage to kind of take ownership of their permissions and how they interact with their feature, so that if they have a requirement like this, that needs to change or needs to have some more granularity or flexibility for users. Then you can make that adjustment as needed.

B

Yeah, okay, cool and.

A

Then give that feature to users to make their own customizations right. Yeah.

B

Because I want this like at least for the first idea, if I don't cast my rows, the customize like this uh override setting like by project by policy and then on two levels. This is on group level. This is um project level.

B

So for the lows like you also plan on group and uh project level are only group level. People can manage another. All the product need to follow. What's it defined by the group. Well,.

A

You can you can define that as you want right. So if you define your organization with that uh permission structure, then it should be no problem right, but it's up to the user to Define that structure.

B

Yeah, okay, cool.

A

But I mean it for you from the from the the git lab side. For example, you want to understand what what is the hierarchy that would impact or that a user would expect that impact to occur right, so should it be only at the top level for all groups and all the projects or is it individualized right?

A

Is there a customized opportunity for every group and project to have their own sort of Behavior interaction right, so it there's a I, don't know how it works right now, I haven't used this particular feature, um but I do see value for both for like a more security-minded organization where, at the top level, it's managed in one spot or like if it's a small team with like three or four developers like I, want to be able to have flexibility everywhere, then make it customizable across the um all of your groups and subgroups.

B

Yeah, okay, it makes sense and when do you think like we can maybe potentially do those type of things.

A

um So right now, like I said we are in the the I guess, validation or QA stage, um because the MVC already exists in the platform, um it's behind the feature for like, if I recall correctly, and so we're getting data on how people interact with it and what sort of problems it uh causes in the platform, if any um so I.

A

Think after that, there'll be like um a showcase or like a discussion to show you know: here's the results, here's what happened um and I'll work with the engineers to to get that information and kind of talk more about it once like we get it, um but I I, don't expect it to be far off the next step.

A

For us right now is creating the the front end, because right now that that new MVC only exists in the API yeah, um but right now from the front end perspective, um the designs are more or less done.

A

um I hope I'm doing like a few rounds of validation with um some Enterprise organizations to see how they feel about it with in terms of the interactions of the interactions, make sense, um but I don't expect anything to change dramatically um but from there um that's when, presumably uh every group and Stage can start making their own um changes or adding to you know, changes to the permissions to allow that more flexibility and that's sort of what I was doing.

A

I don't know if you saw that other epic Grace um broke out every sort of sub category of permissions to try and um have this discussion more or less to start the the thought process. Okay, me, uh as, in your case, Camellia, uh how do I start looking at the permissions to see what I need to change, to make things more logical, more flexible for my users, so they can then have access to this customizable role and make their own um particular custom role like the one, the security example.

A

You showed um and then start prioritizing that work in your Milestone planning.

B

People do share like that. um Like front end, the UI like with me I can maybe over like reuse, something yeah.

A

For sure, let me um send you the figma link.

A

A

Okay, I just sent you an invite to the to the figma file, so you can take a look at it and see how we're planning with it um like I, said right now: I'm doing a validation round with some end users, um but I don't expect much to change dramatically.

B

Cool, how can I see this okay and another thing like women who women and this table on the dock won't be there anymore because, like they can, each group can change it and that dog is like basically not giving the right information.

A

Yes, that's correct because then you'd have your custom permission and then you can Define that permission at the top level and that would been hide or you know, remove that feature from people who don't have access to it.

B

Okay, cool I will have a look to see that like how can I do that, because I'm going to create a new role and this new role? That thing is like the low end. The policy need to be connected. So when there is a security policy enabled and then probably we want those roles to be enabled as well.

A

Yeah and that's part of the the customization of the the role that you're creating right, so you create that custom.

A

New role with that particular permission that allows that uh policy and then you'll Define those permissions in the policy uh once you say you know in that particular example, you showed with like a Dropbox saying this user role can do this or whatever right.

B

Yeah, okay I will think about. It is we'll see how what's the most extreme way of doing that sure.

A

B

I'll, probably, we need to show it somewhere. The interaction between like this low permission, the admin area and the policy I was like um I assume that in the role and permission it will show that which role can do what and if I, have a policy to overwrite those things or changes. We also need to like show it somewhere right.

A

And, and also like I said right now, because the MVC is only in the API and the front end. The the Prototype that you see is a huge long list of permissions. That's not going to happen in the next one or two three Milestones right, because we want the one.

A

um So there's a lot of opportunity to change or improve the front end on the UI.

A

Once we start getting more and more permissions into this customizable screen, but I think for now, I think from my rounds of validation with stakeholders, it seems to make sense and it seems to work, but that's where that other related issue, that I brought up about um overlapping permissions or um connecting permission groupings making sure that permissions connect logically, um that's again back to each individual group or stage to make sure that those connections are logical or perhaps can be improved or reduced in complexity, so giving the y'all or every team every group to start improving the permissions and settings or excuse me the permissions and roles based off of what makes more sense.

A

You know in the past it was kind of like we don't have the ability to make these changes, but now we do.

B

Yeah Okay cool so like this UI, maybe like a safely to say end of this year, we probably have it yeah.

A

I mean it depends on how fast the rest of the team uh can prioritize this work right, so if, if it goes out and everything's working fine and now we have like a a road uh excuse me, a road map um if all the rest of the groups of stages can re-prioritize work and say: okay, now that we have this ability to do this, granular permissions, these changing of permissions.

A

um Let's start rethinking about our ux roadmaps, you know our long-term planning. How can we start shuffling some priorities to give more customization or more flexibility to um the features and for our users right, yeah,.

B

Cool I think that's clear.

A

B

This information, oh.

A

Yeah I'm glad to help yeah and, uh like I said you see, you have the link to the Prototype field. uh Please feel free to contribute and suggest any improvements or any sort of confusion that you might see. um You know just leave some comments.

B

Yeah we'll do that and uh like I will put some new ideas in my prototype and then I will share it. Cool.

A

Sounds good thank.

B

A