►
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
So
to
start
off
with.
Currently,
the
prototype
is
set
right
now
with
a
number
of
variables,
interaction
points.
I
actually
have
two
versions
of
this:
where
one
is
a
single
select,
interaction
and
one
would
be
a
multi-select
interaction
and
you
can
see
what
that
would
look
like
here
to
some
degree.
A
A
So
there's
a
bit
of
super
complexity
here
with
that
project,
I
did
encounter
a
few
problems
along
the
way
in
making
this
I
had
some
help
from
dan
mitzi
harris
and
he
was
able
to
help
me
and
try
and
create
a
let's
see
if
it's
on
the
screen
or
not
helped
me
with
creating
some
interactive
components
that
I
was
not
able
to
reproduce
on
my
own,
so
I'll
actually
create
the
third
or
excuse
me,
the
second
iteration,
with
the
multi-select,
with
a
different
type
of
interactive
component,
to
try
and
minimize
a
lot
of
this
clutter.
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
We
have
in
the
platform
with
these
kind
of
new
components
that
we
have,
that
we
want
to
use
as
a
way
to
expand
content
to
interact
with
it
so
might
be.
There
will
be
a
few
new
pieces
that
will
be
hopefully
designed
for
this
project
as
we
go
forward.
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
So
if
I
were
to
toggle
something,
it
would
basically
work
as
a
unified
connection
or
unified
toggle,
where
I
don't
have
to
go
and
individually
toggle
things
and
things
will
get
broken
if
they're
not
toggled
in
groups
or
pairs,
so
that
might
actually
cause
some
of
this
content
to
be
changed
and
probably
reduced
actually,
because
if
the
example
would
be,
if
I
were
to
make
or
prevent
somebody
from
doing
anything
with
the
code,
then
those
touch
points
would
then
be
disabled
or
grouped
as
one
so
we'll
see
how
that
goes
as
we
get
a
more
defined
picture
from
engineering
on
what
the
problem
looks
like
and
how
they
want
to
solve
it.
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
We
have
just
a
huge
table
of
all
of
our
permissions,
but
that's
going
to
be
reorganized
to
be
relevant
to
particular
categories,
so
things
like
namespace
for
top
repository
product
management,
merge,
request
and
ci
cd,
so
from
here,
let's
go
ahead
and
create
a
new
role
and
we'll
give
the
new
role
a
title
and
we'll
call
this
title
incident
manager
and
right
now
it's
looking
the
default
or
the
zero
state
would
be
the
guest
role.
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.
A
As
of
this
point
right
now,
so
yeah,
that's
the
first
rough
walk-through
we
have
of
our
wireframe.
Excuse
me
our
prototype,
for
this
custom
rolls
and
permissions
and
I'd
love
your
feedback
from
that.