►
Description
See related epic for more details. https://gitlab.com/groups/gitlab-org/-/epics/6777
A
There
we
go
so
just
to
kind
of
catch.
You
upstream,
I
don't
know
if
you
how
much
you've
seen
of
this
or
not,
but
this
is
like
another
iteration
of
the
of
the
service
accounts
system
that
I'm
making,
and
I
wanted
to
get
your
input
to
see
if
you
had
any
insight
on
the
technical
constraints
or
whatever
we're
missing,
and
I've
already
gotten
some
feedback
from
stakeholders
on
this.
B
B
A
A
This
could
be
subgroup
or
anything
so
ignore
that
this
is
an
architectural
or
a
logical
organizational
system.
This
is
just
an
example,
so,
theoretically
yeah
you
could
do
it
at
the
very
top
level
in
a
self-managed
environment,
which
would
be
the
instance
and
that
would
work
across
the
entire
organization.
C
C
A
A
A
So
the
idea
would
be
that
you
would
create
it,
get
a
name,
give
an
avatar
an
access
role
and
then
the
type
of
token
ignore
skim.
Token
that's
going
to
be
removed
from
this,
but
right
now
the
iteration
is
being
able
to
create
an
access
token
or
deploy
token,
and
then
you
would
change
the
scopes
based
off
of
whatever
you're
trying
to
do.
A
B
A
A
A
We
would
just
create
a
token
and
presumably
would
pick
a
scope,
and
that
would
define
whatever
parameters
it
would
have.
Access
to
the
question
is:
what's
more
complicated,
doing
the
unification
and
breaking
all
the
current
examples
of
the
tokens
or
iterating
on
the
current
features
that
we
have
right
now
allowing
for
this
feature
and
then
just
proceeding
as
like
the
first
mvc,
with
the
caveat
that
I'm
not
sure
how
this
would
work
in
creating
an
access
token,
which
actually
doesn't
generate
a
token
like
I
said
it
generates
a
user.
B
Behavior,
I
think
I
found
a
comment
from
emray
that
I
can
dig
up
and
link
to
you.
Okay,
that
we
could
potentially
reuse
a
lot
of
the
project
bot
logic
when
we
start
implementing
service
accounts,
because
there
are
a
lot
of
things
that
are
pretty
useful
when
it
comes
to
project
bots.
For
example,
it's
not
counted
as
a
licensed
seat.
The
bot
isn't
able
to
log
into
the
system.
It's
like
automatically
added
to
the
project
as
like
a
member,
something,
for
example,.
B
A
A
B
A
A
So
in
this
prototype
the
iteration
would
still
exist
where
you
have
this
yes
screen,
but
the
caveat
is
that
it
now
creates
a
member
or
a
bot.
Well,
this
finishes
compiling
yeah,
but
my
question
is
that
let's
go
back
here,
yes,
so
the
idea
that
I
had
was
that
we
would
actually
have
a
separate
section.
That
would
say
service
accounts
because
currently
it
lives
in
the
members
screen
and
we
wanted
to
try
and
help
separate
the
logic
of
a
user
versus
a
service
account
yeah.
B
A
A
A
But
I
can
definitely
chat
with
emra
when
he
gets
back.
I
was
curious
that
maybe
you
might
have
some
insight
on
that,
but
that
was
my
main
concern
right
like
so
the
idea
of
what
happens
when
this
screen
changes
or
should
the
screen
change
at
all
from
here.
Should
I
leave
this
as
an
mvc,
which
I
think.
A
B
A
A
A
C
C
B
B
A
Yeah,
I
guess
that
makes
sense,
because
you
would
call
it
like
api
bot
and
then
you
can
create
another
one
says:
read
bot
and
use
the
read
api
button
and
that
would
change
the
name
of
it.
So
that
would
make
sense
you
would
have
two
bots
doing
two
different
things:
yeah
or
well.
That's
that's
different
bots
right
using
different
tokens
for
one
bot.
That's
where
I'm
curious.
What's
the
benefit
of
that?
Why?
Why?
Wouldn't
you
just
select
multi-select
right.
B
B
A
We
were
that
was
the
next
iteration
right,
because
we
had
already
made
project
access
tokens.
The
next
creation
was
oh
there.
It
is
group
level
access
tokens,
the
re
the
pushback
was
well.
If
we're
gonna
do
that,
let's
just
make
a
feature
or
a
system
that
does
service
accounts
across
the
entire
organization
at
every
level.
A
B
B
A
Bot
with
a
different
access
level
and
call
it
like
api
or
read
api
bot,
because
for
me
it
doesn't
make
sense
to
have
variations
if
you're
not
just
do
the
multi-select
at
once
right,
I'm
not
sure
what,
unless
it
might
be
a
thing
where
they've
gone
back.
Oh
I
made
a
mistake.
I
want
to
go
back
and
add
that
that
might
be
the
difference,
but
then
that
would
generate
a
new
token.
A
A
B
A
A
A
B
For
example,
like
you
know,
project
access
tokens
create
a
project
bot
and
it's
like
a
personal
access
token
that
is
belongs
to
a
user
and
other
types
of
tokens.
Maybe
like
sim
tokens
or
deploy
tokens
or,
like
you
know,
oauth
tokens,
don't
necessarily
belong
to
a
user
they're.
Just
you
know,
like
a
token
digest.
A
A
B
A
B
A
Okay,
so
that
was
something
that
I
was
concerned
about
is
what
happens
or
what's
the
holdups
for
this?
Does
this
make
sense,
as
the
next
step
for
the
idea
of
access
tokens
or
like,
as
you
said,
is
the
cost
effective?
Is
it
doesn't
make
sense
to
do
this
because
of
the
variations
within
the
tokens
like.
A
C
A
C
Okay-
and
so
the
next
question
is,
do
we
have
an
issue
that
proposes
sas?
Groups
can
then
allow
the
use
of
paths
within
their
namespace?
If
our
plan
is
to
standardize
on
service
accounts
and
associated
tokens,
we
should
provide
a
way
to
shut
down.
The
use
of
personal
tokens
is
that
is
that
kind
of
what
we
were
talking
about
with
unifying
tokens,
like
is
pat,
were
personal
access.
Tokens
included
in
the
unification.
B
A
A
Okay,
yeah,
so
that
was
kind
of
like
if
we're
going
to
unify
all
the
tokens.
I
want
to
understand:
what's
the
complexity
here
and
that's
where
like
for
me,
the
hold
up
was
well.
Do
I
wait
for
this
unified
token
process
to
go
before
I
start
playing
with
this,
or
is
it
okay
to
just
go
ahead
with
this
iteration?
We
have
here
and
it
sounds
like
we
can
just
go
ahead
and
go
forward
with
iteration,
because
this
might
be
rather
complex.
C
A
A
C
A
No
no
for
me,
it
makes
sense
to
just
go
ahead
and
continue
with
the
the
the
mvc
that
I
have
the
visual
proposed
and
just
use
the
environment
that
we
currently
have
because
there's
no
sense
in
waiting
for
this
unified
token.
If
it's
a
super
complex
item,
it
might
take
a
year
to
get
resolved,
there's
no
telling
right,
but
we
already
have
the
implementation
currently
for
project
access
tokens,
and
then
we
can
offer
that
feature
at
the
group
and
the
instance
level.
Then
that
would
be
tremendous.