docs: publish restructure (#3496)

* docs: added features and guides overview page

* added image

* added version 2

* added version 3

* added version 4

* docs: implemented new color scheme

* docs: redesigned sidebar (#3193)

* docs: redesigned navbar for restructure (#3199)

* docs: redesigned footer (#3209)

* docs: redesigned cards (#3230)

* docs: redesigned admonitions (#3231)

* docs: redesign announcement bar (#3236)

* docs: redesigned large cards (#3239)

* docs: redesigned code blocks (#3253)

* docs: redesigned search modal and page (#3264)

* docs: redesigned doc footer (#3268)

* docs: added new sidebars + refactored css and assets (#3279)

* docs: redesigned api reference sidebar

* docs: refactored css

* docs: added code tabs transition

* docs: added new sidebars

* removed unused assets

* remove unusued assets

* Fix deploy errors

* fix incorrect link

* docs: fixed code responsivity + missing icons (#3283)

* docs: changed icons (#3296)

* docs: design fixes to the sidebar (#3297)

* redesign fixes

* docs: small design fixes

* docs: several design fixes after restructure (#3299)

* docs: bordered icon fixes

* docs: desgin fixes

* fixes to code blocks and sidebar scroll

* design adjustments

* docs: restructured homepage (#3305)

* docs: restructured homepage

* design fixes

* fixed core concepts icon

* docs: added core concepts page (#3318)

* docs: restructured homepage

* design fixes

* docs: added core concepts page

* changed text of different components

* docs: added architecture link

* added missing prop for user guide

* docs: added regions overview page (#3327)

* docs: added regions overview

* moved region pages to new structure

* docs: fixed description of regions architecture page

* small changes

* small fix

* docs: added customers overview page (#3331)

* docs: added regions overview

* moved region pages to new structure

* docs: fixed description of regions architecture page

* small changes

* small fix

* docs: added customers overview page

* fix link

* resolve link issues

* docs: updated regions architecture image

* docs: second-iteration fixes (#3347)

* docs: redesigned document

* design fixes

* docs: added products overview page (#3354)

* docs: added carts overview page (#3363)

* docs: added orders overview (#3364)

* docs: added orders overview

* added links in overview

* docs: added vercel redirects

* docs: added soon badge for cards (#3389)

* docs: resolved feedback changes + organized troubleshooting pages (#3409)

* docs: resolved feedback changes

* added extra line

* docs: changed icons for restructure (#3421)

* docs: added taxes overview page (#3422)

* docs: added taxes overview page

* docs: fix sidebar label

* added link to taxes overview page

* fixed link

* docs: fixed sidebar scroll (#3429)

* docs: added discounts overview (#3432)

* docs: added discounts overview

* fixed links

* docs: added gift cards overview (#3433)

* docs: added price lists overview page (#3440)

* docs: added price lists overview page

* fixed links

* docs: added sales channels overview page (#3441)

* docs: added sales overview page

* fixed links

* docs: added users overview (#3443)

* docs: fixed sidebar border height (#3444)

* docs: fixed sidebar border height

* fixed svg markup

* docs: added possible solutions to feedback component (#3449)

* docs: added several overview pages + restructured files (#3463)

* docs: added several overview pages

* fixed links

* docs: added feature flags + PAK overview pages (#3464)

* docs: added feature flags + PAK overview pages

* fixed links

* fix link

* fix link

* fixed links colors

* docs: added strategies overview page (#3468)

* docs: automated upgrade guide (#3470)

* docs: automated upgrade guide

* fixed vercel redirect

* docs: restructured files in docs codebase (#3475)

* docs: restructured files

* docs: fixed eslint exception

* docs: finished restructure loose-ends (#3493)

* fixed uses of backend

* docs: finished loose ends

* eslint fixes

* fixed links

* merged master

* added update instructions for v1.7.12
This commit is contained in:
Shahed Nasser
2023-03-16 17:03:10 +02:00
committed by GitHub
parent f312ce1e0f
commit 1decaa27c7
415 changed files with 12422 additions and 5098 deletions

View File

@@ -0,0 +1,477 @@
---
description: 'Learn how to implement order-edit related features in the storefront using REST APIs. This includes showing the customer order-edit requests, authorizing additional payments, and confirming or declining order edits.'
addHowToData: true
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
# How to Handle an Order Edit in Storefront
In this document, youll learn how to allow a customer to confirm or decline an Order Edit.
---
## Overview
A merchant can request to edit an order to make changes to its items. The change can include removing an item, adding a new item, and changing the quantity of an item in the original order.
When the Order Edit is in the “request” state, it requires either a confirmation from the customer, or it can be force-confirmed by the merchant.
This guide focuses on how to use the Storefront APIs to implement the flow that allows a customer to either confirm or decline an Order Edit.
:::note
You can check out how to implement order editing using the Admin APIs in [this documentation](../admin/edit-order.mdx).
:::
### Scenarios
You want to implement the following functionalities in your storefront:
- List and show customers order-edit requests.
- Confirm order edits and authorize any additional payment if necessary.
- Decline order edits.
:::note
You can perform other functionalities related to order editing. To learn more, check out the API reference.
:::
---
## Prerequisites
### Medusa Components
It's assumed that you already have a Medusa backend installed and set up. If not, you can follow our [quickstart guide](../../../development/backend/install.mdx) to get started.
It is also assumed you already have a storefront set up. It can be a custom storefront or one of Medusas storefronts. If you dont have a storefront set up, you can install either the [Next.js](../../../starters/nextjs-medusa-starter.mdx) or [Gatsby](../../../starters/gatsby-medusa-starter.mdx) storefronts.
### JS Client
This guide includes code snippets to send requests to your Medusa backend using Medusas JS Client and JavaScripts Fetch API.
If you follow the JS Client code blocks, its assumed you already have [Medusas JS Client installed](../../../js-client/overview.md) and have [created an instance of the client](../../../js-client/overview.md#configuration).
### Medusa React
This guide also includes code snippets to send requests to your Medusa backend using Medusa React, among other methods.
If you follow the Medusa React code blocks, it's assumed you already have [Medusa React installed](../../../medusa-react/overview.md) and have [used MedusaProvider higher in your component tree](../../../medusa-react/overview.md#usage).
### Previous Steps
You must have an existing order edit in the “request” state.
---
## Retrieve an Order Edit
You can retrieve a single order edit by its ID by sending a request to the [Get Order Edit](/api/store/#tag/OrderEdit/operation/GetOrderEditsOrderEdit) endpoint:
<Tabs groupId="request-type" wrapperClassName="code-tabs">
<TabItem value="client" label="Medusa JS Client" default>
```ts
medusa.orderEdits.retrieve(orderEditId)
.then(({ order_edit }) => {
console.log(order_edit.changes)
// show changed items to the customer
})
```
</TabItem>
<TabItem value="medusa-react" label="Medusa React">
```ts
import { useOrderEdit } from "medusa-react"
const OrderEdit = () => {
const { order_edit, isLoading } = useOrderEdit(orderEditId)
// ...
}
export default OrderEdit
```
</TabItem>
<TabItem value="fetch" label="Fetch API">
```ts
fetch(`<BACKEND_URL>/store/order-edits/${orderEditId}`)
.then((response) => response.json())
.then(({ order_edit }) => {
console.log(order_edit.changes)
// show changed items to the customer
})
```
</TabItem>
</Tabs>
The request requires the order edits ID as a path parameter.
It returns the Order Edit as an object. Some of its important fields are:
- `order_id`: The ID of the order that this Order Edit belongs to.
- `difference_due`: The amount to either be refunded or paid. If the amount is greater than 0, then the customer is required to pay an additional amount. If the amount is less than 0, then the merchant has to refund the difference to the customer.
- `payment_collection_id`: The ID of the payment collection. This will be used to authorize additional payment if necessary.
:::note
You can learn more about what fields to expect in the [API reference](/api/store/#tag/OrderEdit/operation/GetOrderEditsOrderEdit).
:::
### Show Changed Items
All data about changes to the original orders items can be found in `order_edit.changes`. `changes` is an array of item changes. Each item change includes the following fields:
<!-- eslint-skip -->
```ts
{
type: string,
line_item: LineItem | null,
original_line_item: LineItem | null
}
```
`type` can be either:
- `item_add`: In this case, a new item is being added. `line_item` will be an item object and `original_line_item` will be `null`.
- `item_update`: In this case, an items quantity in the original order is updated. `line_item` will be the updated item, and `original_line_item` will be the item in the original order. You can either just use `line_item` to show the new quantity, or show the customer a comparison between the old and new quantity using `original_line_item` as well.
- `item_remove`: In this case, an item in the original order is removed. The `original_line_item` will be the item in the original order, and `line_item` will be `null`.
Heres an example of how you can use this data to show the customer the requested edits to the order:
```tsx
<ul>
{orderEdit.changes.map((itemChange) => (
<li key={itemChange.id}>
<strong>
{
itemChange.line_item ?
itemChange.line_item.title :
itemChange.original_line_item.title
}
</strong>
{itemChange.type === "added" && <span>New Item</span>}
{itemChange.type === "removed" && (
<span>Removed Item</span>
)}
{itemChange.type === "edited" &&
<span>
Edited Item
Old Quantity: {itemChange.original_line_item.quantity}
New Quantity: {itemChange.line_item.quantity}
</span>}
</li>
))}
</ul>
```
---
## Handle Payment
After viewing the changes in the order edit, the customer can choose to confirm or decline the order edit.
In case the customer wants to confirm the order edit, you must check whether a refund or an additional payment is required. You can check that by checking the value of `difference_due`.
### Refund Amount
If `difference_due` is less than 0, then the amount will be refunded to the customer by the merchant from the Medusa admin. No additional actions are required here before [completing the order edit](#complete-the-order-edit).
### Make Additional Payments
:::note
💡 This section explains how to authorize the payment using one payment provider and payment session. However, payment collections allow customers to pay in installments or with more than one provider. You can learn more about how to do that using the [batch endpoints of the Payment APIs](/api/store/#tag/Payment/operation/PostPaymentCollectionsSessionsBatchAuthorize)
:::
If `difference_due` is greater than 0, then additional payment from the customer is required. In this case, you must implement these steps to allow the customer to authorize the payment:
1. Show the customer the available payment providers. These can be retrieved from the details of [the region of the order](/api/store/#tag/Region/operation/GetRegionsRegion).
2. When the customer selects the payment provider, initialize the payment session of that provider in the payment collection. You can do that by sending a request to the [Manage Payment Sessions](/api/store/#tag/Payment/operation/PostPaymentCollectionsSessions) endpoint, passing it the payment collections ID as a path parameter, and the payment providers ID as a request body parameter:
<Tabs groupId="request-type" wrapperClassName="code-tabs">
<TabItem value="client" label="Medusa JS Client" default>
<!-- eslint-disable max-len -->
```ts
medusa.paymentCollections.managePaymentSession(paymentCollectionId, {
provider_id,
})
.then(({ payment_collection }) => {
console.log(payment_collection.payment_sessions)
})
```
</TabItem>
<TabItem value="medusa-react" label="Medusa React">
```ts
import { useManagePaymentSession } from "medusa-react"
const OrderEditPayment = () => {
const managePaymentSession = useManagePaymentSession(
paymentCollectionId
)
// ...
const handleAdditionalPayment = (provider_id: string) => {
managePaymentSession.mutate({
provider_id,
})
}
// ...
}
export default OrderEditPayment
```
</TabItem>
<TabItem value="fetch" label="Fetch API">
<!-- eslint-disable max-len -->
```ts
fetch(
`<BACKEND_URL>/store/payment-collections/${paymentCollectionId}/sessions`,
{
method: "POST",
credentials: "include",
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({
provider_id,
}),
}
)
.then((response) => response.json())
.then(({ payment_collection }) => {
console.log(payment_collection.payment_sessions)
})
```
</TabItem>
</Tabs>
1. Show the customer the payment details form based on the payment sessions provider. For example, if the provider ID of a payment session is `stripe`, you must show Stripes card component to enter the customers card details.
2. Authorize the payment using the payment provider. The [Authorize Payment Session](/api/store/#tag/Payment/operation/PostPaymentCollectionsSessionsSessionAuthorize) endpoint accepts the payment collections ID and the ID of the payment session as path parameters:
<Tabs groupId="request-type" wrapperClassName="code-tabs">
<TabItem value="client" label="Medusa JS Client" default>
```ts
medusa
.paymentCollection
.authorizePaymentSession(
paymentCollectionId,
paymentSessionId
)
.then(({ payment_session }) => {
console.log(payment_session.id)
})
```
</TabItem>
<TabItem value="medusa-react" label="Medusa React">
```ts
import { useAuthorizePaymentSession } from "medusa-react"
const OrderEditPayment = () => {
const authorizePaymentSession = useAuthorizePaymentSession(
paymentCollectionId
)
// ...
const handleAuthorizePayment = (paymentSessionId: string) => {
authorizePaymentSession.mutate(paymentSessionId)
}
// ...
}
export default OrderEditPayment
```
</TabItem>
<TabItem value="fetch" label="Fetch API">
<!-- eslint-disable max-len -->
```ts
fetch(
`<BACKEND_URL>/store/payment-collection/${paymentCollectionId}` +
`/sessions/${paymentSessionId}/authorize`,
{
method: "POST",
credentials: "include",
}
)
.then((response) => response.json())
.then(({ payment_session }) => {
console.log(payment_session.id)
})
```
</TabItem>
</Tabs>
After performing the above steps, you can [complete the Order Edit](#complete-the-order-edit).
---
## Complete the Order Edit
To confirm and complete the order edit, send a request to the [Complete Order Edit](/api/store/#tag/OrderEdit/operation/PostOrderEditsOrderEditComplete) endpoint:
<Tabs groupId="request-type" wrapperClassName="code-tabs">
<TabItem value="client" label="Medusa JS Client" default>
```ts
medusa.orderEdits.complete(orderEditId)
.then(({ order_edit }) => {
console.log(order_edit.confirmed_at)
})
```
</TabItem>
<TabItem value="medusa-react" label="Medusa React">
```ts
import { useCompleteOrderEdit } from "medusa-react"
const OrderEdit = () => {
const completeOrderEdit = useCompleteOrderEdit(orderEditId)
// ...
const handleCompleteOrderEdit = () => {
completeOrderEdit.mutate()
}
// ...
}
export default OrderEdit
```
</TabItem>
<TabItem value="fetch" label="Fetch API">
<!-- eslint-disable max-len -->
```ts
fetch(`<BACKEND_URL>/store/order-edits/${orderEditId}/complete`, {
method: "POST",
credentials: "include",
})
.then((response) => response.json())
.then(({ order_edit }) => {
console.log(order_edit.confirmed_at)
})
```
</TabItem>
</Tabs>
This request accepts the order edits ID as a path parameter.
It returns the full Order Edit object. You can find properties related to the order confirmation, such as `order_edit.confirmed_at`.
After completing the order edit, the changes proposed in the Order Edit are reflected in the original order.
:::info
If the payment isnt authorized first, the order edit completion will fail.
:::
---
## Decline an Order Edit
If the customer wants to decline the Order Edit, you can do that by sending a request to the Decline Order Edit endpoint:
<Tabs groupId="request-type" wrapperClassName="code-tabs">
<TabItem value="client" label="Medusa JS Client" default>
```ts
medusa.orderEdits.decline(orderEditId, {
decline_reason: "I am not satisfied",
})
.then(({ order_edit }) => {
console.log(order_edit.declined_at)
})
```
</TabItem>
<TabItem value="medusa-react" label="Medusa React">
```ts
import { useDeclineOrderEdit } from "medusa-react"
const OrderEdit = () => {
const declineOrderEdit = useDeclineOrderEdit(orderEditId)
// ...
const handleDeclineOrderEdit = () => {
declineOrderEdit.mutate({
declined_reason: "I am not satisfied",
})
}
// ...
}
export default OrderEdit
```
</TabItem>
<TabItem value="fetch" label="Fetch API">
```ts
fetch(
`<BACKEND_URL>/store/order-edits/${orderEditId}/decline`,
{
method: "POST",
credentials: "include",
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({
decline_reason: "I am not satisfied",
}),
}
)
.then((response) => response.json())
.then(({ order_edit }) => {
console.log(order_edit.declined_at)
})
```
</TabItem>
</Tabs>
The request requires passing the order edits ID as a path parameter.
In the request body parameters, you can optionally pass the `decline_reason` parameter. Its a string that indicates to the merchant the reason the customer declined the order edit.
If the Order Edit is declined, the changes requested in the Order Edit aren't reflected on the original order and no refund or additional payments are required.
---
## See Also
- [Edit an order using Admin APIs](../admin/edit-order.mdx)

View File

@@ -0,0 +1,210 @@
---
description: 'Learn how to implement the order-claim flow in the storefront. This includes allowing customers to claim their orders, and verify a claim to an order.'
addHowToData: true
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
# How to Implement Claim Order Flow in Storefront
In this document, youll learn how to implement the claim order flow in a storefront to allow customers to claim their orders.
:::note
This flow was added starting from Medusa v1.7. You can learn more about upgrading in the [upgrade guide](../../../upgrade-guides/medusa-core/1-7-0.md).
:::
## Flow Overview
When a guest customer places an order, their order is not associated with any customer. The order is only associated with an email that the guest customer provides during checkout.
This email must be an email that isnt used with an existing account. It can, however, be used to create another order as a guest customer.
After this customer registers with a different email and logs in, they can claim their order by providing the orders ID. An email will then be sent to the email address associated with the order.
The email should contain a link to a page in the storefront, and the link should have a token as a parameter. This token will be used for verification.
The customer must then click the link in the email they received. If the token is valid, the order will be associated with the customer.
![Claim Order Flow](https://res.cloudinary.com/dza7lstvk/image/upload/v1677782439/Medusa%20Docs/Diagrams/claim-order-workflow_m6oybo.jpg)
### What Youll Learn
In this document, youll learn how to implement two parts of this flow:
1. Allow customers to claim their orders.
2. Verify a claim to an order.
---
## Prerequisites
### Medusa Components
It's assumed that you already have a Medusa backend installed and set up. If not, you can follow the [quickstart guide](../../../development/backend/install.mdx) to get started.
It is also assumed you already have a storefront set up. It can be a custom storefront or one of Medusas storefronts. If you dont have a storefront set up, you can install either the [Next.js](../../../starters/nextjs-medusa-starter.mdx) or [Gatsby](../../../starters/gatsby-medusa-starter.mdx) storefronts.
### JS Client
This guide includes code snippets to send requests to your Medusa backend using Medusas JS Client, among other methods.
If you follow the JS Client code blocks, its assumed you already have [Medusas JS Client installed](../../../js-client/overview.md) and have [created an instance of the client](../../../js-client/overview.md#configuration).
### Medusa React
This guide also includes code snippets to send requests to your Medusa backend using Medusa React, among other methods.
If you follow the Medusa React code blocks, it's assumed you already have [Medusa React installed](../../../medusa-react/overview.md) and have [used MedusaProvider higher in your component tree](../../../medusa-react/overview.md#usage).
### Handle Order Claim Request Event
When the customer requests to claim the order, an event will be triggered. You should subscribe to this event to send a confirmation email to the customer when the event is triggered.
You can learn how to implement this flow in [this documentation](../backend/handle-order-claim-event.md).
### Previous Steps
It is assumed you already have an order placed by a guest customer. You can refer to the [Cart](../../carts-and-checkout/storefront/implement-cart) and [Checkout](../../carts-and-checkout/storefront/implement-checkout-flow.mdx) implementation documentation to learn how to implement them in your storefront.
In addition, it is assumed you already have a logged-in customer before performing the steps in this document. You can refer to the [API reference](/api/store/#tag/Auth/operation/PostAuth) for more details on that.
---
## Request to Claim an Order
When the customer wants to claim an order, they must supply its ID.
To allow the customer to claim an order, send a request to the Claim an Order endpoint:
<Tabs groupId="request-type" wrapperClassName="code-tabs">
<TabItem value="client" label="Medusa JS Client" default>
```ts
medusa.orders.claimOrders({
order_ids: [
order_id,
],
})
.then(() => {
// successful
})
.catch(() => {
// an error occurred
})
```
</TabItem>
<TabItem value="fetch" label="Fetch API">
```ts
fetch(`<BACKEND_URL>/store/orders/batch/customer/token`, {
method: "POST",
credentials: "include",
body: JSON.stringify({
order_ids: [
order_id,
],
}),
headers: {
"Content-Type": "application/json",
},
})
.then(() => {
// successful
})
.catch(() => {
// display an error to the customer
})
```
</TabItem>
</Tabs>
This request accepts as a body parameter the array `order_ids`. Each item in the array is the ID of an order that the customer wants to claim. You can pass more than one ID.
If the customers request has been processed successfully, the request returns a response with a `200` status code.
The customer at this point will receive an email with a link to verify their claim on the order.
---
## Manually Verify a Claim to an Order
The link in the email that the customer receives should be a page in your storefront that accepts a `token` query parameter.
Then, you send a request to the Verify Claim Order endpoint:
<Tabs groupId="request-type" wrapperClassName="code-tabs">
<TabItem value="client" label="Medusa JS Client" default>
```ts
medusa.orders.confirmRequest({
token,
})
.then(() => {
// successful
})
.catch(() => {
// an error occurred
})
```
</TabItem>
<TabItem value="medusa-react" label="Medusa React">
```tsx
import { useGrantOrderAccess } from "medusa-react"
const ClaimOrder = () => {
const grantOrderAccess = useGrantOrderAccess()
// ...
const handleVerifyOrderClaim = (token: string) => {
grantOrderAccess.mutate(({
token,
}))
}
// ...
}
export default ClaimOrder
```
</TabItem>
<TabItem value="fetch" label="Fetch API">
```ts
fetch(`<BACKEND_URL>/store/orders/customer/confirm`, {
method: "POST",
credentials: "include",
body: JSON.stringify({
token,
}),
headers: {
"Content-Type": "application/json",
},
})
.then(() => {
// successful
})
.catch(() => {
// display an error to the customer
})
```
</TabItem>
</Tabs>
This request accepts as a body parameter the string `token`. This would be the token passed as a parameter to your storefront page through the link in the email.
If the verification is successful, the order will now be associated with the customer and the customer will be able to see it among their orders.
---
## See Also
- [Send a confirmation email to claim an order](../backend/handle-order-claim-event.md)