## 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 - 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.
### Scope
Admin routes directories SHI to V.
### 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.
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
### 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](https://github.com/medusajs/medusa/blob/58d23a7b45b6dde8bdeed0bb268139a0017f1649/packages/medusa/src/api/routes/admin/uploads/create-upload.ts#L87-L90)
- [create-protected-upload.ts](https://github.com/medusajs/medusa/blob/58d23a7b45b6dde8bdeed0bb268139a0017f1649/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
### 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
* change titles for admin apis
* adjusted titles for storefront apis
* added a note about length in contribution guidelines
* adjusted title for get customer endpoint
**What**
Wrap all actions that require the usage of an atomic phase into a transaction from the handler
**Info**
The following end points have been removed since that they rely on non existing stuff and can't be used and are not used
admin - create-order
admin - delete order metadata
admin - set region metadata
admin - remove region metadata
Fixes CORE-358
**What**
- include the default sales channel in the result of `get-store` if featureflag is set
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- Add `feature_flags` string array to store response
**Why**
- to provide conditional ui in admin corresponding to enabled features
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* api routes for user management
* add invites and roles to db
* services
* invite repo
* include user in accepting invitation
* include user role in create user
* api password reset
* delete invite
* include email in reset password token
* added metadata as dbawarecolumn
* added events for invite handling and delete functionality
* added invite model to exports
* add default value member and allow null roles
* conditional inclusion of invites in "list-users"
* integration tests for users
* helpers for user testing
* add unauthenticated routes to users
* simplifying create invite
* create users with first and last name, and dev role
* reset password endpoint
* removed token from response
* update user with firstname, lastname and role
* create invite refactor
* test password reset without email in body
* removed redundant router variable
* cleanup
* unit tests
* adjustments
* service tests
* adjustments according to api changes
* fix cart test
* cloned now works
* change name to verified token for the verified token
* add a space
* db aware columns
* fix: timestampz dbaware
* more testing
* add list-invites endpoint
* reset-password error handling
* pr issues adjusted
* fixed test
* add optional to link templates
* move invites to a new endpoint
* migrate invites to own testsuite
* adjust snapshots
* email constraint for invite
* fix integration tests
* addressing pr feedback
* unit tests for extended user api
* linting
* fix integration tests
* fix unit tests
* fix: Addresses breaking change from class-transformer
* fix orders testing
* merge "create-claim" js and ts files
* add out commented tests
* update typescript endpoints to reflect changes made for user management
* converted invites to typescript
* add exports from api endpoints
* remove old js files used for reference
* integration test
* import reflect metadata
* invite service conversion to ts
* removed unused import
* update invite service to match styleguide
* add "expires_at" and "token" to invite table
* update invite service to save tokens and validate expires_at
* fix failing tests
* fix tests after adding token and expires_at to invite
* add expiration to create
Co-authored-by: Sebastian Rindom <skrindom@gmail.com>
Co-authored-by: olivermrbl <oliver@mrbltech.com>
- All schemas have been rewritten to a relational model
- All services have been rewritten to accommodate the new data model
- Adds idempotency keys to core endpoints allowing you to retry requests with no additional side effects
- Adds staged jobs to avoid putting jobs in the queue when transactions abort
- Adds atomic transactions to all methods with access to the data layer
Co-authored-by: Oliver Windall Juhl <oliver@mrbltech.com>
Patrick
Rares Stefan
Oliver Windall Juhl
Shahed Nasser
Adrien de Peretti
Philip Korsholm
Sebastian Rindom
Zakaria El Asri
Srujan Deshpande
olivermrbl
