FIXES: FRMW-2727
MikroORM (with version 5.9) has [hardcoded the TypeScript module](https://github.com/mikro-orm/mikro-orm/blob/5.x/packages/core/src/utils/ConfigurationLoader.ts#L138-L139) system to `commonjs`, which makes it incompatible with the module system we are using, ie `Node16`.
So, in order to continue using the Mikro ORM CLI within our modules, we will have to monkey-patch the block of code responsible for configuring `ts-node`. However, the monkey-patching must be done before their CLI gets booted.
As a result of this, we have to create a wrapper CLI on top of Mikro ORM CLI that performs the following steps.
- Monkey-patch the relevant code
- Register Mikro ORM CLI as the second step.
Due do this, we will have to use this new wrapper CLI within the modules, which is exposed as `medusa-db`. Maybe, `medusa-db` is not a great name, so please send your suggestions.
**What**
- fix location loader returning stale data if SL details are fetched with another field params
**Why**
- if we visit the order details page and visit location details afterwards, delivery and pickup will appear disabled because a new query with `fulfillment_sets` is not fetched
**What**
- hide disabled fulfilment providers on the admin
- check if the fulfilment provider has an identifier when loading providers
---
FIXES CC-549
**What**
- show "not allocated" label only if there are unfulfilled items
- small refactor and general improvement of reservations in order summary
---
FIXES CC-539
**Why**
- price set update uses `upsertWithReplace` so price list prices are removed since we "ignore" them in regular price set operations and use price list methods to manage them
**What**
- preserve price list prices when updating price sets
---
FIXES CC-516
**What**
- Removes broken cart retrieval step `retrieveWithCartLinks` in favor of `useRemoteQueryStep` in `updateTaxLinesWorkflows`
**Why**
- Filters variables in the step were passed with an incorrect shape
- I removed the step, since it's only used once and the behavior is identical to the generic remote query step
**Note**
- Because the filters were passed incorrectly, the, now-removed, step has always returned the first cart in the database. As a result all tax calculations so far have been based on whatever the shape of that cart has. It basically ignores all input to this workflow
**What**
- Fixes an issue where the admin dashboard would send region prices for deleted regions.
- Also, includes the implementation for `GET /admin/shipping-options/:id` and its corresponding SDK function.
**Why**
- When a region price for a deleted region was sent to the backend it would result in the insert hitting a not null constraint on the currency_code for prices. To avoid this the dashboard should not send region prices for deleted regions.
**Additional context**
- Prices for deleted regions should ideally not be returned when fetching shipping option prices. However, we don't yet have a mechanism for cleaning up region prices after a region is deleted.
Fixes CC-540
**What**
- set product title and sales channels column widths to a reasonable value so the scroll is visible on mobile resolutions only
---
FIXES CC-527
What
- Require `code` on Tax Rates
- Update dashboard to account for non-nullable code on Tax Rates
- Include `automatic_taxes` in API Route response
Closes CC-524 CC-525
**What**
- Adds a step to `updateShippingOptionsWorkflow` and `createShippingOptionsWorkflow` that validates if the region prices being updated have corresponding regions configured.
**Why**
- Previously, if you tried to send a region price update for a region that had been deleted the backend would throw an error when attempting to insert the region price. The error comes from a not-null constraint in the db, but it is better to validate that the regions we are trying to create prices for exist.
Fixes CC-542
**What**
- Fetches the stock location's details when creating a fulfillment and return fulfillment.
- Passes the data to the fulfillment module, which in turn passes it to the fulfillment provider.
**Why**
- When creating a fulfillment in a multi-location setup the fulfillment provider will need to know where the package is being sent from (so the shipping service can pick it up).
- Previously, we didn't pass anything but the location id to the fulfillment provider. Because the fulfillment provider can't have a dependency on the stock location module this was not sufficient.
- This change ensures there is enough data passed to the fulfillment provider to build integrations properly.
What:
- The time taken to load in sequence is the same as in parallel, and it doesn't create multiple db queries simultaneously when starting each module.
- Rework modules bootstrap (now all dependencies are available from the constructor and cross deps are allowed without any topological sort needed. It also allow improvements in the future)
- First load all modules
- then resolve and register instances
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
- Fix claim / exchange / return extending an order (we previously addressed this in the http types)
- add `@ignore` for all `raw_*` fields to hide them from references.
