Fix for the problems identified in issue #4892
Bugfix: admin-ui order summary no longer uses gift card total from order when displaying how much has been withdrawn from each giftcard.
Bugfix(?): no longer keep applying gift cards (at 0 value) when sufficient balance has been reached
Feature: multiple giftcards are now applied in ordered fashion. First by end_date (supports null), then by remaining balance. In order to ensure that customers ends up with as long lasting and few remaining gift cards as possible after the transaction.
**What**
There is actually an issue with using the `fields` query params with the way the repositories are using our custom query strategy. This pr aims to fix this issue by reworking the strategy.
What we had to do was to rework the way the selects are built for each subquery in order to follow the aliasing convention and to be taken into consideration. Alongside these changes, the join used to always select everything, this needed to be changed so that if there are any selects provided for a join, the join should not select everything and let the query select the fields that are requested.
Another notable change is that all the repositories are now using the repository util in order to centralize the customization and to have a single place to update when this kind of issue arises. This means that the eager relations when using the query builder are not necessarily taken into account. For that reason, I have removed the `shipping_option` eager option in favor of explicitly asking for the relations like we started to do it in some places.
FIXES CORE-1413
* feat(medusa): add description field to product categories
* chore: set nullable to false
* chore: added UI for description
* chore: added codegen files
* remove reservations from draft order creation and show correct inventory
* add changeset
* add integration tests
* adjust inventory on payment if no inventory service is installed
* fix fulfillment for order lines without inventory items
* fix summary card on order for variants without inventory items
* add changeset
* minor fixes
* remove variants without inventory items from allocate modal
* naming
* Update .changeset/kind-rings-wave.md
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* remove line item indicator
* cleanup
---------
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* Fix effect check in inventory table and overflow UI
* Create ten-berries-rest.md
* Fix edit stock&inventory modal to use the right form
* Fix faulty merge conflict resolution
* Fix inventory item creation
* Add redirect to locations tab if no locations, toast
* Revert redirect and toast, add message in table
---------
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* validate that an inventory level exists as well
* improve create-fulfillment handling in admin
* pass along location id rather than inventory level id
* add changeset
* remove dependency
**What**
- fix `difference_due` in the OE modal to show the correct difference a user has to pay
- fix Timeline crashing due to returned line item being `undefined `(deleted after OE confirmation)
**Why**
We were taking into account `refunded_amount` when calculating "Difference Due" and used the following formula:
`orderEdit.total - paidTotal + refundedTotal`.
The issue here is that `orderEdit.total` is "overpriced" for the amount of items that are returned/refunded already (i.e. we are charging the user again for the returned items).
The straightforward solution would be to subtract `refunded_total` from the `orderEdit.total` to get the total cost of items the user is actually getting after the edit.
`difference_due = (orderEdit.total - refundedTotal) - (paidTotal - refundedTotal ) = orderEdit.total - paidTotal`
But if we have partially refunded returns, we would have the same problem of returned items priced into the total.
In that case, general solution should be something like:
`diff_due_display = orderEdit_total_of_items_user_is_getting - paid_total + refunded_total`
Would like to hear what you guys think!
---
FIXES CORE-1246
**What**
1. Enable the "create location" button in "create stock location" when a field has changed
2. Remove the "successful delete" toast when cancelling stock location creation
3. Properly update available and reserved when editing stock levels for variant
4. invalidate inventoryItemList queryKeys when changing location levels
**Why**
- we had the same bug with form validation when creating location levels as we had when editing them (1)
- when updating location levels, listing inventory items wouldn't show the newly added location levels (4)
- fixing ui bugs (2, 4)
**What**
- Add warning to request-return modal if no inventory level exists for the combination of items that is being requested
- Block receive return at location with the same condition
I believe that changing the requiredness of the `address_1` and `country_code` fields when any part of the address was filled was not being registered correctly with the form state representation of those fields. ~~Have added an effect that unregisters the fields when the requiredness state changes and allows them to be re-registered with the correct `required` value when the next re-render happens due to that state having changed.~~
Have updated the submit button to be available even if form is invalid.
Resolves CORE-1266
Geoffroy Empain
mortenengel
Andreas Deininger
Rares Stefan
Victor Frunza
Frane Polić
Kasper Fabricius Kristensen
Oli Juhl
Adrien de Peretti
Philip Korsholm
Riqwan Thamir
Carlos R. L. Rodrigues
