►
From YouTube: Monitor Respond Live Code Public Stream 10.10
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
A
Okay,
so
what
we're
doing
today
is
continuation
of
last
Wednesday.
The
goal
is
to
fix
the
broken
aspect
tests
so
in
updating
what
we
needed
to
like,
like
if.
B
A
Watched
Wednesday
you'd
see
we
broke
some
tests,
so
our
goal
is
to
fix
those
tests,
that's
our
primary
goal
and
then
yeah
we'll
keep
going
from
there.
So
I'll
share
my
screen
answer
today
with
us.
This
is
Peter
Peter's,
one
of
the
back-end
Engineers
on
monitor,
respond
team.
A
Okay,
so
for
starters,
we'll
have
a
look
at
the
actual
failing
test
and
what
we've,
where
Tristan
and
I
got
to
last
time.
So
here
is
our
failing
test.
The
problem
is
that
when
now
we're
injecting
the
incident
path,
I
think
is
the
problem
and
we
weren't
previously.
So
the
test
was
expecting
the
no
incident
path
and
it
got
an
incident
path,
let's
see
from
the
Plus,
so
then
to
fix
it.
What
we
tried
to
do
is
just
dump
an
incident
path,
but
the
problem
is
that
name.
A
Space.
Four
is
not
the
same
name
every
time.
So
I'll
just
run
this
test
again
to
see
where
we're
at
now
so
I
just
did
just
a
couple.
Little
changes
so
tried
to
add
like
the
static
path
for
this
test,
but
this
didn't
work
because
yeah,
it's
not
always
namesable,
it's
not
always
project
four
and
then
I
thought.
Okay.
What
the
next
step
would
be
to
get
the
dynamic
path
and
inject
it
into
the
expectation
of
the
test
same
as
we've
done.
B
So
yeah
yeah,
let's
start
so
I
I,
have
a
question
about
the
incident
path
actually
being
passed
to
the
front
end
because
in
the
implementation
I'm
seeing
that
we
are
passing
a
symbol
to
the
path
helper.
If
you
go
to
the
helper
to
the
production
code
incident
helper.
B
Yeah,
if
you
go
to
the
incidents,
no,
no,
it's!
Let's
start
in
the
incident
helper.
Are
we
yeah
right?
So
on
line
16
16?
We
are
passing.
A
B
Sim
symbol,
incidents
to
to
issues
incident
path,
so
usually
this
should
be
like
a
very
special
like
this
should
be
in
ID
of
an
incident
or
on
incident
object.
B
B
B
A
B
Is
being
used
on
on
a
view
called
app
views.
A
A
A
B
B
A
A
B
Yeah
yeah,
so
so
this
helper
is
being
used
on
the
on
the
show
page
of
the
incidents.
So
at
that
point
we
don't
don't
have
any
any
incidents
object
to
to
construct
a
path
from
from
right.
So,
okay,
my
question
is
now:
if
you
go
back
to
the
helper
and
the
incident
path
is
actually,
how
is
this
property
being
used
by
the
front
end.
B
My
my
Impressions
that
we
are
using
this
property
in
the
front
end
and
kind
of
like
we
right
now.
It's
a
static
string
right.
A
B
It's
it
says:
go
to
the
project.
Slash
incident,
slash
incident
as
a
word.
So
if
you
look
at
the
failure,
actually
you
have
in
your
bottom
terminal.
Yeah.
You
see
the
the
incident
passes,
namespace
project
issues,
slash
incident,
slash
incidents,
so
there's.
A
B
Is
basically
the
the
route
the
the
second
one
is
the
symbol
we
are
passing
to
the
to
the
helper,
so
the
password.
So
my
question
is:
how
is
the
incident
Pass
Property
being
used
on
the
frontal
side?
So
do
we
need
to
replace
on
the
front
end
the
like
the
last
part
and
right
now
it's
it's
incident
right
with
with
a
kind
of
ID
with
on
the
on
the
front
end,
it's
all
happening
or
how
is
it
used
because.
B
If
we
need
to
do
it,
we
need
to
come
up
like
like
with
some
perhaps
another
symbol
or
string.
We
are
passing
to
this
path
to
construct
the
resulting
pass
or
the
the
property,
because
otherwise,
if
we
want
to
replace
incident
with
ID,
for
example,
you
would
like
kind
of
match
match
it
twice,
because
it
is
twice
in
the
in
the
property
right.
It's
it's.
B
It
says
issue
slash
incident,
slash
incident,
so
I
I
I
would
suggest
to
either
pass
like
an
capitalized,
adid
or
IID
or
whatever,
and
then
in
the
front-end
code.
We
would
replace
this
capitalized
ID
or
ID.
With
the
ID
of
the
incident
of
the
yeah
incident.
We
are
rendering
right
so
I
I'm,
not
I,
just
my
guess
right
now
that
we
are
using
it
this
way.
So
it
would
be
interesting
to
see
how
the
incident
pass
is
being
used.
B
A
B
A
B
Just
just
a
heads
up,
we
I
think
we
are
defined
in
this
much
regrets
request.
We
are
defining
incident
path
in
two
rails,
help
us
so
just
just
to
be
aware
that
we
are
not
confusing
them,
so
I
I
assume
they
are
both
needed,
but
just
just
like
making
sure
that
we
are
not
looking
for
the
for
the
other
one
I
think
the.
B
Is
being
defined
in
in
the
other
helper
I
forgot,
the
name
already.
B
Let
me
check
it
is
in
yeah
it's
in
issuables
helper,
so
there
we
are
actually
defining
also
incident
path,
but
but
for
a
very
specific
issuable.
In
this
case
the
issue.
Well,
it's
kind
of
a
different
word
of
for
incident
in
our
case,
so
so.
A
B
B
So
just
to
like
so
so
we
don't
waste
time
and
like
talk
about
court,
which,
which
is
probably
fine.
A
A
B
B
Issuables
helper
issuables,
the
the
other
one
I'm.
A
B
A
B
And
this
makes
sense
for
for
this
Helper
because,
like
I
assume
the
this
is
like
the
view
like
the
show,
show
view
template
for
Flawless
incident.
I
guess
so.
B
A
B
Okay,
so
I
think
at
gitlab.
At
some
point
we
defined
the
word
issuables
I'm,
not
very
sure,
about
the
the
history,
so
I
might
be
very
wrong,
but
issue
is
used
to
be
for
a
long
time
like
an
apps
kind
of
abstraction
for
issues
and
much
requests.
B
A
B
Not
talking
about
the
the
main
functionality
but
like
adding
comments
or
assigning
Milestones.
A
B
Functionality
actually,
and
as
far
as
I
understand
the
word
issueable
was
chosen
for
that
later.
We
added
like
even.
A
B
Yeah,
more
issuable
types,
I
would
say
like
epics
and
I,
think
it's
it's
even
more
I
forgot
the
list.
This
kind
of
I
would
say
Legacy
because
I
think
right
now
we
are
moving
towards
work
items
or
something
like
that.
So,
but
you
will
find
the
word
issuable
a
lot
still
in
our
in
our
code
base.
So
every
time
you
see
issueable,
you
can
think
of
this
like
object
or
variable
being
either
an
issue
or
merge
request
on
Epic
I
forgot
the
other
ones,
I
guess
they
are
like
two.
Two
more.
B
So
so
so
we
are
defining
like
the
two
properties,
but
they
are
used
differently,
I
assume,
so
the
upper
one
is
being
used
on
the
on
the
list
page
where
we
actually,
if
you
can
bring
up
the
incident
issue
list
so
so
we
are
on
on
this.
B
A
Got
bookmark.
B
Yeah
yeah
perfect.
This
is
great,
so
this
is
like
the
list
of
incidents
and
my
assumption.
As
far
as
I
understand
the
incidents
data
helper,
we
we
also
added
incident
path.
Two
is
used
on
this
page
and
if,
if
you
click
on
on
a
specific
incident,
for
example,.
B
A
B
How
is
the
list
of
the
incidence
ran
out?
Because,
if
you,
you
see
like
many
properties
of
an
issue
right
severity
incident
status
and
so
on
and
yeah,
you
can
already
like
click
on
the
incidents
and
this
like,
if
you
hover
over
this,
this
already
gives
us
the
path
to
the
incident
right.
So
apparently,
we
already
know
how
to
navigate
from
the
list.
View
list
list
template
to
a
specific
or
individual
incidents.
So
my
question
would
be:
do
we
even
need
this
property
being
defined?
A
A
B
So
this
code
already
exists
now
in
our
merge
request.
If
you
go
back
to
our
match
request
the
the
upper
definition
of
incident
path,
yeah,
this
one
yeah,
it's
kind
of
like
defining
incident
pass
but
I
wonder
for
what
reason.
Why
do
we
need
this
definition?
If
we
already
know
how
to
go
from
the
list
page,
like
incident
page
sorry
to
the.
B
Yes,
I
I
would
assume
so
because,
if
you,
if
you
expand
the
code,
a
little
bit
yeah
the
chain
yeah
go
up
yeah.
This
should
be
incidence
data
and
we.
A
B
This
helper
being
called
in
the
index
Hammer
right.
A
B
A
B
A
A
B
A
A
B
Just
remove
the
other
definition.
B
Because,
like
we've
as
far
as
I
see,
we
haven't
done
any
changes
on
the
on
the
front
and
sides
to
use
sites
to
use
this
newly
defined
property.
So
that's
cool
I
guess
the
test
should
pass
because
yeah.
So
by
the
way,
if
you
scroll
up
to
the
failure
and
the
diff,
basically
on
the
internal
window,
yeah
yeah,
you
see,
you
see
a
lot
of
a
little
bit
down.
Please
where
you
see
the
difference
you
see
a
little
like,
although
we
are
just
failing
a
single
property,
it's
showing
more.
B
A
A
B
A
A
A
A
Like
so
issuables
helper,
the
test
for
this
should
be
broken
right.
Yes,.
B
Yeah
easy,
perhaps
let
me
find
out
yeah
I
think
we
have
I'm
not
sure
if
it's
specifically
for
the
for
the
incidents
but
yeah,
we
have
one
but
like
not
specifically
for
this,
for
this
method,
because
this
method
is
like
kind
of
I
would
say,
private
private
method
and
only
being
used
well,
it's.
B
Private
I
mean
it's
not
really
used
outside
of
the
helper
itself
in
like
in
view
templates,
but
it
is
only
used
by
another
helper
which
which
is
called
issueable
initial
data.
So
if
you
go
to
the
app
helpers
issue,
will
helper
Ruby
code.
B
A
A
B
A
B
Like
a
helper
module
right
yeah,
you
have
a
bunch
of
method,
definition
inside
a
module.
You
can
Mark
methods
as
private
yeah.
A
B
A
B
Have
to
you
have
to
you
have
to
omit
the
receiver,
so
you
only
can
do
issue
only
initial
data,
the
problem
in
rails
or
not
the
problem
but
caveat,
is
that
every
helper
you
define
in
rates
is
automatically
exposed
to
view
templates
so
exposed
meaning.
The
modules
are
literally
included
in
the
template
views.
So,
okay,.
A
B
You
include
a
module
into
into
a
class
or
other
module,
all
the
private
private
private
methods
are
available,
so
the
Only
Rule
you
have
to
kind
of
match
is
from
the
Ruby
scientists.
You
are
not
allowed
to
to
explicitly
Define
a
receiver,
so
you
cannot
do
like
food
dots,
initial
and
and
if
and
if
you
are
not
doing
this,
you
are
happy
to
or
welcome
to
use
even
private
methods.
It's
just
just
just
a
sign
out
side
note
from
from
the
Ruby
lens,
so.
A
Heard
that
we're
getting
a
new
engineering
team
to
focus
on
tests-
and
maybe
we
can
write-
create
an
issue
for
them.
B
Oh
nice,
this
is
great
I,
wonder
like
if
we
we
could
do
it
or
we
could
add
a
test,
let
if
you
go
to
the
issueables
help
us
back.
Actually,
we
might
be
able
to
add
this
to
like
to.
We
could
expand
the
specs
to
match
our
our
newly
added
property.
So
if.
A
So
we
could
do
this
here,
but
it's
going
to
have
to
be
in
a
separate
bird
request
anyway.
I.
B
Adding
the
much
we
are
adding,
basically
the
property
right
now
so.
A
B
A
B
B
Either
copy
and
paste
like
an
example
from
the
expected
data
above
like
endpoint
or
update,
endpoint
and
modified
it
at
our
will.
We
can
do
it,
but
to
be
to
be
honest,
I'm,
not
a
huge
fan
of
so
the
reason,
I
see
or
I
like
the
way
I
see
route
help
us
is
kind
of
like
methods
to
my
mind,
so
like
a.
A
B
Table
will
return
like
a
string
which
is
basically
routes
to
to
to
our
application,
and
if
we,
what
I'm
trying
to
say
is
we
can
I
I,
don't
have
a
problem
to
use
a
route
helper
in
specs
as
well,
although
it's
it.
A
B
B
That
right,
yes,
yes
yeah,
so
it's
it's
kind
of
cheating,
basically
and
I
kind
of
agree
on.
On
the
other
hand,
we
are
testing
the
implementation
details,
details
of
the
router
helper
every
time.
So,
if
you
think
about
that
this,
like,
if
we
were
to
change
the
the
route
for
for
issues,
for
example,
uh-huh
and
honest
suddenly
like
a
lot
of
specs,
will
fail
because
we
are
not
using
the
the
methods
over
and
like
to
check
what
what
is
to
check
the
property.
B
But
we
are
basically
checking
the
implementation
detail,
meaning
like
this
is
a
string,
slash
issue,
slash,
IID
and
so
on,
but
having
started
I'm
fine
to
just
copy
and
paste
and
adjust
the
strength
right
now,
at
a
later,
Point
I
I
try
to
perhaps
come
up
with
an
issue
to
to
address
this,
because,
like
I've
seen
that
lots
that
we
are
using,
like
the
specific
paths
and
I
I,
think
we
shouldn't
do
it.
So
in
this
case.
B
I
think
we
should
use
in
this
this
case
the
the
route
hyper
methods.
A
A
B
A
A
B
I
think
the
property
name
is
actually
camera
cased.
So
right
now
the
property
name
is
issue
underscore
path,
but
I
think
it
will
be
camera.
A
A
A
B
Reasons
what
I
want
to
see
as
a
good
or
tdd
test
driven
development
guy
I
would
like
to
see
a
red
failure
for
this.
Just
like
perhaps
yeah
perfect.
Well,
no,
not
one
but
X,
because
one
it
could
be
the
ID
right.
So
you.
A
A
Oh
I'm.
B
A
B
Say
space
Dash
e
space
and
then
the
basically
the
name
of
the
context
or
the
thing
you
want
to
test
so
yeah.
If
you
go
to
live,
yeah
I
think
this
is
enough:
yeah,
because
it's
shorter
yeah
it
doesn't
have
to
be
the
whole
thing
it
can
match
substrings
so
yeah,
but
you
have
to
put
quotes
around
it
so
because
otherwise
hash
is
being
interpreted
as
as
a
shell
command
yeah.
B
This
should
now
only
run
the
specs
for
for
this
one
and
I'm
I'm
sure
it's
it's
all
doable
in
the
vs
code
as
well,
but
is
it
vs
code?
Yes,.
A
A
A
B
A
Use
the
debugger
anyway,
okay,
okay,.
B
A
B
A
B
To
match,
including
okay,
this
is
perhaps
I
was
confused
by
the
by
the
diff
I
was
expecting
much
shorter,
diff,
similar
to
what
we've
seen
before
on.
A
B
It
doesn't
have
to
be
this
order
and
you
can
miss
out
some
some
keys,
like
I,
think
you
could
even
it's
still
failing.
B
Is
it
I
feel
like
running
aspect
nowadays
is
slow
for
several
reasons,
and
we
try
to
fix
this,
but
I
have
yeah.
First
of
all,
I
think
we
don't
need
to
create
an
and
the
user
every
time
yeah.
A
B
So
issue
will
pass
as
namespace
one
project
One
issues
incident,
one
if
you
go
down
scroll
down
right,
yeah-
and
this
is
incident
path-
is
also
called
incident
path.
It's
also
so
it's
it's
kind
of
same
right.
A
B
Nice
spot
yeah.
Thank
you
yeah.
It
should
read
incident
path,
actually
so
yeah.
Sorry
about
that.
This
one
yeah,
no
problem,
can
you
just
yeah
run
the
specs
and
just
like
for
Giggles.
Can
you
remove
the
hash,
including
stuff,
right
right,
why
these
things
are
running
yeah,
yeah
remove
and
the
parentheses
as
well
yeah,
and
if
we
expect
the
specs
now
to
pass,
if
you.
A
B
I
know
it's
it's
failing
for
different
reasons:
yeah,
if
you,
if
you
undo
your
changes
with
the
hash,
including
and
now
it
should
pass
I
I
thought
you
were
just
already
starting
the
aspect,
but
it
took
some
time.
So
it's
fine.
B
B
A
A
Okay,
so
I'm
gonna
commit
it
already.
It's
fine
so
we're
going
to
commit
this
and
then
the
other
problem
we
have
that's
Ruby
related.
Is
this
this
comment
that
Tristan
noticed.
A
Go
to
issues
slash
incident,
so
if
you
go
to
the
list
of
issues,
some
issues
are
incidents.
So
not
all
issues.
I
know.
You
know
this
I'm,
just
explaining
for
the
audience
right.
B
A
A
B
Something
for
that
few
Milestones
ago,
perhaps
one
or
two
so.
A
A
B
Do
you
remember
why
so
I
remember
the
discussions
actually
that
we
didn't
want
to
like?
If,
if
users
are
browsing
the
yeah,
because
it
is
surprising
to
switch
the
navigation
bar
on
the
left
right,
if
you
are
on
the
issues
list,.
A
A
A
A
A
I
think
this
is
where
this
fit
is
super
confusing
for
me.
So
let's
have
a
little
bit
of
changes,
so
my
understanding
is
on
the.
A
A
A
A
B
Looking
out
now
at
right
and
in
this
much
request,
we
only
added
like
three
more
ways
or
three
more
routes
actually
to
the
incidence
section
or
incidents
route.
Yeah
timeline,
metrics
alerts,
so
we
didn't
touch
any
any
kind
of
backend
codes
in
that
regards
and
actually
this
code,
if
we
were
just
to
add
the
the
routes-
and
they
are
all
pointing
to
the
very
same
controller
and
action
incident-
show
we
haven't
changed
any
any
kind
of
behavior
on
the
backend
side,
at
least
so.
A
B
Assumption
is
that
the
vue.js
right
in
in
a
way
is
changing
the
when
clicking
on
okay.
A
B
So
I
from
this
comment,
I
don't
really
get
what
causes
the
redirect
actually
and
one.
A
B
Idea
would
be
that
it
might
be
the
cut
might
be
caused
by
the
back
end,
the
other
one
it
might
be
caused
by
the
front-end
router
right.
So
we
don't
know
it
yet.
So
in
order
to
to
find
out
which
which
one
to
blame,
you
could
perhaps
comment
the
route
definitions
on
the
backend
side
first
and
verify
on
GDK
that
if
this
code
is
gone,
that
the
redirect
is
also
gone.
A
But
what
I
feel
like
is
happening
is
just
every
time
you
go
to
an
incident.
You
go
to
this.
You
go
through
this
path,
but
when
we
Define
the
base
path,
we're
actually
using
the
incident
path
instead
of
either.
B
A
Incident
or
the
issue
path,
so
even
if
it's
we're
looking
at
it
as
if
it's
an
issue
we're
using
the
incident
path,
so
I
guess
on
the
we
can
either
do
like
on
the
back
end,
we
can
say
like
if
it
is,
if
we
go
through
the
incident
path,
use
the
inside
of
the
path.
If
we
go
through
the
issue,
path,
use
the
issue
path,
okay,
but
then
again
we're
going
to
have
to.
B
B
Yeah,
the
problem
is:
do
you
you've
seen?
We
support
a
lot
of
more
more
issue
types
which
is
not
with
issue
type,
to
to
remind
you.
It
might
be
an
issue,
an
incident
and
test
case
I
think
it
was
and
at
the
task
right
so
right
now
we
support
all
of
them,
and
we,
if
we
were
to
choose
a
generic
name
like
base
path,
you
would
need
to
support
all
of
them.
B
And
we
can
do
it,
but
foreign.
A
No,
so
what
we
could
do
is
we
could
look
at
the
current,
like
URL
window.location.
A
And
we
could
compare
it
to
the
base
and
we
can
say
like
if
window.url
sorry
window
dot
location
has
the
word
incident
in
it.
Then
we
should
cut.
Oh
sorry,
we
should
leave
incident
in
the
place.
If
it
doesn't
have
incident
in
it,
then
we'll
just
cut
it
out.
That
would
work,
but
it
feels
a
little
bit
messy.
B
B
A
To
confirm
that,
so
if
we
go
if
we're
here,
no,
so
if
we
go
so
if
we
go
here,
issues
issue
number
this
page,
the
issue
type
is
still
incident
right.
Yes,
but
we're
looking
at
it
as
if
it's
an
issue
so.
B
A
B
For
this
we
could
use
the
property
of
it's
called
issue
type
actually,
which
is
also
passed,
and
this
should.
B
Yeah
it's
already.
If
you
look
into
the
Ruby
helper
again,
where
we
defined.
B
A
B
A
Okay,
so
then
what
we
could
do
in
the
front
end
is
we
could
look
at
issue
time
and
if
it
is,
if
it
is
sorry,
could
we
do
this
on
the
back
end
probably
say
forget
it.
If
you
help
out
when
we
create
the
no
that's
issueable
helper,
that's
the
wrong
one!
Okay,
so
this
is
where
we
say
incident
path.
A
Can
we
can
we
update
this
function?
Yeah.
B
B
If
you
would
need
to
support
all
types
of
of
issues
right,
yeah,
okay,
so
but
I
think
we
I
just
realized.
If
you
go
to
the
sorry,
I
need
to
switch
back.
If
you
scroll
up
in
this
file
on
yeah
online
239,
there's
a
there's,
a
endpoint
called
issuego.
Okay.
This
is
interesting.
If
you,
if
you
go
to
the
definition
of
issueable
path,.
A
An
extra
Ruby
extensions.
A
B
Works
in
JavaScript
yeah,
so
it's
basically
using
the
polymorphic
path
for
that.
So
with
that,
actually
we
are
able
to
create
a
route
string
for
each
issue
type.
B
If
it's
an
issue,
it
said
just
says:
slash
issues,
slash
or
slash
issues,
slash
ID.
If
it's
an
incident,
this
issues
incident
ID
and
test
case
issues
test
case
ID
and
for
for
the
task.
So
we
are
polymorphic
in
that
regard,
so
we
could
just
use
instead
of
adding
and
again
a
new
property.
We
could
just
use
the
midpoint,
and
let
me
verify
this
on
why
that's.
A
B
You,
if
you
add
before
the
author
property,
if
you
add
a
double
colon
incident,.
B
A
B
This
means
we,
this
issue
is
no
longer
an
issue,
but
an
issue
of
type
incident
which
is
again
confusing
and
we
will
just
to
run
the
spec
and
you
can.
You
can
run
the
spec
and
we
learned
that
you
can
pass
like
names,
but
you
can
also
pass
the
the
line
number.
So
you
can.
You
can
run
the
spec
of
this
file
and
appends
double
colon,
three
two
five
and
this
would
run
the
spec
by
line
number
yeah.
If
can
you
remove
the
dashboard
instead
of
yeah
yeah,
like.
A
A
B
B
A
B
B
B
Polymorphic
path
doesn't
know
about
issue
types
actually
and
I
need
to
look
it
up.
If
we
so
a,
we
have
to
Define
like
a
new
property,
because
we
don't
get
this
yet
and
I.
Let
me
try
to
find.
A
A
B
A
B
B
A
B
This
is
on
the
front
end.
I
guess
this
is
done
on
the
front
end,
so
the
vue.js
code
actually
is
is
different
and
I
I
think
all
the
rendering
is
done
on
the
on
the.
A
A
B
A
B
B
The
name
of
the
incident
I
think
no,
no,
you
have
it
on
the
issues
you
have
to.
If
you
go
back
to
the
preview
or
tab
in
the
graphql,
we
were
just
clicking
yeah.
If
you
go
go
down
down
down
yeah
this
one.
This.
A
B
A
B
A
B
B
A
B
Could
just
Implement
the
property
for
issue
and
incident.
B
Just
to
make
like
the
GDK
work
again
or
not
not
redirect
to
the
wrong
path,
so
we
are
good.
So
if
you
go
to
the
Ruby
helper,
where
we
Define
the
incident
pass
path.
B
A
B
B
B
A
B
B
So
if
you
go
to
your
GDK
and
open
open
the
JavaScript
console
on
the
on
the
yeah
on
the
network
network
graph,
sorry
Network
and
make
some
changes
on
a
specific
view
on
a
specific
issue.
If
you
go
to
the
issue
list
pick
or
just
remove
the
incident
from
the
location
bar
right
now,
yeah
go
to
the
issue
view
of
the
incident,
which
is
also
the
excellent
view,
but
just
a
different.
B
If
you
go
to
network
network
type
yeah
and
if
you,
for
example,
change
I,
don't
know
the
title
so
is
my
question
is:
is
this
doing?
Okay,
it's
okay,
it's
doing!
Graphql!
Okay!
Do
you
know
what
I
wanted
to
test
is,
whether
like
we
are
actually
using
the
endpoint
or
the
update
input
at
all.
A
B
B
Okay,
so
let's
not
do
this.
A
B
A
A
B
So,
let's
add
a
new
method,
so
basically,
if
you
copy
and
paste
or
like
cut
or
remove
the
value
of
this
here,
let's
extract
this
into
methods.
So
we
would
call
it
like
issues,
show
path
or
issue.
Issue
type,
show
path,
something
silly.
We
can
change
yes,
yeah
and
just
pass
the
issueable
to
it.
B
B
Everything
to
to
us,
you
don't
also
don't
need
to
ask,
because
it
will
never
be
no
okay,
Now
define
a
new
method,
called
issues
show
path.
A
B
B
Parameter
is
called
issue
the
power
of
the
argument,
the
parallel
argumentary,
so
I
think
it's
spelled
differently.
You
have
to
get
rid
of
the
e
I'm,
not
sure
if
it's
the
yeah
okay
and
what
we
could
do
is
as
simple
as
a
case
statement
which
is
switch
in
JavaScript.
A
B
Yeah
yeah,
yeah,
okay,
so
so
case
statement
Ruby
goes
like
that.
You
define
case
and
object
and
the
the
cases
are
when
so
the
keyword
when
when
yeah
and
we
want
to
match
on
not
on
the
issue
but
on
the
issueable
issue
type.
So
if
you
go
go
up
to
the
case
statement
again
sorry
and
adds
dot
issue
underscore
type.
B
A
B
Did
it's
it's
like
the
last
expression
in
in
Ruby's
return
statements
implicitly,
so
we
could
just
return
the
issue
project
paths,
so
I
I
forgot.
We
we
had
it
previously
right,
so
it's
I
think
it's.
Let
me
check
so
better
Trends.
It's
project
underscore
issues
underscore
path
so.
B
A
B
No,
it's
got
issues
underscore
incident,
I'm,
a
Spoke,
sorry,
residence
path
and
we
are
passing
the
very
same
yeah
and
to
be
fair.
Let's,
usually,
we
want
to
have
a
else
statement.
So,
let's
remove
the
when
issue
statements
and
return
the
project
issue
path
for
for
everything
else,
so
meaning,
if
you
remove
the
one
one
statement,
just
remove
it
and
go
line
law
and
remove
below
remove
the
yeah.
This.
B
A
B
A
B
We
just
return
like
the
issues
part
and
we
don't
care
about
the
other
cases,
and
probably
we
don't
need
to
care
about
until
test
case
or
tasks
are
you're
doing
some
things
specific
to
this
person.
They
are
not
doing
anything,
so
this
I
guess
should
work.
So
if
you
were
to
run
tests,
they
should
pass
yeah.
B
A
B
A
This
project
training.
B
B
Race
goes
like
this,
like
the
list
like
listing,
resources
is
always
plural
and
the
like.
The
actions
on
a
on
our
individual
resources
is
similar.
I
guess
so.
This
should
pass,
but
like
okay,
now.
B
Yeah,
so
in
in
ideal
works
we
would
just
add
a
spec
for
the
methods
we
added.
B
I'm
not
sure
if
we
want
to
do
it,
so
we
there
are
two
ways
to
test
this
either
test
this
newly
added
method,
which
which
would
be
much
smaller.
Oh.
B
So,
okay,
let's,
let's
ignore
the
other
case
for
now
so
remove
the
dot
in
the
double
color
incidents.
Factory
Bots
trade-
for
that
yeah.
A
B
B
B
A
B
Okay,
so
I
I,
I've
never
got
tested,
but
I
think
I
I
have
some
form
of
OCD,
but
I,
not
apparently
it's
not
just
specific
to
to
sorts
constants
alphabet,
at
least
so
I
don't
care.
A
B
A
B
B
A
B
Okay,
let's
go
to
the
product
production
code
of
the
of
the
helper
again.
B
B
A
A
B
So,
okay,
can
we
can
we
check
where
we
actually
use
the
helper
help
our
methods,
because
otherwise
we
can
just
only.
B
No,
not
this
one
but
the
where,
where
this
method
is
actually
used,
because
otherwise,
because
we
don't
need
this
logic
at
all
and
just
like
pass
the
project
issue
path
to
that
or
okay
I
I
think
I
may
misunderstood
the
initial
intent
of
what
we
want
to
to
have
the
show
pass
to
be
so
it's
not
a
show
pass
because
this,
like
from
so
for
the
meaning
of
Show
Pass,
would
be
to
me
if
it's
in
incident
I
want
to
have
issues.
Slash
incident,
slash
ID,
but
we
want
this
to
be.
B
A
B
A
B
B
No
I
can
cannot
see
it
I'm
not
seeing
this
okay,
so.
B
B
A
B
B
Yeah
this
we
can
copy
it's
it's
Below
in
a
difference.
Yeah
I
find
the
show
pass
or
whatever.
B
Do
this
right,
yeah
or
alternatively,
we
could
use
endpoint
in
the
front
in
the
view
JS
code,
but
let's
let's
go
with
this.
We
don't
need
to
run
specs
if
you
just
yeah,
I,
couldn't
really
I.
Think
it's
fine.
B
A
B
Nice,
okay,
so
I
I,
understand
so
I
I
just
wanted
to
verify
that,
and
my
assumption
was
wrong-
that
it's
only
used
on
the
issues
list.
So
it's
it's
used
as
well,
apparently,
which
is
which
is
fine.
Okay,.
A
I
know
where
blackwork,
where
I've
in
meantime
we
had
allocated.
So
if,
if
you
want,
we
could
I'm
ready
to
finish
soon,
we
could
continue
this
asynchronously
yeah.
B
Yeah,
let's
do
that
because
a
few.
B
Yeah
I,
yeah
I
think
I
I
missed
some
some
some
some
context
here
to
to
understand
like
the
problem.
But
it's
it's
fine,
I
I
think
we
made
some
progress.
A
B
Okay,
nice
yeah,
so
let's
leave
it
leave
it
with
with
that
and
follow
up
on
the
MetroCast.
I
I
will
have
a
look
because
yeah
I
sometimes
see
faster,
like
typical
myself,
which
is
yeah
for
sure.
Often
the
case
when
prayer
programming
right.
But
it's.
B
A
B
To
handle
incidents
differently
than
issues
or
test
case
is
assume
I'm,
not
sure
about
that.
So
perhaps
it's
a
good
who
could
be
good,
fits
to
continue
this
like
to
adding
conditions
on
the
front
and
rather
than
on
the
back
end,
so
yeah.
A
B
A
A
B
Only
like
I
I
feel
like
Frontage,
should
that
should
only
have
enough
information
to
to
handle
this
case,
but
perhaps
not
so
it's
yeah
I,
don't
know.
I
I
understand,
like
we
shouldn't,
replicate
the
logic
on
the
front
end
to
construct
the
URL,
the
different
URLs.
So
this
should
be
best
exposed
by
by
back-end,
because
if
we,
for
whatever
reason
decide
to
change
the
routes
to
incidents,
we
won't
end
up
changing
the
frontal
code
as
well
as
right.
So
it's.
A
B
Unlikely,
but
still
so
it's
it's
doable
on
the
back
end.
Obviously,
what's
yeah,
let's
follow
up
on
on
the
Marshall
question.
A
Okay,
yeah
yeah,
sorry,
so
what
I
heard
you
say
well,
I
just
want
to
make
sure
was
when
we
render
the
list
of
issues
or
incidents
on
at
this
stage,
we're
currently
building
that
link
to
the
incident.
A
Whether
it's
a
incident
link
or
an
issue
link
we're
deciding
that
on
the
front
end,
then
we
were
just
accepting
the
path
on
the
back
end,
but
if
we
were
able
to
determine
on
the
back
end,
should
it
be
issues
slash
or
should
it
be
issues
slash
incident
slash
if
we
can
make
that
decision
on
the
back
end,
then
we
should
also
make
that
decision.
On
the
back
end,
when
we
render
the
lists.
B
B
But
yeah
so
it
basically,
it
boils
down
to
where
to
implement
the
logic
of
constructing,
like
constructing
a
routes
to
either
issue
or
incident
right,
and
one
could
argue
there
are
cases
for
for
defining
them
on
both
sides,
but
I
also
understand
like
to
find
it
on
the
back
end.
Even
if
backend
is
not
using
this
information
other
than
Expo
or
passing
it
to
the
front
end.
But
I
I
also
understand
that
the
front
end
do
not
want
to
replicate
any
kind
of
route.
Construction
logic.
B
And
it
would
just
like
receive
a
property
which
is
like
and
use
the
property
like
we
used
in
the
router.
So
you
you
just
change
incident
paths
to
show
pass
and
it
just
magically
worked
because
we
created
a
new
router
based
on
this
path
right,
so
I
think
from
from
the
front
fronts,
fronts
front-end
side
of
view
makes
sense
to
to
let
the
backends
actually
Define
define
the
past.
We
should
also
come
up
with
a
good
name:
Yes
Show
Pass
is
not
a
good
name
yeah.
A
B
In
a
different
mindset,
so
it's
we
should
come
up
with
I,
don't
know
action
path
or
like
kind
of
it's
it
should
the
the
name
should
make
sure
like
make.
Make
it
clear
that
we
are.
You
want
to
stay
on
the
on
the
current
controller
right.
So
if
it's,
if
we
are
on
an
incident
on
issues,
we
should
say
within
issues,
we
are
issues
incident
we
should
say
and
so
on
so
this
this
name
should
include
this
information.
B
Okay,
let's
try
this:
can
you
push
your
changes
so
yeah?
We.