GitLab UX Team, 1 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: UX Showcase - Service Accounts

Description

Manage & Plan
UX Showcase - Dec. 1st, 2021
See related epic: https://gitlab.com/groups/gitlab-org/-/epics/6777

A

Hi, my name is daniel moore, I'm a senior product designer with access- and today I want to talk about service counts uh service accounts is a project. We've been working on for a while. uh This is basically the next iteration of what we already have in terms of access tokens, specifically project access tokens.

A

So I don't have my gdk running here. We are so currently access tokens exist here.

A

At a project level, you can create a project access token and when you do that it creates a user. Let's see, let's give it a moment.

A

Let's see, I had a project. Excuse me a bot token right here uh this one I created recently.

A

So imagine, if you have you know, 10 000 members in your group, it's kind of hard to find that without you know doing a search, uh probably the optimal id would be just drop it in a sub item here.

A

What we want to do is find a way to improve this behavior. This was one of the initial prototypes we had done.

A

And the idea is that you have a service account section, be able to create a service account, give it a name, give it an avatar, give it some role and you can choose what kind of token you give it to your scopes and it generates a token and the idea is, you can then make any changes. Add more tokens here.

A

If you need for different features or different access levels, and then you can remove or go back to the edit or create a new service account. This was one of the prototypes we had already tested with stakeholders. To see.

A

Does this process make sense, and so we have a bit of some updates in regards to that uh we're looking at actually maybe improving the process. By doing what's, uh we call unifying the tokens, so I spoke with um serena here she's one of our back-end engineers, and we had a lot to discuss uh in regards to this topic here, which is unified tokens.

A

So the idea is that we would unify our project access tokens, um personal access, tokens deploy tokens, and this idea that we had with group level, or uh instance, level tokens. um This was kind of like an older topic.

A

You see here it's been about a year since we were talking about this, but the idea of unifying a token is instead of having all these iterations of different tokens, that the feature would just be one specific behavior or one specific action to create a token and live in one place in the database and then have service accounts work off of that. So that is the next step in the service accounts.

A

Project is to actually go and unify the tokens first, which would then my next step would be to actually change or improve this prototype that we have here to try and see if there's a more logical way of doing this with a unified token.

A

So there's a few concerns that we have specifically. If we unify the token we might have a problem because a deploy token actually generates a token.

A

An access token creates a token and a user account, so that will definitely put a change on this behavior, where we have a token generation process through separate tokens. You know here, I said earlier where it creates a seat.

A

This is a gonna need, a rethink, so that's currently where I am at with service accounts and thanks for listening.