►
Description
Jason Colyer, Support Operations Manager, takes us through how the Account Deletion form (and related components) work
A
A
A
A
It
contains
all
the
form
html
and
at
the
very
bottom
you've
got
some
basic
javascript
stuff.
It's
going
to
do
some
basic
form
checking
and
then
it's
going
to
submit
this
data
to
a
zapier
web
hook,
which
will
then
refresh
the
page
to
say
thank
you
for
your
submission,
et
cetera,
et
cetera,
et
cetera.
A
A
A
A
Now
you've
got
a
lot
of
functions
in
this
script.
The
first
one
is
the
find
user
by
email.
It
takes
email
that
the
user
put
into
the
form
and
a
get
lab
token.
It
does
a
search
via
the
get
lab
api
and
then
it
basically
just
tries
to
compare
them.
If
they're,
not
equal,
it
will
check
for
secondary
email
addresses
via
the
check
section.
A
Your
emails,
you
know,
object,
function
down
below
if
they
do
match
you're
going
to
end
up
returning
the
user
object,
but
otherwise
it's
returning
false,
let
us
know
they
didn't
match
now.
The
check
secondaries
is
just
going
to
use
the
user's
id
to
check
for
secondary
email
addresses.
If
it
finds
a
match,
it
will
return
true.
A
The
find
user
by
username
is
very
similar
in
that
it's
making
api
requests
using
the
username
they
provided,
and
then
it's
going
to
compare
the
username
they
provided
with.
What's
in
the
gitlab
database,
if
they
match
it's
going
to
send
back
the
user
object,
if
they
don't
it's
going
to
give
us
a
false,
let
us
know
that
they
have
not
passed
this
test.
A
The
find
paid,
namespaces
function,
which
you've
got
right
here,
that's
going
to
make
requests
to
determine
their
memberships,
and
then
it's
going
to
go
through
every
single
membership
to
see
if
any
of
them
are
paid.
If
any
of
them
are
paid
namespaces,
it's
going
to
actually
return
that
they
are
paid
true.
A
A
The
check
page
is
just
going
to
take
the
name
space,
we're
looking
at
grab
the
plan
and
see
if
it
is
part
of
a
paid
plan
or
not
the
paid
plans
being
bronze
silver
gold
premium
and
ultimate
bronze
silver
and
gold
kind
of
being.
You
know
the
older
names
premium,
ultimate
being
the
newer
names.
We
have
a
mix
of
both
right
now,
so
we
have
to
check
for
all
five
of
those.
A
A
The
determine
type
functions
is
going
to
take
the
request,
type
that
is
sent
via
the
form
to
determine
what
type
of
deletion.
This
is
because
some
checks,
don't
a
general
question,
doesn't
need
to
do
as
many
as
all
these
checks.
It
just
kind
of
needs
to
be
a
conversation,
but
a
full
account
deletion
has
to
do
all
everything
it
can.
A
A
The
account
validated
function
is
just
a
check.
Basically,
it's
trying
to
determine
if
any
of
these
are
false.
If
there
was
an
email
issue,
username
issue
a
mismatch,
it's
going
to
return
false
loads,
snow,
yeah,
hey
it
did
not
pass,
it's
not
validated.
Otherwise,
it's
going
to
return
true
to
let
us
know.
As
far
as
the
script
is
concerned,
it
is
validated
we're
going
to
skip
some
of
the
next
functions,
because
mostly
this
is
just
the
messaging
to
use
in
the
issue
itself.
A
So,
let's
get
past
those,
we
have
the
general
question
validated
as
an
example
where
it's
just
giving
us
the
general
question
template
the
issue.
Title
is
going
to
use
the
request,
type
of
that
they
submitted
to
us
and
basically
just
tell
us.
This
is
what
the
title
should
be,
based
on
the
type
of
request
they
sent
for
invalid
issue.
Titles
you're
gonna
have
an
invalid
request
in
their
email
and
there
will
be
a
description
via
the
error
output
list
to
kind
of
tell
us
why
it
didn't
so.
A
Your
issue,
body
you've,
got
your
basic
general
stuff
here
for
your
form
entries
message.
This
is
just
going
to
return
a
string
that
contains
all
the
entries
they
put
into
the
form.
The
reason
for
that
being
we
want
that
information
present,
so
whoever's
working.
The
issue
in
question
can
see
it
review.
It
make
sure
the
script
did
everything
it
was
supposed
to
etc,
etc.
A
I
should
say
the
return
of
find
user
by
username
and
the
original
inputs
message
is
just
that
forms
entry
message
we
showed
before
that
says:
here's
what
they
enter
on
the
form
so
now
we're
going
to
get
into
the
actual
checks,
because
we've
done
a
lot
of
data
gathering,
but
nothing's
really
been
checked
yet.
So
the
first
thing
we
check
is:
did
they
give
confirmation?
A
If
they
didn't
it's
going
to
tell
us
yeah
hey,
they
did
not
give
confirmation
we're
not
going
to
proceed
if
the
user
was
found
was
not
found
by
email.
It's
going
to.
Let
us
know
we
couldn't
locate
them
based
on
this
email.
If
it's
not
found
by
username
same
thing.
We
couldn't
find
this
username
next
we'll
kind
of
go
over
this,
and
if
the
length
of
errors
is
zero,
this
means
so
far.
Everything's
kind
of
passed,
so
we
want
to
do
some
more
checks
here
and
one
is.
A
We
check
the
value
from
user
by
email
and
the
value
of
user
by
username.
We
check
the
username
of
both
these
objects
and,
if
they're
not
the
same
well,
that's
a
problem.
There's
a
username
mismatch.
We
haven't
passed,
we
do
the
same
thing
for
the
email
addresses
and
we
check
for
paid
name
spaces
now
beyond
that,
depending
on
the
request,
type
will
depend
on
what
kind
of
output
we
have
present.
That's
really
what
all
of
this
is
doing.
A
You
can
see
this
giant
thing
is
just
determining
what
our
output
variable
is
from
there
we're
going
to
make
an
api
request
to
mail
gun
we're
making
this
files.
I
believe
python
calls
the
dictionaries
or
library
dictionaries
or
something
along
that
line.
I
don't
quite
remember
the
pythonic
terms
for
this,
so
bear
with
me,
but
essentially
this
is
just
going
to
have
a
from
two
subject
text
and
then
a
header
of
reply
to
the
re.
A
A
That's
all
there
is
to
actually
how
these
how
these
requests
are
processed
from
there
they
go
into
the
project.
We
have
some
triage
stuff
in
place.
That'll
handle
that
and
then
you
know,
support
engineers
or
whomever
is
working.
The
issue
have
their
own
workflows
for
handling
it.
This
is
how
it
goes
from
the
user
wants
to
make
the
request
to
the
issue
so
that
we
can
work
it
from
there.