►
From YouTube: Custom Roles Lunch and Learn - 2023-03-07
Description
Lunch and Learn about the technical details of the custom roles feature.
Agenda/notes doc open to all GitLab: https://docs.google.com/document/d/1x2ExhGJl2-nEibTaQE_7e5w2sDCRRHiakrBYDspPRqw
A
Right
and
I
think
we
can
start
thanks
everyone
for
joining
for
the
first
lunch
and
learn
from
the
oath
team
on
customizable
roles
and
I
will.
My
topic
will
be
the
first
one.
I
will
talk
about
the
initial
Discovery,
the
motivation
behinding,
the
introducing
the
feature
and
the
technical
Discovery
we
did.
A
So,
as
everyone
knows,
the
the
building
rows
we
have
in
gitlab
isn't
a
very
flexible
I
think
the
first
feature
we
implemented
to
make
it
more
flexible
was
to
allow
developers
to
create
projects.
I
think
that
was
added
five
years
ago,
but
we
soon
realized
via
bug
reports
that
there's
a
few
issues
related
to
that
one
is
that
there
are
a
couple
of
dependent
permissions,
for
example,
to
project
creation.
A
So
one
of
the
bug
was
that
once
someone
as
a
developer
created
a
new
project
and
try
to
push
a
readme
via
the
O2
generated,
read
me
the
default
readme,
but
it
failed
because
there
was
a
dependent
permission
and
it
was
also
just
made.
Basically
the
approach,
creation
and
check
more
complex,
and
if
we
wanted
to
like,
introduce
more
and
more
flexibility
into
permissions
that
way
that
isn't
really
manageable
it
would.
A
The
complexity
of
the
code
would
soon
go
out
of
hand,
so
that
was
basically
the
the
motivation
to
figure
out.
How
can
we
create
or
make
it
more
flexible?
We
soon
received
more
and
more
issues
and
feature
requests
to
like
make
other
permissions
more
flexible,
but
we
decided
to
postpone
motion
and
so
the
more
generic
solution
we
started
with
the
with
the
technical
Discovery.
A
The
first
is:
we
have
a
in
the
documentation,
a
static
permission
table
and
the
problem
with
the
with
the
static
permission
table
is
that
there's
like
no
one-to-one
relation
to
the
permissions
in
the
code
base.
So
the
the
permissions
in
the
code
base
are
more
Dynamic.
Some
of
them
will
rise
on
licensing
checks.
Some
of
them
relies
on
on
feature
checks.
The
documentation
is
more
how
we
expect
certain
permissions
to
work,
but,
as
I
mentioned,
there's
like
no
one-to-one
permission
as
features
are
developed.
A
We
try
to
like
keep
it
up
to
date,
and
we
always
so.
For
example,
when
a
feature
flag
is
rolled
out,
then
it
was
like
the
related
permission,
if
there's
any,
but
since
there's
a
game
between
the
two
there's,
obviously
a
documentation
issues.
Sometimes
these
documenting
issues
can
happen
that
the
documentation
has
different
permission
or
different
access
level
than
the
code
has,
or
we
also
had
bug
reports
when,
for
example,
a
certain
permission
was
checked
in
the
API,
but
it
required
a
different
access
level
on
the
UI.
So
there's.
C
A
Basically,
a
single
source
of
truth,
but
as
I
mentioned
it's
like
not
not
easy.
We
we
figured
out.
We
can
evaluate
the
permissions
for
a
certain
instant
setting,
so
we
set
some
certain
feature,
Flags
or
add
a
licensing,
and
then
we
can
evaluate,
but
still
there's
like
more
permissions
in
the
code
base.
We
need
to
like
map
how
each
of
them
relates
to
the
permission,
table
and
they're
still
ongoing
discovery
on
this.
A
We
are
also
thinking
about
consolidating
permissions,
because
there's
a
high
level
of
redundancy
there
and
probably
most
of
them,
can
be
simplified
and
the
second
part
of
the
of
the
technical
Discovery.
How
are
we
going
to
actually
introduce
more
generic
solution
to
make
the
roles
more
customizable
and
we
came
up
with
a
a
technical
Discovery,
an
initial
plan,
how
we
are
going
to
do
that?
Basically
introducing
a.
A
In
the
code
base
and
attacking
a
phase
manic
permission
check
related
performance
issues.
One
of
the
main
concern
was
how
if,
if
there
will
be
like
any
degradation
regarding
the
performance,
so
we
wanted
to
like
first
evaluate
introduce
a
this
technical
Discovery
behind
the
feature
flag
and
ask
for
the
help
of
the
okay
to
make
sure
that
there's
a
no
performance
degradation
introduced.
A
A
The
the
gem
is
not
well
maintained,
and
now
we
have
a
standards
to
introduce
external
dependencies
for
the
gem,
so
that
data.
The
conclusion
of
the
database
thing
was
that
it's
better
to
spend
our
time
on
making
sure
that
the
performance
is
better
than
thinking
about
storage,
so
that
was
the
two
parts
of
the
technical
Discovery
and
I
will
hand
over
to
Jesse
to
talk
about
the
MVC
on
read
code.
F
E
C
E
It
out
to
everybody-
and
we
are
in
1510
now
so
that
was
just
a
few
weeks
ago
in
the
the
note
stock
here,
I
just
did
a
little
table
to
kind
of
show
you
you
know,
based
on
the
technical
discovery
that
imra
did
before
I
was
even
on
this
team,
like
kind
of
how
we
architected
it
just
look
at
the
database
level,
because
there
is
like
another
path,
we
could
have
gone
down
right
where
we
were
like.
Let's
build
a
whole
new
permission
system
I.
E
Actually,
when
I
first
joined,
did
some
investigation
into
Zanzibar,
which
is
this
white
paper
that
Google
put
out
about
kind
of
a
very
performant
permission
system
and
and
other
companies
I.
Think
Airbnb
was
one
of
them
built
this
whole
new
permission
system.
Permissions
are
a
problem
for
every
software
company
and
they're,
always
challenging
from
a
performance
perspective,
so
anyways,
our
our
MVC.
Our
iterative
approach
was
to
build
it
on
top
of
our
existing
infrastructure
in
our
assisting
in
our
existing
mono
repo.
E
So
we
already
have
namespaces
right
in
the
gitlab
code
base.
Namespace
can
be
a
project
or
a
group,
and
then
member
records
are
associated
with
those
namespaces.
So
there's
a
members
table
a
member
has
a
namespace
ID
on
it,
so
you
would
know
which
namespace
it
is
associated
with.
We
introduced
a
new
table
called
member
role.
This
will
come
up
again
in
inro
section
on
challenges
or
like
things
we're
thinking
about,
but
in
the
database
representation
of
custom
rules.
They
are
called
member
roles
because.
E
I
hope
I
get
this
explanation
right,
I
guess!
The
idea
is
that,
right
now
we
are
thinking
of
these
as
custom
roles,
but
there
is
a
potential
future
where
they're
just
role
like
this
is
how
we
do
roles.
We
don't
have
this
idea
of
a
static
role
anymore,
and
so
these
custom
roles
might
become
just
regular
roles.
So
member
role
was
like
a
more
generic
name
for
that.
E
It's
a
member
role
is
created
on
a
root
namespace,
so
a
group-
and
it
also
has
a
base
access
level
which
those
of
you
who
don't
work
with
us
stuff
every
day
might
not
know
how
access
levels
work.
I
actually
put
this
in
the
glossary
at
the
top
access
level.
This
is
something
that
took
me
a
little
I'll
understand,
so
access
levels
are
integer
values
and
they
map
to
our
current
static
permissions,
so
I
think
guest
is
10.
Is
that
right?
E
They
go
up
the
more
commissions
you
had
on
like
owners
40.,
and
we
use
these
everywhere,
like
it's
kind
of
this
funny
dual
world
right,
where
we
talk
about
owners
and
developers
and
reporters
and
then
the
code,
like
those
terms,
don't
show
up
very
much.
It's
all
like
access
level,
integers
that
are
saved
as
constants,
so
anyways
with
member.
E
E
Know
if
the
conclusion
came
from
the
iteration
office
hours-
or
it
was
before
that,
but
it
was
like
Hey
we've
heard
a
lot
of
feedback
from
our
customers.
That
guests
should
be
able
to
read
code
like
they
would
like
to
have
a
guest
user
that
can
just
read
code
because
normally
a
guest
user
on
a
private
repository
with
our
static
roles
doesn't
see
anything
like
you
get
to
the
project
and
it's
just
like
hey.
You
know
this
is
a.
E
This
is
a
project
that
exists
and
you
really
don't
have
any
information
aside
from
that
as
a
guest.
So
we
added
this
Boolean
attribute
called
read
code,
and
so,
if
you
are
one
of
the
many
people
who
raise
your
hands
and
said,
you
tried
this
MVC,
what
you've
seen
is
that
a
guest
with
this
custom
role
can
go
in
and
actually
read
code
in
a
project.
So
it's
exciting
so.
C
D
Have
a
quick
question:
yeah
wondering
if
the,
if
the
one
of
the
considerations
in
making
the
member
role
as
part
of
the
namespace
had
to
do
with
one
like
one
of
the
challenges
of
doing
development
for
git
lab
is
that
you
have
to
take
SAS
and
self-manage
into
consideration.
So
was
that
a
consideration
when
doing
the
MVC
that
we
don't
have
this
at
the
instance
level,
because
then
it
wouldn't
be
available?
This
ass.
A
Yeah
I
think
there's
a
there's,
an
ongoing
initiative
by
the
or
the
organization
group
or
not
the
ports
group
to
handle
or
basically
make
the
experience
between
self-managed
and.com
more
consistent.
So
there's
a
misalignment
because
we
have
instance
level
on
on
self-hosted
and
which
doesn't
exist,
on.com
and
I
think
it
it
is.
We
want
to
introduce
an
organization,
a
new
level
which
is
basically
going
to
be
a
root
group
and
and
consolidate
consolidate.
F
F
E
Okay,
yeah
and
then
just
from
like
a
database
design
perspective
just
so
the
custom
role,
the
member
role
it
has
to
belong
to
a
root
group,
but
you
can
associate
it
with
any
of
the
member
records
in
the
hierarchy.
So
even
if
I'm,
a
member
of
a
project,
I
can
still
have
that
membership
be
a
custom
role
using
the
custom
role
of
the
root
group
of
that
project.
E
Learned
a
lot
about
root
groups,
interesting
world,
so
anyways
when
I
showed
up
in
the
scene
here,
emra
and
Hannah
and
others
had
done
a
lot
of
pre-work
so
that
really
implementing
this
MVC
was
like
pretty
simple.
It
was
like:
okay,
like
this
is
what
I
have
to
do
got
it?
Did
it
had
the
code
ready,
pushed
up
my
code
and
then
it
was
like
spec
failure,
spec
failure,
spec
failure
speculate.
E
All
the
specs
I
was
feeling
because
we
have
these
n
Plus
One
specs
in
many
parts
of
our
code
base
and
by
introducing
custom
roles,
we
created
a
massive
n
plus
one
issue.
I,
don't
know
who
here
has
dealt
with
our
access
level,
our
project
authorizations
preloaders
anyone
anyone?
Yes!
So
we
already
have
preloaders
everywhere
the
way
that
we
do
permissions
checks
now.
Are
we
have
these
preloaders?
They
kind
of
find
all
of
your
memberships,
which
there
are
many
kinds.
There
are
direct
memberships.
E
There
are
inherited
memberships,
there
are
shared
memberships,
there
are
implicit
memberships
of
the
parent
group
of
project,
so
they
find
all
of
those
for
a
user
or
a
group
of
users
and
a
project
or
a
group
of
projects,
and
they
pre-load.
All
of
those
I
believe
it's
saved
in
redis.
Is
that
right
is
that
the
caching
mechanism
sure.
C
E
Think
that
it
may
also
do
something
in
revise,
not
sure,
that's
a
loopback
on
that.
But,
yes,
project
authorizations
are
pre-saved
in
the
database
to
know
to
calculate
like.
Basically
what
can
this
user?
What
role
do
they
have
on
this
project
because
they
might
be
associated
with
the
project
in
like
five
ways?
And
so
you
have
to
say
well
what
is
their
Max
role
and
we
use
sermon
so
suddenly
with
custom
roles,
we've
really
thrown
a
wrench
into
that
whole
system,
because
we're
like
and
in
addition
to
you
know,
having
an
access
level.
E
E
I
think
the
general
guidance
is
put
upon
a
feature
flag,
roll
it
out
slowly
like
make
sure
that
things
aren't
breaking.
But
permissions,
as
all
of
you
know
who
worked
under
anything
related
to
permissions,
are
everywhere.
We
do
permissions
checks
everywhere.
We
do
many
of
them,
and
so
even
a
moderate
performance
problem
with
permissions
could
cause
a
really
large
problem
with
gitlab
as
a
whole.
So
this
was
a
super
clever
approach.
E
We
rolled
out
the
user
feature
flag
to
50
of
users
and
then
we
slowly
rolled
out
the
the
custom
roles
feature
flag
to
groups
and
we
made
sure
we
like
kind
of
evaluated
okay
users
with
and
without
the
feature
flag.
What
are
the
request
times
to
these
endpoints
that
are
using
the
custom
roles
and
luckily
I
was
very
shocked
by
this.
We
didn't
have
to
do
any
more
Performance
Tuning.
Once
we
started
looking
at
then
times.
A
A
F
A
Group
sharing,
yes,
so
there's
actually
a
lot
of
edge
cases
which
need
to
be
considered
and
not
just
from
engineering
perspective
from
product
perspective
as
well.
So,
for
example,
one
of
the
questions
whether
in
a
project,
if
invited
to
private
group,
they
should
see
each
other
there's
like
a
lot
of
pros
and
cons
for
each.
A
But
it's
it's
a
it's
a
really
tricky
issue,
and
so
we
haven't
implemented
group
sharing
for
customizable
roles
and
it's
it's
also
a
tricky
issue
because,
as
we
mentioned
already,
the
custom
laws
can
be
created
on
the
root
group
levels.
So
it's
scoped
to
a
single
group
hierarchy
on
our
organization,
but
groups
can
be
shared
across
group
hierarchies.
A
A
So
that's
one
of
the
questions
we
need
to
resolve
and
the
second
one
I
already
mentioned,
as
always
comes
up
with
group
sharing
is
performance
because
it
complicates
querying
a
lot
and
we
might
probably
need
to
do
the
the
same
performance
testing
we
did
with
the
previous
rollout
just
to
make
sure
that
there's
no
performance
degradation
during
the
technical
MVC.
We
also
investigated
a
few
backup
plan
in
case.
We
need
to
do
something
else.
A
Basically,
the
the
biggest
help
from
performance
wise
can
come
from
the
group
project,
consolidation
which
organization
team
was
working
on
also
so
now
now
the
pods
team,
I
think
and
because,
because
authorization
checks
can
be
very
complex,
as
we
mentioned,
we
need
to
like
check
sharing.
We
need
to
check
inheritance,
we
need
to
check
direct
membership
and
a
lot
of
things.
A
If
we
consolidate
groups
and
projects,
we
can
eliminate
many
parts
of
this
complex
query
and
make
it
much
simpler.
So
we
basically
wanted
to
like
figure
out
if
we
need
to
tackle
a
group
project
consolidation
first
before
we
can
introduce
custom
rules,
but
so
far
it
seems
custom
rows
can
go
ahead
and
the
next
topic
is
naming
Jesse
already
mentioned.
A
A
If
you
have
the
static
building
rows
and
we
have
the
customizable
raws
and
they
live
next
to
each
other
and
ideally
from
architecture
standpoint,
there
should
be
a
single
system,
so
in
the
future
free
My3
Factor
the
existing
static
rows
as
a
as
a
fixed
roles
in
the
in
the
database.
That
cannot
be
changed
and
if
we
do
that
we
can
have
a
single
system.
A
So
if
we
consider
that
the
member
role
name
might
make
more
sense
than
customizable
or
but
this
would
mean
a
huge
refactor,
so
we
haven't
decided
and
and
committed
on
the
approach
yet.
But
these
are
the
things
we
consider
and
then,
during
the
technical
Discovery
we
also,
we
were
also
thinking
about
creating
roles
where
permission
can
be
denied
or
allowed.
A
But
we
soon
realized
that
allowing
only
additive
custom
roles
would
make
the
architecture
much
simpler
and
the
implementation,
because
there's
a
a
lot
of
edge
cases
around
around
how
we
calculate
the
effective
permission
in
a
project
or
a
group
for
a
for
a
single
number.
So
if
we
also
allow
preventive.
A
Even
more
complex
and
the
the
effective
static
wall
for
a
user
since
the
access
flows
down,
we
just
take
the
the
maximum
of
all
available
of
all
available
memberships.
A
user
can
have
whatever
type
and
this
Rhymes
better
with
additive
rows.
When
we
just
need
to
like
figure
out,
if
there's
any
custom
role
that
allows
the
permission,
then
we
allow
it.
So
it's
much
more
aligned
with
the
existing
static
walls
and
yeah
reasoning
and
debugging
is
also
much
simpler.
With
with
additive
only
roles.
A
And
we
also
soon
realized
that,
oh
sorry,
one
more
thing
regarding
additive
only
custom
laws,
so
we
don't
lose
any
of
the
capability
we
had
previously,
because
if
a
permission
should
be
prevented
for
a
custom
role,
a
user
can
create
the
same
custom
row
with
a
lower
base
access
level
and
just
enable
all
of
the
permissions,
except
for
the
one.
So
we
can
still
have
the
same
functionality
via
additive
rows
and
the
custom
rows
cannot
be
edited
once
used.
So
the
reasoning
behind
that
is
a
as
I
already
mentioned.
A
And
if
you
imagine
the
scenario,
when
there's
like
a
thousand
members,
poop
hierarchy,
it's
really
really
hard
to
to
to
understand
if
changing
a
custom
role.
What
are
the?
What
are
the
far-reaching
implications
of
of
that
edit?
Because
the
custom
laws
can
be
used
like
on
any
level
and
they
also
conflict
with
with
other
sources
of
memberships?
A
It's
it's
really
really
hard
to
foresee
the
implication
habit
of
an
edit.
So
we
decided
to
not
allow
it
if
we
go
ahead
and
require
the
admin
to
create
a
new
custom
role
and
then
assign
all
of
the
users
to
that
to
the
neural.
That's
much
more
of
a
of
an
explicit
action
than
just
changing
the
the
existing
or
the
already
assigned
a
custom
role,
and
the
last
one
is
a
validating
the
access
level
of
the
membership
and
the
base
access
level
of
the
custom
role.
A
So
this
is
important,
as
we
mentioned,
there's
like
these
two
systems,
next
to
each
other,
the
static
building
rules
and
the
customizables,
and
we
need
to
make
sure
that
those
Works
in
harmony
until
we
have
these
two
systems,
and
so
we
enforce
this
validation,
that
the
two
levels
need
to
be
need
to
be
the
same.
So
if,
if
there
would
be
like
a
difference
between
between
the
two,
it
would
be
really
hard
to.
We
need
to
make
sure
or
figure
out
which
has
priority
over
the
other.
A
It
will
also
complicate
how
users
reason
about
the
effective
permission
or
the
effective
access
level
when
considering
this.
So
we
decided
that
until
we
have
these
two
systems,
the
base
access
level
and
the
access
level
must
match
for
for
the
two
and
that's
the
part
on
limitation
and
challenges
and
I'm
handing
back
to
Jesse.
G
C
G
A
There's
actually
an
ongoing
discussion
just
from
yesterday,
so
you
might
get
like
different
answers,
but
I
I
think
yes,
so
I
think
the
idea
was
that
we
can
add,
like
any
permission
to
a
custom
role.
So
even
if
even
if
the
the
base
access
level
for
the
for
the
custom
role
is,
for
example
reporter,
then
you
can
basically
like
add
every
single
permission
and
admin
has,
except
for
one
if
you
wish,
but
Jesse
might
have
a
some
thoughts
on
that.
E
I'm
just
linking
to
the
live
discussion
in
an
issue
because
it
is
a
live,
a
live
issue
and
I
I
think
the
answer
Eduardo
is
going
to
be
yes,
I.
Think
you're,
going
to
be
able
to
add
to
group
give
a
guest
a
permission
that
usually
does
an
owner
has
I
think
the
challenge
is
going
to
be
primarily
a
ux
challenge.
So
I
think
the
scenario
that
I
was
thinking
of
is
day.
You
want
to
give
a
guest.
E
E
We
can
make
that
technically,
like
technically
that's
going
to
be
possible
and
that
guest
user
even
get
to
the
menu
that
has
the
delete
button
that
because
there
are
going
to
be
maybe
dozens
of
other
permissions
checks
to
get
to
that
point.
So
we
have
to
logically
group
permissions
or
like.
Basically,
we
want
to
make
sure
that
we're
not
letting
our
customers
create
custom
roles
that
are
not
going
to
actually
work
for
them,
especially
in
the
web.
Ui
I.
Think
in
general,
with
the
API
permissions
are
much
more
straightforward.
It's
like.
E
Can
you
do
a
get
request
to
this
endpoint?
Can
you
do
a
post
request
at
the
endpoint
if
we
were
only
managing
an
API
I
think
this
would
all
be
a
lot
more
straightforward,
but
in
the
UI,
because
you're
clicking
to
different
pages
to
get
to
different
sub
Pages,
there's
a
risk
of
allowing
infinite
flexibility
might
create
a
bad
ux.
G
E
B
E
E
We
thought
yay,
we
did
it
and
then
it's
like
okay,
what's
next
and
what
I
I
feel
like
this
has
been
for
me,
a
really
like
eye-opening
experience
or
a
very
like
seeing
the
world
in
a
different
way,
because
the
past
few
Milestones
I
feel,
like
I've,
been
really
heads
down,
making
sure
that
this
first
MVC
could
launch
and
be
usable,
and
then
we
got
there.
And
then
you
know
you
know
that
Meme
about
like
draw
the
circles
for
the
owl,
like
you
draw
two
how
to
draw
an
L.
You
draw
a
circle.
E
You
draw
another
Circle
and
then
the
step
three
is
like
and
then
draw
the
rest
of
the
owl.
It's
like
just
just
do
it.
So
it's
like
we've,
we've
got.
We
drew
our
circles,
that's
our
MVC
and
then
it's
like
and
now
customize
everything
right,
just
customize
everything
and
a
big
part
of
this.
Like
Emma,
already
said
it's
going
to
be
consolidating
our
existing
permissions.
E
But
it's
like
you're
scrolling
on
that
page
you're,
scrolling,
you're,
scrolling,
you're
scrolling
there's
been
an
effort
going
back
a
while
to
consolidate
those
permissions,
and
that
was
very
much
focused
on
okay,
like
what
in
the
docs
can
be
smooshed
together,
just
so
that
it's
like
easier
for
customers
to
understand
how
our
permissions
work
today.
This
isn't
even
exactly
related
to
custom
roles.
E
So
that's
an
effort
and
we
actually
have
an
issue
for
this
Milestone
that
I've
been
working
on
for
consolidating
two
of
those
just
to
see.
Can
we
consolidate
these
I
started
working
on
that
and
quickly
realized
that
there
is
no
one-to-one
mapping
of
a
permission
in
our
docs
to
an
ability
in
the
code
right.
So
a
declarative
policy
is
our
permissions.
E
E
E
Like
or
it's
like,
a
simultaneous
like
make
a
little
bit
of
progress
on
the
project
like
add
another
customizable
permission,
but
at
the
same
time
like
be
thinking
further
down
the
road
and
kind
of
make
sure
that
we're
designing
a
system,
that's
going
to
be
scalable
because
with
700
there
are
over
700
abilities
in
our
policy
files.
If
we
just
went
through
and
made
each
of
those
customizable
one
by
one,
we're
going
to
be
building
this
feature
forever,
and
we
don't
want
that.
E
E
F
First
of
all,
I
think
you
should
celebrate
for
more
than
three
minutes,
because
this
is
a
great
great
accomplishment,
so
Kuda
studio
for
doing
that
and
yeah.
My
first
question
is:
are
you
going
to
prepare
prepare
a
guidance
for
teams
regarding
adding
new
abilities
permissions
so,
for
example,
if
it's
is
it
going
to
be
a
new
standard?
F
If
you
adding
a
new
ability,
it
needs
to
go
to
custom
models
as
well,
or
it's
going
to
be
like,
depending
on
the
team's
I,
don't
know
thinking,
because
I
can
see
that
you
know
having
too
many
granular
permissions.
The
customers
can
also
be
confusing
for
users,
especially
when
we
add
the
UI
UI
section
to
to
configure
them.
E
E
Today,
it's
very
difficult
to
determine
who
owns
a
permission.
So
when
you
say
when
a
team
adds
a
permission,
it's
like
we
don't
really
track
that
in
any
way
and
then,
if,
if
we
want
to
like
want,
if
I
want
to
refactor
a
permission,
it's
a
manual
process
of
like
diving
through
git
history,
to
figure
out
who,
which
team
might
know
about
this
permission
and
like
own
it
so
I
think
we
need
to
encode
some
version
of
ownership.
E
Emra
suggested
something
similar
to
what
we
do
for
database
tables
today,
and
what
was
the
other
thing?
Oh
in
in
terms
of
the
changes?
Yes
like
I
think
we
I
was
just
in
the
back
end
pairing
session
last
week.
I
was
asking
folks
about
like.
Is
there
a
Robocop
rule?
We
could
add
that
basically
doesn't
allow
anybody
to
add
a
new
policy
like
a
new
ability
to
apology.
Like?
E
Can
we
just
like
stop
everything
and
make
people,
because
we
want
to
consolidate,
and
so
we
want
to
make
sure
that,
as
we're
consolidating
permissions,
people
aren't
just
like
throwing
new
permissions
in
on
the
side
like
that.
We're
actually
creating
an
adhesive
system.
So
I
I
think
we
will
need
to
introduce
some
kind
of
automated
check,
not
necessarily
to
say
you
can't
add
any
more
abilities.
But
it
needs
to
be
like
named
in
a
certain
way
and
yeah
considered
in
a
certain
way.
F
A
Then
I'm
going
to
read
rohit's
question:
it's
not
on
the
call,
a
great
work
on
on
customers
and
thanks
a
lot
for
providing
a
detailed
context
on
the
topic.
Much
appreciate
much
appreciated.
I
do
a
question,
though,
as
a
part
of
the
work
on
custom
roles.
Are
there
any
plans
on
providing
a
capability
like
AWS
IAM
policy
simulator,
which
lets
a
user,
see
the
permission
applied
to
a
principal
in
a
given
context?
A
A
feature
like
this
would
be
extremely
helpful
to
our
customers
and
ourselves
to
figure
out
what
permissions
apply
to
a
user
project
group
in
a
given
context,
especially
if
a
custom
raw
is
assigned
to
them.
So
I
wasn't
aware
of
the
policy
simulator,
but
this
is
something
I
talked
about
previously
that
when
about
editing
custom
roles,
so
when
someone
on
admin
edits
a
custom
laws,
it's
very
hard
to
like
foresee
the
the
changes
they
have,
but
I
think
this
IAM
policy
simulator
would
be
a
great
hub
for
that.
A
There's
no
existing
issue
to
integrate
to
it,
but
I
think
it's.
It's
definitely
something
that
we
shouldn't
want
to
consider
in
the
future.
Also,
even
if
we
just
consider
current
permissions,
even
without
customizable
roles,
I
think
there's
a
there's
a
lot
of
misunderstanding
because
of
the
complexity
on
how
it
works
and
also
there's
bugs
in
the
API
that
sometimes
the
the
members
API
Returns,
the
the
wrong
access
level
and
I
think
there's
this
policy
simulator
would
help
both
systems
to
understand.
B
That's
true,
but
we
I
have
a
a
sort
of
generic
issue
which
we
haven't
filled
out
much
detail
yet
in
this
kind
of
says,
you
need
to
be
able
to
see
what
role
your
users
have
and
what
constitutes
that
role
and
then,
especially
if
we
start
throwing
in
inheritance
and
group
sharing,
it
becomes
complicated
quickly
to
see
that
information
so
I've.
So
let's
say
at
this
point:
we
have
a
placeholder
for
this
concept,
but
we
haven't
decided
yet
how
to
implement
it.
G
B
B
D
A
A
I
will
read
the
next
question
as
well
from
roid.
Does
the
custom
rows?
Work
also
include
adding
support
for
fine
grade
Scopes
to
our
API.
Github
has
already
been
supporting
buying
grain
scopes
for
a
few
years
now,
and
they
took
it
a
step
further
last
year
by
introducing
support
for
fine-grained
personal
access.
Token.