docs: added docs for deleting user of actor type (#9104)
- Added to general guide on creating actor type how to delete its user later. - Added to restaurant delivery recipe how to delete a restaurant admin
This commit is contained in:
Shahed Nasser
@@ -858,11 +858,7 @@ const user = createUserStep(input.user)
|
||||
const authUserInput = transform({ input, user }, (data) => ({
|
||||
authIdentityId: data.input.auth_identity_id,
|
||||
actorType: data.input.user.actor_type,
|
||||
key:
|
||||
data.input.user.actor_type === "restaurant"
|
||||
? "restaurant_id"
|
||||
: "driver_id",
|
||||
value: user.id,
|
||||
value: data.user.id,
|
||||
}))
|
||||
|
||||
setAuthAppMetadataStep(authUserInput)
|
||||
@@ -1034,7 +1030,201 @@ This returns the created driver user.
|
||||
|
||||
---
|
||||
|
||||
## Step 8: Create Restaurant Product API Route
|
||||
## Step 8: Delete Restaurant Admin API Route
|
||||
|
||||
In this step, you'll create a workflow that deletes the restaurant admin and its association to its auth identity, then use it in an API route.
|
||||
|
||||
<Note title="Tip">
|
||||
|
||||
The same logic can be applied to delete a driver.
|
||||
|
||||
</Note>
|
||||
|
||||
### Create deleteRestaurantAdminStep
|
||||
|
||||
First, create the step that deletes the restaurant admin at `restaurant-marketplace/src/workflows/restaurant/steps/delete-restaurant-admin.ts`:
|
||||
|
||||
```ts title="restaurant-marketplace/src/workflows/restaurant/steps/delete-restaurant-admin.ts"
|
||||
import {
|
||||
createStep,
|
||||
StepResponse,
|
||||
} from "@medusajs/workflows-sdk"
|
||||
import { RESTAURANT_MODULE } from "../../../modules/restaurant"
|
||||
import { DeleteRestaurantAdminWorkflow } from "../workflows/delete-restaurant-admin"
|
||||
|
||||
export const deleteRestaurantAdminStep = createStep(
|
||||
"delete-restaurant-admin",
|
||||
async ({ id }: DeleteRestaurantAdminWorkflow, { container }) => {
|
||||
const restaurantModuleService = container.resolve(
|
||||
RESTAURANT_MODULE
|
||||
)
|
||||
|
||||
const admin = await restaurantModuleService.retrieveRestaurantAdmin(id)
|
||||
|
||||
await restaurantModuleService.deleteRestaurantAdmins(id)
|
||||
|
||||
return new StepResponse(undefined, { admin })
|
||||
},
|
||||
async ({ admin }, { container }) => {
|
||||
const restaurantModuleService = container.resolve(
|
||||
RESTAURANT_MODULE
|
||||
)
|
||||
|
||||
await restaurantModuleService.createRestaurantAdmins(admin)
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
In this step, you resolve the Restaurant Module's service and delete the admin. In the compensation function, you create the admin again.
|
||||
|
||||
### Create deleteRestaurantAdminWorkflow
|
||||
|
||||
Then, create the workflow that deletes the restaurant admin at `restaurant-marketplace/src/workflows/restaurant/workflows/delete-restaurant-admin.ts`:
|
||||
|
||||
```ts title="restaurant-marketplace/src/workflows/restaurant/workflows/delete-restaurant-admin.ts" collapsibleLines="1-13" expandButtonLabel="Show Imports"
|
||||
import { MedusaError } from "@medusajs/utils"
|
||||
import {
|
||||
WorkflowData,
|
||||
WorkflowResponse,
|
||||
createWorkflow,
|
||||
transform,
|
||||
} from "@medusajs/workflows-sdk"
|
||||
import {
|
||||
setAuthAppMetadataStep,
|
||||
useRemoteQueryStep,
|
||||
} from "@medusajs/core-flows"
|
||||
import { deleteRestaurantAdminStep } from "../steps/delete-restaurant-admin"
|
||||
|
||||
export type DeleteRestaurantAdminWorkflow = {
|
||||
id: string
|
||||
}
|
||||
|
||||
export const deleteRestaurantAdminWorkflow = createWorkflow(
|
||||
"delete-restaurant-admin",
|
||||
(
|
||||
input: WorkflowData<DeleteRestaurantAdminWorkflow>
|
||||
): WorkflowResponse<string> => {
|
||||
deleteRestaurantAdminStep(input)
|
||||
|
||||
// TODO update auth identity
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
So far, you only use the `deleteRestaurantAdminStep` in the workflow, which deletes the restaurant admin.
|
||||
|
||||
Replace the `TODO` with the following:
|
||||
|
||||
```ts title="restaurant-marketplace/src/workflows/restaurant/workflows/delete-restaurant-admin.ts"
|
||||
const authIdentities = useRemoteQueryStep({
|
||||
entry_point: "auth_identity",
|
||||
fields: ["id"],
|
||||
variables: {
|
||||
filters: {
|
||||
app_metadata: {
|
||||
restaurant_id: input.id,
|
||||
},
|
||||
},
|
||||
},
|
||||
})
|
||||
|
||||
const authIdentity = transform(
|
||||
{ authIdentities },
|
||||
({ authIdentities }) => {
|
||||
const authIdentity = authIdentities[0]
|
||||
|
||||
if (!authIdentity) {
|
||||
throw new MedusaError(
|
||||
MedusaError.Types.NOT_FOUND,
|
||||
"Auth identity not found"
|
||||
)
|
||||
}
|
||||
|
||||
return authIdentity
|
||||
}
|
||||
)
|
||||
|
||||
setAuthAppMetadataStep({
|
||||
authIdentityId: authIdentity.id,
|
||||
actorType: "restaurant",
|
||||
value: null,
|
||||
})
|
||||
|
||||
return new WorkflowResponse(input.id)
|
||||
```
|
||||
|
||||
After deleting the restaurant admin, you:
|
||||
|
||||
1. Retrieve its auth identity using Query. To do that, you filter its `app_metadata` property by checking that its `restaurant_id` property's value is the admin's ID. For drivers, you replace `restaurant_id` with `driver_id`.
|
||||
2. Check that the auth identity exists using the `transform` utility. Otherwise, throw an error.
|
||||
3. Unset the association between the auth identity and the restaurant admin using the `setAuthAppMetadataStep` imported from `@medusajs/core-flows`.
|
||||
|
||||
### Create API Route
|
||||
|
||||
Finally, add the API route that uses the workflow at `src/api/restaurants/[id]/admins/[admin_id]/route.ts`:
|
||||
|
||||
```ts title="src/api/restaurants/[id]/admins/[admin_id]/route.ts"
|
||||
import {
|
||||
AuthenticatedMedusaRequest,
|
||||
MedusaResponse,
|
||||
} from "@medusajs/medusa"
|
||||
import {
|
||||
deleteRestaurantAdminWorkflow,
|
||||
} from "../../../../../workflows/restaurant/workflows/delete-restaurant-admin"
|
||||
|
||||
export const DELETE = async (
|
||||
req: AuthenticatedMedusaRequest,
|
||||
res: MedusaResponse
|
||||
) => {
|
||||
await deleteRestaurantAdminWorkflow(req.scope).run({
|
||||
input: {
|
||||
id: req.params.admin_id,
|
||||
},
|
||||
})
|
||||
|
||||
res.json({ message: "success" })
|
||||
}
|
||||
```
|
||||
|
||||
You add a `DELETE` API route at `/restaurants/[id]/admins/[admin_id]`. In the route, you execute the workflow to delete the restaurant admin.
|
||||
|
||||
### Add Authentication Middleware
|
||||
|
||||
This API route should only be accessible by restaurant admins.
|
||||
|
||||
So, in the file `src/api/middlewares.ts`, add a new middleware:
|
||||
|
||||
```ts title="src/api/middlewares.ts"
|
||||
export default defineMiddlewares({
|
||||
routes: [
|
||||
// ...
|
||||
{
|
||||
method: ["POST", "DELETE"],
|
||||
matcher: "/restaurants/:id/**",
|
||||
middlewares: [
|
||||
authenticate(["restaurant", "user"], "bearer"),
|
||||
],
|
||||
},
|
||||
],
|
||||
})
|
||||
```
|
||||
|
||||
This allows only restaurant admins and Medusa Admin users to access routes under the `/restaurants/[id]` prefix if the request method is `POST` or `DELETE`.
|
||||
|
||||
### Test API Route
|
||||
|
||||
To test it out, create another restaurant admin user, then send a `DELETE` request to `/restaurants/[id]/admins/[admin_id]`, authenticated as the first admin user you created:
|
||||
|
||||
```bash
|
||||
curl -X DELETE 'http://localhost:9000/restaurants/01J7GHGQTCAVY5C1AH1H733Q4G/admins/01J7GJKHWXF1YDMXH09EXEDCD6' \
|
||||
-H 'Authorization: Bearer {token}'
|
||||
```
|
||||
|
||||
Make sure to replace the first ID with the restaurant's ID, and the second ID with the ID of the admin to delete.
|
||||
|
||||
---
|
||||
|
||||
## Step 9: Create Restaurant Product API Route
|
||||
|
||||
In this step, you’ll create the API route that creates a product for a restaurant.
|
||||
|
||||
@@ -1144,29 +1334,6 @@ export async function POST(req: MedusaRequest, res: MedusaResponse) {
|
||||
|
||||
The creates a `POST` API route at `/restaurants/[id]/products`. It accepts the products’ details in the request body, executes the `createRestaurantProductsWorkflow` to create the products, and returns the created products in the response.
|
||||
|
||||
### Add Authentication Middleware
|
||||
|
||||
This API route should only be accessible by restaurant admins.
|
||||
|
||||
So, in the file `src/api/middlewares.ts`, add a new middleware:
|
||||
|
||||
```ts title="src/api/middlewares.ts"
|
||||
export default defineMiddlewares({
|
||||
routes: [
|
||||
// ...
|
||||
{
|
||||
method: ["POST", "DELETE"],
|
||||
matcher: "/restaurants/:id/**",
|
||||
middlewares: [
|
||||
authenticate(["restaurant", "user"], "bearer"),
|
||||
],
|
||||
},
|
||||
],
|
||||
})
|
||||
```
|
||||
|
||||
This allows only restaurant admins and Medusa Admin users to access routes under the `/restaurants/[id]` prefix if the request method is `POST` or `DELETE`.
|
||||
|
||||
### Test it Out
|
||||
|
||||
To create a product using the above API route, send a `POST` request to `/restaurants/[id]/products`, replacing `[id]` with the restaurant’s ID:
|
||||
@@ -1209,7 +1376,7 @@ The request returns the created product in the response.
|
||||
|
||||
---
|
||||
|
||||
## Step 9: Create Order Delivery Workflow
|
||||
## Step 10: Create Order Delivery Workflow
|
||||
|
||||
In this step, you’ll create the workflow that creates a delivery. You’ll use it at a later step once a customer places their order.
|
||||
|
||||
@@ -1362,7 +1529,7 @@ In the workflow, you:
|
||||
|
||||
---
|
||||
|
||||
## Step 10: Handle Delivery Workflow
|
||||
## Step 11: Handle Delivery Workflow
|
||||
|
||||
In this step, you’ll create the workflow that handles the different stages of the delivery. This workflow needs to run in the background to update the delivery when an action occurs.
|
||||
|
||||
@@ -1898,7 +2065,7 @@ In the next steps, you’ll execute the workflow and see it in action as you add
|
||||
|
||||
---
|
||||
|
||||
## Step 11: Create Order Delivery API Route
|
||||
## Step 12: Create Order Delivery API Route
|
||||
|
||||
In this step, you’ll create the API route that executes the workflows created by the previous two steps. This API route is used when a customer places their order.
|
||||
|
||||
@@ -2074,7 +2241,7 @@ In the upcoming steps, you’ll add functionalities to update the delivery’s s
|
||||
|
||||
---
|
||||
|
||||
## Step 12: Accept Delivery API Route
|
||||
## Step 13: Accept Delivery API Route
|
||||
|
||||
In this step, you’ll create an API route that a restaurant admin uses to accept a delivery. This moves the `handleDeliveryWorkflow` execution from `notifyRestaurantStep` to the next step.
|
||||
|
||||
@@ -2526,7 +2693,7 @@ Meaning that the `handleDeliveryWorkflow`'s execution has moved to the `awaitDri
|
||||
|
||||
---
|
||||
|
||||
## Step 13: Claim Delivery API Route
|
||||
## Step 14: Claim Delivery API Route
|
||||
|
||||
In this step, you’ll add the API route that allows a driver to claim a delivery.
|
||||
|
||||
@@ -2671,7 +2838,7 @@ This indicates that the `handleDeliveryWorkflow`'s execution continued past the
|
||||
|
||||
---
|
||||
|
||||
## Step 14: Prepare API Route
|
||||
## Step 15: Prepare API Route
|
||||
|
||||
In this step, you’ll add the API route that restaurants use to indicate they’re preparing the order.
|
||||
|
||||
@@ -2761,7 +2928,7 @@ This message indicates that the `handleDeliveryWorkflow`'s execution has moved t
|
||||
|
||||
---
|
||||
|
||||
## Step 15: Ready API Route
|
||||
## Step 16: Ready API Route
|
||||
|
||||
In this step, you’ll create the API route that restaurants use to indicate that a delivery is ready for pick up.
|
||||
|
||||
@@ -2853,7 +3020,7 @@ This message indicates that the `handleDeliveryWorkflow`'s execution has moved t
|
||||
|
||||
---
|
||||
|
||||
## Step 18: Pick Up Delivery API Route
|
||||
## Step 17: Pick Up Delivery API Route
|
||||
|
||||
In this step, you’ll add the API route that the driver uses to indicate they’ve picked up the delivery.
|
||||
|
||||
@@ -2993,7 +3160,7 @@ This message indicates that the `handleDeliveryWorkflow`'s execution has moved t
|
||||
|
||||
---
|
||||
|
||||
## Step 19: Complete Delivery API Route
|
||||
## Step 18: Complete Delivery API Route
|
||||
|
||||
In this step, you’ll create the API route that the driver uses to indicate that they completed the delivery.
|
||||
|
||||
@@ -3083,7 +3250,7 @@ As the route sets the status of the `awaitDeliveryStep` to successful in the `ha
|
||||
|
||||
---
|
||||
|
||||
## Step 20: Real-Time Tracking in the Storefront
|
||||
## Step 19: Real-Time Tracking in the Storefront
|
||||
|
||||
In this step, you’ll learn how to implement real-time tracking of a delivery in a Next.js-based storefront.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user