►
Description
Jason Colyer, Support Operations Manager, takes us through how the Customer Ticket Generator works.
A
A
This
is
just
a
basic
html
form
asking
for
the
required
information
towards
the
bottom.
We
have
some
basic
javascript
checking
for
you
know
bad
entries
and
missing
values.
Beyond
that,
it
will
then
submit.
You
know
an
ajax
request
to
adapt
your
web
hook,
which
will
get
us
in
the
place.
We
need
to
be
the
zapier
web
hook,
which
we
can
see
here
at
the
top
we're
importing
requests
in
json.
A
A
The
first
function
we
see
here
is
the
find
user
by
username.
This
is
essentially
taking
the
username.
They
submitted
the
one
they
said.
This
is
who
I
am
and
then
it's
double
checking
it's
sending
a
request
through
the
getlab.com
api,
to
check
if
the
username
that
they,
basically
they
can
be
located
in
gitlab.com.
A
A
The
next
thing
we
have
is
the
ticket
label.
This
is
basically
going
to
take
the
issue
link.
They
give
split
it
up
to
grab
the
the
project
it
exists
in
and
then
it's
going
to
add
the
issue
id
to
it.
We
also
have
the
ticket
body
function.
This
is
basically
taking
the
description
they
gave,
but
replacing
name
space
list
here
with
a
namespace
list.
A
A
namespace
list
item
is
basically
just
an
asterisk
and
the
item
itself.
The
namespace
list
is
going
to
take
the
namespaces
from
the
user
based
on
the
csv
they've.
Given
us,
it's
going
to
split
it
by
space
and
it's
basically
just
going
to
give
us
a
bunch
of
user
item
a
bunch
of
namespace
items.
A
These
two
functions
here
work
to
basically
not
only
parse
the
csv
string
but
double
check
it,
namely
it's
going
to
split
it
by
lines.
It's
going
to
look
and
say
hey.
There
should
be
three
columns:
three
comma
delimiter,
comma,
separated
columns.
A
If
there's
not
something's
wrong
with
the
csv
file,
we're
going
to
return
false,
we
can
say
it's
not
if
it's
you
know
beyond
that,
we're
going
to
also
make
sure
for
actually
parsing
it
we're
basically
just
doing
split
lines
on
it
to
say,
yeah
split,
each
of
this
giant
string
by
new
y.
A
Here
we
have
the
failed
issue
description.
All
this
is
doing
is
adding
a
bunch
of
information
to
generate
the
issue
to
say:
hey,
it
was
a
failed
request.
Here's
why
we
can't
proceed.
Success
is
doing
the
same
thing.
A
This
giant
function
here
and
I'm
not
going
to
go
too
much
into
detail
over
it.
We'll
go
over
the
detail
of
it
by
looking
at
the
actual
script
in
a
bit,
it's
just
generating
a
ruby
script
for
you
to
run
and
use
in
the
actual
process.
This
is
to
make
your
lives
easier
so
that
it's
quicker
to
kind
of
process.
These
you
don't
have
to
use
the
ruby
script
generated.
You
can
absolutely
manually,
go
make
the
tickets
or
do
something
of
your
own
design.
A
The
key
here
is:
we
want
to
make
the
tickets
we
want
to
make
it
right.
We
want
to
make
sure
we
know
what
issue
link
our
ticket
links.
Were
you
know
what
the
link
to
the
tickets
are,
so
that
we
can
add
them
back
to
the
issue
so
we'll
skip
through
this
labels
that
it's
always
going
to
add
on
the
issue
here:
support
ops
category
other
sports
party
normal.
This
is
for
zendesk
global
and
it's
a
support,
ops
to
do
item
for
a
failed
request
issue.
A
The
title
is
going
to
be
customer
ticket
generator
failed
request.
The
description
comes
from
that
function
above
the
labels
are
the
ones
that
we
got
here
and
it's
going
to
create
the
issue.
Success
is
basically
the
same
kind
of
deal.
Customer
ticket
generator
successful
request
the
description
that
we
generated
above
the
labels.
It's
going
to
assign
the
username
of
the
user
who
submitted
this
ticket.
That's
so
that
they
get
updates
on
this,
and
then
it
will
create
the
issue.
A
Creating
the
issue
is
just
going
to
make
a
post
request
to
the
projects
api
that
were
for
the
issues
api
for
the
project
that
we're
keeping
these
in
the
content.
Types:
application,
json,
the
private
token,
is
a
get
lab
token
to
generate
these
list.
Submitted
values
is
for
a
failed
request
so
that
we
can
see
what
they
submitted
in
the
issue
itself,
so
that
we
can
kind
of
point
to
it.
If
they
ask
questions
but
beyond
the
functions
we
get
to
the
actual
script
itself,
we're
setting
an
empty
array
for
errors.
A
The
subject
description,
submitter
are
all
coming
from
the
input
that
they
gave.
What
basically
what
they
put
on
the
form.
The
author
is
the
submitter.
We
do
that
just
to
duplicate
the
variable,
so
we
can
modify
it
as
needed.
Csv
is
from
the
csv
content
that
they
gave
us
we're
calling
strip
on
it
to
get
rid
of,
leading
and
trailing
white
space
or
yeah.
Sorry,
white
space
is
beginning
in
string
issue.
Link
priority
and
token
are
all
coming
from
input
data
as
well,
whereas
issue
link
priority
are
coming
from.
A
A
A
So
if
there
are,
if
the
length
of
the
errors
is
not
zero,
basically
we're
going
to
submit
a
failed
request,
but
if
it
is
zero,
that
means
nothing
failed.
We
can
submit
the
request
normally
now.
This
is
what
the
form
actually
looks
like
that's
generated
from
the
project
itself.
It's
basically
just
asking:
what's
your
username?
What's
the
subject,
what
issue
is
most
relating
to?
What's
the
priority,
the
ticket
should
have
what's
the
message.
A
Now,
let's
go
into
an
actual
issue
and
we'll
get
to
one
of
these
test
issues
that
we
generated.
A
A
Taking
in
you
know
the
url,
the
username,
the
token
and
saying
it
wants
to
do
a
retry.
The
subject
is
going
to
be
what
they
entered.
You'll
see
it
like
this
in
a
string
format,
that's
something
you
want
to
check
to
make
sure
the
string
is
valid
because
if
they
put
like
single
quotes
in
it,
it
might
not
render
correctly
or
if
they
put
weird
symbols
in
that
can't
be
parsed
correctly.
That
might
also
cause
issues
the
description
string.
A
Basically,
all
this
is
doing
is
giving
us
the
description
string
itself,
the
namespaces
it's
going
to
list
out
the
namespaces
and
it's
going
to
add
them.
You
know
it's
going
to
basically
join
them
with
a
new
line.
A
The
ticket
object.
This
is
where
we
get
the
actual
ticket
object
itself.
This
is
what's
going
to
be
sent
to
gitlab.com
to
zendesk
to
generate
the
ticket.
Now
you'll
see
how
some
things
in
here
look
weird.
This
is
stuff
we
want
to
know
like
as
an
example,
the
user's
array
is
empty.
That's
that's
strange,
even
though
this
says
it's
successful,
we
couldn't
actually
process
this.
It
wouldn't
make
any
tickets.
So
this
is
something
you
want
to
bring
up.
We'd
want
to
kind
of
go
check.
A
Staff
here
see
what
they
submitted
for
the
csv,
come
back
to
them
and
say:
hey
here's
why
this
didn't
work
you
can
see
here.
How,
like
the
join,
looks
weird,
that's
something
we
also
would
want
to
address.
You
can
see
how
I
have
no
idea
what
I'm
doing.
It's,
probably
not
what
they
want
to
be
sending
to
customers.
So
it's
probably
worth
talking
to
them
and
saying
hey
you.
You
said
this
is
what
the
description
of
the
ticket
is,
but
we
probably
shouldn't
send
that
to
the
customer.
A
These
are
good
things
to
check,
for
we
want
to
make
sure
all
this
looks
right,
but
in
theory,
if
everything
looks
good
in
the
script,
you
feel
comfortable
running
it.
You
can
just
copy
this
on
your
computer
and
run
it
and
from
there
it
will
generate
tickets
as
needed.
A
A
You
know,
add
any
tags
that
you
need
to
add,
such
as,
like
the
support
ops,
the
academy
you
know,
support
ops
doing
instead
of
to
do
because
you're
now
working
it
from
there,
you
know
review
the
script
once
you've
run
the
script
grab
the
output
from
the
script
or,
if
you
manually,
make
the
tickets
get
the
ticket
links
paste
them
back
in
the
issue
in
the
issue,
so
that
it's
tracked
add
the
time
that
it
took
you
to
track
it
close
out.
A
The
issue
add
that
label
support
ops
completed,
that's
really
how
you
work
them,
but
if,
at
any
point
you
don't
feel
comfortable
process
absolutely
reach
out
to
your
fellow
support,
ops,
team
members
reach
out
to
myself
reach
out
to
another
support,
ops.
You
know
manager
we're
always
more
than
happy
to
look
over
with
you
and
go
through
the
process.