Comment from @olivermrbl:
What
We've included Multi-language support in our roadmap and will likely start scoping mid-next year.

OP
Hello, would be nice to have multi-language support. It will make it much easier to manage content for multi-language stores.

status: backlog

Multi-language support

Comment from @olivermrbl:
What
In Q1 2023, we will revisit our Product API and begin to extend its capabilities. In the first iteration, we will introduce Nested Categories (see RFC (TBA)), and later we will add support for custom fields. We are likely to start scoping the Custom Fields API in mid-Q1.

OP
I checked the admin demo and could see no way to add custom attributes for products. Did I miss something or would this need to be done via code?

Custom Fields API

What
Add a storefront component library containing implementations of the more complex customer flows e.g. checkout.

Storefront Component library

What
Introduce an API that allows for advanced reporting on merchant operations

Reporting API

What
In our efforts to support a broader range of payment providers, we will introduce a Checkout API defining the interface for payment providers that combines authorization and capture in a single step e.g. PayPal, GooglePay, ApplePay.

Checkout API

What
Improve our logging system by introducing an advanced Tracing API that works in a distributed architecture

Improve internal Tracing and Logging

What
Allow developers to build custom components for the admin system in their local project or plugins

status: completed

Extensible Admin

What
Introduce a concept Category in the products domain and allow merchants to create nested relationships
Motivation
In our continuous efforts to extend our Products API, we will introduce categories. This will allow merchants to expose more granular customer-facing search capabilities.
Technical design
RFC

Nested Categories

What
Introduce a Medusa Admin component library, that will allow plugin-builders to create components at ease.

Admin Component library

What
Support for running Medusa in a serverless environment

Serverless deployments

What
Allow merchants to manage inventory across locations and enable new customer experiences
Motivation
Merchants with multiple stock-keeping locations want to manage their inventory at each location and make it available for different sales channels and fulfillment methods. Currently, Medusa only holds a single inventory count. This forces merchants to either make heavy customizations to Medusa or use 3rd parties if they need to make fulfillments across locations or restrict inventory across locations.

Multi-warehouse API

What
Shipping Medusa Admin as a core plugin through npm to allow for versioning
Motivation
Medusa Admin is currently a separate entity from the core. More often than not, this is frustrating for our users, as they may experience issues due to a version mismatch between Medusa Admin and the core package.
Right now, if you want to avoid upgrading admin, you'll have to dig out the specific commit that is compatible with your version of Medusa. This is not ideal and generally a bad developer experience.
To address these issues, we are bringing the admin closer to the core project by deprecating the separate admin repository and moving the admin to our monorepo. This allows us to version Medusa Admin similarly to all other packages. Going forward, you'll be able to match your core Medusa version with a specific Medusa Admin version ensuring compatibility.

Admin as `npm` package

What
In our efforts to support a broader range of payment providers, we will introduce a Payment Processor API defining the interface for payment providers with a traditional authorization -> capture flow e.g. Stripe.

Payment Processor API

Migrating to Typeorm V3

Last week, Meilisearch v1.0.0 was released. As a result of changes to the way they handle primary key inference, anyone following the Medusa docs for using Meilisearch will be unable to use the Meilisearch plugin.
The problem - meilisearch

If multiple attributes ending with id are detected, Meilisearch will ask you to specify the primary key instead of choosing the first found one.

If your documents have multiple keys like id and collection_id, Meilisearch won't index them by default, because it won't choose a primary key. And it won't return an error, because it only ever returns 202 for accepting a task.
Since this applies to the Medusa seed data, a new user following the docs won't have their documents indexed, and they won't get any feedback as to why. (Yes, I spent more than the weekend figuring that out 😞 )
The problem - medusa-plugin-meilisearch
The obvious solution is to just set the primary key at the point of index creation. The problem with that is, as far I can tell, the SearchService's createIndex method isn't actually called
From what I can see, the way it works is that the first call to Meilisearch is from the updateSettings method and that's what creates the index. But since you can't set the primary key this way, the index is always created without a primary key. Which means the subsequent call to addDocuments will fail.
(Temporary) Solution
The fix for this is very easy - I just create the index and set the primary key in updateSettings
async updateSettings(indexName, settings) {
    await this.client_.createIndex(indexName, {
      primaryKey: "id",
    });
    return await this.client_.index(indexName).updateSettings(settings);
  }
This means that the call to createIndex is always made, but Meilisearch just ignores it so it's not the end of the world in the short term. Of course this does mean the primary key is hardcoded; plus there's a race condition as you have to rely on the index being created by the time addDocuments is called; so it's a hack, not really a pushable fix.
A more permanent solution would involve changing the way the SearchService module is used, and calling createIndex first. Then the user could set their own primary key in the config.
(Another thing I'd like to do is be able to set my own transformDocuments function in config)
My partner and I would happily devote some time to this, as we intend to use Meilisearch with Medusa going forward, but I thought it would be best to start this discussion first. I know Medusa is in very active development so perhaps there are already ideas floating around for the future of the search service and plugins. Looking forward to hearing people's thoughts on this. 😃

Support Meilisearch v1.0.0+

What
Introduce an EventBus abstraction allowing businesses to use any PubSub provider to power the event's infrastructure in Medusa
Motivation
With our current architecture, you are forced to have Redis as part of your stack if you want to leverage the events system in Medusa. Ideally, the events system should not be tied to a specific provider, such that if your existing infrastructure contains a PubSub provider different from Redis (e.g. RabbitMQ), you can use it to power Medusa's events system.

EventBus module

What
Allow store operators to edit orders after it has been placed by a customer
Motivation
Allow placed orders to be edited by store operators to eliminate the need for canceling orders if an order is placed that needs changes. This may happen in a few scenarios e.g.:

Stock discrepancies result in an order coming in with OOS items
Customer changes their mind after placing an order

Order Editing API

What
Leverage our OAS to generate types and ship them separately from the core
Motivation
Main motivation: Manually maintaining API clients is time-consuming and error-prone. Time that could be spent on more valuable efforts
Secondary motivation: Reduce direct imports from Medusa core package in clients and apps. These direct imports sometimes have side effects, likes pulling unnecessary dependencies into clients and apps.

Separating types from the core

What
Allow merchants to collect payments for arbitrary cases e.g. discrepancies on Orders
Motivation
With the introduction of Order Edits, we allow merchants to edit an open order. Those edits could lead to payment discrepancies. The Payment Collection API serves as a way to collect payment for such cases (and many others in the future).

Payment Collection API

What
Introduce a CacheService abstraction allowing businesses to use any cache provider to power the caching mechanism in Medusa

Cache module

What
Use Publishable Keys to determine which resources can be requested from a particular client
Motivation
Requesting products from a specific Sales Channel currency requires you to add sales_channel_id as a query param to all API calls, which is a tedious task and a bad developer experience. Publishable Keys aims to introduce more robust and scalable support for scoping resources and to allow for a better client experience by allowing a Publishable Key to be defined in a single place.

Publishable Keys API

It would be nice to have role based access control on the medusa API endpoints.
The user role could also be used to filter out admin UI components, like links, buttons, etc

Provide Role Based Access Control feature to admin API and admin dashboard UI

In our Roadmap, you'll find the following labels in use:

Started - Actively worked on. Expect to complete within two months.
Planned - Confidence in the technical design of the feature. Work will commence within two months.
Backlog - No technical design. We are doing light validation of the feature.
Completed + Feature Flagged - Feature has been released but is still guarded by a feature flag
Completed - Feature has been released

Roadmap.

Started

Planned

Completed

Backlog