What:
- Parent was being updated incorrectly because of a weird typeorm issue, making the rank pick up the wrong entity's rank. This PR fixes that issue by passing in an ID and letting the service take care of fetching the parent.
RESOLVES CORE-1274
Encoded the `location_id` into the query params and ensured it gets parsed on mount, into defaults. This allows safer refreshes of the locations table or accurate deep-links to be shared.
Resolves CORE-1252
I believe that changing the requiredness of the `address_1` and `country_code` fields when any part of the address was filled was not being registered correctly with the form state representation of those fields. ~~Have added an effect that unregisters the fields when the requiredness state changes and allows them to be re-registered with the correct `required` value when the next re-render happens due to that state having changed.~~
Have updated the submit button to be available even if form is invalid.
Resolves CORE-1266
Previously, if an order had two fulfilments that fully satisfied the order, then only one was shipped, the status would change to `partially_shipped` and show the "Create Fulfillment" button again, which would open a buggy modal with no items to fulfil. Added another check that looks at the items in the order and compares `quantity` and `fulfilled_quantity`, so that we can hide the button based on this as well, rather than just the order's `fulfillment_status`, which can be misleading.
Also added a status icon to the Fulfillment card's title bar for the `partially_shipped` status, as this area was blank before in that state.
Resolves CORE-1262
**What**
- Fix stock locations quantities being shown as `undefined` and `NaN`
- Throw if updates to location levels are made with negative quantities through the api
- Show "allocated" in order summary for partially fulfilled orders
Fixes CORE-1268, CORE-1267, CORE-1265
* init deploy command
* add include flag
* add 'shortcut' flag
* add dev command, fix var replacement, change default behaviour
* cleanup params of build command
* fix defaults when using the plugin to serve admin
* add changeset
* fix globals
* update README
* throw error on no build found
---------
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- Add check to see if any items is unfulfilled when validating reservations for allocation indicator
- Add reservations refresh to onSuccess when creating a fulfillment to automatically update indicators on fulfillment
Fixes CORE-1248
Co-authored-by: Sebastian Rindom <7554214+srindom@users.noreply.github.com>
## What
Commit generated client types to codebase.
## Why
As a developer, we will provides better visibility on the impact of OAS changes to the generated type. Also allow for browser the types on GitHub.
## How
* Remove `/lib` from .gitignore
* Add a non-blocking github action check validating if the latest generated build has been committed.
* Runs `yarn build --force --no-cache` on GitHub. Caching was creating false positives.
* Use `git status` and filter the output to target only `packages/generated` directory.
## Test
Proof of a failing check:
https://github.com/medusajs/medusa/actions/runs/4432323763/jobs/7776235128
UPDATE: Failing check after updating branch with latest develop
https://github.com/medusajs/medusa/actions/runs/4436707954/jobs/7785472045
**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`
