## What
Pluralize OAS tags
## Why
OAS tags are commonly used by code generator to group routes under a name space based on a tag.
Our JS client convention is to use plural, e.g: client.products, client.customers. In order to minimize friction when migrating to a client generated from OAS, tags should be plural as well.
## How
Match tag naming with JS client resource naming.
## Test
* Run `yarn build`
* Run `yarn openapi:generate`
* Run `yarn redocly preview-docs docs/api/admin/openapi.yaml --config=./docs-util/redocly/config.yaml`
* Expect side menu items to be plural.
* Run `yarn redocly preview-docs docs/api/store/openapi.yaml --config=./docs-util/redocly/config.yaml`
* Expect side menu items to be plural.
## What
Include `/admin` and `/store` in OAS paths URLs
## Why
Allow for generating a combined OAS that include routes for both "admin" and "store" endpoint.
Fix potential issues with code generator where routes are not prefixed with "admin" and "store" leading to 404 errors.
## Test
* Run `yarn build`
* Run `yarn openapi:generate`
* Run `yarn redocly preview-docs docs/api/admin/openapi.yaml --config=./docs-util/redocly/config.yaml`
* Expect paths to be prefixed with /admin.
* Run `yarn redocly preview-docs docs/api/store/openapi.yaml --config=./docs-util/redocly/config.yaml`
* Expect paths to be prefixed with /store.
## Scope
Admin routes
## What
Add OAS `required` to response schemas.
## Why
Code generator can use the `required` property of a schema to mark fields as optional or not when generating TS types.
## Test
* Run `yarn build`
* Run `yarn openapi:generate`
* Run `yarn redocly preview-docs docs/api/admin/openapi.yaml --config=docs-util/redocly/config.yaml`
* Open the documentation preview URL in a browser (http://127.0.0.1:8080)
* Expect responses to have their fields declared as `required`
### What
Declare `x-codegen` in OAS for Admin routes - A to D.
### Why
We are introducing a new `x-codegen` OpenApi extension, also known as _vendor extension_, in order to help with passing information down to code generators.
In our case, we wish to declare the `method` name that we would expect to call on a client. This mimics our current JS client package.
E.g. `medusaClient.product.list` where `product` is the tag of the route and `list` is the x-codegen.method value.
We are also defining the name of a potential typed object for query parameters. OAS 3.0 does not allow to bundle query parameters under a single definition but it is not uncommon to see API clients handle all query parameters as a single typed object, like our JS client package. With x-codegen.queryParams, a code generator can create a named and typed object to bundle all query parameters for a given route.
E.g. `medusaClient.customer.retrieve(id: string, queryParams: AdminGetCustomerParams)`
### How
Declare `x-codegen` as an object with fields `method` and `queryParams` on all paths.
Match method and queryParams values with equivalent ones from our current JS client package.
### Test
* Ran OAS validator.
* Ran docs build script.
Expect no visible changes to the documentation.
* reserve quantities when creating a draft order
* only adjust quantities if a location is provided on a fulfillment
* initial fix for fulfillments
* changeset
* add check for inventory service when cancelling fulfillment
* update test-request with module loaders
* remove unused variable
### 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.
### What
Move inline OAS requestBody schema declaration under their respective class-validator classes in order to expose them through `#/components/schemas`. Replace inline OAS requestBody schema with a `$ref` reference pointing to the newly declared schema.
### Why
Having requestBody declared as its own "named" schema will allow OAS code generators to output typed entities/DTO that can be manipulate without having to reference the route/operation.
### How
Declare a new @schema JSDoc for each class-validator 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.
### Out-of-scope
requestBody of type `multipart/form-data` used for file uploads. These will be address as part of CORE-934
- [create-upload.ts](58d23a7b45/packages/medusa/src/api/routes/admin/uploads/create-upload.ts (L87-L90))
- [create-protected-upload.ts](58d23a7b45/packages/medusa/src/api/routes/admin/uploads/create-protected-upload.ts (L87-L90))
Path Parameter and Query Parameter. These will need more research and experimentation, part of CORE-931
---
Resolves CORE-853
### What
Rename all JSDoc OAS `@schema` and `$ref: #/components/schemas/` from snake_case to PascalCase, `foo_bar -> FooBar`
Extra scope: Remove `x-resourceId` from JSDoc OAS.
### Why
Classes use PascalCase as a convention but the OAS @schemas describing them were using snake_case. OAS code generators tend to use the schema name when generating typed models.
In order to avoid mismatch between source code, the OAS, and the generated client code, it is advised to align OAS @schemas formatting to the classes they represent.
Extra scope: x-resourceId is not a widely used OAS property. It's current usage in our OAS does not provide additional value. Therefore, we recommend to remove it in order to have one less item to maintain.
### How
Good old search & replace. Regex search to further make sure we didn't miss any.
The scope is limited to `@schema` definition and their usage in `$ref: #/components/schemas/`.
### Test
* Ran OAS validator.
* Ran docs build script.
Expect no visible changes to the documentation.
Resolves: CORE-852, CORE-859
* test subtotals on draft order operations
* fetch cart with subtotals when doing draft order operations
* write test for updating discounts seeing changes in totals
* formatting
* udpate test
* force taxes
* missing select
* add import
* rm force_taxes
### What
OAS: Explicitly declare type:object on schemas with properties.
### Why
While not officially required, schemas with properties should have their type explicitly declared as "object". Omitting the type translates to type: any with properties XYZ. The ambiguity can lead to issues when using code generators.
### How
Multiple regex searches to identify schemas missing type: object. Manually edit each schema. Spot check generated OAS.
### Testing
- Ran OAS validator.
- Ran docs build script
### Proof
RESOLVES CORE-847
**What**
If `total` or `subtotal` are selected then get the line item totals and assign them to the items.
I also had to remove the totals from the cart update service since they are not used and that by having them the items get the tax lines attached and since the update is performed by passing the entire cart, it is trying to insert the tax lines with the cart update
**Tests**
Add an integration tests to validate that the items includes the totals in the order and draft order
FIXES CORE-687
**What**
- Implement adding a line item to order (edit)
**How**
- _by implementing the following "flow"_
- generate a line item
- computing line item adjustments for that line item
- creating tax lines
- creating a change record
**Testing**
- **_integration tests_**
- check if line item and order item change objects are created (with correct tax lines)
- line item adjustments are generated if
- fixed discount is applied to cart
- percentage discount is applied
- **_unit tests_**
- ensure that methods from Inventory, LineItem, LineItemAdjustment etc. services are called
---
RESOLVES CORE-495
* change titles for admin apis
* adjusted titles for storefront apis
* added a note about length in contribution guidelines
* adjusted title for get customer endpoint
* wip: validate line item SC
* fix: repository type, remove relation, use sc id, check if cart has associated sc
* feat: setup tests and seeder, change entity retrieval in cart service method
* feat: remove repo usage and method, use Adrien's method from product service to check sc association, add test cases, add seeder entities, accept flag for validating sc on the endpoint
* feat: add a unit test to ensure validation method is called if flag is passed
* feat: allow `validate_sales_channels` flag in other relevant endpoints
* fix: typo
* fix: flag rename
* fix: correct FF in test suites
* fix: address PR feedback
* fix: change error message
* feat: remove query params, guard with FF, refactor
* feat: guard validation in the service
* refactor: rename validation method
* refactor: reorganise tests
* wip: cleanup test file
* wip: revert cart seeder changes use factories
* fix: remove seeder, update mocks
* fix: method name
* fix: units, validate by default
* git: resolve merge conflicts
* refactor: separate line item sales chanel units
Co-authored-by: fPolic <frane@medusajs.com>
* fix: migrate cart service to typescript
* fix: jsdoc inventory service
* fix: revert route unit test change
* fix: typo
* fix: revert integration test packages
* fix: cleanup
* fix: tests
* fix: integration tests
* fix: create props type guards
* fix: move total field to common types
