Attribute Sets (Product Type Templates)

Free — GPL coresize Mplanned, not built

Generated from docs/plan/core/attribute-sets/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Metadata templates that define which attributes apply to each product family (product type). Prevents every product from carrying every attribute, reduces UI clutter, and enables family-specific workflows. A sunglasses product type has {brand, lens_size, uv_protection}; a shirt product type has {brand, size, color, material}. Attribute sets make this distinction explicit in the schema.

The problem

Every product carries 40 attributes even though a camera only uses 20 and a lens uses 15. Admin product page is overwhelming. When I filter by ‘width’ (a shoe attribute), cameras show up (they don’t have width). I need product types to define which attributes are relevant for each category of product.

What it does

• Create attribute sets in admin: name, description, assigned attributes (select from all attributes)
• Assign attribute set to a product at creation time (default: ‘default’ attribute set with all attributes)
• Product detail editor shows ONLY attributes in product’s attribute set (not all 40 attributes)
• Attribute set change: when reassigning a product to a different set, offer to preserve or discard unmapped attribute values
• Attribute set assignment is inherited by product variants (all variants use parent’s attribute set)
• Admin filters refined: ‘show only width attribute’ now shows only products assigned to attribute sets that include width
• Attribute set selector in admin product form — merchant can pick set when creating product (e.g., ‘Camera’, ‘Lens’, ‘Accessory’)
• Bulk change attribute set: select 50 products, reassign to ‘Clearance’ attribute set to streamline old inventory
• Attribute set report: show which products use which sets, identify orphaned attribute sets (no products)
• Attribute set export/import: export sets as JSON to move between shops or version control

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Automatic product-type detection — that is ML/AI categorization, a separate module. Admin must manually assign sets.
• Attribute inheritance or hierarchy — this is flat sets only. Multi-level attribute hierarchies are a separate feature.
• Localized attribute set names — i18n module owns multi-language labels. Sets are stored in one language.
• Set-based pricing rules — that is catalog price rules, a separate feature. This is attributes only.
• Set-based recommendation rules — that is recommendation module. This is schema definition only.

Data model

New ATTRIBUTE_SET table (id, name, description, attributes JSON array of attribute_id). New column on PRODUCT: attribute_set_id (foreign key to ATTRIBUTE_SET). Migration required: backfill PRODUCT.attribute_set_id with default set for all existing products.

API

• POST /admin/attribute-sets (create set with name and attribute list)
• GET /admin/attribute-sets (list all sets with product count)
• PATCH /admin/attribute-sets/:id (update set name or attribute membership)
• DELETE /admin/attribute-sets/:id (delete set, warn if products use it)
• PATCH /admin/products/:id/attribute-set (reassign product to different set)
• GET /admin/attribute-sets/:id/products (list products using this set)
• POST /admin/attribute-sets/bulk-reassign (reassign multiple products to a set)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Attribute Sets page listing all sets with product count. Create/edit set modal showing selected attributes with checkboxes. Product detail page shows current attribute set with ‘Change’ button. Product editor only displays attributes in the product’s set. Bulk reassign dialog: select products, pick target set, confirm to reassign.

The seam — why this is core

Core owns attribute set schema, product-to-set assignment, and UI filtering. Core does not own rule engines that consume sets (pricing, recommendations) — those are paid modules. Core owns the interface; paid modules consume it.

Without this, every product carries every field, bloating the interface. This is the metadata layer above EAV that lets different product families have different schemas.

Dependencies

• flexible-product-attributes (must exist first)
• Product model (core, existing)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Attribute set ‘Camera’ is created with attributes {brand, megapixels, sensor_size, manual_mode, video_quality}
• Product assigned to ‘Camera’ set shows only those 5 attributes in editor, not 40
• Reassigning product from ‘Camera’ set to ‘Lens’ set: old attribute values (megapixels) are discarded if Lens set does not include that attribute
• Attribute set ‘Clearance’ with 10 attributes is bulk-assigned to 50 old products; all 50 now use Clearance set
• Attribute ‘megapixels’ is removed from ‘Camera’ set; admin is warned ‘30 products use Camera set and have megapixels values — data will be hidden’
• Export set ‘Camera’ as JSON; JSON is version-controllable and can be imported to another shop
• Filter products by ‘attribute set = Camera’; results show only products with Camera set, not Lens or Clearance
• Default attribute set exists and all existing products are backfilled to use it on migration

Risks

If reassigning sets does not warn about data loss, merchants lose attribute values (e.g., megapixels) unintentionally. Mitigate: preview which values will be discarded before confirmation. If migration does not backfill existing products to a default set, queries break. Mitigate: atomic backfill in migration, verify all products have set_id before release. If UI does not show which set a product uses, merchants get confused. Mitigate: display set name prominently in product detail, show in list view.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.