►
From YouTube: UX: RBAC permissions mapping exercise - CI/CD
Description
Daniel Mora from the Authentication and Authorization group syncs with the CI/CD UX designers to evaluate the permissions mapping effort done so far and investigate next steps to progress the RBAC project.
A
Cool
so
thanks,
everyone
for
joining
I
wanted
to
get
in
touch
with
all
of
y'all,
because
I
am
working
on
a
project
with
the
permissions.
Some
of
you
may
have
already
seen
the
work
that
I've
been
doing
a
couple
of
you
all
have
already
provided
feedback.
So
that's
great.
A
So
just
a
brief
overview
in
case
you're
not
familiar,
I've
been
working
with
Amelia
and
Andy
on
redoing,
the
entire
permissions
architecture
in
the
platform
based
off
of
the
idea
that
we're
going
to
make
customizable
permissions
and
so
Amelia
had
gone
through,
and
the
first
round
of
organizing
the
permissions
based
off
of
what
they
have
here
in
our
documentation
on
this
table
here.
A
So
you
know
analytics
would
be
grouped
as
one
and
then
we
would
try
and
find
out
where
his
clusters
be
gone
to
what
is
a
container
industry
Etc,
so
that
was
the
first
pass
I
did
after
we
had
started.
Looking
at
some
of
this,
we
under
we
started
seeing
a
problem
where,
as
an
example
where,
if
I
were
to
look
at
a
individual
permission
called
view,
project
code
and
I
was
to
disable
this
permission.
A
So
what
I've
done
is
I've
gone
through
and
mapped
all
of
the
permissions
to
try
and
see
if
I
could
find
these
sorts
of
mappings
and
tied
to
this
issue.
Specifically,
the
devs
are
looking
at
consolidating
this
permission
to
view
Pipeline
and
view
pipeline
details
so
that,
instead
of
it
being
two
permissions,
it's
just
one
kind
of
like
consolidating
line
items
here
in
this
table
or
the
same
thing
here.
A
The
idea
is
that,
if
we're
going
to
move
forward
with
having
a
prototype
where
an
admin
can
go
and
toggle
individual
features,
if
we
try
and
minimize
this
complexity,
that
can
help
on
the
back
end
with
the
problem
that
they
describe
here,
that
they
would
have
there
wouldn't
be
a
need
for
overlapping
or
redundant
permission.
So,
in
the
case
of
here
they
have
the
same
access
level.
A
We
wouldn't
be
less
confusion
here
and
then
it
would
make
things
easier
to
undo
or
to
make
changes
within
the
the
code
base,
without
being
so
catastrophic
towards
like
if
you
allow
something
that
they
shouldn't
have
access
to,
they
wouldn't
necessarily
cause
any
sort
of
negative
impact
in
the
in
that
sort
of
permission.
If
you
were
to
enable
that
permission
right,
so
the
reason
I
need
you
all
to
to
sync
with
me
today
is
to
kind
of
go
over.
A
This
vitika
and
Gina
have
already
kind
of
looked
at
this
a
bit
and
I
think
it's
more
or
less
okay,
but
I
just
wanted
to
kind
of
go
through
as
part
of
this
work
that
I'm
doing
here,
where
I
go
through
the
entire
permissions
architecture
and
meet
with
every
team.
A
That
kind
of
has
Insider
impact
with
this
to
make
sure
that
I'm
thinking
of
everything
in
this
model
and
then
also
see,
if
there's
opportunities
to
merge
or
group
things
that
don't
necessarily
need
to
exist
individually
and
so
with
that
I
will
open
the
discussion
for
anyone
who
wants
to
kind
of
jump
in
and
provide
feedback.
B
The
first
question
from
me
Daniel
is
like
what
is
the
like
basis
of
consolidating
like?
Are
you
thinking
of
in
terms
of
page
access,
or
is
it
dissociated?
The
the
primary
permission
is
dissociated
from
the
page
access
and
something
an
entity
of
its
own.
A
So
the
idea
would
be
specifically
in
this
case,
where
view
pipeline
page
and
view
pipeline
Details
page.
The
question
presents
itself:
why
are
these
separate?
What
is
the
use
case
or
the
job
to
be
done
to
have
them
individual,
independent
permissions,
and
so,
if
there
isn't
a
real,
realistic
or
definitive
purpose
for
them
being
separate,
then
can
we
merge
those?
A
The
benefit
is
that
it
reduces
the
code,
the
amount
of
code
that
we
have
and
reduces
things
that
are
it's
touching,
so
it
kind
of
improves
the
security
in
that
instead
of
having
to
watch
or
monitor
two
code
code
points,
you
actually
are
just
looking
at
one
and
then
that
sort
of
logic
would
apply
to
the
whole
project
that
I'm
working
on
right,
so
minimizing
the
code
base
or
reducing
it
in
terms
of
complexity,
as
well
as
what
sort
of
improvement
that'll
present
on
the
front
end
where
an
admin
doesn't
necessarily
have
to
toggle.
A
B
Got
it
so
one
thing
that
I
just
noticed
in
the
link
that
I
just
shared
it's
just
your
list
of
permissions
which
are
specific
to
pipelines
on
the
dots
and
while
looking
at
this
table.
If
you
see
the
we
have
separated
out
view
pipeline,
detail,
speed
view
pipeline
page
and
view
pipeline
tab
in
Mr
and
when
I
kind
of
cross
checked
that
with
the
documentation
that
I
have
in
my
personal
Excel
sheet.
The
only
difference
that
I
see
between
accessing
the
pipeline
list
view
versus
the
pipeline.
B
Tab
in
merge
request
is
that
guests
cannot
access
the
pipelines
in
a
merge
request.
B
So
that's
something
that
I
think
we
should
also
cross
check
with
the
team
if
there
is
a
possibility
to
consolidate
that
with
these
two
permissions
that
you
just
talked
about,
unless
there
is
a
very
compelling
case
of
not
allowing
guests
to
visit
that
particular
job
in
a
mode
request,
but
at
the
same
time
be
able
to
look
at
the
pipeline
list.
View.
A
Well
so
one
thing
I
guess
I
should
probably
clarify-
is
that
this
change
doesn't
necessarily
have
any
reflection
on
guest
reporter
developer
maintainer
owner.
The
idea
being
is
that
as
an
admin,
I
can
then
customize
all
of
these
to
offer
those
individual
permissions.
So
if
a
guest
only
had
access
to
one
particular
permission,
I
could
then
enable
that
they
would
no
longer
be
a
guest,
so
any
sort
of
restriction
that
you're
seeing
by
a
non-member
or
a
guest
not
having
access
to
that
doesn't
necessarily
play
into
this
particular
problem.
A
I,
don't
think,
okay,
apart
from
what
do
they
have
currently
and
can
I
enable
or
disable
that
the
idea
being
that
an
admin
would
then
give
custom
feature
custom
access
to
something
the
impetus
for
the
project
is
our
permissions
are
either
too
permissive
or
too
restrictive.
So
if
somebody
can
come
in
here
and
say,
I
want
a
guest
role
but
I'm
going
to
also
give
them
permission
to
run
a
pipeline
and
then
disable
all
the
other
things
that
could
be
possible.
A
But
we're
looking
more
so
is
that
any
sort
of
problems
that
might
arise
by
making
those
changes
by
if
I
do
allow
that
does
any
sort
of
security
concern
arise
or
again
going
back
to
the
idea
of
merging
stuff.
If
I
merge
a
particular
permission,
does
that
have
impact
elsewhere.
B
Right
in
that
case,
I
think
it
definitely
makes
a
lot
of
sense
to
kind
of
treat
the
pipeline
tab
in
merge
request
the
same
way
as
we
treat
list
view.
The
only
thing
that
I
don't
think
I
have
the
I
have
complete
knowledge
to
comment
on
is
how
that
plays
with
the
access
to
merge
request
page
because,
eventually,
like
the
same
pipelines,
are
also
going
to
appear
on
the
python
list
view.
B
A
Yeah
I
guess
that's
also
something
where
I
was
looking
for.
Your
knowledge
is
that
so,
as
it's
grouped
so
far,
we're
just
looking
at
this
CI
CD
screen,
but
it
doesn't
necessarily
just
stop
there
right.
So
it
touches
merger
quests,
and
you
know,
parts
of
the
repo
right.
So
are
there
connections
there
that
I'm
not
linking
correctly
because
they're
in
these
little
boxes
right?
Should
this
be
a
more
connected
prototype
or
not
prototype
but
connected
mapping?
Here.
B
B
So
I'm,
just
thinking
of
this
hypothetical
scenario
that.
A
C
A
B
B
A
A
Kind
of
what
I'm
wondering
is
that
if
you
would
be
able
to
see,
merge
requests
or
if
you
don't
have
merge
requests,
you
wouldn't
be
able
to
see
Pipelines.
B
I,
don't
think
so,
I
think
the
whole
Magic.
If,
if
I'm
not
allowed
to
look
at
merge
requests,
then
of
course
I
cannot
access
that
page
and
the
tab
is
anyway
not
going
to
be
available
to
me.
C
C
If
you,
if
you
can't
access
pipelines,
though,
can
you
access
jobs,
because
I
was
wondering
what
the
difference
between
the
pipelines
list
page
and
the
details
pages
and
I'm
wondering
if
it's
because
the
details
shows
the
jobs
within
a
pipeline
and
sometimes
specific
users
can't
see
the
jobs
because
they
contain
whatever.
B
C
This
is
yeah
and
the
list
you
can
see
like
there's
a
list
of
jobs
down
there
too,
like
in
its
own
tab
that
and
then
you
could
like
view
jobs
but
technically
I
guess
you
could
do
that
from
the
pipeline
mini
the
little
mini
graph
as
well.
Yes,
I.
B
B
Yeah,
here's
the.
B
A
A
A
And
that's
kind
of
what
I'm
also
curious
is,
if
you
were
to
disable
that
what
does
it
look
like
from
the
UI
that
basically
just
disappears
these?
Can
these
navigation
items
I?
Guess
that's
how
we
are
handling
thing
right
now,
I
mean
with
just
basic
permissions
right.
If
you
just
don't
have
access,
nothing
will
appear
right.
This
tab
would
go
away
yeah.
B
A
B
Who
has
access
to
the
merge
request?
Has
access
to
the
pipeline
widget.
B
There
is
one
restriction
that
they
cannot
run
a
pipeline
if
the
pipeline
fails,
but
I
think
recently
we
made
a
change
that
if
a
pipeline
fails,
developers
should
have
access
to
the
Run
pipeline
button,
which
is
inside
the
pipelines,
tab.
B
B
Oh,
that's
oddly
placed
okay
that
was
not
available,
I
think
to
non-maintainers,
if
I'm
not
wrong,
I'll
check,
and
so
if,
if
a
pipeline
fails
for
a
merge
request,
any
other
developer
working
with
that,
you
probably
could
not
run
the
pipeline
manually.
B
A
But
for
some
reason
you
could
see
you
could
see
the
pipelines
if
for
some
reason
they
were
turned
on,
but
you
just
couldn't
see
this
content
and
maybe
the
changes
yeah
and
the
commits.
C
A
A
A
The
example
we're
using
I
think
is
is
a
fair
example,
but
it
might
be
like
an
outlier
case
right.
I
think
the
more
relevant
example
might
be.
I,
don't
want
an
external
contributor
to
see
code,
but
they
can
look
at
the
the
merger,
Quest
and
where's.
The
merge
request
real
quick.
A
B
A
So
disabling
pipeline
might
not
be
an
example
that
would
be
valid,
but
it
is
the
one
that
they're
working
on
right.
Where
was
that
issue?
A
I've
lost
the
issue,
oh
here
it
is
where
they
want
to
merge
these
two.
A
A
C
B
B
But
jobs
are
acts
like
permission,
for
jobs
are
definitely
tied
to
these.
So
if
somebody
has
access
to
view
pipeline,
they
can
definitely
look
at
the
job,
details
and
job
list.
A
B
That's
correct
so
like
out
of
the
12
trigger
sources
for
that
initiative
pipeline
come,
it
is
I,
think
one
of
them
and
commit
is
again
related
to
the
changes
and
like
for
security
purpose.
If
the
changes
have
to
be
hidden
from
someone
what
happens
to
the
pipeline
permission.
A
C
One
other
thing
to
to
throw
in
there:
it's
not
fully
live,
yet
it's
only
enabled
for
this
project
for
git
lab
projects.
But
if
you
go
to
CI
CD,
we
also
have
artifacts
now,
and
that
depends
on
jobs
and
Pipelines.
So
it's
like
the
way
that
we
think
I
was
just
saying.
If,
if
you
don't
have
access
to
a
pipeline,
you
don't
have
access
to
the
jobs,
then
you
also
won't
have
access
to
the
artifacts.
A
A
So
I
guess
that's
something
that
I
need
help
with
over
here
is:
can
you
help
and
fix
this
tree
with
me
to
make
sure
that
the
links
look
correct
from
your
perspective?
A
Yeah
so
like
I
think
that's
my
my
ask
for
the
team.
Is
that
just
double
check
what
I
have
so
far
and
make
new
links
or
break
links,
as
you
see
relevant
to
your
group
and
then
also
just
you
know,
feel
free
to
note
or
call
out
anything
that
might
be
weird
or
problematic,
and
we
can
talk
about
it.
Async
and,
like
I,
said
I'm
also
going
to
pass
this
through
with
the
devs.
So
they
can
see
what
we're
talking
about
in
our
concerns.
B
C
C
C
A
Cool
so
yeah.
This
has
hopefully
been
helpful
and
I
hope.
I
have
explained
what
I'm
trying
to
do
correctly.
A
A
Okay
cool
so
then
yeah,
like
I,
said
when
you
have
opportunity.
Please
add
some
changes
here
or
links
that
I'm
missing.
That
you
think
should
belong
here,
especially
like
across
these
sorts
of
features.