Global Option Groups & Option Group Collections

[dlhck]

Description

At the moment ProductOptionGroup rows are created per‑product. For large catalogs this means hundreds of structurally‑identical rows (e.g. “Size”, “Colour”, “Material” on every T‑shirt) plus duplicated ProductOption rows. Aside from bloating the DB, it makes bulk editing impossible, e.g changing the spelling of “Colour” requires editing every instance.

Benefits

• One canonical option definition → no catalog drift.
• Single update propagates instantly to every assigned product.
• Dramatically smaller product_option_group / product_option tables.
• Better DX: typical flow becomes “attach ’ClothingOptions’ collection” rather than three separate mutations.

[mickiewicz]

One step further can be done, instead of managing ProductOptionGroup globally some kind of Product Template/Type could be introduced. It can work similar to interfaces, so basically product extend some Product Type and inherit not only Product Options but also some other custom attributes that are specific for some types of products. i.e 'Fabric' attribute for Clothing, which is not a variant option but it's only relevant for cloth products

[nostva]

hi, I’ve explored this issue while building a multi-seller platform and have implemented a solution that introduces channel-specific and global ProductOption and ProductOptionGroup entities, rather than assigning them per-product. My fork is here: https://github.com/nostva/vendure

key changes:

• added a global flag to ProductOption and ProductOptionGroup
• associated both with channels for channel-specific config
• updated queries, validation, and translation loading accordingly
• introduced a new GlobalProductOption permission to manage global options

this allows flexible product configuration across channels—ideal for multi-seller or multi-channel setups.
⚠️ Note: this introduces breaking changes due to the model shift. Also changes are not yet reflected in the admin-ui.

happy to polish this into a PR if the approach aligns with vendure’s goals. Feedback welcome!

[dlhck]

@nostva amazing, thank you! Do you think there is a way without a breaking change?

[nostva]

@nostva amazing, thank you! Do you think there is a way without a breaking change?

Thanks @dlhck, There are some minor schema changes that require migrations:

• Added Channel relation to ProductOption and ProductOptionGroup
• Added a global flag to ProductOptionGroup
• Changed Product ↔ ProductOptionGroup to many-to-many

No breaking changes to existing graphql resolvers, just added new ones to support the updated model.

[dlhck]

Changed Product ↔ ProductOptionGroup to many-to-many

I think this is actually a breaking change on a database level. I think existing data might need to be manually migrated there.

[nostva]

You're right. The many-to-many change and adding Channel relations are both breaking DB changes. To handle this safely, a migration script should be implemented to populate the new join table from existing data.

Other than that, I don't see a way to support this use case while reducing the large number of ProductOptionGroup / ProductOption records that currently exist per product.