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
what:
- user can add/remove/update outbound items to a claim
- adds API to query variants
Note: There are several paths that are not implemented yet correctly, but have some code lying around. Those will be tackled in the followup PRs
https://github.com/user-attachments/assets/cadb3f7a-982f-44c7-8d7e-9f4f26949f4f
RESOLVES CC-330
RESOLVES CC-296
* wip: setup UI
* wip: rendering modal, adding claim items, create checks
* fix: make form work after merge
* fix: continuation of claim edit
* chore: ability to add and remove items to claim inbound
* chore: minor fixes
---------
Co-authored-by: fPolic <mainacc.polic@gmail.com>
* feat(core-flows,payment,medusa,types): add ability to set and manage refund reasons
* fix(payment): validate total amount when refunding payment (#8437)
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
* feature: introduce additional_data to the product endpoints (#8405)
* chore(docs): Generated References (#8440)
Generated the following references:
- `product`
* chore: align payment database schema
* Update packages/core/core-flows/src/payment-collection/steps/create-refund-reasons.ts
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
* chore: address review
---------
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
Co-authored-by: Harminder Virk <virk.officials@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
* feat(dashboard,types,js-sdk,payment): ability to refund payment in order page
* chore: use confirmation variant for capture payment
* chore: change refund design accords to figma
* chore: move to js-sdk + currency input
what:
- when children scope beyond the pagination limit, we fail to load all descendants and ancestors
- we fix this by fetching all categories in the tree scoped by the where clause
**what:**
- DML can apply composite indexes
- Where clause is currently a string, QB version will come as a follow up
```
model.define("user", {
email: model.text(),
account: model.text(),
}).indexes([
{
name: "IDX-unique-name",
unique: true,
on: ["email", "account"],
where: "email is NOT NULL",
},
])
```
RESOLVES CORE-2391
**what:**
- hides different fields depending on the chosen template
- remove operator values API
- fixes to edit promotion rules
- make currency optional for promotion
RESOLVES CORE-2297
what:
Multiple active sessions are used for split payments. We don't currently support split payments. Until we have that implemented, this change is to ensure that whenever we create a new payment session, we delete an existing session if present.
RESOLVES CORE-2284
* chore: ability to group events on redis event bus
* chore: fix tests
* Update packages/modules/event-bus-redis/src/services/event-bus-redis.ts
Co-authored-by: Adrien de Peretti <adrien.deperetti@gmail.com>
* chore: change shape of input and body data
* chore: fix builds
* chore: address comments
* chore: fix unit test
---------
Co-authored-by: Adrien de Peretti <adrien.deperetti@gmail.com>
what:
- santizes inputs to prevent reserved_quantity from being updated directly
- inventory items create api can create location levels
- add validation to update quantity of reservation items
- general cleanup
RESOLVES CORE-2254
what:
When creating a variant, we can now create inventory as a part of the product and variants create endpoint.
This applies only to variants where `manage_inventory=true`. 2 cases present itself:
1. When inventory_items are present
- Link an inventory item with required_quantity to the variant
- the inventory item already needs to be present
2. When inventory_items are not present
- A default inventory item will be created
- links the created item to the variant with a default required_quantity
RESOLVES CORE-2220
what:
- adds variant inventory link management endpoints:
```
Link inventory item to variant
POST /products/:id/variants/:vid/inventory-items
Update variant's inventory item link
POST /products/:id/variants/:vid/inventory-items/:iid
Unlink variant's inventory item
DELETE /products/:id/variants/:vid/inventory-items/:iid
```
- a batch endpoint that does the above 3 across variants
```
POST /products/:id/variants/inventory-items
```
what:
- when inventory_quantity is requested through the API, we calculate the inventory based on sales channels + stock locations and return the total available inventory.
A variant can have multiple inventory items. As an example:
Table: (variant)
- 4 (required_quantity via link) x legs (inventory item)
- 2 x table top
Only if all individual inventory items of a variant are available, do we mark the variant as available as a single unit.
RESOLVES CORE-2187
* feat(core-flows,types,utils,medusa): Update existing line items when adding the same variant to cart
* chore: split steps into 2 for add-to-cart
* chore: split steps into 2 for add-to-cart
* chore: iterate safely
* chore: parallelize upsert
what:
The true source of promotions applied are present in the adjustments, previously we had links as the source of truth, but some issues popped up when you're trying to delete a line item as it was holding onto stale promotion data.
For this to truly work properly in the current form, we would have to pass data from the deleted line item step to the refresh promotion step and mutate the links twice to get the correct promotions for a cart. Additionally, the final list of codes to apply, comes from computeAction, because some previously applied codes could no longer be valid. The combination of passing codes from adjustments to computeActions and the codes returned from the computedActions are how we can accurately calculate the right promotions to apply.
With this change, the promotions step always look at the latest line item adjustments of the cart, pass them to compute actions, pick the correct codes to apply from the compute actions and then mutate the links based on the final result. This way, we perform the correct calculations for a cart and have promotion links that are correct.
Riqwan ThamirandCarlos R. L. Rodrigues
