►
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
All
right
I'll
start
again
current
situation
from
a
front-end
point
of
view.
Is
we
already
have
an
app
that's
existing,
we're
modifying
it
already
for
approval
gate,
so
me
and
jana
getting
good
a
good
understanding
of
how
it
all
functions
and
how
it
all
works.
So
when
we
do
have
a
back
end
implementation
for
us
at
least
it's
going
to
be
relatively
straightforward,.
A
A
C
Just
just
something
that
I
would
like
to
add
to
that
just
so
that
everyone's
aware,
I
would
strongly
suggest
that
we
follow
up
with
a
refactor
on
the
form,
because
currently
each
page
is
injecting
its
own
configuration
with
a
bunch
of
like
conditional
statements
in
into
that
form,
and
I
think
it
would
make
much
more
sense,
especially
if
we're
going
to
add
another
instance
of
this
to
extract
that
configuration
and
just
make
it
a
dummy
form
that
can
be
used
everywhere
and
that
configuration
then
lies
in
group
projects
and
mr
edits.
A
Yeah,
that's
a
good
point.
Currently
it
passes
context
through
booleans
and
then
within
the
form
you're
going.
If
this
do
this,
otherwise
do
that.
I
think
we
already
have
an
issue.
Don't
you
to
change
that,
so
it
passes
in
the
entire
context
rather
than
just
boolean,
so
the
logic
gets
moved
out
of
the
form
and
into
a
dedicated
sort
of
wrapping
container.
C
D
A
D
Cool
then,
let's
just
go
down
the
list
and
back
end.
What's
the
I
guess
summary
of
the
current
situation
in
terms
of
what
you're
working
on.
E
Okay,
so
I
can
talk
briefly
about
the
back
end
changes.
I
have
dedicated
whole
issues
to
talk
about
what
the
current
situation
is
and
how
it
can
integrate
with
the
new
group
level
motion
quest,
I
think
mainly
around
the
database
table
structure
and
how
to
integrate
with
so
that's
they
still
gather
feedback
from
the
source
code.
E
Whatever
the
team
is
source
group,
source
code
and
group
code
reviews,
I
think
two
of
them
have
some
input
into
how
it
fit
into
the
current
model
and
then
so
some
behavior
in
regards
to
how
it
work
with
with
saying
much
request
level
rules
as
well.
E
D
E
Yeah,
so
at
the
moment,
whatever
set
a
project
level,
you
can
override,
given
the
settings,
allow
you
to
override
the
user
can
override
merge
requests
level
and
it's
effectively
created
new
copies
of
it
in
the
back
end
yeah,
whether
we
want
to
carry
the
similar
kind
of
experience
between
you
know,
groups
and
projects,
there's
something
we
want
to
to
to
find
out.
I
think
you
know
whether
we
go
down
the
path
of
doing
the
same
thing
or
we
want
to
have
different
treatment
for
that
yeah.
F
I
guess
the
only
way
it
can't
be
overwritten
is.
If
that
box
is
checked,
saying
or
I
guess
yeah
the
box
has
to
be
checked
to
say,
allow
merge,
requests
to
have
the
approval
rules
changed
in
mmr,
otherwise,
they'll
be
read
only
on
that
page
yeah.
E
Yeah,
but
even
with
that
that
disablement
allow
them
to
change,
we
still
want
to
allow
them
to
change
the
group
or
inherited
group
level
rules
or
not.
E
Okay,
yeah,
so
that's
that's.
Coming
to
the
other
questions
I
have
well,
maybe
we
go
through
the
ux
a
little
bit
later.
I
think
there's
some.
F
Yeah
I
mean
I
totally
relate
to
all
these
problems
that
have
been
discussed.
I
think
we
can
jump
to
most
of
my
points
that
are
interspersed
throughout
the
front
end
and
back-end
and
highlighted
issues,
but
overall
yeah
just
figuring
out
the
pattern,
and
then
I
can
help
just
modify
this
mock-ups
to
help
clarify
if
that's
useful,.
B
D
All
right,
then,
it
sounds
like
it's
a
good
time
to
just
start
going
down
the
list.
So
first
up,
we've
got
front-end
implementation
of
the
approve
of
roles
who
would
like
to
leave
the
first
item
there
of
whether
or
not
the
current
app,
which
has
the
branch
list
as
a
drop-down,
whether
it
should
be
an
input.
A
With
any
corrections
or
his
own
concerns
about
what
I
suggested
so
the
reason
I
raised
this
is
because
a
project
could
have
several
projects
could
have
different
branches,
some
might
be
in
common,
you
know
main
or
staging
or
devops,
develop
or
whatever,
but
there
will
be
several
which
aren't
so,
but
they
might
have
a
naming
convention
where
they
prefix
all
their
branches,
with
a
certain
prefix
or
suffix
or
whatever,
to
keep
a
company-wide
convention.
A
So
the
idea
was
to
try
and
make
it
less
confusing,
trying
to
build
a
drop
down
and
retrieve
all
these
different
branches
to
be
able
to
put
in
a
list
and
the
performance
concerns
that
might
have
would
be
to
have
an
input
where
any,
while
wild
card
matches
against
that
value,
that's
been
entered.
Obviously,
that's
a
big
deviation
from
what
we're
doing
currently
and
it's
probably
not
an
nvup.
A
F
F
The
only
thing
I
can
think
of
is
like
when
you're
configuring,
a
protected
branch
you're,
given
the
option
to
pick
a
branch
or
create
a
wild
card,
which
is
what
I
think
you
were
insinuating
by
saying
like
you
could
input
the
word
develop
effectively
creating
a
wild
card
and
then
anytime
that
that
appears,
I'm
not
sure
if
it
would
be,
only
the
word
developed
or
if
it
would
be
to
just
develop,
appears
in
any
form
of
the
branch
name,
but.
A
Yeah
that
would
be
my
aim
would
be
any
any
time.
The
word
develop
at
least
as
an
initial
initiation.
Initial
implementation,
but
tan
has
a
very
good,
be
point
on
that.
E
I
have
another
thoughts
in
terms
of
the
backend
implementations.
This
is
my
effect.
How
we
surface
this
in
the
front
end.
So,
instead
of
searching
for
protected
brand
for
all
the
child
projects
group
will
have
their
own
protected
branches,
so
it
have
it
on
stored
and
we
do
that
matching
or
we
we
do
that
exact
match,
searching
when
we
view
the
project
to
see
whether
that
protected
branch
has
been
kind
of
in
the
rules
specified
group
level,
so
yeah
so
and
that
list
will
be
smaller.
E
A
E
E
F
A
C
But
I
think
from
ux
point
of
view-
and
this
is
definitely
something
I
think
for
that
we
can
do
after
mbdp
is
like
seeing
as
a
user
which
projects
are
going
to
be
affected.
So
basically
saying
yes,
it's
like
one
master,
but
can
I
get
like
a
50
plus
or
you
know
some
sort
of
ui
element
telling
me
what
it's
going
to
what
what
the
impact
is
going
to
be.
A
So
I
kind
of
referenced
this
way
down
on
issue
five,
but
I
thought
I'd
mention
this
now
as
an
mvp
to
keep
this
small,
and
I
think
it's
been
mentioned
elsewhere
as
well.
To
be
fair,
we
could
just
have
as
a
starting
point
the
branch
list
being
any
branch
like
it
normally
is,
or
the
git
lab
application
setting
default
branch,
because
obviously
people
can
change
the
name
of
their
default
branch
and
that
is
it
as
a
basic
mvp.
You
can
pick
either
your
main
branch
or
your
default
branch
just
to
get
it
out.
D
E
D
C
A
A
My
assumption
is
that
a
group
owner
would
have
knowledge
of
the
projects.
In
said
group,
I
mean
that's
a
big
assumption.
Obviously
I'm
not
saying
the
ux
is
perfect,
but
I
don't
necessarily
expect
it
to
be
as
an
issue
in
implementation.
C
Yeah
the
the
impression
that
I
have
from
our
user
context
on
this,
and
some
of
the
stories
that
was
shared
is
that
this
is
definitely
someone
who
who
has
an
idea
of
what
they
really
want
to
do.
That
is
probably
initially
going
to
use
this
feature,
so
I
think,
for
start,
maybe
for
mvp
we
can
just
you
know,
keep
it
simple
in
terms
of
our
current
projects
approach
and
if
there's
then
further
questions
or
we
get
feedback
that
hey
I'm
confused.
I
don't
know
what
this
is
doing.
D
F
E
Yeah,
I
think
the
default
branch
is
it's
a
good
and
they
say
now:
project
can
change
the
default
brand
to
any
value
with
any
value
they
like,
I
believe,
can
be
either
yeah.
They
can
change
full
branch
to
any
and
as
far
as
it's
from
the
group
level,
they
just
want
to
enforce
the
kind
of
motor
brand
to
say
any
default
brand
or
whatever
your
projects
that
will
have
the
rules
apply,
and
I
think
it
will.
I
mean
it
feel
like
a
sensible
approach,
but
finally,.
A
E
F
F
A
D
I
think
we'd
have
to
circle
back,
maybe
meet
with
sam
to
kind
of
talk,
reach
out
to
the
customers,
who
are
initially
the
most
vocal
about
this
see.
If
that
would
address
that
issue,
because
my
I
guess
it
would
be,
I
think
it's
simpler.
D
I
think
we
can
agree
it's
a
simpler
nbc
or
to
to
start
as
a
first
iteration,
but
I
guess
we
would
start
to
validate,
if,
like
we
still
have
to,
because,
of
course,
matt
went
through
the
work
of
kind
of
creating
this
delineation
of
work
in
terms
of
what
the
customers
were
supposedly
going
to
be
satisfied
with
and
to
see,
if,
like
that,
addresses
their
core
concern,
at
least
for
the
time
being,
while
we
continue
to
iterate
on
it.
D
F
D
D
A
I
would
say
that
it's
a
very
viable
solution
or
initial
first
step.
It
might
be
worth,
as
you
say,
validating
with
sam
before
validating
your
customers.
It
sounds
like
our
either
either
our
option
is
to
do
that
any
eligible
user
rule
initially
or
do
a
simplified
version
of
the
more
wider
ad
approvals
concept
and
see
which
one
we
customers
would
be
happy
with.
As
an
initial
implementation
from
a
implementation
perspective,
I
can't
I
believe
that
tank
can
correct
me
from
a
back
end
and
front-end
point
of
view.
A
The
same
structure
exists
either
way,
so
we
we
wouldn't
be
stepping
back
necessarily
if
we
then
have
to
go
ahead
and
quickly
implement
adding
approval
rules
which
we
do
anyway.
The
same
structure
exists:
whether
we
go
ad
approval
rules
now
or
any
eligible
rules.
We
use
a
rule.
E
One
thing
I
think
from
the
back
end:
it
can
be
simplified
because
you
suggest
going
with
any
brand
before
brands.
We
don't
have
to
necessarily
have
to
create
the
protected
branch
at
you
know
for
an
mpc,
but
rather
kind
of
coded
in
that's
any
brand
to
default.
So
we
don't
have
to
to
have
a
list
of
branches.
Therefore,
it
will
simplify
the
database
changes
and
also
we
don't
have
to
create
model
for
the
branches
to
store
in
the
group.
E
A
Sorry,
I
was
just
writing
the
first
possible
solution.
We
have
yeah,
I
agree,
reducing
the
bright
scope
of
the
branches
would
be
helpful.
It's
kind
of
them
raises
again
going
back,
but
I'm
jumping
ahead
to
bring
in
the
rest
of
my
point
from
my
point
about
using
default
branch
or
any
branch
we
are
currently.
A
I
know
there's
some
contention
around
how
we
display
it
on
an
mr
level,
but
we
are
currently
implementing
approval
gates,
which
would
also
because
it
only
has
an
external
url,
we're
removing
the
complexities
around
user
group
permissions
and
what
who
gets
viewed
where
and
etc.
They
are
the
main
contentious
point
that
we
have
around
users
in
the
back
end
on
the
back
end,
so
we
could
implement
approval
gates
on
the
group
level.
F
It
says
hold
off
I'm
putting
the
approval
gates
at
the
group
level
for
now
and
just
focus
on
the
the
rules
that
affect
branches,
we'll
see
well,
the
rules
that
are
defined
to
have
users
approving
changes
on.
C
Also
be
a
question
for
max
after
having
watched,
this
call
is,
I
believe
there
would
be
quite
a
big
overhead
to
implement
approval
gates
on
groups
at
the
moment
it
seems
to
be
tied
quite
closely
with
projects
and
we're
gonna.
Have
that
whole
same
inheritance.
F
Down
yeah-
and
we
do
have
a
meeting
next
week
to
talk
with
kai
and
pedro
about
their
opinions
and
thoughts
on
the
placement
of
approval
gates
and
we'll
kind
of
see
how
that
goes
and
if
there's
any
pivot
or
redirection
that
might
even
impact
what
we
do,
the
long
term
with
them
and
so
we'll
see.
D
So,
just
for
my
understanding,
we're
on
one
one
hand
we're
talking
earlier:
can
we
can
we
tweak
the
nbc
to
just
support
either
any
branch
or
a
default
application
setting
right
and
on
the
other
hand,
we
also
have
the
other
option
of
do
we
just
work
on,
let's,
let's
cut
out
at
approval
rule
from
the
scope
and
then
just
go
with
any
eligible
user
right?
That's.
D
Okay,
yeah,
because
then
now
that
I
understand
that
it
doesn't
really
make
sense
for
me
to
push
for
like
some
type
of
decision
here,
because
I
think
that
ultimately
has
to
be
something
that
we'll
have
to
decide
on
as
a
group.
So
once
max
reviews
that
and
then
we'll
talk
to
dan
and
sam
about
it,
then
we
can
kind
of
make
the
call
there.
D
But
that's
not
to
say
the
rest
of
the
items
we
have
on
this
agenda
are
still.
These
are
still.
Details
will
start
to
work
out
right
because,
ultimately,
we'll
still
work
towards
the
original
scope
of
this,
even
though
we
may
slice
it
differently,
as
we
do
our
first
couple
iterations,
does
it
sound
right.
A
Felt
that
the
top
adding
it
to
the
instance
would
be
simpler
because
the
it's
less
complicated
there's
only
one
source
that
we
need
to
reference.
We
don't
need
to
inherit,
necessarily
we
can
just
depend
or
prepend
these
to
the
check
boxes.
It's
a
bit
simpler,
less
complicated
than
going
from
a
group
level.
E
I
think
that's,
I
think
that
was
only
when
we
consider
self-managed
instances
and
when
we,
you
know
we
take
sas
and
group
is,
is
more
applicable.
I
guess,
because
they
don't
really
use
admin
settings.
E
The
challenge
I
found
with
the
existing
instant
level
settings,
not
the
rules,
is
that
the
path
of
not
introducing
breaking
changes.
If
we
want
to
change
the
experience
between
group
and
projects,
we
wanted
to
play
nice
with
existing
instance
settings
because
you
know
from
experian
user.
They
have
certain
ways
of
doing
it
and
by
changing
it
it
introduces
some
security
issues
for
them
yeah.
So
that's
just
to
call
out.
A
Yeah
yeah
the
piece:
the
lack
of
remaining
checkboxes
is
one
resulting
from
a
p1
s1
concern
that
was
raised
when
we
started
implementing
these
with
group
and
project
in
mind,
and
the
second
is
just
halfway
through
us
implementing
it.
We
had
a
shift
in
direction
from
focusing,
on
instance,
level,
first
group
level.
First,
so
I
think
the
instance
level
issues
are
still
around
they've
just
been
pushed
right
down
much
further
down
the
list
of
priorities.
D
B
A
We've
already
touched
on
users
in
groups
doesn't
sound
like
that's
something
that
could
be
solved
in
an
immediate.
This
meeting
quite
complicated,
but
I
wanted
it
there
just
to
raise
that
this
is
you
know
as
a
source
of
truth.
This
is
a
concern,
so
I'm
happy
to
move
on
to
back
end.
Unless
jan
has
any
particular
things
he
wants
to
race.
C
Oh,
I
think
you
said
it
ball
rob
it's!
It's
good
that
we're
raising
these
concerns
now,
so
we
can
think
about
them
in
terms
of
specifically
engineering
for
the
front
end
yeah,
you
know
it's
like
you
said
it's,
it's
kind
of
straightforward.
It's
it's
more,
the
back
end
and
ux.
It's
like
the
whole
entire
user
experience.
That
is
the
that
is
the
concern
lucky
for
for
us.
Javascript
is
easy.
D
So
do
you
feel
like
let's
say,
for
example,
we
can
go
with
up
solution,
a
of
implementing
any
eligible
user.
First.
Do
we
see
like
point
three,
a
two
current
app
user
sees
uses
usergen
groups
for
approvals
like
would
that
be
something
we
have
to
iron
out?
Even
for
that,
or
is
that
a
concern
we
kind
of
like
worry
about
later.
A
On
do
you
mean
the
branches
one,
I'm
very
confused,
you
said
words
and
I
didn't
hear
it.
A
A
That
any
eligible
user
removes
most
of
the
edge
cases.
We
don't
need
to
care
about
branch.
We
don't
need
to
care
about
users,
and
groups
is
just
a
default
setting
with
an
up
up-down
number
tick.
It's
hard-coded
static,
basically,
except
for
that
number
of
change,
but
the
second
idea
of
producing
branch.
We
do
still
have
users
and
groups
as
a
concern.
D
F
E
All
right,
let's
talk
about
to
move
into
back
end
items
yep,
so
the
database
table
structure.
I
think
that's
I
briefly
mentioned
earlier
on.
That's
that's
been
dropped
out.
I
guess
we're
still
collecting
feedback
from
the
other
group
and
I
guess
with
the
in
the
simplifications
of
branches
and
and
so
will
reduce
the
effort
of
creating
extra
data
database
table.
E
A
About
the
database
table
structure
does
that
is
that
simplifying
the
nine
different
database
tables
we
have
currently
for
approval
rules
across
mr
project
and
instance
level?
Is
that
unifying
those
or
is
it
just
tacking
on
additional
tables
at
the
minute.
E
E
Now,
they're
they're
just
aware
today
that
they're
an
ongoing
epic
from
the
source
code
team
trying
to
simplify
that
further
by
reducing
a
number
of
tables.
So
they
having
talking
about
four
months
now
haven't
had
anything
planned
yet
so,
but
I
know
that
they
thinking
about
it,
I'm
not
sure
what
the
implications
it
had
on
our
design.
A
So
would
there
be
scope
for
us
to
take
this
new
table
structure
that
we're
implementing
and
merging
the
project
and
mr
level
data
into
that
as
a
to
try
and
simplify
the
database
structure?
In
future
I
mean
not
as
an
mvp,
but
as
a
would
it
be
possible
to
join
those
all
in
the
future
and
contribute
to
that
epic.
E
Yeah,
I
think
it's
it's
possible,
we're
not
making
anything
worse.
It's
now
like
we're
having
you
know,
different
approval
rules
for
most
requests
and
projects.
So
this
is
introducing
group,
but
yet
I
think
at
some
point
we
need
to
do
migrations.
If
they're
meant
to
collapse
these
into
one
tables
and
restructure
it
then
there'll
be
extra
effort
to
move
the
group
one
because
introduce
it
for
our
well
yeah.
E
A
And
I'm
assuming
that
the
people
working
on
that
epic
are
aware
of
our
work
at
the
minute.
E
Yeah,
so
I
got
wrist
on
from
just
earlier
this
week,
but
yes,
there's
two
teams
looking
after
that,
so.
E
E
All
right
so
moving
on
next,
I
think
inheritance
of
rules.
I
think
that's.
We
agree
that
we
just
go
with
the
top
level
group
and
leave
the
subgroup
for
later
and
also
perform
a
concern
around
that
area
as
well,
and
I've
realized
that
we
also
use
the
same
concept
for
compliance
frameworks.
We
just
do
at
the
top
level
so
that
simplify
a
fair
bit,
so
we
don't
have
to
drop
our
group
structure
to
get
the
rules.
E
That's
that's
a
bonus,
so
we
go
with
top
level
group
projects
and
then,
mr,
I
think
we're
gonna
do
that
for
for
existing,
but
also
for
new
projects
as
well,
which
gonna
inherit
the
group
rules.
F
Yeah,
that's
what
I
was
thinking,
because
currently
our
approval
settings
affect
both
so
kind
of
back
to
your
initial
point.
Tanya
brought
up
was:
let's
keep
it
consistent,
I
agree
so
if
we
can
affect
both
already,
I
think,
ideally,
that's
the
case.
So
if
your
group
defines
an
approval
rule,
it
should
affect
all
the
projects
and
all
the
ones
that
are
coming
in
the
future.
E
E
A
So
part
of
it
is
the
current
exist.
Sorry
ten,
I
was
just
gonna
say
that
the
approval
rules
currently
allow
you
to
find
users
or
groups
for
approval
purposes.
So
there's
that
as
well
is
a
one
group
may
not
have
permission
in
another
group,
so
maybe
we
should
just
limit
the
scope
to
just
users.
E
Yeah
and
I
think
if,
if
we
just
select
users
that
belong
to
the
group,
the
questions
I
have
is
how
we
surface
these
rules
at
the
project
level,
whether
we
can
show
you
know
user,
that
is
part
of
the
group,
but
not
at
that
project.
Is
that
a
concern,
I'm
not
sure.
F
E
F
F
A
So
our
mechanic,
we
don't
have
a
mechanism
on
a
project
to
say
un,
remove
all
group
level
users
and
only
put
these
certain
specific
users
in
instead.
What
you
need
to
do
is
to
find
a
separate
group
and
add
those
users
to
that
group
say
for
a
security
part,
a
security
application
or
something
or
hr,
something
that
only
a
certain
subset
of
users
should
have
access
to.
You
need
to
put
them
in
that
in
a
separate
group.
Currently,
that's
our
mechanism,
yeah.
D
F
Works
yeah.
I
don't
really
see
a
way
around
it,
we're
just
trying
to
prevent
people
from
creating
mr
approval
rules
that
are
impossible
to
actually
do.
D
E
Well,
I
think
the
last
item
is
performance
impact
and
how
we
manage
inheritance
collation
of
rules
at
this
level.
I
think
the
source
core
team
also
raised
a
point
and
regards
to,
I
think,
it's
more
about
the
revert
function,
functionality.
E
E
E
E
We
still
effectively
making
extra
call
when
the
user
view
the
project
settings
and
potentially
create
or
view
mr,
but
if
we
lump
them
up
into
the
project
project
rules
api,
then
it
might
not
be
an
issues,
but
that
also
means
we
have
to
extend
the
api
to
indicate
whether
that
coming
from
a
group
or
project,
because
there's
some
extra
ui
that
we
need
to
tell
the
user
that's.
These
are
the
these.
Are
the
rules
coming
from
the
project
api,
but
they
effectively
from
group
locked,
I'm
not
sure
what
level
details
we
have
here.
A
The
approval
rules,
api
lists,
an
approval
rule
type.
If,
when
it,
when
you
see
the
output,
so
there's
you
know
general
approval
rule,
but
you
we
could
also
define
a
group
approval
rule
as
well
as
a
new
type
in
the
api
which
would
it
could
be
our
differentiator
and
would
also
limit.
The
one
problem
we
had
with
approval
gates
was
that
we
had
to
make
that
second
api
call
and
setting
up
that
promise
to
to
make
sure
we
get
all
the
api
calls
and
merge
them
all
back
together
again.
A
So
that
would
reduce
the
complexity
because
we
just
would
still
be
making
from
the
front
end.
We'd
still
be
making
one
call,
but
we
would
get
all
the
rules
and,
if
we
needed
to
from
that
type,
we
could
then
visually
differentiate
between
a
group
level,
rule
on
a
project
or
an
mr
basis
and
a
generic.
E
F
F
It
was
an
idea
I
had
from
last
fall,
but
I'm
glad
to
see
it's
getting
support
somewhere
else,
so
I
can
just
piggyback,
but
just
adding
a
lock
next
to
it
and
then
like
a
pop
over
on
the
lock.
That
says,
like
this,
setting
is
being
inherited
from
a
group.
This
would
be
inherited
from
a
subgroup,
even
though
that's
not
a
thing
right
now.
That
gives
us
a
way.
F
I
mean
right
now
it
kind
of
sucks,
because
if
you're
in
mr
and
those
approval
rules
are
read
only
you
don't
know
why
they
just
are.
So,
I
think,
there's
a
there's
a
lot
of
opportunity
to
improve
there,
but
at
least
for
the
way
that
we're
getting
looked
at
on.
We
can
at
least
start
with
using
that
pattern.
D
Would
we
want
to
show
where
that's
coming
from
or
would
we
like?
I
guess
like
what
I'm
asking
is
like?
Would
we
want
to
show
that
it's
defined
at
a
specific
level,
or
we
just
want
to
generically
like
at
the
merger
crystal
just
say
like
hey?
This
has
just
been
locked
like?
Would
that
depend
on
your
role,
perhaps
using.
E
The
ux
stuff-
yes
right,
so
the
interaction
between
rules
yeah
so
keep
thinking
about
it.
Whether,
but
I
think
we
already
kind
of
refine
it
go
through
there.
They
are
different.
So
the
interaction
between
the
group
and
project
is
different
to
that
project.
Much
request
in
the
way
that
it's
not
allowed
overwrite
overwriting
oops.
B
F
F
So
you're
talking
about
the
fact
that
you
can
you
can
edit
a
project's
merge,
request
approval
rule
in
the
mr.
If
the
prevent
users
from
modifying
them,
our
approval
rules
is
not
checked.
Based
off
of
that,
most
recent
merge
request.
E
Yeah,
so
that's
that's
my
impression.
Prior
to
the
conversation
we
have
today
that
we
want
to
go
down
the
path
of
using
project
and
merge
request
interactions
at
the
group
and
project,
which
means
that
we
allow
overriding
but
sin,
then
I
think
that
that
have
changed.
So
we
we
don't
want
to
allow
user
to
override.
I
think
that's
go
quite
nicely
with
approval
settings
and
restricted
to
saying
any
branch
with
your
full
brain,
just
kind
of
like
at
high
level,
this
kind
of
like
tick,
the
box
yeah.
F
Yeah,
I
think
long
term,
I
think,
would
be
great-
is
I'm
trying
to
get
this
defined
in
pajamas
as
a
pattern,
but
I
have
a
loosely
held
belief
that
children
should
always
be
able
to
define
a
more
restrictive
environment
than
their
parent,
so
yeah.
If
you
inherited
this
reviewer's
rule
and
your
parent
says
it
requires
at
least
one.
If
the
project
wants
to
say
it
should
be
two,
they
should
be
allowed
to
do
that.
F
F
F
But
imagine
if
you
were
a
group
owner
and
you
could
go
into
a
specific
project
or
a
specific,
mr
and
you
could
delete
that
rule
or
modify
it
or
change
it,
so
that
if
you
needed
a
way
to
get
out
of
it
for
some
reason,
you
could
but
the
person
that
ultimately
makes
the
decision
or
has
the
power
to
do
that.
The
group
level
would
need
to
be
the
one
to
do
it
in
the
child
area.
B
E
I
think
the
roles
slightly
different
from
settings
that
that
additive,
so
wherever
we
added
the
group
level
respectively,
similar
like
what
they've
done
at
like
adding
new
roles
at
the
project
level.
E
A
And
my
point
was
that
if
we
were
going
to
exclude
do
exclusions,
then
it'd
probably
be
better
to
have
a
single
source
of
truth
in
that
so
we'd
probably
want
to
add
an
exclusion
area
to
the
group
level.
Approval
rules
form
to
say.
I
don't
want
this
to
happen
on
x,
y
or
z,
rather
than
having
a
mishmash
of.
Can
I
remember
which
project
I
modified
that
rule,
especially
when
you
consider
updating
the
group
level
rule
and
us
knowing
which
one
we've
deleted
or
edited
previously.
If
that
makes
sense,
it
can
get
messy.
F
No,
but
legitimately
that's
not
a
part
of
the
scope
here.
So
I
don't
want
to
hold
up
any
more
time
talking
about
it,
but
I
do
have
a
change
that
I'm
trying
to
work
on
in
pajamas
to
better
define
this
so
that
we
have
some
thing
to
refer
to
in
the
future,
because
we
keep
touching
so
many
different
areas.
So
it's
not
ready
yet,
but
if
you
have
opinions
on
it,
please
please
help
me.
D
F
Not
not
for
this
purpose,
maybe
for
my
proposed
change
in
the
inheritance
model
down
the
rib,
but
I
think
at
least
we're
trying
to
get
the
mvc
out
of
getting
approval
rules
and
approval
settings
at
the
group
level.
Make
it
as
dead,
simple
as
possible
and
has
already
hardened.
E
Yeah,
I
think
the
folks
at
source
code
are
thinking
about
it,
so
they
they
have
to
tackle
problems
with
project
to
merge
requests
because
they
need
to
track
what
change.
I
guess,
because
they
want
to
revert
it
back
to
the
default
project.
So
we
might
be
able
to
pick
you
back
on
that
when
it
comes
to
doing
the
gripping
project.
B
F
Sure
but
yeah
I
tried
to
update
these
screenshots.
I
hope
they
all
clarify.
I
did
add
in
a
subgroup
one
just
to
illustrate-
and
I
don't
have
approvals
at
the
instance
level
intentionally,
but
I
tried
to
reflect
some
of
the
most
recent,
mrs,
that
we've
kind
of
put
through
to
revise
the
language
of
some
of
these
settings.
F
Given
our
conversation
today,
it
might
be
possible
I'll,
like
cut
out
all
of
this
stuff
and
leave
only
any
eligible
approver
or
any
eligible
user
in
any
branch,
but
I
didn't
bother
putting
in
the
whole
ticker,
but
I
I
mean
I
just
imagine
you
would
just
get
an
error
if
you
try
and
go
below
what
your
group
has
said
like
if
you
try
to
put
in
two
this,
can
you
can't
put
a
negative
number
in
so.
E
The
other
thing
that
I
also
want
to
ask
for
you
showing
the
ux
here,
is
the
potential
of
the
group
specified
rules
with
the
same
name
with
the
project.
So,
for
example,
I
think
any
eligible
user
is
a
special
one,
but
yeah
but
yeah
at
the
group
level.
We
can
have
a
similar
one
with
that
name
as
well.
So
maybe
you
want
to
have
some
kind
of
indications
here
that
it's
coming
from
the
group
or
would
have
the
peploc
or
so
on.
You
know
it's
some
way
to
differentiate
it.
F
Yeah,
I
was
thinking
so
what
dennis
was
referring
to
is
there's
a
change
going
in
for
like
enabling
the
delayed
project
setting,
there's
gonna,
be
a
lock
that'll
appear
next
to
it,
and
I'll
tell
you
that
it's
been
locked
by
administrator.
I
imagine
if
you
do
a
pop
over
here
that
says
this
rule
is
locked.
It's
been
defined
by
a
group
or
by
I
guess.
In
my
example,
literally,
it's
been
defined
by
group,
so
it's
not
directly
readable
in
the
table.
So
it's
possible.
E
E
No,
you
can't,
you
can't
have
the
same
name,
but
I'm
talking
about.
If
we
introduce
group,
because
I
see
yeah,
they
don't
have
visibility
every
they
don't
need
to
go
into
every
project
to
see
what
rules
are
so
they
potentially
collide
with
the
existing
name
right,
and
I
think
we
should
allow
to
have
similar
name
with
some
way
of
showing
that
it's
coming
from
the
group.
F
Could
happen?
How
would
you
know
the
difference?
Yeah
yeah,
I
see
you're
saying
yeah
we
could.
We
could
maybe
use
a
badge
for
that.
I
do
think
the
lock.
For
now
it's
advice
just
because
the
only
way
that
things
are
getting
locked
is
it's
coming
from
a
group.
So
in
a
way
it's
kind
of
an
indicative
of
itself
that
it
came
from
some
sort
of
parent
object.
D
F
The
way
we
do
it
on,
like
I'm
thinking
the
protected
branches
like
we
put
a
badge,
it
says,
default
or
something
next
to
one
of
the
branches
that
gets
picked,
so
it
could
be
kind
of
similar
but
just
say
group
as.
A
An
immediate
point,
the
if
a
user
is
prevented
from
modifying
approval
rules
on
a
merge
request,
we
would
be
having
a
a
lock
symbol
against
the
project
level.
So
if
you
had
a
group
level
which
said
reviewers
a
project
level
which
said
reviewers,
the
emr
would
say,
reviews
reviewers
without
indicating
which
one
it
came
from,
possibly
unless
the
tooltip
said
right.
This
comes
from
the
project
level.
F
F
Often
but
yeah
I
mean
I
like
your
thinking.
I
think
it
could
be
maybe
cool
to
use
a
a
badge
with
a
lock
and
then
the
name
of
the
level.
It
came
from
group
subgroup
project
so
using
the
same
pattern,
but
maybe
using
a
different
component
to
communicate
more
useful
information.
A
F
No,
no,
I
intentionally
left
that
one
out,
so
we
are
gonna,
basically
do
what
the
instance
level
does
so
instant
says,
prevent
users
from
modifying
mr
approval
rules
that
will
lock
down.
You
know
this
whole
section
and
mr
locks
it
down
in
the
project.
F
F
F
Initially
rob
in
the
thread
last
week
when
you're
asking
me
hey,
which
one
of
these
did
you
need
an
extra
issue
for
an
implementation,
got
you.
A
A
F
D
Eggs
awesome,
I
know
we're
over
time
thank
everyone
for
for
going
a
little
bit
over
any
other
since
we're
all
here.
Any
other
questions
feedback
concerns
anyone
wants
to
voice
before
we
call
it
awesome.
Well,
oh,
okay!
Sorry
I
thought
you're
gonna
start
talking
so
cool!
No,
a
lot
of
topics
here.
I
think
a
lot
of
the
ideas
we
have.
We
just
want
to
circle
back
with
the
the
wider
group
to
just
you
know,
validate
and
they
may
have
to
sam
may
have
to
go
and
talk
to
customers
about
it
as
well.
D
So
I
will
circle
back
and
feed
these
when
I
wake
up
in
six
hours,
so
I
will
take
care
of
that
other
than
that
thanks
everyone
for
joining,
especially
like
shout
out
to
austin
for
joining
it
very,
very
late.
I
won't
mention
the
hour,
but
everyone
else's,
of
course,
as
you
have
an
evening
into
your
perhaps
time
off
or
whatever.
So
thanks
for
joining
thanks
for
the
discussion,
I
think
there's
a
lot
of
valuable
discussion
here.
So
yeah
thanks
and
have
a
good
morning
afternoon
evening
night
thanks.