* chore: Clean up authentication middlewares
* chore: Rename AuthUser to AuthIdentity
* feat: Define link between user, customer, and auth identity
* feat: Use links for auth, update auth context content
* fix: Adjust user create command with new auth setup
* fix: Make auth login more dynamic, review fixes
* fix: Change test assertions for created by
* feat: Add search capability to api keys
* feat: Add support for searching to currency and customer endpoints
* fix: Clean up product search filters
* feat: Add search support to regions
* feat: Add search support to sales channels
* feat: Add search support to store module
* feat: Add search support to user module
* fix: Clean up inventory search
* feat: Add search support for payments
* fix: Add searchable attributes to stock location models
* feat: Add search support to tax
* feat: Add search support to promotions
* feat: Add search support for pricing, filtering cleanup
* fix: Further cleanups around search
whats missing:
- make rules required for overrides
- conditions for other rules
- populating condition reference ids with labels on update
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>
new wrapper for medusa integration tests.
for now it is only applied to the modules directory, but it could be used in the api integration tests or any other integrations that requires a db and a server up and running.
It is not perfect, but I wanted to have something working and centralised before improving it, also avoiding too many conflicts with other prs
**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).
