►
From YouTube: UX Showcase - 2022-08-03 - RBAC prototype status update
Description
We discuss the state of the RBAC work and will start getting user feedback in testing.
A
Hi,
my
name
is
danielle
mora,
I'm
a
senior
product
designer
with
the
authorization
authentication
group
at
getlab,
and
today
I
want
to
walk
you
through
the
latest
updates
of
the
rbac
work
that
we've
been
doing.
That's
role-based
access
control
project
and
how
we're
going
to
be
moving
forward
with
user
testing
and
kind
of
just
the
state
of
the
project.
Right
now,
so
I'm
going
to
split
this
video
up
into
two
halves.
A
The
first
half
of
this
video
will
be
kind
of
like
a
walk
through
for
the
current
state
of
the
designs,
how
I
created
the
prototype
and
some
of
the
possible
pitfalls
to
be
aware
of
when
it
comes
to
creating
such
a
complex
prototype
and
figma.
This
one's
quite
robust
and
lots
of
interaction,
points
and
then,
in
the
second
half
it'll
kind
of
jump
to
a
second
recording.
I've
made
it'll
talk
about.
A
A
I
don't
know
the
status
of
their
computer
if
you're,
using
chrome
or
something,
but
if
we're
going
to
use
this
in
a
testing
environment,
I'm
not
sure
if
this
much
interactivity
or
complexity
when
the
prototype
would
actually
be
causing
the
problem
or
if
there
was
something
else,
but
I
wanted
to
try
and
minimize
those
variables
so,
basically,
as
I
go
through
real
quickly,
I'll
just
run
through
this
as
the
ux
side
of
it,
the
idea
is,
a
lot
of
the
visuals
has
been
cleaned
up.
It's
actually
using
you
know
correct
components.
A
A
Let's
see
the
idea
for
right
now
is:
let's
see
if
I
can
find
it
for
an
mvc
of
this
project
would
be
maybe
it's
this
one
real,
quick
where
we
go
through
and
actually
only
offer
one
permission.
That'll
be
interactive,
or
I
should
say
this
list
will
probably
be
greatly
truncated
just
as
a
way
to
test
this
whole
new
idea.
Since
this
is
a
total
redesign
of
our
permissions
architecture,
we
have
right
now
a
problem.
We
just
don't
have
the
dev
resources
to
investigate
the
amount
of
interactivity.
A
That's
going
to
be
done
are
not
much
of
our
interactivity
but
complexity
associated
with
our
permissions
model,
where
all
of
the
permissions
have
some
sort
of
relations
that
are
not
cleanly
defined.
So
as
an
example,
this
here
be
view
project
code
as
a
permission,
if
you
disable
that
that
has
some
implications
in,
for
example,
merge
requests
where
you
can't
apply
code
suggestions-
or
you
probably
wouldn't
be
able
to
see
code
suggestions,
so
there
needs
to
be
a
an
engineering.
A
But
for
now
like
I
said
this
is
the
state
of
our
current
prototype.
It's
pretty
polished,
it's
ready
to
go.
I've
already
gone
through
some
testing,
with
some
internal
stakeholders
and
right
now
I
am
scheduling,
interviews
with
end
users
and
particular
clients
that
we
have
to
try
and
get
more
hands-on
testing
done
and
actually
get
that
feedback
that
we
need
from
those
enterprise
users.
A
So
we're
looking
at
the
admin
screen
right
now
and
the
idea
is
that
we'll
have
a
new
section,
labeled
roles
and
permissions
where
system
administrators
can
manage
their
permissions
model
based
off
of
whatever
they
are
needed.
Excuse
me,
whatever
is
needed
for
their
environment,
so
the
idea
is
I'll,
go
ahead
and
see
these
two
sections.
This
would
be
your
custom
roles
and
our
gitlab
standard
roles.
A
The
standard
roles
are
the
current
roles
that
exist
within
gitlab
today,
so
the
five
guest
reporter
developer,
maintainer
and
owner
these
will
be
used
as
kind
of
like
a
template
where
you
can
build
your
own
custom
role
off
of
and
I'll
go
into
detail
a
bit
about
that.
So
we
keep
the
the
standard
roles
kind
of
like,
as
for
like
I
said,
a
template,
but
also
as
a
way
for
troubleshooting.
A
A
So
this
is
the
guest
role
and
its
permissions,
the
or
the
associated
permissions
within
this
role,
and
if
you
go
through
the
list,
you'll
see
there's
various
permissions
here
in
this
table
and
they'll
change
based
off
of
whatever
I
have
as
my
role
template.
So
let's
go
back
to
this
and
we'll
change
it
to
a
developer.
A
So
now
we'll
see,
this
column
has
been
changed
to
the
developer
role,
and
the
permissions
have
now
changed
so
from
here.
We'll
go
ahead
and
create
a
custom
permission,
so
in
this
case
I
want
to
say
that
our
incident
manager,
custom
role,
will
have
the
ability
to
view
insights
in
the
environment
so
we'll
allow
that
and
then
we'll
save
it.
A
And
now
it
brings
us
back
to
the
previous
screen,
where
we
have
our
incident
manager
for
our
new
custom
role
before
there
was
only
the
empty
state
or
the
zero
custom
roles,
and
we
also
have
our
standard
five
roles
that
exist
within
kit
lab
and
you
can
switch
back
and
forth
between
those
as
you
create
more
custom
roles,
they
will
populate
this
section
here
and
the
next
step
of
adding
that
role
to
a
user
or
a
member
within
your
environment
will
still
be
the
same.
So
nothing's
really
changed
in
that
capacity.