CMS UX display FinalCode and if FinalCode matches base product code in summary fields

[muskie9]

This will help a CMS user understand if a variation matches the base product.FinalCode is a field generated based on the modification settings. The second additional field for the summary would likely be a getter of some kind that compares the variation's FinalCode with its product's Code field.

[jsirish]

If I'm understanding correctly it's migrating some of this code?
https://github.com/dynamic/foxystripe/blob/master/src/Model/OptionItem.php#L124

Could probably break this up to first return final code, then use that to generate with symbol for the form field:
https://github.com/dynamic/foxystripe/blob/master/src/Model/OptionItem.php#L326

[jsirish]

Gonna need to brainstorm this a bit - now that any Page can be a product, we're not able to hardcode $this->Product() to get these values. We do have a FoxyHelper::getProuductClasses() method, maybe we can come up with a creative getParentProduct() method in the custom VariationDataExtension class that's created per project to determine which class is the parent? Perhaps formalize the getter via interface?

[muskie9]

Correct, the "Final" fields are indexed for lookups with future inventory control and are generated from those methods that previously provided a dynamic value. When a transaction gets processed in the future and inventory is on, we will be able to check the code of product classes, as well as the FinalCode of variations to find the appropriate record to decrement the available inventory total.

For getting the parent product, we may just need to state that the relation MUST be named Product for the variations to work. I think it's safe to enforce this, and Silverstripe will complain if a has_one is not set to reciprocate the has_many anyways. This should allow us to assume $this->Product() is valid, and could always to a hasMethod() check where needed before calling, throwing an error if necessary.

[jsirish]

re: 2nd paragraph - it's the scenario where any Page, or multiple Pages, can be products. We don't hard code a base product class anywhere in the suite other than silverstripe-foxy-products. I'm picturing a scenario where you have a Product, and Event, a Donation, all with Purchasable but not sharing a common ancestor class. The rest of the suite is setup for this, so we'll need to decide if we want to keep that setup with the Variation change.

I took the multi class idea from the CatalogAdmin module, I'll see how they handle it and see if anything occurs to me.

[muskie9]

Have we ever tried to go nuclear with the polymorphic approach, meaning 'Product' => DataObject::class,? There's an experimental way of doing this in the Many Many Through docs so it might be something to test out in the sandbox if we roll a couple of DO type products that aren't pages. See if we can get away with spec'ing the object at that high of level.