**What**
- In the latest design changes, the Switch component needs to be wrapped in a container with a label and description. It doesn't make sense to add this "variant" to `@medusajs/ui`, so I have created a local component that we can use every time the design calls for this setup, to avoid re-implementing it multiple times, and the design being inconsistent across usages.
- Updates the Product domain forms to use the component. There are other places that needs to be updated to use it, but we can tackle those in our clean up tasks. I have checked with Ludvig and this design should be used everywhere we previously had the design shown in the first image.
<img width="604" alt="image" src="https://github.com/medusajs/medusa/assets/45367945/053e40c4-fa8f-4cac-96b3-659deeb6d760">
<img width="745" alt="image" src="https://github.com/medusajs/medusa/assets/45367945/890eb28f-83ac-4fa6-968f-cc204f1acd1e">
**What**
- Paginates comboboxes
- Loads categories relation on details page.
- Fix the endpoint used by client to fetch product tags (temp until we add sdk methods)
Resolves CORE-2073
**What**
- Allows users to customize the Vite config from `admin.vite` in `medusa-config.js`
**How**
```
/** @type {import('@medusajs/types').ConfigModule} */
module.exports = {
projectConfig,
admin: {
backendUrl: "http://localhost:9000",
// the config param is our default config
vite: (config) => {
return {
define: {
__TEST__: JSON.stringify("test"), // this will now be defined as a const that can be accessed in widgets
},
};
},
},
// ...
};
```
The `vite` param is a callback that takes our default config as a param. If the user does not need to access our config they don't have to use it, as we merge their config with our own, but accessing the default config can be useful in some cases.
**What**
- Adds injection zones to the product domain.
- Fixes an issue where changing the `zone` in a widget config to another valid widget would not trigger a HMR event.
- Fixes an issue where UI Routes would not work in production.
**What**
- First part of the product creation form.
- New components:
- ChipInput - Allows users to input chips into a input field. Chips are created by hitting the `,` or `Enter / Return` keys. Deleting a chip is done by hitting `Backspace` when the cursor is next to chip, or clicking the `X` button in the chip. Used for inputting option values.
- SortableList - A sortable drag-n-drop list that allows the user to re-arrange the order of items. Used for re-arranging the ranking of variants.
- ChipGroup - New re-usable component that is used to render a group of values as Chips. This should be used for SplitView form items.
- CategoryCombobox - (WIP) Nested Combobox component for selecting multiple categories a product should be associated with.
- New hooks:
- useComboboxData - Hook for easily managing the state of comboboxes.
- useDebouncedSearch - Hook for managing debounced search queries.
**What**
- Adds `has_account` to the default fields returned by the API.
**Why**
- The field is used heavily in the admin dashboard, so it makes sense to include it out of the box.
**What**
- Adds new design
- Separates secret and publishable keys into two domains (re-uses the same code).
- Adds skeleton layout for loading state of details page.
- Adds toasts.
**What**
- Re-works how toasts work in Medusa UI. API is now built on top of `sonner` instead of `@radix-ui/react-toast`. This is a breaking change, and we will need to update the documentation once this has been merged and released (cc: @shahednasser).
- Adds an example of usage in the products list table in the new admin dashboard. As part of the coming weeks cleanup we will add toasts everywhere that they are currently missing.
CLOSES CORE-1977
**What**
- Cleans up some artifacts from the V1 -> V2 migrations.
- Removes the MedusaProvider from the root in favor of a plain QueryClient.
- Applies font styles to make the text in admin resemble designs in Figma more closely.
**What**
- Adds missing translations
- Minor cleanup
**Note**
- The domain is still missing features that are supported in V1, but are currently not available in V2. The types are also all wrong, so will need to revisit after the pricing domain is revisited, types have been added, and missing features implemented.
CLOSES CORE-1901
**What**
- Sets up the initial work for Pricing domain
- Fixes Store domain
**Todo in follow up PR**
- Translations
- Add status when creating the Price List and allow updating it
- Improve DataGrid component
- Add missing functionality once backend support is added (customer_groups, region prices and update prices)
CLOSES CORE-1931
**What**
- Updates the V2 store domain.
- Abstracts some of the API requests logic into re-usable hooks
**Note**
- Partial PR as we need to add support for setting a default currency, region and location. Currently the `q` param is missing on all V2 endpoints, so we can't use our combobox component to list these options. Will be added later when that has been fixed in core.
- The PR includes a generic hook for fetching combobox data, that I added before realising that `q` is not currently supported. But keeping it as it will be useful once support is added.
**What**
- Fixes an issue where opening a Combobox inside a modal, and then closing the modal would result in the body preserving the `pointer-events: none;` style.
**What**
- Adds form to edit variant details.
- If stock and inventory modules are installed we omit inputs for stock and inventory as they should be managed in a separate form in that case. (Still a bit unsure about this, but its what we have in the current admin)
**What**
- Adds Create draft order form
- Updates draft order details page to also display "custom" items.
**Note**
- Currently, the form is missing a way to input a discount code. Need to rethink this a bit, as the we can't implement the design in Figma.
- The current design is missing a way to select from a customers existing shipping addresses, we should add that to keep the features we have today.
- This PR uses `useInfiniteQuery` which does not work on our staging (due to duplicate dependencies as a result of building straight from the monorepo), so you will need to test locally.
**What**
- Adds the initial Timeline component.
- Not all events have been added, as it makes sense to add them with their respective RMA flows.
- Emoji picker is omitted from initial PR as it's a nice-to-have that we can add later.
**What**
- Adds draft order details page
- Adds Shipping and Billing address forms to both draft order and order pages
- Adds Email form to both draft order and order pages
- Adds transfer ownership form to draft order, order and customer pages
- Update Combobox component allowing it to work with async data (`useInfiniteQuery`)
**@medusajs/medusa**
- Include country as a default relation of draft order addresses
**What**
- Moves all current route definitions to `v1.tsx`
- Creates a new `v2.tsx` file for future V2 routes.
- Updates RouteProvider to serve V1 or V2 routes based on if `MEDUSA_V2` is set.
**How to use it**
When working on V2 domains you should set `MEDUSA_V2=true` in `/packages/admin-next/dashboard/.env`. We can't use the Feature Flag in the Medusa project since there are breaking changes in the `/admin/store` endpoint between the two versions, so it needs to be managed manually.
**For people implementing V2 domains**
To add a new route you should:
- Add the route component in `/v2-routes`
- Define which path will render it in `v2.tsx`.
I would prefer that we don't try to implement a lot of conditional code that will make the codebase unnecessarily complex. So if I was to implement the V2 login page, I would copy/past the v1 login route into `v2-routes`, make the required changes, eg. replace `useAdminLogin` with `useAdminCustomPost(...)`, instead of trying to force the current V1 Login page to work with both APIs.
There will hopefully be a lot of components/sections from each domain that is re-usable between versions. As an example if you are working on the Product details page for V2 you might want to reuse the `product-general-section.tsx` file, as it works without having to make any modifications. In that case I propose that we create a `modules/product` folder and move the component in there which we can them import into both the v1 and v2 version of the route.
**What**
- Initial work on pricing domain.
- List page
- Details page
- Partial edit form
- Fixes admin/price-lists/:id/products endpoint to allow filtering products by multiple ids.
**Note**
Pushing this now as the current design need a bit of tweaking so we display all relevant data to users. Future PR will include completed Edit moda, Create modal, Edit prices modal and Add prices modal.
**What**
- Adds list page for reservations and inventory items
- Adds new String filter type, that allows users to filter by a string, eg. "material === 'metal'"
- Adds new Number filter type, that allows users to filter by a number or numerical comparator, eg. quantity === 10 / quantity is gt 10 and lt 50.
**What**
- v1 of executions domain
**TODO in follow up PR**
I think it might be a good idea for Carlos or Adrien to go over the design with Ludvig, and make sure we are displaying what is relevant to developers, and how things should be displayed. So this PR is just the initial implementation, and does not handle displaying things like compensation steps (not part of the current design), step input (not supported by the API but part of the design), etc.
Closes CORE-1751, CORE-1755
**What**
- Adds pages for managing tax settings and tax rates for regions.
- Fixes `list` tax rates endpoint, which was missing pagination, search, order, and filters.
**Note**
The fix to the tax rate list endpoint is very rough, as I have had to reimplement most of the logic from our transformQuery middleware. This is because this endpoints does not follow normal convention for fields and expand and uses string arrays instead of strings separated by commas. Our middleware does not support this, and changing the endpoint to align with other endpoints on the expand and fields params would be a breaking change. Since this is very temporary until 2.0 I think it's okay for the time being.
CLOSES CORE-1654
**What**
- Adds the different display cards to the order details page. This does not include any of the different forms for editing various aspects of an order.
**What**
- Implements new Region domain design
- Adds new SplitView component for managing adding nested relations in FocusModals, eg. adding countries to a region.
- Adds new Combobox component for multi select fields in forms
**medusajs/ui**
- Fix styling of RadioGroup.Choicebox component
CLOSES CORE-1650, CORE-1671
**What**
- Reworks how RouteModals are setup.
**Why**
- With the current implementation it was possible to create a race-condition in the logic that handled displaying a prompt if the user tried to close a modal, while a child form was dirty. The race condition would cause a new prompt to spawn each time the user clicked the screen, making it impossible to dismiss the prompt. This only occurred in a few specific cases.
**How**
- Creates two new components: RouteFocusModal and RouteDrawer. The component shares logic for handling their own open/closed state, and now accept a form prop, that allows the modals to keep track of whether their child form is dirty. This change ensures that race conditions cannot occur, and that the prompt always only renders once when needed.
The PR for the Products section is growing quite large, so I would like to merge this PR that contains a lot of the ground work before moving onto finalizing the rest of the domain.
**Note**
Since the PR contains changes to the core, that the dashboard depends on, the staging env will not work. To preview this PR, you will need to run it locally.
## `@medusajs/medusa`
**What**
- Adds missing query params to `GET /admin/products/:id/variants`
- `options.values` has been added to the default relations of admin product endpoints.
## `medusa-react`
**What**
- Adds missing hook for `GET /admin/products/:id/variants`
## `@medusajs/dashboard`
- Adds base implementation for `DataGrid` component (formerly `BulkEditor`) (WIP)
- Adds `/products` overview page
- Adds partial `/products/create` page for creating new products (WIP - need to go over design w/ Ludvig before continuing)
- Adds `/products/:id` details page
- Adds `/products/:id/gallery` page for inspecting a products images in fullscreen.
- Adds `/products/:id/edit` page for editing the general information of a product
- Adds `/products/:id/attributes` page for editing the attributes information of a product
- Adds `/products/:id/sales-channels` page for editing which sales channels a product is available in
- Fixes a bug in `DataTable` where a table with two fixed columns would not display correctly
For the review its not important to test the DataGrid, as it is still WIP, and I need to go through some minor changes to the behaviour with Ludvig, as virtualizing it adds some constraints.
## `@medusajs/icons`
**What**
- Pulls latest icons from Figma
## TODO in next PR
- [ ] Fix the typing of POST /admin/products/:id as it is currently not possible to delete any of the nullable fields once they have been added. Be aware of this when reviewing this PR.
- [ ] Wrap up `/products/create` page
- [ ] Add `/products/:id/media` page for managing media associated with the product.
- [ ] Add `/products/id/options` for managing product options (need Ludvig to rethink this as the current API is very limited and we can implement the current design as is.)
- [ ] Add `/products/:id/variants/:id` page for editing a variant. (Possibly concat all of these into one BulkEditor page?)
**Dashboard**
- Adds different views for managing manual/custom gift cards (not associated with a product gift card).
- Cleans up several table implementations to use new DataTable component.
- Minor cleanup of translation file.
**Medusa**
- Adds missing query params for list endpoints in the following admin domains: /customers, /customer-groups, /collections, and /gift-cards.
**UI**
- Adds new sizes for Badge component.
**Note for review**
Since this PR contains updates to the translation keys, it touches a lot of files. For the review the parts that are relevant are: the /gift-cards domain of admin, the table overview of collections, customers, and customer groups. And the changes to the list endpoints in the core.
**What**
- Adds Pub. Api Key domain
**Note**
- Pagination for sales channels associated with the pubkey is not implemented correctly as it is not supported by the API. Will open a separate issue on this, and revisit the impl. once fixed.
CLOSES CORE-1656
**What**
- Adds list, detail, edit, create, add customers views to the CG domain.
**Note**
- Missing metadata in forms (coming in separate PR for entire admin)
- Missing table filters (separate PR)
CLOSES CORE-1648
**What**
- Move packages for `next` version of admin to core repo
**Other**
- Since this PR introduces packages that depend on Vite 5, it also introduces @types/node@^20. We have never had a direct dependency on the types package for Node, and as far as I can see that has resulted in us using the types from Node.js@8, as those are a dependency of one of our dependencies. With the introduction of @types/node@^20, two of our packages had TS errors because they were using the NodeJS.Timer type, which was deprecated in Node.js@14. We should add specific @types/node packages to all our packages, but I haven't done so in this PR to keep it as clean as possible.
- Q: @olivermrbl I've added the new packages to the ignore list for changeset, is this enough to prevent them from being published?
**What**
- Bumps `class-variance-authority` to new beta version - `cva@beta`.
- Updates all usages of `cva` to new API.
- Clear up the naming of types in `usePrompt`
**Why**
- A bug in how `class-variance-authority` exported its types mean that we were relying on patching the package to ensure that the correct types made it into the build of our UI package. This was important to ensure intellisense for component variants, such as `<Button size="large" />`. Previously in the UI monorepo, having the patch was enough to ensure that the correct types made it into the build, but that was not the case after we moved the design system to the core repo. The issue with types is fixed in the `@1` version of `cva` which is currently in beta. I have pinpointed the version to the current beta version to ensure stability despite the package currently being in beta.
