**What**
Add `POST /admin/regions`
Add `POST /admin/regions/:id`
Add `DELETE /admin/regions/:id`
All are added for v2 using API Routes and workflows.
In follow-up PRs, I will add support for passing countries in update and create.
Update: First follow-up PR is #6372
* adjusted configurations
* enhancements to tool and configurations
* change reference in docs
* fixed issue in workflows reference
* added project name
* more optimizations
* fix context error
* added a types reference
* resolved missing types
* fix reference reflection types not having children
* add an expand url parameter
* added new option to the README
* added details about new option
* ✨ feat(migrations): add metadata column to product_category table in database to store additional information about each product category
* ✨ feat(product-category.ts): add metadata field to ProductCategory model to store additional details
📝 docs(product-category.ts): add documentation for new metadata field in ProductCategory model
* ✨ feat(product-category.ts): add metadata field to ProductCategoryInput type to support additional data
* ✨ feat(ProductCategory.ts): add optional metadata field to ProductCategory model to store additional details
* ✨ feat(product-categories): add metadata field to product categories for additional information storage
📝 docs(product-categories): add documentation for new metadata field in product categories
* ✨ feat(product-categories): add 'metadata' field to default and allowed product category fields for enhanced data tracking
* ✨ feat(product-category.ts): add metadata support to product categories
🔧 refactor(product-category.ts): import setMetadata from utils to handle metadata setting in a more efficient way
* ✨ feat(models): add metadata field to AdminPostProductCategoriesCategoryReq and AdminPostProductCategoriesReq models to store additional information
* 📝 docs(api-reference): add metadata field to ProductCategory schema in both admin and store specs
🔧 fix(api-reference): make metadata field required in ProductCategory schema to ensure data consistency
* Create nine-fishes-matter.md
---------
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**what:**
**PriceList Service APIs:**
- createPriceList
- updatePriceList
- addPriceListPrices
- removePriceListRules
- setPriceListRules
- deletePriceList
- listPriceLists
- listAndCountPriceLists
**Price Calculations**
- Returns prices with price list prices
- Returns a new shape with calculated and original prices
Co-authored-by: Philip Korsholm <88927411+pKorsholm@users.noreply.github.com>
* Expose item tax total and shipping tax total in order totals
* Added changeset
* Fixes to tests
* Fixes to integration tests
* Fixes to integration tests
* Fixes to integration tests
* Change changeset to patch
**What**
- includes some type fixes in the DAL layer
- List products including their prices and filtered by the sales channel as well as q parameter and category scope and all other filters
- Assign shipping profile
- ordering
- Add missing columns in the product module
- update product module migrations
**Comment**
- In regards to the fields, we can pass whatever we want the module will only return the one that exists (default behavior), but on the other hand, that is not possible for the relations.
**question**
- To simplify usage, should we expose the fields/relations available from the module to simplify building a query for the user and be aware of what the module provides
**todo**
- Add back the support for the user to ask for fields/relations
**What**
There is actually an issue with using the `fields` query params with the way the repositories are using our custom query strategy. This pr aims to fix this issue by reworking the strategy.
What we had to do was to rework the way the selects are built for each subquery in order to follow the aliasing convention and to be taken into consideration. Alongside these changes, the join used to always select everything, this needed to be changed so that if there are any selects provided for a join, the join should not select everything and let the query select the fields that are requested.
Another notable change is that all the repositories are now using the repository util in order to centralize the customization and to have a single place to update when this kind of issue arises. This means that the eager relations when using the query builder are not necessarily taken into account. For that reason, I have removed the `shipping_option` eager option in favor of explicitly asking for the relations like we started to do it in some places.
FIXES CORE-1413
* docs: added cart conceptual guide
* changed link of idempotency key
* apply suggestions from code review
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* tiny change
* Used correct entity name representation
* small fixes in totals section
---------
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* feat(medusa): add description field to product categories
* chore: set nullable to false
* chore: added UI for description
* chore: added codegen files
## What
Replace AddressFields with actual AddressPayload schema based off the actual type used by the controllers.
## Why
AddressPayload is currently being referenced in client code. Our OAS schema should attempt to match current client usage in order to reduce friction when migrating to a OAS generated types package.
## How
* Represent AddressPayload and AddressCreatePayload in our OAS schemas.
* Replace reference to AddressFields
* Plus, fix typo in /admin/orders/ route
