►
From YouTube: Customizable permissions sync with the Govern team
Description
We discuss allowing an admin to prevent group maintainers from changing branch protections with a customized role.
A
A
So
yeah,
you
were
saying
how
you
have
a
situation
where
maintainers
can
still
change
Branch
protections,
and
you
want
to
find
a
way
to
prevent
that.
Yes,.
B
A
B
A
Our
current
implementation
will
only
be
additive
permissions,
so
an
example
being
that
I
can't
subtract
or
remove
that
permission
from
the
ability
for
that
maintainer.
So
in
this
case,
you
would
need
to
create
a
custom
developer
role
with
the
maintainer
permissions
that
you
want
that
do
not
have
that
permission
now
in
the
future.
The
way
this
is
supposed
to
work
or
the
way
that
we
want
this
to
work
for
the
rest
of
the
groups
is
that
you
will
be
able
to
then
customize
or
create
changes
within
this
permission
table.
A
So
one
of
the
things
we're
doing
is
we
are
unifying
or
merging
permissions
as
sort
of
the
MVC,
so
the
first
one
we
merged
was
to
view
you
Branch
details
or
view
pipeline
details
and
edit
pipeline
details.
So
in
this
example
of
merging
these
permissions,
your
team
would
be
able
to
do
something
similar
in
regards
to
perhaps
making
changes
to
this
particular
permission,
but
that's
something
that
you'll
need
a
test
first,
obviously,
but
you'd
want
to
go
through
the
standard
process
of
just
like.
A
How
is
this
going
to
work
in
the
larger
environment
and
that's
sort
of
what
I'm
trying
to
work
on
a
process
to
allow
all
the
other
groups
and
stages
to
go
and
create
and
customize
the
permissions
table
to
make
them
more
I,
don't
want
to
say
individualized
but
more
appropriate
for
their
feature.
So
in
this
case
for
your
feature,
you
want
to
prevent
that
particular
permission,
but
we
don't
have
that
ability
to
remove
that
permission.
A
So
the
First
NBC
of
that
proposal
would
be
to
create
the
developer
role
and
then
add
the
permissions
from
maintaining
that
you
want
minus
that
that
one
branch
protection
permission.
So
then
they
won't
have
the
ability
to
enable
disable
permissions
yeah
that
might
be
quite
a
bit
down
the
road
in
the
future.
So
I
don't
know
if
the
The
Proposal
you
had
made
with
the
check
boxes.
If
you
want
to
show
that
if
that
would
be
the
faster
proposal.
B
Yeah,
so
I
was
thinking
if
that's
possible
in
the
future.
So
now
what
we
can
do
is
like
we
can
just
do
this
like,
for
example,
create
a
new
policy,
and
it
says
overwrite
settings
so,
for
example,
like
like
this
is
like
the
one
I
showed
you
before,
like
with
those
checkbox
is
like
in
each
policy.
You
enable
that
so
I
can
also
create
a
new
policy
which
says
like
for
overwrite.
This
settings
is
enable
what
product.
A
B
I
think
in
the
future
it
could
be
easier.
It's
not
size
project
who
says
row
it's
like
if
they
create
a
new
row.
It's
like
on
a
row.
B
A
Right
exactly
so
yeah
both
ways
would
work,
but
once
we
have
more
once
the
customization
of
the
permissions
and
roles
is
more
mature,
then
we
can
definitely
get
to
that
better
permission.
You
showed
of
just
like
security
role
and
can
do
that
and
then
you'll
have
that
customized
permission
or
that
customized
role
for
that
yeah.
B
So
our
like,
you
think,
maybe
it's
ease
like
you
said
down
in
the
row,
so
maybe
the
first
is
like
remove
this
position
like
remove
this
permission,
for
certain
laws
could
also
be
it's
like
no
developer
like
allowed
to
do
this.
I
will
do
that
later,
but
it's
like
for
this
show
no
developer
can
do
this.
A
B
A
I
think
in
the
meantime,
yes,
like
I,
said
because
the
customization
of
this
might
take
a
while,
where,
like
I
said,
we're
just
doing
that
first
MVC
right
now
to
see
how
that
works,
but
at
some
Future
Point,
yes,
I
just
don't
know
how
long
so.
Arguably
the
plan
is
that
once
we
have
like
a
process
to
create
and
manage
and
edit
custom
roles
and
then
you
as
a
designer
can
say,
okay
I
have
a
requirement
for
my
feature
where
I
need
to
make
a
change
to
a
particular
permission.
A
Behavior
to
allow
for
this
sort
of
condition,
then
I
can
now
create
an
issue
or
a
task
for
the
rest
of
the
team
to
go
back
and
engineer
that
change
in
the
permissions.
B
A
To
allow
for
this
or
to
create
that
customization
ability
to
where
then
the
user
can
create
or
create
their
own
customized
permission
for
that.
B
Yeah
I
think,
there's
probably
like
really
in
the
future.
That's
like
the
policy,
maybe
is
generalized,
it's
not
like
a
security
policy,
but
there's
a
policy
for
roles
like
the
new
role.
What
the
things
need
to
do.
It
could
be
like
a
if
we
have
a
pattern
now
in
the
future.
We
can
like
have
a
just
reuse,
this
security
permission
and
things
for
all
the
roles.
B
Okay,
I
will
explore
more
of
this
option.
I
think
there's
more
like
future
are
rented
thing.
If
we
create
a
new
policy
right,
yeah.
A
But
but,
like
I
said
the
ideas
that
once
we
have
our
first
iteration
and
the
foundation
laid
down
for
this
process,
then
you
can
take
ownership
and
push
the
change.
You
need
for
your
permission
and
your
feature
faster
right
without
having
to
rely
on
somebody
else
to
prioritize
it.
A
So
the
the
big
thing
about
the
customizable
permissions
is
that
we
want
every
group
and
Stage
to
kind
of
take
ownership
of
their
permissions
and
how
they
interact
with
their
feature,
so
that
if
they
have
a
requirement
like
this,
that
needs
to
change
or
needs
to
have
some
more
granularity
or
flexibility
for
users.
Then
you
can
make
that
adjustment
as
needed.
B
Because
I
want
this
like
at
least
for
the
first
idea,
if
I
don't
cast
my
rows,
the
customize
like
this
override
setting
like
by
project
by
policy
and
then
on
two
levels.
This
is
on
group
level.
This
is
project
level.
B
So
for
the
lows
like
you
also
plan
on
group
and
project
level
are
only
group
level.
People
can
manage
another.
All
the
product
need
to
follow.
What's
it
defined
by
the
group.
Well,.
A
You
can
you
can
define
that
as
you
want
right.
So
if
you
define
your
organization
with
that
permission
structure,
then
it
should
be
no
problem
right,
but
it's
up
to
the
user
to
Define
that
structure.
A
A
Is
there
a
customized
opportunity
for
every
group
and
project
to
have
their
own
sort
of
Behavior
interaction
right,
so
it
there's
a
I,
don't
know
how
it
works
right
now,
I
haven't
used
this
particular
feature,
but
I
do
see
value
for
both
for
like
a
more
security-minded
organization
where,
at
the
top
level,
it's
managed
in
one
spot
or
like
if
it's
a
small
team
with
like
three
or
four
developers
like
I,
want
to
be
able
to
have
flexibility
everywhere,
then
make
it
customizable
across
the
all
of
your
groups
and
subgroups.
A
So
right
now,
like
I
said
we
are
in
the
the
I
guess,
validation
or
QA
stage,
because
the
MVC
already
exists
in
the
platform,
it's
behind
the
feature
for
like,
if
I
recall
correctly,
and
so
we're
getting
data
on
how
people
interact
with
it
and
what
sort
of
problems
it
causes
in
the
platform,
if
any
so
I.
A
Think
after
that,
there'll
be
like
a
showcase
or
like
a
discussion
to
show
you
know:
here's
the
results,
here's
what
happened
and
I'll
work
with
the
engineers
to
to
get
that
information
and
kind
of
talk
more
about
it
once
like
we
get
it,
but
I
I,
don't
expect
it
to
be
far
off
the
next
step.
A
For
us
right
now
is
creating
the
the
front
end,
because
right
now
that
that
new
MVC
only
exists
in
the
API
yeah,
but
right
now
from
the
front
end
perspective,
the
designs
are
more
or
less
done.
A
I
hope
I'm
doing
like
a
few
rounds
of
validation
with
some
Enterprise
organizations
to
see
how
they
feel
about
it
with
in
terms
of
the
interactions
of
the
interactions,
make
sense,
but
I
don't
expect
anything
to
change
dramatically
but
from
there
that's
when,
presumably
every
group
and
Stage
can
start
making
their
own
changes
or
adding
to
you
know,
changes
to
the
permissions
to
allow
that
more
flexibility
and
that's
sort
of
what
I
was
doing.
A
I
don't
know
if
you
saw
that
other
epic
Grace
broke
out
every
sort
of
sub
category
of
permissions
to
try
and
have
this
discussion
more
or
less
to
start
the
the
thought
process.
Okay,
me,
as,
in
your
case,
Camellia,
how
do
I
start
looking
at
the
permissions
to
see
what
I
need
to
change,
to
make
things
more
logical,
more
flexible
for
my
users,
so
they
can
then
have
access
to
this
customizable
role
and
make
their
own
particular
custom
role
like
the
one,
the
security
example.
A
You
showed
and
then
start
prioritizing
that
work
in
your
Milestone
planning.
B
People
do
share
like
that.
Like
front
end,
the
UI
like
with
me
I
can
maybe
over
like
reuse,
something
yeah.
A
For
sure,
let
me
send
you
the
figma
link.
A
Okay,
I
just
sent
you
an
invite
to
the
to
the
figma
file,
so
you
can
take
a
look
at
it
and
see
how
we're
planning
with
it
like
I,
said
right
now:
I'm
doing
a
validation
round
with
some
end
users,
but
I
don't
expect
much
to
change
dramatically.
B
A
New
role
with
that
particular
permission
that
allows
that
policy
and
then
you'll
Define
those
permissions
in
the
policy
once
you
say
you
know
in
that
particular
example,
you
showed
with
like
a
Dropbox
saying
this
user
role
can
do
this
or
whatever
right.
B
A
B
I'll,
probably,
we
need
to
show
it
somewhere.
The
interaction
between
like
this
low
permission,
the
admin
area
and
the
policy
I
was
like
I
assume
that
in
the
role
and
permission
it
will
show
that
which
role
can
do
what
and
if
I,
have
a
policy
to
overwrite
those
things
or
changes.
We
also
need
to
like
show
it
somewhere
right.
A
A
Once
we
start
getting
more
and
more
permissions
into
this
customizable
screen,
but
I
think
for
now,
I
think
from
my
rounds
of
validation
with
stakeholders,
it
seems
to
make
sense
and
it
seems
to
work,
but
that's
where
that
other
related
issue,
that
I
brought
up
about
overlapping
permissions
or
connecting
permission
groupings
making
sure
that
permissions
connect
logically,
that's
again
back
to
each
individual
group
or
stage
to
make
sure
that
those
connections
are
logical
or
perhaps
can
be
improved
or
reduced
in
complexity,
so
giving
the
y'all
or
every
team
every
group
to
start
improving
the
permissions
and
settings
or
excuse
me
the
permissions
and
roles
based
off
of
what
makes
more
sense.
A
I
mean
it
depends
on
how
fast
the
rest
of
the
team
can
prioritize
this
work
right,
so
if,
if
it
goes
out
and
everything's
working
fine
and
now
we
have
like
a
a
road
excuse
me,
a
road
map
if
all
the
rest
of
the
groups
of
stages
can
re-prioritize
work
and
say:
okay,
now
that
we
have
this
ability
to
do
this,
granular
permissions,
these
changing
of
permissions.
A
Let's
start
rethinking
about
our
ux
roadmaps,
you
know
our
long-term
planning.
How
can
we
start
shuffling
some
priorities
to
give
more
customization
or
more
flexibility
to
the
features
and
for
our
users
right,
yeah,.
A
A
Yeah
I'm
glad
to
help
yeah
and,
like
I
said
you
see,
you
have
the
link
to
the
Prototype
field.
Please
feel
free
to
contribute
and
suggest
any
improvements
or
any
sort
of
confusion
that
you
might
see.
You
know
just
leave
some
comments.
B
Yeah
we'll
do
that
and
like
I
will
put
some
new
ideas
in
my
prototype
and
then
I
will
share
it.
Cool.