Expose query for a partner's orders about metaphysics HOT 13 CLOSED

CMS going WHITE? !!!

from metaphysics.

Thank you @jonallured ! This is great.

I have a few initial comments:

• Let's sync up with @mzikherman re: current best-practices for pagination, since this seems very related to the current work being done on the artist page
• what is inventory_id of an artwork?
• what do we mean by updated_at on an order? Is that the time we want to show there? I would have expected that to be created_at or a more controlled timestamp. I worry that updated_at might become confusing due to side effects of admins messing with orders or users/partners changing irrelevant fields.
• we have some standards for rendering money in metaphysics, so the query may want to take the form:

total {
  amount
  display
}

(may only need display in this case)

from metaphysics.

Thanks for opening this 🙌 This is how I have Stress setup for orders query, we are using GraphQL Connection which provides pagination options on both orders and line items embedded in an order:

orders(partnerId:<optional partner id>, userId: <optional user id>, state: <optional filtering by state>){
  edges{
      node{
        id
        state
        code
        itemTotalCents
        shippingTotalCents
        taxTotalCents
        commissionFeeCents
        user{
           id
           name
        },
        partner{
          id
          name
        },
        currencyCode
        createdAt
        lineItems{
          edges{
            node{
              artwork{
                 id
                 title
                 artists{
                   edges{
                      node{
                         name
                      }
                   }
                 }
              }
              priceCent
            }
          }
        }
      }
    }
  }

Few validations regarding query above:

• we need at least one of partnerId or userId
• when userId is passed we make sure it matches the user id of JWT
• when partnerId is passed we make sure it matches list of partner ids in JWT

In your example, what is type: "open"? is that same as state?

from metaphysics.

in terms of price related fields, i know MP has its own way of exposing those, so it may be little different in real life, need to look into that

from metaphysics.

There was some discussion about the topic of states and timestamps on Slack here:

https://artsy.slack.com/archives/CB110C6LE/p1529421574000589

@sweir27 made a good point that from Volt's point of view, all we care about is knowing the current state of the order and the timestamp that corresponds to that state. That, along with a few other things I've learned, revises my ideal query to this:

{
  orders(partner_id: "abc123") {
    id
    state
    state_updated_at
    expires_at
    total
    line_items {
      id
      artwork {
        id
        inventory_id
        artists {
          id
          name
        }
      }
    }
  }
}

What Volt is interested in is knowing the state of the order and then the timestamp that goes with that transition. Since the UI has the orders grouped by state, we're always sorting by the same type of timestamp, so this is about as simple as I can think of.

As an aside, I'm interested in the idea of storing only timestamps in stress, rather than a state column. What's nice about only storing timestamps is that you can compute the current state and thus an entire class of out-of-sync data problems are impossible. At the end of the day, however, both Volt and MP shouldn't care about how this work is done.

Note, I've also added expires_at, which would start as order.submitted_at + 2.days, but there's talk of allowing Admins to mutate this date, so I'd like to see the server send it down to the client and then I can compare with current time to compute the time remaining.

You'll also notice that I've taken type off. That was meant to be state, but I'd rather get all orders for a partner and then group/count/filter them myself.

@sweir27 Inventory ID is a string on Artwork:

gravity:staging> artwork = Artwork.find('5b27d82cf6d9f3155a0fc355')
=> #<Artwork _id: 5b27d82cf6d9f3155a0fc355, ...>
gravity:staging> artwork.inventory_id
=> "omglol"

It might be new-ish, idk. It's something that many partners fill out for works that we'd like them to be enrolling in copilot, so it seemed worth adding to this page. It's typically an internal id for the gallery.

@ashkan18 yep, you're right that MP seems to report dollars a little more complicated than what i've done here. Happy to follow that precedent or not - whatever you think is best.

from metaphysics.

as for state and timestamp, we actually had some discussion around it in https://github.com/artsy/stress/pull/6#discussion-diff-194090972R10 and we should be able to just use update_at as the last time the order state was changed.
As for expired orders, I think we need to handle it on server side since it can expire for different reasons right?

