►
From YouTube: Magento GraphQL Community Meeting, 13 December 2018
Description
Agenda:
-) Plans for 2.3.1/2.3.2 release (velocity/public burndown chart) (@mkotov)
-) GraphQl-42: [Query] My Account - My Downloadable Products (@Yaroslav Rogoza)
-) [FEATURE] Added Grapqhl Endpoint to Retrieve Last Order Information (@Mr. Lewis)
-) [TASK] Added the StoreName to the StoreConfigData (@Mr. Lewis)
GraphQL Community Project Wiki: https://github.com/magento/graphql-ce/wiki
Mind Map: https://www.mindmeister.com/1094880388?t=a5LVAQ71Vq
Backlog (with Zenhub): https://github.com/magento/graphql-ce#boards?repos=128075669&showPRs=false
Backlog (without Zenhub): https://github.com/magento/graphql-ce/issues
Zenhub Chrome Add-on: https://chrome.google.com/webstore/detail/zenhub-for-github/ogcgkffhplmphkaahpmffcafajaocjbd
A
All
right,
let's
get
going
good
morning,
everybody
and
good
afternoon
to
some
of
you
welcome
to
our
weekly
graphical
meeting.
I
think
holiday
might
be
absent.
Today.
He's
got
some
other
things,
but
he
was
kind
enough
to
provide
an
agenda
for
us.
So
what
that
looks
like
is:
we've
got
several
things.
One
will
talk
about
releases
that
are
coming
up
that
are
in
the
pictured
post
to
3-0.
A
We've
got
the
presentation
about
my
downloadable
products
and
then
a
couple
things
from
mr.
Lewis
here
about
so
a
feature
that
has
to
do
with
the
endpoint
to
retrieve
last
order
information
and
then
adding
store
name
to
the
store,
config
data.
So
that's
our
that's
our
agenda
for
the
day
and
I'll
kick
us
off
with
a
little
bit
about
how
we,
how
we
think
about
our
tasks
and
work,
that's
outstanding
in
the
graphic
you'll
track,
that's
post
to
three
of
these.
So
let
me
share
my
screen
here.
A
We've
got
a
column
for
investigation
here
when
somebody
takes
something
into
work.
We
move
it
into
here.
If
they
need
a
little
bit
more
time
to
either
perform
a
spike
or
do
some
sort
of
technical
investigating,
then
our
in
progress
column
that
has
23
issues.
Currently
that's
a
lot
I'm,
not
sure
that
all
of
them
have
active
development
associated
with
them,
and
we
should
probably
be
better
about
returning
some
of
these
items.
A
If
they
are
stalled
too,
you
know
to
be
up
for
grabs
again
for
other
people,
but
you
know
we'll
we'll
get
there
as
we
go
and
then
we've
got
a
review,
/qa
column.
This
is
the
stuff.
That's
been
mostly
completed,
emerging
in
progress
and
then
all
the
stuff
that's
been
closed
and
done,
and
we've
got
50
plus
issues
here.
So
when,
when
we
were
thinking
about
future
roadmap
of
graph
tol
and
where
we
wanted
to
go,
we
always
spoken
about.
A
You
know:
completing
the
checkout
and
focusing
on
the
engine
end
flow
for
a
shopper
who
can
browse
products
they
can.
They
can
explore
different
products,
get
on
the
product
detail,
page
Add
to
Cart,
and
then
you
don't
go
through
the
checkout
steps
needed
to
complete
an
order.
So
a
good
view
of
that
is
through
our
mind
map
here.
This
is
kind
of
a
top-level
visual
view
of
the
totality
of
scope
for
for
graph
QL
collapse
this
here.
A
Basically,
it
breaks
down
the
the
total
work
that
we
would
like
to
get
done
in
graph
QL
space
into
kind
of
areas,
and
we've
talked
about
these
before
you
see
performance
here,
improvements
for
framework,
a
few
items
on
security,
but
the
majority
of
the
work
that's
still
outstanding
is
still
yet
to
be
done,
is
in
coverage.
Right
and
coverage
is
broken
down
further
into
different
areas
like
product
coverage.
A
And
then
you
know
these
cart
operations.
We've
marked
certain
ones
that
have
been
previously
worked
on
as
completed
or
you
know
partially
completed,
but
this
is.
This
is
really
where
we
want
to
focus
development
of
the
future.
It
releases
so
the
first,
the
first
place
that
we
want
to
get
to
is
in
is
a
ability
for
using
graphic
ability
of
only
using
graphic
you
operations
to
complete
checkout
and
to
end
right
and
there's
certain
big
pieces
missing
in
order
for
us
to
be
able
to
do
that.
A
Obviously,
the
next
sequential
release,
post,
two-30
and
currently
the
state
is
that
we've
taken
a
pass
at
you
know
most
issues
that
are
involved
and
that
are
outstanding
still
to
be
solved
for
completion
of
check
out.
We,
we
marked
them
as
two
three
one
and
we
put
them.
You
know
a
good
way
to
view
a
report
of
those
issues
is
to
go
to
down
here
to
reports
and
well.
We
can
look
at
an
overview
and
see
what
all
kinds
of
reports
are
possible.
A
It's
you
know
several
different
ones.
What
we've?
What
we've
been
considering
recently
is
the
ability
to
do
burn
down
charts
and
what's
what
was
missing
for
us
to
be
able
to
do
burn
down
is
really
estimates
in.
In
level
of
effort
scoring
for
these
stories,
for
those
of
you
who
are
familiar
with
our
board,
you
guys
know
that
we've
always
marked
issues
as
small,
medium
or
large.
A
Again,
we've
talked
about
these
labels
a
lot,
but
now
what
you'll
you'll
start
seeing
is
these
estimates
and
what
we
call
story,
points
very
standard
practice
and
agile
software
development?
We
try
to
mark
them.
Basically,
it's
not
a
reflection
of
how
long
it
will
take
it's
a
it's,
a
reflection
of
relative
size
or
complexity
in
relation
to
all
other
stories
that
we
have
on
the
board.
A
So
we've
had
one
date
went
through
and
scored
a
bunch
of
these
that
we're
again
particularly
interested
in
4-2-3-1
release
and
marked
them
for
you
know,
given
it
gave
them
a
estimate
and
story
points
and
that's
what
these
round
numbers
are
and
now
with
that.
What
that
allows
us
to
do
is
kind
of
forecast
the
work
based
on
you
know:
relative
dates,
we
don't
know.
A
No
one
has
exact
exact
dates,
yet
four
releases,
but
we
just
know
that,
assuming
we
have
a
few
weeks
to
work
on
two
three
one
scope,
you
know
where,
where
how
much
potentially
work
can
we
take
on
hope
that
makes
sense
and
so
to
help
us
visualize
this
again
to
come
back
to
the
to
the
reports
and
go
to
some
of
these
things
that
are
available
here?
If
you
click
on
this
burn
down
report,
which
is
the
one
that
I
want
to
focus
on,
you
will
see
if
we
select
release
two
three
zero
I'm.
A
Sorry,
two
three
one
you'll
see
the
total
scope.
So
what
this
includes
is
issues
that
we
have
been
merging
into
two
three
one
for
the
last
few
months.
Actually,
since
about
mid-september
we've
started,
we've
cut
off
a
branch,
and
you
know
all
the
issues
that
we've
been
working
since
then
did
not
make
it
into
two
three
zero.
A
Obviously,
but
they
have
been
accumulated
into
this
two
three
one
release
and
then,
in
addition
to
those
issues
that
have
been
merged,
we
have
like
I've,
been
saying,
marked
a
bunch
of
other
issues
that
are
still
outstanding
to
be
solved.
For
that
we'd
like
to
attempt
to
solve
for
231,
mainly
again
shipping
shipping
stories
payment
stories,
you
know
placing
the
actual
order,
mutation
things
like
that,
besides
those
specific
stories
again
that
we
want
to
call
out
for
q3
or
release.
A
There
are
a
bunch
of
stories
in
here
that
that
are
that
I've
been
in
progress,
so
I'm,
a
little
hesitant
to
you
know,
stop
work
on
those
or
ask
our
contributors
to
stop
work
on
issues
that
they're
that
they're
currently
have
in
progress.
So
I
think
the
best
course
of
action
here
is
to
allow
people
to
kind
of
complete
the
stories
that
they
want
to
complete,
even
though
that
may
not
be
directly
relevant
to
the
scope
we
want
to
get
done
4-2-3-1.
A
If
you
keep
scrolling
down
on
this
page,
what
you'll
see
too
is
like
I
said
the
issues
that
have
been
already
completed
and
merged.
You
see,
there's
there's
a
lot
here.
I,
don't
know
it
gives
me
a
count,
but
there's
quite
a
bit
that
we've
been
able
to
close
and
emerge
in
the
in
the
past
couple
months.
This
is
the
outstanding
scope
from
from
here
again.
A
This
is
this
may
not
be
100%
accurate
and,
as
you
see
on
the
burndown
chart,
what
it
tells
us
is
given
the
dates
that
we're
currently
guessing
and
given
the
scope
that
we
currently
have
here,
we've
got
a
little
bit
more
than
technically
we
can.
We
should
be
able
to
handle
right
and
because
of
that,
within
throwing
some
of
these
issues
that
are
currently
assigned
for
this
release.
We've
been
postponing
them
or
signing
them
to
the
next
subsequent
release
that
one
being
two
three
two
and
actually
we
can.
A
Bleach
our
scope
here,
two
three:
we
I
think
we
we
don't
have
any
dates
defined
and
that's
probably
why
it
can't
really
tell
us
anything,
but
you
can
see
that
already
we're
starting
to
the
scope
is
starting
to
take
shape
here.
4
3,
mainly
it's
things
that
we
don't
consider
first
priority
that
are
outside
of
that
checkout
experience,
but
they
will
start
kind
of
accumulating
here
and,
of
course,
this
being
a
community
project,
we're
always
open
to
feedback
about
which
items
that
we
that
we
picked
and
which
items
we've
currently
assigned
to
3.
A
If
you
see
something,
that's
you
know,
for
whatever
reason
may
be
more
urgent
or
critical
for
certain
applications,
we're
obviously
open
to
that
dialogue
with
the
community.
This
is
just
it
seems
pretty
straightforward.
The
first
thing
we
want
to
do
with
graph
QL
is
to
enable
that
checkout
experience
for
shoppers
I'm
going
to
pause
here
and
just
ask
you
guys
if
there's
any
questions,
if
I
confuse
you
in
any
way
or
if
you
you
know,
if
anyone
has
any
any
other
comments
or
suggestions
about
how
we
proceed
with
with
this
work
in
our
track.
B
A
From
date,
so
now,
like
I,
said
we,
we
won't
know
the
exact
dates
for
for
a
long
time.
This
is
kind
of
an
educated
guess
for
for
when
development
will
wrap
it
up,
and
so
what
that?
What
that
means
is
you
know
past
that
point?
We
will
still
have
to
go
through
a
bunch
of
testing,
iterations
and
regression
and
basically
stabilization
period
of
time,
which
will
also
be
unknown.
A
So
we
can
only
guess
that
you
don't
past
past
some
time
in
February,
we'll
do
a
code
freeze
for
scope
and
then
we'll
do
a
period
of
stabilization
like
we
always
do,
and
then
you
know
the
release
will
be
what
will
be
viable
only
after
we
feel
good
about
the
quality
of
the
code.
Does
that
make
sense
cool?
Yes,
thank
you
for
your
answer.
Absolutely
any
any
other
questions
here
and
on
the
phone.
A
Awesome
so
the
next
action
item
support
us
here
internally
are
really
two
obviously
cut
more
scope
here.
We're
gonna
be
moving
some
of
these.
You
know
some
of
these
stories
that
are
currently
assigned
4-2-3-1.
Obviously
we
need
to
trim
this
down
more
if
we
believe
that
the
dates
are
correct,
so
more
of
these
stories
will
fall
out
into
two
three
two.
However,
you
know
if
you're
looking
for
new
new
functionality
or
new
areas
to
help
with,
obviously
the
this
checkout
flows
are
the
most
critical.
A
So
it's
a
it
should
be
a
safe
bet
that
if
you
on
something
that's
that
will
help
advancement
in
those
areas,
then
it
would
be,
it
would
be
great
for
231,
but
basically
the
main
takeaway
is
that
we've
introduced
estimates
we've
introduced
milestones
now.
It
should
be
kind
of
a
better,
more
clear
picture
of
how
we're
progressing
and
where
we're
going,
and
what
what
kind
of
progress
have
we
made
we
ahead
are
we
behind
so
hopefully,
this
kind
of
helps,
transparency
and
clarity
on
on
the
entire
project.
One.
B
A
More
reflection
of
basically
relative
size
to
other
stories.
We
we
don't,
we
don't
translate
them
directly
to
an
amount
of
time,
because
that's
no,
that's
that's
kind
of
dangerous
and
it
really
makes
me
a
picture
unclear,
but
normally
yeah.
You
you
the
way
to
think
about
it
or
just
a
relative
size
compared
to
other
stories.
So
you
know
a
story.
That's
marked,
as
a
three
should
should
be
about
three
times
as
complex
to
tackle
as
a
story.
That's
mark,
isn't
one
and
I
think
likely
with
time.
A
You
know
right
right
now:
we've
got
a
mixture
of
things.
We've
got
the
size
labels
and
we've
got
the
estimates
likely
as
time
goes
along
we're
going
to
be
getting
rid
of
the
size
labels
and
only
kind
of
reference.
The
the
size
and
story
points,
but,
but
even
even
so,
I
just
want
to
point
out
that
you
know
the
relative
complexity
has
been,
has
been
scored
by
one
person
and
potentially
you
know,
they're
not
always
gonna
be
perfect
either
so
we're
open
for
discussion.
It
was.
A
It
was
nice
that
the
same
person
went
through
and
and
marked
Alden
because
at
least
they're
consistent.
You
know,
and
from
from
one
perspective
we
we
didn't
do
we
didn't
have
very
many
people,
you
know
chime
in
and
with
with
different
opinions.
So
at
least
there
is,
you
know,
a
a
consistency
bar,
but
again
these
these
could
change,
potentially
with
more
discussion
or
with
clarification
of
acceptance,
criteria
and
use
cases
etc.
Just
like
in
a
normal
development
cycle,
yeah.
C
A
C
A
B
B
What
I've
added
is
the
name,
but
it's
not
the
store
name
of
the
model,
but
it's
the
store
name
which
is
used
in
configuration,
because
if
you
have
like
a
store
switch,
which
you
want
to
use
the
language
code,
that
is
the
one
which
is
on
the
store
model
saved.
But
if
you
want
to
show
it
like
in
the
copyright
footer,
it's
the
name
which
is
set
in
the
configuration.
B
So
if
we
take
a
look
at
is
over,
it
didn't
actually
change,
but
in
the
deeper
level
the
name
which
is
saved
here
is
the
one
based
on
the
configuration.
So
as
I
explained,
it
is
not
not
the
name
on
the
model,
so
it's
not
the
basic
store
name,
because
that
one
you
can
use
for
your
store
switch.
This
is
really
to
display
the
correct
name
in
the
copyright
in
the
footer.
If
you
are
using
PVA
studio,
the
the
other
one
is
hey.
B
B
Okay,
now
you
see
my
database.
Yes,
you
have
like
here
the
store
information
which
is
the
configuration
then,
but
you
also
have
the
store
table
in
which
you
have
the
which
is
relevant
for
if
you
have
a
store
switch,
but
that
is
like,
like
a
language
switch
and
if
you
want
to
display
beneath
the
name
of
your
company,
that
one
is
that
one
in
the
configuration.
So
it's
like
this
the
store
name
compared
to
a
store
view.
Name,
that's
actually
a
difference.
B
So
that's
like
the
global
company
name,
which
you
display
in
the
footer
normally,
so
if
you
go
back
to
PHP
store
there,
you
can
also
see
it
in
the
data
provider
on
2nd
of
things
above
this
you
can
see
it
here.
This
here
is
the
path
also
used.
This
is
the
basic
path,
so
it's
really
the
store
information
name.
Ok,
the
other
thing
I've
added
is
the
second
pool
request
which
is
I
will
show
you
why
I've
done
this
this
in
PVE
see.
B
Do
you
have
the
order
ID
when
you
place
the
order
you
get
the
actual
entity
ID
and
not
the
increment
ID.
So
what
I've
added
is
a
graphical
to
retrieve
the
order
information
of
the
last
order
of
the
current
session.
So
normally
you
have
the
lost
lost
real
order,
ID
that
one
is
going
to
be
returned
explained
here
in
the
schema.
I
used
the
normal
customer
order,
because
the
data
is
exactly
the
same,
but
there
is
a
different
resolver
for
it
open
the
resolver.
What
does
it?
It
gets.
B
D
Problem
because
our
group
kill
should
not
be
stateful
and
usually
what
happens.
You
should
pass
all
required
arguments
in
request
in
query,
so
in
this
case
it
can
be
identified
based
on
your
talking,
for
example,
but
we
should
not
take
anything
from
session,
so
you
can
potentially
say
I
know
who
you
are
based
on
your
talking
and
then
like.
We
can
identify
customer
ID
and
then
based
on
that
customer
ID.
D
We
can
try
to
find
like
this
order,
but
we
definitely
cannot
use
fashion
because
you
can
also
use
I'm
sure
like
how
you
did
authentication
here
but
Rob.
They
used
cookies,
I
assume,
but
you
can
also
use
tokens
and
in
case
of
tokens,
I
I'm,
not
sure
what
will
will
happen
cause
session
I
believe
is
not
available
at
that
case,
like
it's
not
shared
between
requests.
B
D
B
D
B
D
B
B
D
A
A
D
Yeah
sure
so
we
can,
we
can
review
it
and
we
can
see
what
options
we
can.
But
ya
know
you
can
just
see
how
we
do
let's
say
called
flow
for
gas
students.
We
never
operate
the
session.
Instead,
we
use
card
ID
like
cash,
hair,
scalp
eggy,
and
they
pass
it
around
between
request
and
there
is
no
like
state
perform
like
state
between
request.
D
So
if
you
basically
to
record
one
request
and
then
do
second
request,
second
request
doesn't
depend
on
trust
request
like
if
first
request
created
card-
and
you
get
the
startegy
you
provided
in
second
request
and
what
we
have
done
here.
Basically,
your
second
request
will
return
different
results,
like
you
send
same
request,
but
you
look
at
different
results
depending
on
like
previous
request,
and
this
is
equal,
like
state
persistence
between
different
requests,
and
this
is
what
we
definitely
cannot
do
in
it
guys.
B
D
D
A
Yeah,
so
that's
yeah,
it's
exactly
what
I
was
saying.
Sorry
I
wasn't
explaining
it
very
well.
I
was
just
kind
of
thinking
that
it
should
be
the
responsibility
of
that
future
plate
a
place
order
mutation
and,
as
you
know,
it
will
have
certain
fields
that
you
can
query
or
you
can
request
as
part
of
that
mutation
to
be
returned
to
you
and
the
think
of
an
ID
could
be
one
of
those
fields.
A
B
A
D
I'm,
sorry
so
in
rest,
I'm,
just
thinking
like
how
you
can
work
around
that
for
your
use
case
at
the
moment,
I
don't
think
you
can
do
it
in
any
way.
If
you
don't
introduce
custom
endpoint,
because
when
you
get
order
ID
as
a
guest,
you
will
not
be
able
to
get
that
all
the
information
by
ID,
because
it
is
my
simple,
like
security
issue.
A
C
So
my
implementation
is
about
an
issue:
it's
a
possibility
to
show
Adam
loadable
products
purchased
by
a
customer,
so
in
my
account
section
the
great
grid,
with
information
about
the
not
downloadable
products
and
also
on
this
shot
here
is
no
link
or
download
the
product,
but
if
you
are
able
to
download
some
information
from
purchase
order,
you'll
have
links
here
and
we're
providing
this
possibility.
I
have
introduced
a
new
endpoint
in
your
query
in
scope
of
don't
know
the
whole
graph
module
and
actually
it
to
execute
this
query.
C
It's
not
to
be
logged
in
it's
to
provide
your
token
in
headers,
and
once
you
request
this
query,
it
returns
an
array
of
type
customer,
the
model
product,
and
this
type
includes
the
exact
feels
like
we
have
here
in
this
table.
So
it's
order
increment
idea,
order
date,
status,
URL
of
the
notable
link
and
remaining
downloads,
and
unfortunately,
I
have
broken.
My
graph
girl
instance
right
before
the
demo
classics,
but
I
have
like
requests
from
my
working
instance,
and
it
looks
like
the
following
month:
o
in
result,
you
will
have
all
information
you
need.
C
A
A
I
I
was
gonna,
say
that
I
think
we
moved
in
in
the
again
in
the
spirit
of
prioritizing
the
you
know
getting
to
the
engine
and
flow
first
I
I
think
we
moved
out
the
a
bunch
of
stories
for
support
of
different
product
types
to
be
added
to
card
and
them
to
be
to
be
to
be
checked
out.
So
we
currently
have
I,
think
simple
and
configurable
and
we
basically
moved
all
the
rest
of
the
product
types
two
to
three
to
scope
in
in
favor
of
prioritizing.
A
You
know
the
the
shipping
payments
and
order
placement,
and
once
once,
we've
got
that
probably
with
basic
shipping.
That's
like
the
static
shipping
methods.
First
and
then
the
static
you
know
payment
methods
as
well,
then
we
can
start
iterating
and
actually
adding
you
know
more
complex,
live
payment
methods
and
credit
card
processing
and
live
carriers,
and
all
that.
So
that's
that's
kind
of
the
idea
to
move
forward
for
now.
A
D
We
are
argument,
and
it
also
affects
how
we
write
resolvers
and
I
just
created
before
the
demo.
A
story
or
like
might
be
like
a
small
task,
to
change
our
approach
and
what
it
means
we
will
just
take
information
from
our
from
headers
as
to
which
current
store
is,
and
we
pop
we
probably
identify
the
object
of
store,
and
then
we
put
it
to
context
which
is
part
of
resolver
interface.
So
we
are
not
going
to
request
store
manager
in
constructor
anymore,
but
instead
you
will
get
access
to
store
information.
D
We
are
construct
object.
We
should
get
as
argument
of
resolve
method
in
resolve
and
we
already
do
this
for
user
context,
so
we
have
user
context,
object
which
actually
gives
information
as
to
who
current
user
is
and
what
his
ID
is,
and
we
already
use
graph
key
resolver
context
for
storing
this
information
and
if
you
have
any
future
global
state
that
you
want
to
request
around
the
application,
we
also
need
to
follow
the
same
approach
so
in
in
case
you're.
Writing
any
new
is
over
and
you
need
access
to
store
manager.
D
You
have
to
get
it
from
context
as
soon
as
we
implement
this,
like
small
feature
on
framework
level,
that
it's
available
via
context,
because
currently
it's
not
allowable
by
context
and
brain
work
should
put
into
context
first.
But
this
just
heads
up
and
if
you
have
any
concerns
just
let
us
know
before
we
implemented
this.