**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
**What**
- fix `prepareConfirmInventory` to account for inventory kit items
- _note: this step is reused in the complete cart and all RMA flows_
- properly remove reservations for items that are removed from the order edit
- invalidate inventory/reservations cache when order edit is confirmed
---
https://github.com/user-attachments/assets/f12e9198-0718-4c08-bd81-efc536eca146
---
FIXES CC-565
Fixes: FRMW-2742
In this PR, we fix the build output of the backend source code, which eliminates a lot of magic between the development and production environments.
Right now, we only compile the source files from the `src` directory and write them within the `dist` directory.
**Here's how the `src` directory with a custom module looks like**
```
src
├── modules
│ └── hello
│ ├── index.ts
```
**Here's the build output**
```
dist
├── modules
│ └── hello
│ ├── index.js
```
Let's imagine a file at the root of your project (maybe the `medusa-config.js` file) that wants to import the `modules/hello/index` file. How can we ensure that the import will work in both the development and production environments?
If we write the import targeting the `src` directory, it will break in production because it should target the `dist` directory.
## Solution
The solution is to compile everything within the project and mimic the file structure in the build output, not just the `src` directory.
**Here's how the fixed output should look like**
```
dist
├── src
│ ├── modules
│ │ └── hello
│ │ ├── index.js
├── medusa-config.js
├── yarn.lock
├── package.json
```
If you notice carefully, we also have `medusa-config.js`, `yarn.lock`, and `package.json` within the `dist` directory. We do so to create a standalone built application, something you can copy/paste to your server and run without relying on the original source code.
- This results in small containers since you are not copying unnecessary files.
- Clear distinction between the development and the production code. If you want to run the production server, then `cd` into the `dist` directory and run it from there.
## Changes in the PR
- Breaking: Remove the `dist` and `build` folders. Instead, write them production artefacts within the `.medusa` directory as `.medusa/admin` and `.medusa/server`.
- Breaking: Change the output of the `.medusa/server` folder to mimic the root project structure.
- Refactor: Remove `Symbol.for("ts-node.register.instance")]` check to find from where to load the source code.
- Refactor: Use `tsc` for creating the production build. This ensures we respect `tsconfig` settings when creating the build and also perform type-checking.
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
**What**
- Adds `metadata` to the default response for `/admin/collection` endpoints.
- Fixes tests to expect correct shape and not use objectContaining.
Fixes CC-551
**What**
- Removes the <Copy /> wrapper from the Token badge in API key tables.
- The usage of copy spawned to issues: the click was being propagated despite stopping propagation causing navigation to the API keys detail page, the Copy acts as a <a /> tag when it's a child of a <Link />, escaping react-router-dom and doing a "hard" navigate to the next page.
Fixes CC-576
**What**
- allow to create a variant without managed inventory (we need to explicitly pass `false` now since the default on the model is `true` for `manage_inventory`)
---
FIXES CC-575
**What**
The extra serialization check hapen to break the serialization chain by reusing already serialized entities when they have been serialized from a different parents sequence
What
- Store result of cart-completion workflow for three days by default
- This enables the built-in idempotency mechanism to kick-in, provided the same transaction ID is used on workflow executions
- Return order from cart-completion workflow if the cart has already been completed
- In case transaction ID is not used on workflow executions, we still only want to complete a cart once
**What**
If the country on the shipping address changes to a country without an associated tax region, we clear the tax lines on shipping methods and line items.
**What**
On cart creation:
- If region only has one country -> create cart with country code
On cart updates:
- If shipping address country code is provided in input ->
- If cart region doesn't include that country -> throw
- If cart includes the country -> update shipping address
- If region is provided in input and is different from the one currently on the cart ->
- If there is a shipping address on the cart -> clear the address
- If the region only has one country -> set country code of address
- If there is not a shipping address on the cart ->
- If the region only has one country -> set country code of address
Closes CC-545
**What**
The `updateTaxLinesWorkflow` rely on the cart shipping method meaning that concurrent refresh of shipping method can impact tax lines therefore leading to wrong tax lines
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
