Resolves CC-616
**Note**
- I have added some missing fields to a couple of types, to resolve TS errors in the dashboard.
- For the ApiKey types I have left the created_at, updated_at, etc. as type Date, as changing them to string, caused @medusajs/medusa to fail building. We need to clean up the types at a later time.
Remove the following exchange methods (and hooks from dashboard) which point to routes that don't exist:
- `delete`
- `addItems`
- `updateItem`
- `removeItem`
**What**
- Fix product category repository missing context passed to down level methods
- Ensure the base repository when getting the active manager returns a fresh one if possible instead of the global one in order to prevent shared entity map by mistake
* chore: Update modules providers configuration with 'identifier' and 'PROVIDER'
* update check
* fix tests
* type
* normalize auth provider
* emailpass
* providers
---------
Co-authored-by: Carlos R. L. Rodrigues <rodrigolr@gmail.com>
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
What:
* removes resouces type "shared" or "isolated" from internal modules.
* modules can have an isolated database connection by providing a database config as part of their options on `medusa-config`
CLOSES: FRMW-2593
**Breaking changes**
The `outDir` has been deprecated and wont be used anymore, instead all the path are computed internally following these rules
- if admin is not `disabled` and the `build` command is run without the `--admin-only` flag, then the admin output dir will be `.medusa/server/public/admin` and it will be served from that same location from the medusa instance.
- if admin is not `disabled` and the `build` command is run with the `--admin-only` flag, then the admin output dir will be `.medusa/admin` with the purpose of deploying the admin separately. ⚠️ (expect to receive a warning log)
- if the admin is `disabled` and the `build` command is run with the `--admin-only` flag, then fallback to rule number 2
| admin enabled | medusa build --admin-only | output dir |
|---|---|---|
| true | true | `.medusa/admin` ⚠️ (expect to receive a warning log) |
| true | false | `.medusa/server/public/admin` |
| false | true | `.medusa/admin` |
| false | false | none |
```diff
// medusa-config.ts
{
// ...
admin: {
- outDir: 'some/path'
}
}
```
cc @kasperkristensen @sradevski @olivermrbl
**What**
When resolving the modules through an array, if the module does not have a joiner config to rely on (not `queryable`, not using the `Module` util), then the key should be provided to register the module in the container. Eventually, the module author should provide that key to be used.
The only exception is for the medusa modules where we have a map that allows us to resolve that key automatically from the path of the resolve value
* chore: add compare_at_unit_price when price list price is retrieved
* chore: add test for update item + more fixes along the way
* chore: fix tests
* chore: add refresh spec
* Apply suggestions from code review
Co-authored-by: Adrien de Peretti <adrien.deperetti@gmail.com>
* chore: use undefined checker
* chore: switch to map
---------
Co-authored-by: Adrien de Peretti <adrien.deperetti@gmail.com>
**What**
- validate that variants are unique with respect to options on product update/create and variant update/create
- validate that the product has options upon creation
- ensure variants have the same number of option values as the product has options
- admin error handling
- update tests
---
FIXES FRMW-2707 CC-556
**What**
- remove cascade delete of inventory items on product delete
- implement inventory deletion in product/variant delete workflows with checks:
- product/variant cannot be deleted if there are reservations associated with their inventory items
- inventory item will be cascade deleted if it's not used by other variants (that are not being deleted in the current flow)
---
FIXES CC-581 CC-582
**What**
The module service name case has changed and the hash generation was performed on the non lower cased version of it while after the hash generation everything is based on the lower case version of the generated table name form the service names leading to different hash computation. This pr update the link migration table to adjust the to/from module value with its new value as well as generating the hash from the lower case version of the computed table name
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
Fixes: FRMW-2743
This PR extracts and removes the `additional_data` from the workflow input before calling the steps and hence the `additional_data` is not passed down to the service layer.
However, this bug has made me discover one inconsistency in the input structure of certain workflows.
✅ **Following is the input structure of the `updateProductsWorkflow`**. Here, we accept the `products` and the `additional_data` as two separate top-level properties.
```ts
// Shape
export type UpdateProductsWorkflowInputSelector = {
selector: ProductTypes.FilterableProductProps
update: Omit<ProductTypes.UpdateProductDTO, "variants"> & {
sales_channels?: { id: string }[]
variants?: UpdateProductVariantWorkflowInputDTO[]
}
} & AdditionalData
// Calling the workflow
const { result } = await updateProductsWorkflow(req.scope).run({
input: {
selector: { id: req.params.id },
update,
additional_data,
},
})
```
❌ **Following in the input structure of the `updateCartWorflow`**. In this case, we are accepting the cart properties at the top-level, hence the `additional_data` is merged within those properties, increasing the chance of passing it down to the service layer by mistake.
```ts
// Shape
WorkflowData<UpdateCartWorkflowInputDTO & AdditionalData>
// Calling the workflow
await workflow.run({
input: {
...req.validatedBody // Additional data is part of the validatedBody,
id: req.params.id,
},
})
```
Ideally, the input of `updateCartWorkflow` should look as follows.
```ts
WorkflowData<{ cart: UpdateCartWorkflowInputDTO } & AdditionalData>
```
**What**
- Adds the ability to do global searches from cmd + k in the admin.
- The solution is temporary, until we have a proper search API.
**Note**
I have deviated a bit from the design, due to the constraints of this temporary solution:
- We don't have nested items, such as showing variants under a product (don't think having a proper search API will make this any easier, and not entirely sure how we would handle this for cases where a query returns multiple products, which is the only case that is designed)
- I have added a "Load {{count}} more" button instead of doing infinite scrolling, I am assuming the later is the intended behaviour based on the design file, but with 20+ sources of data changing so often it was resulting in some weird behaviours, so settled for the simpler approach for this temporary solution.
- Removed the "Details" label on search results as it seemed a bit repetitive
- I haven't added icons for the different types of search results, as there are only a couple of examples in the design doc, and I wasn't sure what to pick for all the different types of results. If we want to add icons, then I think it's something we can add when we revisit this later, but think its fine to omit, as each group of results is labeled, so they are easy to tell apart.
Resolves CC-574
