* Include locale field for traslations on tax line workflows
* Translate tax lines in getItemTaxLinesStep with new util
* Update tax calculation context, so that we pass locale to third party tax providers if they want to return translated tax rates
* Apply translations to tax lines on product and variant tax middlewares
* Cart management translations tests
* Update tax lines when order locale gets updated
* Add changeset
* Get tranlsated tax lines step
* Fix wording
* Mutate ref directly
* Update order tax lines translations upon order locale change
* Claims translations tests
* Update tax lines upon draft order locale update
* Exchange tests for tax lines translations
* Order edits test for tax line translation
* Add tests for shipping methods tax line translations on various order flows
* Returns shipping method translations tests
* Execute update in parallel
* Use TranslationFeatureFlag.key
* Fix feature flag import
* Add @medusajs/medusa dependency for feature flag usage
* Revert "Add @medusajs/medusa dependency for feature flag usage"
This reverts commit e8897aed0a88f83c1034ac73e817e4222250a2c9.
* Use feature flag string directly
* Fix test
* Parallelize tax line translations application
Closes#13163
I have a few questions about expected behaviour, since this currently breaks some tests:
- Many tests use the productModule to create products, with default status == "draft", and use the addToCart workflow which now throws. Should I change all breaking tests to specify status == "published" whne creating the product? The alternative would be to check the status in the store API route before the workflow but 1. it would be an extra query and 2. the addToCart workflow is only used in the store currently, and even if it was to be used admin-side, it still doesn't make sense to add a draft product to cart
- After this PR an unpublished product would give the same error as a variant that doesn't exist. While imho this is correct, the thrown error (for both) is "Items do not have a price" which doesn't make much sense(i believe the workflows goes through with an empty variants list and then errors at the price check point). Should I throw a different error when a variant doesn't exists/isn't published?
---
> [!NOTE]
> Enforces that only variants from published products can be added to carts, adds status fetching, refines errors, and updates tests to use ProductStatus.PUBLISHED.
>
> - **Core Flows**:
> - addToCart: Validate variants exist and belong to `product.status = PUBLISHED`; throw clear `INVALID_DATA` when not found/unpublished.
> - Data fetching: Include `product.status` in `cart` and `order` variant field selections.
> - **Tests/Fixtures**:
> - Update integration tests to set `status: ProductStatus.PUBLISHED` when creating products and import `ProductStatus` where needed.
> - Add cases for unpublished products and non-existent variants producing the new error message.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit ca72532e957964d2d8e6bcecbb0905054c677ded. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
* fix: return fulfillment creation
* chore: changeset
* fix: link
* fix: cancel claim flow
* chore: test fulfillment creation as a part of return lifecycle test
* fix: exchanges cancle flow
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
This PR adds a couple new statuses to the payment collection and payment webhook results. The payment collection will now be marked as "completed" once the captured amount is the full amount of the payment collection.
There are several things left to improve the payment setup, so non-happy-path cases are handled correctly.
1. Currently the payment session and payment models serve a very similar purpose. Part of the information is found on one, and the other part on the other model, without any clear reason for doing so. We can simplify the payment module and the data models simply by merging the two.
2. We need to handle failures more gracefully, such as setting the payment session status to failed when such a webhook comes in.
3. We should convert the payment collection status and the different amounts to calculated fields from the payment session, captures, and refunds, as they can easily be a source of inconsistencies.
**What**
- validate that variants are unique with respect to options on product update/create and variant update/create
- validate that the product has options upon creation
- ensure variants have the same number of option values as the product has options
- admin error handling
- update tests
---
FIXES FRMW-2707 CC-556
what:
I've added some specs and comments in the specs for where I think totals are incorrect.
Lets get this test merged in as the status quo and proceed to fix these issues one by one.
Additionally, this also removes the temporary_difference as its not something we use.
RESOLVES CC-346
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
* feat(core-flows): create or update payment collections in RMA flows
* chore: change ui to pick payment link from unpaid payment collection
* Apply suggestions from code review
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
* chore: fix mathbn
* feat(dashboard,core-flows,js-sdk,types): ability to mark payment as paid
* chore: add captured bt
---------
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
what:
- enables a button to create a payment link when a payment delta is present
- api to delete order payment collection
- adds a pending amount to payment collections
Note: Not the happiest with the decision on when to create a payment collection and when not to. The code should programatically create or delete payment collections currently to generate the right collection for the payment delta. Adding a more specific flow to create and manage a payment collection will help reduce this burden from the code path and onto CX/merchant.
Another issue I found is that the payment collection status doesn't get updated when payment is complete as it still gets stuck to "authorized" state
https://github.com/user-attachments/assets/037a10f9-3621-43c2-94ba-1ada4b0a041b
what:
- allows completing claim with only inbound items
- allows completing claim with only outbound items
- validates against creating claims when an active change order is present
