## 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
Add missing x-codegen + fix schema naming and $ref
## Why
OAS code generator was missing information to be able to match current JS client.
## How
Ensure OAS matches JS client methods.
## 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
Store 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/store/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`
## 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`
* feat(medusa): Cleanup swap creation flow
* revert test and package
* fix unit tests
* fix swap seeder that does not include the tax lines on the return line item
---------
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
What:
Assign the default sales channel if none is provided while creating a new product.
FIXES: CORE-1114
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
This PR improves the OAS by adding `type: object` to schemas that have `properties` and no `type`. While this attribute is not required for a valid spec, omitting it opens the possibilities of non-object input. See https://stackoverflow.com/a/47390723 for a detailed description of this behavior. When generating code or schemas from an OAS with tools like takeshape.io having `type` attributes is important to get the correct behavior.
**What**
- Allows passing data on shipping methods during claim creation and updates. Defaults to an empty object.
**Testing**
- Updates a test so it also passes along shipping method data.
**What**
- Fixes wrong payload class for `POST /admin/shipping-profiles`
- Fixes wrong payload class for `POST /admin/shipping-profiles/:id`
- Fixes an issue where updating a shipping profile with products and/or shipping options would fail.
- Fixes an issue where passing `profile_id` to `ShippingOptionService.update()` would not update the shipping profile of the option.
**Testing**
- Adds new `simpleshippingProfileFactory`
- Adds new integration test suite for shipping profiles operations.
Resolves CORE-1065
What:
Products can be filtered through the API by category parameters
Why:
To filter products by category
How:
- adds 2 params in admin/store route
- updates repository to accept 2 new parameters
RESOLVES CORE-1032
RESOLVES CORE-1033
### What
Declare `x-codegen` in OAS for Admin routes - S to V.
### 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.
### What
Declare `x-codegen` in OAS for Admin routes - PRO to R.
### 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.
### What
Declare `x-codegen` in OAS for Admin routes - D to PRI.
### 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.
### 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.
### What
Declare `x-codegen` in OAS for Store routes.
### 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.
What:
- Removes the requirement to have an address id while creating a new stock location.
- Add field company to Location Address
FIXES: CORE-1018
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
What:
Admin endpoints to handle inventory items and their stock levels per location
FIXES: CORE-975
Co-authored-by: Sebastian Rindom <7554214+srindom@users.noreply.github.com>
