►
Description
The compliance group discusses the challenges with the current implementation of Merge Request Approvals and how they will improve upon it.
A
B
So
to
refresh
your
memory,
rob
we
were
reviewing
the
epic
for
group
level,
merge,
request,
approvals
and
you'd.
Call
that,
like
hey,
I
still
I'm
kind
of
confused
like
what
is
happening
in
terms
of
like
the
inheritance
logic.
Behind
what
happens
if
something
is
triggered,
and
it's
at
the
instance
level,
and
you
pick
a
compliance
framework,
what
happens
to
the
groups
and
projects
it's
kind
of
hard
to
convey
it
just
through
screenshots
alone.
B
So
what
I
pulled
up
on
my
computer
is,
I
have
the
issue
open.
I've
also
got
the
figma
screenshots
and
some
examples
from
gdk
in
case
we
needed
to
jump
into
it,
but
the
first
thing
that
I
was
trying
to
show
was
base
the
basic
like
progression
between
the
three,
so
instance
group
project,
ignoring
subgroup.
For
now-
and
I
realize
this-
one
is
only
focused
on
groups,
but
I
think
it's
important
to
know
like
what
happens
at
the
instance
level
will
trickle
down
two
groups
and
it
already
affects
projects.
B
So
there
is
an
example
of
a
project
that
is
a
stock2
project,
it's
inheriting
from
essentially
the
instance
and,
additionally,
you
could
add
an
additional
approval
rule,
but
you
can't
mess
with
the
ones
that
were
maybe
configured
at
the
instance
level,
so
that
can
be
inherited
down
so,
which
is
why
it's
being
inherited
from
the
instance
and
group
level
I'll
pause
there
and
see
like
does
that
track?
Does
that
make
sense?
A
Do
all
projects
get
these
values
or
none
nothing,
nothing
happens
today.
Why
do
we
allow
them
to
save
the
changes
if
that
makes
no
effect,
because
the
blue
title,
the
blue
alert
box,
tells
me
if
I
want
to
set
defaults,
use
the
compliance
framework,
but
surely
the
reality
should
be
that
we
just
don't
have
that
we
just
we
make
it
requirement
when
they
select
a
compliance
framework.
B
It
doesn't
do
anything,
so
I
mean
we
can
even
test
that
ourselves
if
we
wanted
to,
but
as
far
as
I've
noticed,
if
you
have
no
label
assigned
to
your
project
or
if
you
have
a
label
assigned
to
your
project
and
you're
at
the
instance
level
and
you
configure
something
it
doesn't
go
like
it
doesn't
inherit
anywhere.
Matt.
C
Is
that
right
yeah?
So
I
think
I'll
I'll
look
for
it.
While
you
all
continue
the
conversation,
but
I
know
that
I
raised
that
question
with
tan
during
the
initial
implementation
of
part
of
this,
and
I
forget
the
rationale
why
we
decided
to
go
with
that
for
now,
but
that's
not
the
intended
long-term
experience.
A
So
my
guess
is
so
then
you
can
revert
out
of
it,
because
otherwise
there's
no
way
to
unset
these
values.
If
that
makes
sense,
so
once
you've
set
the,
if
you
don't
have
a
compliance
framework
set,
if
you've
stopped
them
from
setting
of
compliance,
no
combined
framework,
then
there's
no
way
for
them
to
to
turn
it
off.
A
If
you've
made
a
mistake
or
you're
running,
you
were
just
playing
around,
so
my
argument
here
would
be
to
have
some
kind
of
reset
or
cl.
You
know
button
a
separate
action,
so
you
either
have
to
select
all
or
you
can
clear
the
compliance
framework
requirement
entirely
and
have
two
separate
actions
that
removes
the
confusion
I'm
having
around
that
text,
rather
than
trying
to
figure
out
what
that
tech
should
actually
say
to
convey
it
in
a
easy
to
way
easy
to
follow
process.
B
Yeah,
I
I
totally
hear
that
I
think
why
I
mixed
that
was
it
was.
It
was
already
difficult
enough
to
try
and
improve
the
existing
logic
and
introduce
just
like
the
idea
of
inheritance
across
the
the
layers.
So
to
me,
what
felt
like
the
simplest
thing
to
do?
First
was
just
use
existing
logic,
expose
attributes
of
the
group
level
and
additionally
add
in
the
approval
rules.
This
would
be
a
separate-
and
this
is
probably
a
separate
epic,
but
introduce
those
into
the
instance
level
just
to
have
some
parity
between
the
three
layers.
A
Yeah,
so
I
mean
to
be
clear:
the
reset
button
would
basically
do
what
clearing
all
the
frameworks
does
now
from
a
code
point
of
view,
the
logic
wouldn't
change,
it
would
be
a
front-end
visual
sort
of
change.
We'd
do
to
get
that
distinction.
I
guess
that
would
be
yeah.
That's
my
main
suggestion
on
it.
Rather
than
necessarily
the
flow,
I
think
the
flow
works.
B
C
B
Well,
this
doesn't
actually
make
total
sense,
because
I
mean
this.
This
logic
doesn't
totally
hold
up,
but
you
might
not
want
like
you
might
want
to
require
that
prevent
approvals
of
merge
requests
by
merge.
Request,
author
be
unchecked,
so
then
it
doesn't
like
I
might.
I
might
actually
want
this
to
be
what
I
require
it's
a
kind
of
illogical,
but
this
might
I
maybe
want
all
these
things
to
be
unchecked,
and
I
want
that
to
be
what
all
my
things
abide
by.
B
C
So
I
feel
I
mean
that's
that's
a
valid
point.
Given
the
context,
I
cannot
imagine
a
single
scenario
where
they
would
do
that
and
if
they
want
to
go
the
exception
route,
like
maybe
we
bake
in
some
toggle
on
the
label
itself
to
say
if
this
is
enabled
ignore
you
know
inherited
things,
but
but
then
it's
like
really
easy
to
go
in
this
circle,
where
we're
like,
adding
more
and
more
toggles
that
undo
or
do
the
inheritance
thing,
but
I
mean
valid
point
so
I'll
yield
to
y'all
on
the
implementation.
C
B
C
C
B
Yeah
and
I
think
some
of
the
proposals
that
we
had
in
mind
at
least
make
sense
to
start
with
so
like
I
just
hid
the
approval
rules
just
for
the
sake
of
showing
like
this
is
kind
of
how
it
is
today.
This
is
what
instance
level
would
look
like
this
is
what
project
level
looked
like.
You
could
just
put
an
x
through
the
group
for
now,
and
all
we
really
are
doing
is
introducing
some
quality
of
life.
B
C
B
C
C
So
that's
one,
two,
the
the
ui
text
or
copy
improvements,
general
experience,
improvements
to
make
things
more
intuitive,
add
the
approval
rules,
and
then
I
think
the
fourth
most
important
thing
is
fixing
the
inheritance
quark.
Where,
like
at
the
project
level,
they
should
be
able
to
add
additional
rules
and
right
now,
it's
just
totally
uneditable
right
and
actually
fifth,
I
just
scheduled
the
issue
to
allow
only
admins
and
group
owners
to
modify
the
project.
Compliance
label
and
that'll
be
important,
because
otherwise
a
maintainer
could
just
go.
C
B
Yeah
everything
until
the
last
point:
it's
such
a
it's
such
a
weird
one,
because
then
it
is
like
well
now
I'm
creating
a
project
as
a
maintainer.
I
want
to
abide
by
my
company's
soc2
instance.
Level
rules.
I
can't
add
the
label
and
I'll
have
to
call
up
my
compliance
manager
to
come.
Add
it
to
my
project.
B
B
A
Could
you
not
could
just
to
say,
could
you
could
we
not
just
have
a
group
level
select
check
box
to
say
whether
we're
gonna,
whether
you
allow
compliance
labels
to
be
changed
by
project
owners?
Would
that
not
be
the
best
change
and
then
it's
up
to
group
owners
to
make
that
decision
individually
on
an
individual
basis.
A
C
Yeah
austin's
point
is
valid
and
the
feedback
I
received
from
the
customer
I
spoke
to.
I
think
it
was
monday.
They
said
that
what
they
would
prefer
in
terms
of
the
labels
is
to
have,
because
I
mentioned
the
two
person
approvals
we
were
working
on
like
oh,
yes,
you
want
that,
and
so
I
think
eventually,
the
the
future
state
would
be.
Maybe
let
maintainers
set
it
like
give
them
the
freedom
to
do
whatever,
but
then
to
change
it.
We
maybe
add
in
that
approval
process
to
say
like.
C
B
It
does
it
even
does
it
even
matter,
though,
if
we're
going
to
give
the
ability
for
the
project
maintainer
to
be
able
to
add
an
additional
approval.
Rule
like
in
this
mock-up,
the
ad
approval
rule
button
is
there
at
the
project
level,
and
it's
not
right
now
I
mean
that's
really.
The
only
thing
that
they
can
use
the
workaround
for
would
be
right
now
to
add
approval
rules,
because,
right
now
I
have
this
new
lock
down.
C
A
B
B
A
C
So
so
what
I
think
I'm
understanding
is
so
so
okay,
so
what
I'm
saying
is
right
now
maintainers
if
they
say?
Oh,
I
don't
like
these
rules.
They'll
just
go:
remove
the
label
on
the
project
delete
the
rules
there
because
they
can
now
do
that
and
then
reapply
the
label
to
get
around
whatever,
like
they
might
add
additional
rules
when
they
remove
it
right
and.
B
What
I'm
saying,
though,
is
okay,
yeah
yeah.
I
think
I
have
an
answer
for
your
your
concern
so
today,
if
we,
if
we
match
the
existing
behavior,
I
I
could
take
the
label
off,
because
the
only
thing
that
only
we
have
parity
right
now
are
the
check
boxes.
I
can
change
the
check
boxes,
but
as
soon
as
I
put
the
label
back
on,
it
goes
back
to
whatever
the
instance
has
set
for
that
compliance
framework.
B
C
C
C
A
C
And
so
that's
where
we
come
back
to
like,
I
agree,
making
owners
and
admins
the
only
ones
able
to
modify
the
label
setting
is
probably
not
the
best
long-term
solution,
but
it
might
be
the
best
short
term,
maybe
but
then
maybe.
Instead,
we
just
work
towards
adding
two-person
approvals
to
that
setting
or
something
like
there.
There
has
to
be
some
mechanism
in
place
to
control
that,
otherwise
the
label
mechanism
is
just
easy
to
bypass
yeah.
C
One
and
the
other
thing
too
right
is
we
talked
about
how
you
could
we
could
work
towards
the
future
state
of
the
labels
where
in
the
customization
process
you
point
it
to
a
project
template
and
have
it
create.
So
if
you
wanted
to
say,
oh,
I
want
to
create
a
sock,
2
thing
as
a
project
maintainer,
the
group
owner
should
create
a
label
that
points
to
or
references
some
sock,
2
project
template.
So
when
the
project
gets
created
by
the
maintainer,
oh,
but
then
they
can't
apply
the
label
right.
C
A
That's
actually
a
good
idea
that
during
the
whole,
you
know
we're
eventually
looking
to
have
some
kind
of
yaml
set
up
where
you're
able
to
pre-configure
project
settings
having
that
would
mean
that
if
someone
creates
a
new
project,
it
would
automatically
apply
the
correct
frame,
the
correct
compliance.
Couldn't
it
oh.
A
C
So
you
could
maybe
go
that
route
and
say
this
group
has
to
create
from
this
one
or
two
or
three
templates
and
they're
all
like
socks,
sock,
two
and
hipaa.
Maybe
it's
like
you
can
only
create
a
project
from
one
of
those
three
templates.
So
that's
one
way
to
go
about
it
as
well.
So
I
think
maybe
what
we
have
to
figure
out
is
like
what
is
that
that
threshold
we're
willing
to
tolerate
for
now
from
the
ux
side
and
say
like
this
is
good
enough.
B
My
I
guess
my
short
narrow-minded
view
is
I'm
okay,
with
the
workaround
being
its
own
thing,
that
we
try
and
address
separately,
whether
that
comes
as
this
resolution
through
project
templates
or
something
different.
But
we
also
have
the
compliance
dashboard.
That
would
tell
you
if
someone
essentially
did
take
off
things
and
did
things
without,
let's
say
using
two
different
authors
and
approvers,
because
we
flagged
that
under
the
approval
status,
if
it
didn't
abide
by
separation
of
duties.
A
C
B
C
B
A
B
A
B
I
would
love
to
get
their
feedback
in
case
they're,
watching
this
on
how
we
use
the
alert
to
tell
the
user.
What's
about
to
happen
if
you
use
these
settings
additionally,
the
current
language
for
this
unique
attribute
is
confusing,
and
the
reason
why
it's
confusing
today
is
it
shows
up
as
prevent
users
from
modifying
merge,
request
approvers
list
at
the
instance
level,
and
it
shows
up,
as
can
override
approvers
and
approvals
required
per
merge
request.
B
A
B
No
matter
what
I
have
checked
there,
this
guy
is
just
going
to
always
remain
read
only
so
it's
not
actually
doing
anything
to
the
project
level.
It's
just
if
you
have
a
compliance
label
that
is
set
at
the
instance
level.
If
you
have,
if
you're
matching
this
one
gdpr
gdpr
in
this
example,
it's
going
to
be
read
only
which
mazda
I
talked
about
we're
going
to
fix
that
you're
going
to
be
able
to
add
rules,
but
I
think
it.
I
think
this
behaves
differently
within
a
merge
request.
A
B
B
C
Yeah
thanks
thanks
for
coordinating
the
call,
it's
clearly
a
very
complex
problem,
but
I'm
glad
we
have
a
much
better
path
forward.
There
are
just
for
context.
There
are
a
couple
of
customers
who
have
who
are
either
currently
undergoing
or
have
upcoming
audits
that
they're
very
interested
in
this
and.
A
B
C
Communicated
to
them
that,
like
hey,
we've,
sort
of
paused
development
on
this
because
we're
trying
to
figure
out
how
to
implement
this
better,
so
we
learned
a
lot
of
very
valuable
lessons
from
how
we
implemented
it
now,
it's
time
to
do
that,
so
I'll
go
create!
That
issue
like
I
said,
and
we
can
maybe
go
from
there.