**What**
- Add method to validate fulfillment option from the provider
- Separate list/list and count from context rules validation and add listShippingOptionsForContext
FIXES CORE-1861
The changes in this PR are:
1. Change how product options are created and stored. The relationship changed from
`options --> option values <-- variants`
to
`options --> option values --> variant options <-- variants`
Now we can enforce non-duplicate option values, easier creation and updates of options, and more.
2. Refactors the product module. The product module did a lot of things in a non-ideal approach, and this is a step towards a more consistent usage of the base repository and methods exposed by a module. There is still work left to improve the module, but a large chunk of the changes are included in this PR
Things to do as a follow-up:
1. Remove many-to-many relationships if an empty list is passed in the base repository.
2. Improve the typings of the module
3. Further cleanup and improvements (there are few questions that I need answered before I can improve the API)
Apologies for the giant PR in advance, but most of these are removing of files and migrations from old workflows and routes to new.
What:
- Adds CRUD endpoints for price lists
- Migrate workflows from old sdk to new
- Added missing updatePriceListPrices method to pricing module
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**
- 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
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>
Few things to keep in mind:
1. You need to set MEDUSA_FF_MEDUSA_V2 to true before running the tests to run with the v2 API
2. You can use the `breaking` function to differentiate between v1 and v2 differences. This can help us identify what was breaking pretty quickly afterwards
3. You will need to run specific tests for now instead of all if you want to target v2. I think that's fine though, as we don't really need these to run on every PR until we have feature parity (and by then, all tests would be both v1 and v2 compatible)
**note: Adrien**
- add a new way to load modules only to run their loaders comparable to the way to run the migrations only
- improve tests runner to cleanup the data properly as well as re running all loaders and core defaults
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
**What**
- Create the fulfillment manual package with a first iteration API
- Create a new `AbstractFulfillmentProviderService` and `IFulfillmentProvider`
- Modify the module service interface to add new methods to manipulate the fulfillment and the communication with the external provider
- create (no bulk)
- cancel (no bulk)
- update (no bulk)
- list
- listAndCount
- retrieve
- Add new methods to the service provider service to include communication with the third party provider
- get options
- create
- cancel
- validate data
- validate option
- Update/create interfaces and DTO's
- fix repository serializer to allow non entity to be passed without throwing
- split module tests into multiple files to simplify navigation
- Add integration tests to validate fulfillments manipulation and external provider loading + communication
FIXES CORE-1729
FIXES CORE-1785
FIXES CORE-1784
FIXES CORE-1766
This implementation obviously lacks a lot of things, and there are a lot of TODOs. However, there are already a lot of questions I'd rather get answered soon, so I figured it's much easier to do the implementation in steps.
I wrote down all breaking changes, suggested changes, and new additions with comments (TODO and Note).
In a follow-up PR I will:
Add the remaining/missing models
Make the workflows handle all interactions between the different models/modules
Add integration tests
**What**
- Introduce link between Region and PaymentProvider
- Introduce API endpoint `GET /store/regions/:id/payment-providers` for retrieving providers by region
- Add tests for both
~~Opening a draft PR to discuss a couple of implementation details that we should align on~~
**What**
Add workflow and API endpoint for creating payment sessions for a payment collection. Endpoint is currently `POST /store/payment-collection/:id/payment-sessions`. I suggested an alternative in a comment below.
Please note, we intentionally do not want to support creating payment sessions in bulk, as this would become a mess when having to manage multiple calls to third-party providers.
**What**
Adds endpoints to manage tax rules on a tax rate:
- Create a tax rule: POST /admin/tax-rates/:id/rules
- Delete a tax rule: DELETE /admin/tax-rates/:id/rules/:rule_id
- Replace tax rules: POST /admin/tax-rates/:id -- with { rules: [...] } in body.
### Noteworthy things I bumped into
**Updating nested relationships**
A TaxRate can have multiple TaxRules and in this PR we enable users to replace all TaxRules associated with a TaxRate in one operation. If working with the module directly this can be done with:
```javascript
taxModuleService.update(rateId, { rules: [{ ... }] })
```
Internally in the `update` function the TaxModule first soft deletes any TaxRules that exist on the TaxRate and then creates new TaxRules for the passed rules ([see test](https://github.com/medusajs/medusa/pull/6557/files#diff-cdcbab80ac7928b80648088ec57a3ab09dddd4409d6afce034f2caff08ee022bR78)).
A challenge arises when doing this in a compensatable way in a workflow. To see this imagine the following:
1. `updateTaxRatesWorkflow` gets the current data for the tax rates to update. This includes the tax rates' rules.
2. `updateTaxRatesWorkflow` calls `taxModuleService.update` with new rules.
3. Internally, the tax module deletes the rules in 1. and creates new rules.
4. Imagine an error happens in a following step and the workflow has to compensate.
5. The workflow uses the data from 1. and calls upsert. The tax module may correctly update the previous tax rules so they are no longer soft deleted. However, upsert (at least not by default) doesn't delete the new rules that were created in 2.
As illustrated by 5. compensating the update is not pretty. To get around this I instead opted to let the workflow handle setting the rules for a rate that makes the compensation more straightforward to handle. [See workflow here](https://github.com/medusajs/medusa/pull/6557/files#diff-ff19e1f2fa32289aefff90d33c05c154f9605a3c5da6a62683071a1fcaedfd7bR89).
**Using nested workflows**
Initially, I wanted to use the `setTaxRateRulesWorkflow` within the `updateTaxRatesWorkflow`. And this worked great for the invoke phase. However, when I needed to compensate the update workflow (and hence also had to compensate the set rules workflow), I found that the workflow engine no longer had the set rules transaction in memory and therefore could not roll it back. ([This is where I try to rollback](https://github.com/medusajs/medusa/pull/6557/files#diff-ff19e1f2fa32289aefff90d33c05c154f9605a3c5da6a62683071a1fcaedfd7bR62), but the transaction id can't be found).
I therefore opted to copy the steps from the set tax rate rules workflow into the update tax rates workflow; however, once we figure out a good way to ensure we can compensate nested workflows we should move to the nested workflow instead.
This also made me realize that the current implementation of workflows that use `refreshCartPromotions` may create inconsistencies in case of failures (cc: @riqwan).
I ultimately went with having a flat list of settings for the store. It wouldn't be very difficult to change it if we wish to do so, but for now this keeps the codebase simpler
what:
- promotion modules (application method and campaign budget) uses big number fields instead of numeric fields
- refreshes the migrations to include new fields for big numbers
- adds a promotion_ prefix to promotion models
- uses `take: null` within the module to prevent the default pagination on performing actions within the module
