**What**
- Moves all current route definitions to `v1.tsx`
- Creates a new `v2.tsx` file for future V2 routes.
- Updates RouteProvider to serve V1 or V2 routes based on if `MEDUSA_V2` is set.
**How to use it**
When working on V2 domains you should set `MEDUSA_V2=true` in `/packages/admin-next/dashboard/.env`. We can't use the Feature Flag in the Medusa project since there are breaking changes in the `/admin/store` endpoint between the two versions, so it needs to be managed manually.
**For people implementing V2 domains**
To add a new route you should:
- Add the route component in `/v2-routes`
- Define which path will render it in `v2.tsx`.
I would prefer that we don't try to implement a lot of conditional code that will make the codebase unnecessarily complex. So if I was to implement the V2 login page, I would copy/past the v1 login route into `v2-routes`, make the required changes, eg. replace `useAdminLogin` with `useAdminCustomPost(...)`, instead of trying to force the current V1 Login page to work with both APIs.
There will hopefully be a lot of components/sections from each domain that is re-usable between versions. As an example if you are working on the Product details page for V2 you might want to reuse the `product-general-section.tsx` file, as it works without having to make any modifications. In that case I propose that we create a `modules/product` folder and move the component in there which we can them import into both the v1 and v2 version of the route.
what:
- adds fulfillment shipping option rules batch endpoint
- remove fulfillment shipping option rules batch endpoint
- breaks my British based education to not call it fulfilment with a single "l"
**What**
- Runs loadMedusaV2 when v2 flag is enabled.
- V2 loader loads only project-level framework features. E.g., project APIs, subscribers, jobs, and workflows.
- No plugin support yet.
Prepare CODEOWNERS file for reviewer auto-assignment by isolating the ownership of the engineering team to packages. Without this, the team would be asked to review docs PRs too.
**What**
- Update migration for backward compatibility. This does not take into account data migration and table cleanup (@olivermrbl do we have a general tasks for the modules on that subject)?
- Rename fulfillment provider id to provider id
- add integration tests to ensure the migration backward compatibility
- add new module type for the options to be used in the medusa config for example
FIXES CORE-1724
**What**
- Ensure soft delete works properly according to the soft delete configuration and validate all relation of the entire data model
- Add is_enabled to the providers in order to manage new providers to enabled or disabled
- include joiner config update
FIXES CORE-1853
FIXES CORE-1830
FIXES CORE-1719
The 2 bigger remaining tasks are:
1. handling prices for variants
2. Handling options (breaking change)
After that all tests should pass on both v1 and v2
**What**
- Initial work on pricing domain.
- List page
- Details page
- Partial edit form
- Fixes admin/price-lists/:id/products endpoint to allow filtering products by multiple ids.
**Note**
Pushing this now as the current design need a bit of tweaking so we display all relevant data to users. Future PR will include completed Edit moda, Create modal, Edit prices modal and Add prices modal.
**What**
- Adds list page for reservations and inventory items
- Adds new String filter type, that allows users to filter by a string, eg. "material === 'metal'"
- Adds new Number filter type, that allows users to filter by a number or numerical comparator, eg. quantity === 10 / quantity is gt 10 and lt 50.
**What**
- v1 of executions domain
**TODO in follow up PR**
I think it might be a good idea for Carlos or Adrien to go over the design with Ludvig, and make sure we are displaying what is relevant to developers, and how things should be displayed. So this PR is just the initial implementation, and does not handle displaying things like compensation steps (not part of the current design), step input (not supported by the API but part of the design), etc.
Closes CORE-1751, CORE-1755
**What**
- Adds pages for managing tax settings and tax rates for regions.
- Fixes `list` tax rates endpoint, which was missing pagination, search, order, and filters.
**Note**
The fix to the tax rate list endpoint is very rough, as I have had to reimplement most of the logic from our transformQuery middleware. This is because this endpoints does not follow normal convention for fields and expand and uses string arrays instead of strings separated by commas. Our middleware does not support this, and changing the endpoint to align with other endpoints on the expand and fields params would be a breaking change. Since this is very temporary until 2.0 I think it's okay for the time being.
CLOSES CORE-1654
In this PR:
1. I added upsert support for the product
2. I updated the create and update signatures to match the latest interface standards
3. Small changes to make the v1 and v2 APIs compatible (WIP)
This is a PR to keep them relatively small. Very likely changes, validations and other features will be added.
What:
Basic methods to cancel, confirm or decline order changes
Apply order changes to modify and create a new version of an order
Things related to calculation, Order and Item totals are not covered in this PR. Properties won't match with definition, etc.
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
### What
Add workflow for refreshing a payment collection.
The idea is that on all cart updates, we want two things to happen (in the context of payments) 1. the currently active payment sessions should be destroyed, and 2. the payment collection should be updated with the new cart total.
We do this to ensure that we always collect the correct payment amount.
From a customer perspective, this would mean that every time something on the cart is updated, the customer would need to enter their payment details anew.
To me, this is a good tradeoff to avoid inconsistencies with payment collection.
Additionally, I updated the Payment Module interface with `upsert` and `updated` following our established convention.
### Note
This PR depends on a fix to the `remoteJoiner` that @carlos-r-l-rodrigues is working on.
Update: Fix merged in #6602
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
