### Scope
Admin routes directories D to N.
### What
Move inline OAS response schema declaration under their respective class declarations in order to expose them through `#/components/schemas`. Replace inline OAS response schema with a `$ref` reference pointing to the newly declared schema.
### Why
Having response declared as its own "named" schema will allow OAS code generators to output typed entities/DTO that can be consumed without having to reference the route/operation.
### How
Declare a new @schema JSDoc for each "Res" class used to parse and validate request body. Move the current inline requestBody to the new @schema.
### Test
- Ran OAS validator.
- Ran docs build script.
Expect no visible changes to the documentation.
### Scope
Admin routes directories O to PRI.
### What
Move inline OAS response schema declaration under their respective class declarations in order to expose them through `#/components/schemas`. Replace inline OAS response schema with a `$ref` reference pointing to the newly declared schema.
### Why
Having response declared as its own "named" schema will allow OAS code generators to output typed entities/DTO that can be consumed without having to reference the route/operation.
### How
Declare a new @schema JSDoc for each "Res" class used to parse and validate request body. Move the current inline requestBody to the new @schema.
### Test
- Ran OAS validator.
- Ran docs build script.
Expect no visible changes to the documentation.
What:
Introduces a store endpoint to retrieve a product category
Why:
This is part of a greater goal of allowing products to be added to multiple categories.
How:
- Creates an endpoint in store routes
RESOLVES CORE-967
What:
Introduces an admin endpoint that allows a user to update a product category
Why:
This is part of a greater goal of allowing products to be added to multiple categories.
How:
- Creates a route on the admin scope to update category
- Creates a method in product category services to update a category
RESOLVES CORE-956
What:
Introduces an admin endpoint that allows a user to create a product category
Why:
This is part of a greater goal of allowing products to be added to multiple categories.
How:
- Creates a route on the admin scope to create category
- Creates a method in product category services to create a category
RESOLVES CORE-958
**What:**
Introduces an admin endpoint that allows a user to delete a product category, given an ID.
Why:
This is part of a greater goal of allowing products to be added to multiple categories.
How:
- Creates a route on the admin scope to delete category
- Creates a method in product category services to delete a category
RESOLVES CORE-957
* chore: added get route for admin categories API
* chore: add tree method to mock repository
* chore: added changeset to the PR
* chore: rename id to productCategoryId in service
* chore: switch cli option to string
* chore: lint fixes, tests for parent category
* chore: move Nested Categories behind feature flag
* chore: use transformQuery hook in api
* chore: add feature flag in migrations
* chore: remove migration FF, fix FF name
* chore: add free text search + count repo function
* chore: added list endpoint for admin
* chore: added changeset for feature
* chore: address pr review comments
* chore: change oas comment
* chore: add nullable parent category filter + test
**What**
The order cancelation does not include the refunds relation. It means that the check of the length of the refund is never true and therefore no errors are thrown if the order contains the refunds.
**How**
Add the refunds relation and tests
FIXES CORE-976
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* remove duplicate key from oas
* changeset
* initial suggestion for adding locations to fulfillments
* update migration
* re-add functionality for removing entire reservations
* fix tests
* add location when adjusting reserved inventory of a line_item
* add changest
* handle multiple reservations for a product in the same channel
* confirm inventory in stock location previous to creating the fulfillment
* fix tests after updating create-fulfillment to confirm inventory prior to creating fulfillment
* remove bugged code
* initial validation
* initial changes for review
* chekcpoint
* update validate inventory at location
* redo some unwanted changes
* typing
* update snapshots
* redo change for eslintrc
* add eslint disable
* re-order methods in interface
* assert no_notification
* iterate one time less
* add test for validation of correct inventory adjustments in case of no inventory service installation
* ensure correct adjustments for order cancellations
* remove comment
* fix tests
* fix but with coalescing
* remove location id from confirm inventory
* don't throw when adjusting reservations for a line item without reservations
* move reservation adjustments to the api
* add multiplication for updating a reservation quantity
* move inventory adjustments from the service layer to the api
* delete reservation if quantity is adjusted to 0
* rename updateReservation to updateReservationItem
* update dto fields
* reference the correct fields
* update with transaction
* add jsdocs
* force boolean cast
* context-ize cancel and create fulfillment transaction methods
* undo notification cast
* update with changes
* refactor withTransaction to variable
* use maps
* fix service mocks
**What**
The actual behavior is that the skip/take is applied in a first query returning the correct number of results. When there is no relations, we are calling findByIds with the previously retrieved ids, but we also pass skip/take which means that no result are returned after the first increment of the skip.
The skip/take should not be applied in that case as it has already been applied.
FIXES CORE-970
**What**
- Add integration test suite for database options
- Expose integration tests DB to additional options
- Add test for `idle_in_transaction_session_timeout`
**What**
Only use `setPaymentSessionsBatch` in `setPaymentSession` to reuse the logic as it is the same behavior. One for a unique session and the other one for multiple sessions.
This refactoring reduce the risk of introducing bugs when working around payment session if it needs to be changed (which is currently happening as part of the payment refactoring) and having to change it in less places instead of more and more places
Patrick
Carlos R. L. Rodrigues
Shahed Nasser
Adrien de Peretti
Oliver Windall Juhl
Riqwan Thamir
Philip Korsholm
Kasper Fabricius Kristensen
olivermrbl
Sebastian Rindom
Alex Chiu