• an order can expire if it never gets submitted by collector (we called it abandoned)
• an order can expire if it never gets approved by partner
  these may end up being different states but still we need to handle them server side.

As for the schema, i think we still need to do connection (edge, node) and have all different totals so something like

orders(partnerId:<optional partner id>, userId: <optional user id>, state: <optional filtering by state>){
  edges{
      node{
        id
        state
        code
        itemTotalCents
        shippingTotalCents
        taxTotalCents
        commissionFeeCents
        currencyCode
        createdAt
        updatedAt
        user{
           id
           name
        },
        partner{
          id
          name
        },
        lineItems{
          edges{
            node{
              priceCent
              artwork{
                 id
                 title
                 artists{
                   edges{
                      node{
                         name
                      }
                   }
                 }
              }
            }
          }
        }
      }
    }
  }

As for state param, that one is optional, so if you don't pass it we wont filter things by it.

from metaphysics.

Oh interesting, hadn't heard of inventory_id (is that what the Artwork ID column is in the comp? I assumed it was the one we store but I guess that doesn't really mean much to partners 😅).

I think we should agree/follow our precedent for amounts! Makes it easy to go cross-concern. If we have questions about approach, best to bring up in #graphql or #front-end.

Agree that expired_at should be set on the server (sort of has to be assuming that it will enact state transitions and such).

Re: sorting/filtering/ordering, we don't know how many orders a partner will have but given that it's planning to grow we may want to have separate queries for each tab so that we can easily paginate through each one. You can actually alias fields in a query, so we could maintain our understanding of each field in MP and also make for a nice UI:

...
  orders(state: "submitted") {
    relevantTimestamp: submitted_at
  }
...

now Volt can use relevantTimestamp for each subset of orders in its UI, but that effectively resolves to the submitted_at timestamp.

Just a note that we can be fairly flexible, and it might be nice to see this explicitly on Volt's side. (but this is minor, there are many ways to achieve the same thing 😄).

from metaphysics.

I'd assume so, likely these:

from metaphysics.

After talking to @orta, i think it makes sense to namespace our models here for safer future :)
I'd suggest call orders ecommerce_orders so basically

ecommerce_orders(partnerId:<optional partner id>, userId: <optional user id>, state: <optional filtering by state>){
  edges{
      node{
        id
        state
        code
        itemTotalCents
        shippingTotalCents
        taxTotalCents
        commissionFeeCents
        currencyCode
        createdAt
        updatedAt
        user{
           id
           name
        },
        partner{
          id
          name
        },
        lineItems{
          edges{
            node{
              priceCent
              artwork{
                 id
                 title
                 artists{
                   edges{
                      node{
                         name
                      }
                   }
                 }
              }
            }
          }
        }
      }
    }
  }

from metaphysics.

Here is what i have working from MPs perspective in #1120

{
  orders(userId: "55b2354e72616970c3000023"){
    edges{
      node{
        id
        code
        state
        currencyCode
        partner{
          name
        }
        lineItems{
          edges{
            node{
              priceCents
              artwork{
                title
                artists{
                  name
                }
              }
            }
          }
        }
      }
    }
  }
}

from metaphysics.

This is the latest query example defined and working in #1120

{
  orders(userId: "55b2354e72616970c3000023", state: "PENDING"){
    edges{
      node{
        id
        code
        state
        currencyCode
        taxTotalCents
        shippingTotalCents
        itemTotalCents
        commissionFeeCents
        transactionFeeCents
        user{
          name
        }
        partner{
          name
        }
        updatedAt
        createdAt
        lineItems{
          edges{
            node{
              id
              price(symbol: "$")
              quantity
              updatedAt
              createdAt
              editionSet{
                id
              }
              artwork{
                title
                artist{
                  name
                }
              }
              
            }
          }
        }
      }
    }
  }
}

one thing to note here is partner, user , artwork and editionSet are mapped to Gravity's data so we'd have access to everything in those models.
Also all price related fields have option of setting symbol and few other things, i have sample here for line item price, but all other price fields are the same.

from metaphysics.

#1120

from metaphysics.

closing this 👍

from metaphysics.