Create Shop orders 🧽

[lucca65]

Is your feature request related to a problem? Please describe. Today we have products and a very basic structure called orders. Before it was called sale_history because it was really only a registration of buying something from the shop. This proposal suggests a new structure to make the order abstraction more powerful and more useful.

Describe the solution you'd like First we need to make the order have status. Orders always relate to trying to buy products from the same seller, or user. An order looks like this:

• Product ID list which contains a list of the product IDs that the buyer wants
• Quantity
• Amount
• Status status of the order. This first draft will allow only the basic ones: created, completed
• Payment a JSON or even only a transaction ID. allow us to link an order with a transfer
• Timestamps for creation/updates

Another change is that today, orders are created by listening to this contract call. We should change this to make the creation of an Order to be an GraphQL call. After the order is created we can update it with the transaction ID to link it with the payment. This process can later be expanded to include several payments, until the oder is completed.

With that we can completely remove the transfer_sale call and properly using the order abstraction.

Orders will also need to be approved by the creator of the offer/product. This is because change is to be expected and orders must be accepted

We will need the following screens:

• My orders (as a seller)
• My orders (as a buyer)
• Community orders (for admins)
• Community stats of orders
• Individual order
  • Notion of quantities for products
  • Notion of payments on its own area
  • Contact information
  • Status of the order (a way for the user to predictably know what's next -- wait for the seller, etc)

The new features users may gain

• This will allow us to create interfaces to both seller and buyer to know how their orders are.
• It will be easy to add steps related to shipping or partial payments too
• This will also allow sellers to have greater control, with dedicated shop pages to search and see their orders
• This will make the timeline possible, with our current structure we cannot achieve the result shown in the designs

Describe alternatives you've considered We could start working on the idea of expanding possible statuses. We could choose to track partial payments (useful for payments with fiat and crypto). We could add tracking capabilities to allow users to inform delivering/posting information and also add stuff like canceled or other abstractions

Additional context Add any other context or screenshots about the feature request here.

[muguika]

Love this evolution of our shop! This new "order" abstraction seems the perfect next step towards creating a more robust experience and better information for both the seller and the client buying.

Apart from what you already suggested, we may need to think on a way to give admin users a reading version of the total list of orders... so the teams behind each community can see what is happening and help users that get lost. Eventually, this general view can be available to anyone in the community, when we move to a more decentralized decision making process.

great improvement @lucca65 thanks for suggesting this new path!

[lucca65]

Entity and abstractions

Product

• name
• slug (to be used on the url)
• price
• community_id
• creator
• available_on
• discontinue_on
• categories list_of(int)
• properties (key value list to be used freely by seller and displayed on product page)
• multiple images

Orders

• id (uuid)
• creator
• community
• status (cart, address, delivery, payment, confirm, cancelled, returned, complete, paused)
• payment_status (paid, captured, confirmed)

Categories

References

• https://github.com/solidusio/solidus

Mutations

• Upsert for products

[lucca65]

It could also have slugs and slug lookup:

• Create column with unique slug
• Migrate existing to slug
• Add GraphQL query that allows us to query using slug

[lucca65]

About the Categories implementation:

• It should allow us to add an image to it
• It should be community scoped
• Default categories will have translations, but custom ones will not
• Products can belong to several different categories
• Category will have a slug name, defaulting to the name slugged
• All communities will share the same default list of categories:
  • Art and craftsmanship
  • Self-care
  • Food and drinks
  • Footwear
  • clothing and accessories
  • Courses
  • consultancies and mentoring
  • Events
  • Books and Publicantions
  • Furniture and household items
  • Household services and repairs
• ☝️The above point assumes this will be defaulted via a migration script on the database

[lucca65]

@juramos-2020 pra você dar uma olhada, que estamos começando a trabalhar nisso!

[juramos-2020]

Olá pessoal, @lucca65 @NeoVier @MatheusBuss @muguika

Com base nas informações dessa Issue, comecei a desenhar o mapa mental com as principais frentes das Orders ( vendedor, comprador, pedido e produto) para termos algo mais visual sobre o caminho que estamos traçando.

https://www.figma.com/file/7i222dvmbckzXfQsRlfoNB/Orders?node-id=0%3A1

Fiquem a vontade para contribuir ou deixar suas dúvidas. Ainda não ta nada gravado em pedra, pois ainda temos muito o que decidir.

Eu e a @rafachadud vamos começar a desenhar a jornada do usuário para termos uma visão mais clara de cada passo que ele vai dar com esse novo recurso. Quando tivermos tudo pronto vamos convidar a todos para definirmos essa jornada juntos 👌

[lucca65]

👏

[MatheusBuss]

Show @juramos-2020! :rocket:

[ethtop90]

good