Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Comparison of OCA modules bom_stock and stock_available_mrp
Re: New Odoo Product Configurator Module
Re: New Odoo Product Configurator Module
by
Eska Yazilim, Levent Karakaş
Paul, have you checked OdooMRP's product configurator addons? (sale_product_variants, sale_product_variants_types, product_variants_no_automatic_creation, product_attribute_types, product_attribute_types_views, product_attribute_views and so on) website_sale part of it doesn't exist (afaik) but it works very nice as itself. Completing missing features might be an option for you....
2016-03-16 16:08 GMT+02:00 Paul Catinean <paulcatinean@gmail.com>:
Hello,Given that the presentation was mostly functional I indeed have to setup a resource with a more technical approachUntil then to answer your question and give a bit more detail here are a few bits:So far the functionality is split between two modules:Product Configurator (handling all the backend logic and base for the updated variant approach)Website Product Configurator (Module depending on the previous adding all the website logic)The product.template and product.product did not undergo any fundamental changes. A boolean marker "config_ok" (name inspired from sale_ok, purchase_ok already present on the model) marks the extra functionalities added on top of the model.With it removed it's just the regular object unchanged in functionality or displayOnce that is set the extra notebook page and fields are then visible and the following occur:- Variants are no longer created automatically on product.template save and this basically serves as a actual template for the frontend configurator to generate new variants (We also have a backend configurator with a lot of fields_view_get and fields_get hacks that can do this from the sale.order for our customer but it's pretty old and relies too much on "black magic" but we can share that as a concept as well)- Attribute lines on the product.template have extra fields (Required, Custom, Multi) which dictate the behavior of the configurator when a user selects options.More importantly they also affect the configuration rules/restrictions later on- Configuration rules are made on the product.template object and use attribute lines set on the object (they also works without saving the template first).With them you can set restrictions for each and every attribute value.Restrictions such as "Attribute value 1 from attribute A works only if attribute value 2 or 3 from attribute B and 5 or 6 from attribute C" are picked.This is the concept of multi-dependency where a certain option depends on more than one selection from one attribute.Not just Part one works with Part 2 or 3 from attribute A- Configuration steps are grouping attribute lines in several steps with a custom view linked to them.This gives you the possibility to display each group in a different view that you can create/customize.This also takes into account the configuration rules from above e.g. If Step 2 has a attribute inside that has a dependency set on a attribute present in Step 1 then that step is not accessible and a re-direct is made to Step 1.The logic considers if all of the options have dependencies and are required etc- Attribute values also have a link towards product.template since often times a option represents another sub-product/part added on the finished product.This enables you to make computations of the final product regarding pricing and BOM's- When configuring a new variant via the interface firstly a search is made to see if another configuration with the same attributes exists and returns the found product or creates a new one and returns that otherwise- Custom value types are set on the attribute value and it can also be marked as searchable to be included in the previous search if needed.The custom values are saved on the variants themselves via one2many relationship- When building a product the final image is in some cases not enough.That is why you have the configuration images which take a configuration code and display a certain image to show the process of customization real time.We are currently working on this to make a version where we extract the images from attribute values or the linked product from the attribute values and display them in the frontend in a building block.So you can drag and drop the position of the images, resize and set z-index and they pop-up one by one in the defined position when the customer configures the product as it is build before themThere are quite a few things to cover and I digress from your initial questionLong story short, all the extra logic is applied only when the marker is set and it does not interfere with the standard behavior at all except the variant creation.At least so far, for the future it might change depending on need, possibly with other modules etcI hope this brought in a bit more insight on how the issues are handled and if there is anything else I can share that you or anyone else for that matter wants to know please send and emailKind Regards,PaulOn Wed, Mar 16, 2016 at 11:38 AM, Yajo <yajo.sk8@gmail.com> wrote:2016-03-15 10:37 GMT+01:00 Paul Catinean <paulcatinean@gmail.com>:Please checkout and share the campaign video that explains the addressed isues and features offered: https://www.indiegogo.com/projects/odoo-product-configuratorSeems a good idea. Can you give some details on implementation? Will current addons based on product.product be compatible?_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe
