Feature Request: Index Field for Product Type (Master / Variant / Standalone)

[CapiauD]

Summary

Add a dedicated, indexable field that exposes the product type (Master, Variant, or Standalone) directly on the product record, so it can be used in queries, facets, and filters without needing to combine multiple expressions.

Background / Context

In the Dynamicweb backend product list, an icon is displayed indicating whether a product is a Master, a Variant, or a Standalone product. However, this information is not persisted as a single field — it is computed on-the-fly based on the presence (or absence) of ProductVariantId and related variant data.

As confirmed by Dynamicweb Partner Support, there is currently no single field available in the database or index that can be used to directly determine whether a product is a Master.

Current Workaround (and its Limitations)

To identify Master products in a query today, we need to combine multiple expressions, typically:

• ProductVariantId is empty AND
• VariantOptions is not empty

Problems with this approach

• Not reliable: When all variants of a Master are deleted, the Master no longer matches the condition and is incorrectly skipped.
• Not consistent with how the backend product list determines and displays the product type.
• Complex queries: Requires multiple expressions for what should be a single, simple filter.
• No standalone detection: Standalone products (no variants) cannot easily be distinguished from Masters whose variants have been removed.

Requested Feature

Introduce a new field (e.g. ProductType) that:

1. Is available on the product record and exposed in the index.
2. Contains a clear value indicating the type, for example:
   • Master
   • Variant
   • Standalone
3. Is queryable and facetable like any other index field.
4. Uses the same logic as the backend product list icon, so behavior is consistent across the platform.
5. Is automatically maintained by the system (no manual flag needed).

Benefits

• Reliable filtering of Master / Variant / Standalone products in queries and repositories.
• Simpler query definitions — one expression instead of multiple combined conditions.
• Consistency between backend UI and query/index behavior.
• Robust against edge cases such as Masters with no remaining variants.
• Enables cleaner implementations for product feeds, integrations, frontend filters, and reporting.

Use Cases

• Building a product feed that should only contain Master products.
• Creating a query/repository for variants only (e.g., stock overviews).
• Frontend logic that needs to behave differently for Standalone vs. Master products.
• Reporting and dashboards based on product type.