Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: New Odoo Product Configurator Module
by
Pledra Netcom, Paul Catinean
Hi Levent,
Yes Pedro Manuel Baeza was the first one to point out the module series from MRP (being a active OCA member and contributor).I have also noticed them around 75-80% through the project development. I've been working on it for quite some time (starting late 6.1) and the OCA itself as well as the mrp repo appeared later.
Just to be clear the intention was never to compete with any other project (especially since it started before any others were created) nor was it to raise money or make a profit for a personal agenda.
The purpose was to fund the amount of work done that received no funding or support from anyone whatsoever which served no personal gain in order to give value to the platform and the community.
In the end the plan was always to add the modules and logic to OCA and converge with any existing users or work and knowledge at the time and in the future. In this context it would mean taking responsibility over the project and bring it to a full functioning state + new features as I was and am prepared to do.
The OCA modules have indeed a solid basis and I could never be naive enough to think I have a better approach compared to an entire community of strong developers.
While the logic does converge the website module is not present (as Pedro mentioned in the email I have received at the time of this writing) nor do the compatibility/dependency rules exist yet.But I think I saw a PR on this agenda that has been idle from last year if I'm not mistaking.Also the version I developed is working in production for a few months with the frontend version for my customer and backend for a year now with few bugs reported.
Long story short this was the main reason why the campaign was set as Fixed and not flexible.Either everyone agrees it offers value and worth investing or only a few people agree. And if there's only a few they should not suffer in any way for showing initiative and support
Also if it was not an independent development but based on OCA modules I would have presented it as a website builder addon added on top of existing work made by others
If the timing was bad or the functionality added it not considered valuable enough then I believe there is no harm done to anyone.I will consider other methods of funding or just cut my losses and learn a lesson on speed and research before investing this much in a product
Thank you for your time and attention
Respectfully,
Paul Catinean
On Wed, Mar 16, 2016 at 4:38 PM, Levent Karakas <levent@mektup.at> wrote:
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_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe
