**What**
- Adjust reservations correctly according to the following heuristic:
adjustment by addition: (i.e. positive quantity adjustment passed to the adjustment method)
- if a reservation for the line-item in the location exists add quantity to that
- if not create a new reservation
adjustment by subtraction:
- if a reservation with the exact quantity exists, delete it and return
- if a reservation with a greater quantity exists, subtract from it and return
- otherwise delete from reservations until a reservation with greater quantity than the remaining is found and adjust that with the remaining quantity OR there are no more reservations
Fixes CORE-1247
**What**
- Ensure that an inventory level exists for a sales channel (which it will since this is invoked after `confirmInventory` that will validate that stock exists in the sales channel)
Fixes CORE-1225
## What
On expanded relations, mutate type using SetRelation, an alias for SetRequired with SetNonNullable.
## Why
Simplifies implementation in client code.
## How
* Export SetRelation type util
* Update codegen template
Extra scope:
* Improve codegen error handling when processing x-expanded-relations
* Add `eager` sub-categorization to x-expanded-relations to highlight relations that are loaded using TypeORM eager.
## What
Declare and use AdminExtendedStoresRes for `[get] /admin/store` endpoint.
## Why
Only `[get] /admin/store` returns `ExtendedStoreDTO`. Other `/admin/store` endpoints return `Store`.
## How
* Create new AdminExtendedStoresRes OAS schema
* Update medusa-js
* Update medusa-react
**What**
- Remove related inventory levels and reservation items when a stock location is removed
**How**
- Add bulk deletion methods for both inventory levels and reservation items to the inventory service api
- invoke both on location removal
Fixes CORE-1232
**What**
- Toggle manage inventory in the inventory management modal
**How**
- Create/update/remove inventory item based on if `manage_inventory` is set and if an inventory item already exists
- Move all stock location updates to when the modal is submitted
- Add create-inventory-item endpoint in the core
Fixes CORE-1196
Co-authored-by: Sebastian Rindom <7554214+srindom@users.noreply.github.com>
**What**
- include location id when creating a fulfillment
- Allow location updates to reservations without passing along quantity
**Why**
- location_id on fulfillment was null after creation
Fixes CORE-1242, CORE-1243
This PR aims to tackle a few different small fixes and tweaks related to inventory and order details UI, in connection to multiwarehousing features.
- Successfully deleting an allocation should now only present one toast
- Updated copy in allocation editing toasts
- Inventory table search should now be the same height as the location selection trigger
- Inventory table rows should now correctly visually indicate that they are clickable
- Removed Filters from Inventory table for the time being
- Added actions to Inventory table rows for adjusting availability (same action as clicking the row, which remains) and going to the product detail page for the inventory item
Resolves CORE-1229, CORE-1228, CORE-1227, CORE-1233, CORE-1230
* add location_id to request_return endpoint to support "receive_now" returns
* changeset
* admin request return
* add locations to recieving returns
* cleanup test
* add check for inventory service
What:
- increase tree depth in react nestable
- scope categories on store queries
- allow categories relation in products API
RESOLVES CORE-1238
RESOLVES CORE-1237
RESOLVES CORE-1236
## What
Alter generated types base on `x-expanded-relations` OAS extension declared on schemaObjects.
## Why
Often, API endpoints will automatically expand a model relations by default. They can also decorate a model with calculated totals. In order to more accurately represent the API, we wish to alter the generated types based on the expanded relations information.
## How
- Follow the relation declaration signature as the backend controllers and the `expand` query param, i.e.: `items.variant.product`.
- Introduce a custom `x-expended-relations` OAS extension.
- Allow for organizing declared relations to help their maintenance.
- Use traversal algorithms in codegen to support deeply nested relationships.
- Use [type-fest](https://www.npmjs.com/package/type-fest)'s `Merge` and `SetRequired` to efficiently alter the types while enabling great intellisense for IDEs.
Extra scope:
* Added convenience yarn script to interact with the `medisa-oas` CLI within the monorepo.
## Test
Include in the PR are two implementations of the x-expanded-relations on OAS schema, a simple and a complex one.
### Step 1
* Run `yarn install`
* Run `yarn build`
* Run `yarn medusa-oas oas --type combined --out-dir ~/tmp/oas`
* Run `yarn medusa-oas client --type combined --component types --src-file ~/tmp/oas/combined.osa.json --out-dir ~/tmp/types`
* Open `~/tmp/types/models/StoreRegionsRes`
* Expect relations to be declared as required
### Step 2
* Open `~/tmp/types/models/StoreCartsRes`
* Expect relations to be declared as required
* Expect nested relations to have relations as required.
### Step 3 (optional)
* Open `~/tmp/types` in an intellisense capable IDE
* Within the `index.ts` file, attempt to declare a `const storeRegionRes: StoreRegionRes = {}`
* Expect IDE to highlight that `countries` is a required field of `StoreRegionRes`
## What
Generated client types package based on the API's OpenApi Spec.
## Why
This package aims at replacing the need to import types directly from the core `@medusajs/medusa` package which can lead to side effects like importing backend dependencies into the client's realm.
## How
* The package contains a script that is invoked during the build step.
* The script will use the `medusa-oas oas --type=combined` cli to generate a combined oas file.
* Then, `medusa-oas client --component=types` uses the oas file to generate the types based on the OAS schema definitions. The result is outputted into `/src/lib`
* `prettier` is run on the `/src/lib` directory to ensure that the generated code follows the monorepo coding style.
* Finally, with `"emitDeclarationOnly": true`, `tsc` compiles the src directory to only output types.
Until we update our CI pipeline, we will not commit the content `/src/lib`.
## Test
* Run `yarn install`
* Run `yarn build`
* Expect `packages/generated/client-types/dist/` to contain types generated from the OAS defined by `@medusajs/medusa`
**What**
- Fix `delete-reservation` endpoint to allow deletions of reservations
- remove `inventory_item_id` from reservation update call to properly update reservation
- invalidate all list caches to properly update order overview after an allocation has been created
- Fix overlap for long product titles in edit-allocation-modal
Fixes CORE-1214
## What
Replace AddressFields with actual AddressPayload schema based off the actual type used by the controllers.
## Why
AddressPayload is currently being referenced in client code. Our OAS schema should attempt to match current client usage in order to reduce friction when migrating to a OAS generated types package.
## How
* Represent AddressPayload and AddressCreatePayload in our OAS schemas.
* Replace reference to AddressFields
* Plus, fix typo in /admin/orders/ route
