►
From YouTube: UX Showcase - RBAC Work
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi,
so
I'm
daniel
moore,
I'm
senior
product
designer
for
authentication
and
authorization,
and
I
want
to
talk
a
bit
about
the
rbac
design
pod
and
the
current
status
of
the
rvac
work
that
we're
doing
in
the
pod
and
the
auth
group.
A
So
first
off,
what's
a
design
pod,
so
a
few
of
us
were
getting
user-related
feedback
about
overlapping
problems,
specifically
in
regards
to
our
permissions
and
the
roles
that
we
have
the
five
permission
or
excuse
me,
the
five
roles
that
we
have
are
limited
to
currently
guest
reporter
developer,
maintainer
and
owner.
A
So
we
wanted
to
try
and
collaborate
to
address
the
problem
and
maybe
investigate
a
product-wide
solution
instead
of
just
being
kind
of
a
compartmentalized
to
one
particular
group
and
having
disparate
solutions
across
the
organization
which
kind
of
has
led
to
the
problem
that
we're
experiencing
today,
where
every
component
within
the
environment
has
some
unique
or
particular
feature
permission
structure.
That
only
applies
to
that
feature
or
aspect
of
gitlab.
A
So
what
is
r
back
so
r
back
is
role
based
access
control.
Git
lab
has
the
r
back
permission
system
with
our
five
roles,
as
I
mentioned
previously,
and
for
large
organizations
who
require
more
granularity
and
control
compliance
regulations.
A
These
five
permissions
or
these
five
roles,
don't
necessarily
fit
that
or
fit
in
their
requirements.
So
I'll
give
you
an
example
here.
If
we
look
at
the
permissions,
you
know
we
have
quite
a
few
here
and
just
as
an
example
for
a
developer
can
view
product
audit
events.
Well,
perhaps
that's
not
a
compliant
thing
that
is
allowed
for
all
members
of
an
organization,
perhaps
there's
a
compliance
restriction
that
says
only
group
owners
or
particular
auditor
persona
can
view
audit
events
and
there's
other
things.
A
You
know
like
things
that
are
more
complicated
or
more
security
focused
such
as
like
the
repo
rewrite
or
remove
get
tabs
things
like
that.
So
a
number
of
the
features
that
we
offer
within
these
various
five
roles
offer
too
much
flexibility
or
too
much
freedom,
and
that
makes
sense
for
like
a
smaller
organization,
but
once
you
start
increasing
the
number
of
people
in
your
organization,
especially
having
to
deal
with
compliance
or
security
aspects,
that
can
be
a
bit
of
a
problem.
A
So,
as
I
mentioned
here,
the
current
five
roles
are
two
permissive
organizations
have
to
make
compromises
in
the
permissions
assigning,
causing
compliance
problems,
and
we
have
a
number
of
interviews
you
can
go
if
you
want
to
see
some
more
detail
of
that.
One
of
the
specific
examples
I'll
cite
here
is
that
the
user
stated
we
assigned
a
user
a
reporter
role,
but
technically
speaking,
that
user
could
go
and
change
the
issue
boards.
A
That's
what
we
found.
So
you
think
the
reporter
is
only
able
just
to
do
the
reporting
of
select
for
views,
but
technically
they
are
able
to
edit
the
issue
board
and
that's
causing
kind
of
a
downstream
effects
or
a
negative
impact.
A
A
So
a
lot
of
this
is
basically
come
down
to
organizations
have
very
specific
roles
that
just
simply
do
not
match
the
five
that
we
have,
and
so
with
the
group
that
we
are
working
on
with
amelia
and
andy
and
myself,
we've
begun
trying
to
aggregate
some
of
this
information
or
some
of
those
problems
that
we're
getting
from
feedback
from
users.
A
So
amelia
had
spent
a
bunch
of
time
going
through
this
whole
table
and
categorizing
the
concepts
that
we
see
here
so,
for
example,
like
issues,
are
now
compartmentalized
into
one
particular
section
in
her
work
that
she's
done
for
this
and
then
licensed
compliance
so
going
through
this
whole
table
and
just
trying
to
group
things
into
a
more
of
a
logical
system
instead
of
just
a
table
of
data.
A
The
reason
for
that
is
kind
of
what
we
were
getting
feedback
from
our
users
is
that
our
users
have
a
lot
of
experience
with
various
platforms
with
various
permission
models,
so
they
are
not
necessarily
afraid
of
going
in
and
making
these
granular
changes
or
customized
roles.
So
the
knowledge
or
this
giving
the
the
level
of
expertise
is
quite
high
for
this
sort
of
complexity
and
the
adoption
should
be
pretty
simple
if
we
were
to
try
and
expand
or
iterate
towards
this
direction.
A
A
A
So
the
idea
is
that
we'll
be
at
our
dashboard
view
here,
we'll
go
to
our
admin
settings
and
we'll
have
this
new
section,
labeled
roles
and
permissions.
This
has
not
necessarily
been
defined
yet
again.
This
is
just
a
rough
wireframe,
we're
trying
to
get
feedback
from
users
and
just
to
get
a
kind
of
perspective
on
how
they
feel
about
this,
and
this
is
the
categorization
that
amelia
had
invested
in
trying
to
group
these
topics.
A
So
the
idea
that
we
might
have
our
default
roles
here,
which
would
be
used
as
kind
of
like
a
way
to
for
troubleshooting
or
kind
of
like
a
safety
check
to
make
sure
that
an
organization
can
revert
back
to
a
permission
without
having
to
break
something
or
re-evaluate
or
recreate
these
roles.
So
these
will
be
unmodifiable
kind
of
like
a
zero
state
so
to
speak,
and
then
we
would
have
some
way
to
separate
that
content.
So
an
organization
would
have
their
own
permissions.
A
So
the
idea
is,
we
would
go
and
create
a
new
role,
give
it
a
new
name,
for
example,
incident
manager.
We
would
have
a
role
to
base
it
off
of
so
based
off
of
our
current
five
roles
that
we
have.
We
can
use
that
as
a
template.
So
the
idea
is
that
whenever
you
make
a
selection
off
of
the
template
of
the
five
personas
or
the
five
roles,
that
would
then
change
the
content
within
the
table.
A
So
in
this
example,
a
developer
does
not
have
access
or
ability
to
delete
epics.
So
if
I
were
to
say
well,
I
want
that
permission
I'll,
go
ahead
and
turn
that
on
and
then
we'll
go
ahead
and
create
this
I'll
now
have
my
new
incident
manager,
role
and
I'll
be
able
to
then
apply
that
in
my
in
my
environment.
A
So
let's
go
back
to
the
dashboard
and
we'll
go
back
to
the
members
I'll
invite
a
member
and
I'll
give
them
my
new
role
of
incident
manager-
and
this
is
kind
of
the
the
step
where
we're
at
right
now
to
see
getting
feedback
on.
Does
this
sort
of
set
up
make
sense
what
sort
of
problems
we
might
encounter
in
the
flow?
So
far?
So
far,
we've
already
got
a
number
of
interviews
completed.
Thankfully,
we've
gotten
a
lot
of
feedback
already,
so
our
next
step
is
to
take
that
feedback.
A
The
largest
concern
right
now
is
specifically,
we
need
back-end
resources
to
re-evaluate
the
the
scope
of
the
problem,
because
currently
our
devs
have
told
us
that
our
permissions
are
not
just
confined
to
one
space
in
terms
of
making
changes
in
one
location
will
impact
the
entire
platform
they're
kind
of
all
over
the
place.
A
So
right
now,
like
I
said,
it's
kind
of
a
in
a
research
phase,
and
hopefully
this
will
come
out,
or
at
least
we'll
have
some
better
progress
in
the
next
quarter
or
two,
but
that's
not
until
we're
kind
of
restricted
until
the
back
end
can
kind
of
evaluate
the
problem
and
get
us
some
feedback
from
our
side.
A
I
think
a
lot
of
it's
going
pretty
well,
and
I
think
a
lot
of
that
is
due
to
the
fact
that
we've
been
able
to
collaborate
with
the
three
of
us
together
and
get
this
moving
forward.
It's
been
a
big
problem
that
a
lot
of
users
have
been
asking
for
for
years.
Sadly,
and
it's
just
because
of
the
scope
of
the
problem,
has
always
been
pushed
back
so
hopefully
again
like
I
said
this
will
be
moving
forward
now
that
we
have
more
recess
being
thrown
at
the
problem.
A
A
Okay,
I
don't
see
anybody
typing,
so
if
you
want
to
add
a
question
later
feel
free
to
add
it
and
I'm
gonna
stop
recording.