From: "Bob Morley" <rmor...@emforium.com>
Jacques Le Roux wrote:
I don't think that there is anything in ProductFeature that fits and Gift
Cards are actually associations between products with
predefined prices
https://demo-trunk.ofbiz.apache.org/catalog/control/EditProductAssoc?productId=GC-001
Hey JLR -- I am replying here because I don't think this needs to be
included on the JIRA ticket.
I believe Gift Cards are modeled as a virtual product with a number of
variants. To do this there is a ProductAssoc from the virtual to the
variants to tie them together (as you have indicated).
Right
However, if you look
a little further in DemoProducts.xml in the ecommerce component, you will
see a series of ProductFeatures and how they are applied via
ProdcutFeatureAppl.
My speculation is that this is what the e-commerce site is using to populate
a dropdown list when the virtual product (GC-001) is selected for purchase.
Yes, you are right. The application type needs to be a selectable for showing
in dropdown
It is also smart enough to realize that when the feature does not have a
selected amount, it will render a textbox so the customer can choose the
amount on their gift card. (This is with having used the e-commerce site to
do this but never looking at the code).
This is because the application type is standard (ie not selectable) and the product is defined as requirinq an amount
(Product.requireAmount field) and this is checked/used by code of course (productdetail.ftl)
What I do find odd is that the ProductPrice is hanging right off the virtual
/ variants (each of them). I actually would have thought that the
ProductFeaturePrice would have been used to define the $10, $25, $50, etc
prices and since both the CLASSIC and HOLIDAY cards use those same features
they would not have to double define the pricing. AKA - you have a gift
card that has the $10 standard feature which implies the price of the card
is $10 regardless of the style, type, or whatever other features it may have
(granted some features could increase the price, say a credit card gift card
which may charge a $5.95 setup fee).
This is because the virtual/variant mechanim is building all the tree by using the possible combinations defined by Feature Category
(here "Gift Card Features")
So where this relates to the original enhancement, I was speculating that a
ProductFeature that is defined as an "AMOUNT" without a selectable amount
may have some restrictions on the boundaries of that amount. Looking at
productFeatureId 2006 specifically.
There is nothing like that in the data model, this is why it comes down to defining a new field somewhere. Deepak and Rishi tried to
avoid it. But it seems that we have plenty of ideas now...
You see, maybe this discussion would be worth to be in the Jira ;o)
Jacques
--
View this message in context:
http://n4.nabble.com/jira-Created-OFBIZ-3633-Minimum-order-quantity-tp1749165p1754400.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
