Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: New Odoo Product Configurator Module
by
Camptocamp SA, Joël Grand Guillaume
Hi,
That is not an easy one ! I mean, the work done here is good, wanting to share it within the OCA and its community is something great, thanks for that. Now it is true we always said that we'll try to avoid having more than one apps covering the same need in the OCA (to share the maintenance burden).Now we're here and nothing will change this. My personal opinion is that in an ideal world, we should finance the merging of OdooMRP team and yours. Now I also know that such a task is not easy.
What is your opinion about this Paul ? I mean, do you had a look at the OdooMRP modules ? How can they be integrated with yours ? You're the best suited persone to say wether it is possible or not.
Tryning to promote one solution over the other is not good IMO. We should discuss more about how do we converge !
My2cents,
Joël
On Fri, Mar 18, 2016 at 1:08 PM, <Pedro@pad.odoo-community.org> wrote:
Paul, another remark: attribute restriction is also implemented by us here: https://github.com/odoomrp/odoomrp-wip/pull/904 (but only as a POC).Regards.2016-03-18 12:53 GMT+01:00 Paul Catinean <paulcatinean@gmail.com>:Thank you for your input ErminRegardin POS I have not tested yet and I will have another look at migration to V9. When I tried it during V9 release one could not even define a regular product since the one2many fields were messed up.I feel it will not be difficult to migrate since I migrated the V7 version with the product_variant_multi community module to the new API, new variant standard addon along with a working database while in production.To be honest my version does not go into manufacturing much it is more a way to generate new variants with attribute restrictions.Thus it will not be changed that much by MRP updates.While the OdooMRP modules indeed generate variants from the backend they do not employ any sort of attribute restrictions. Meaning you can basically build a new variant with any of the attributes on the product.template with no restrictions, anything goes.Also it does not allow multiple selection of the same attributes or provide a method of generating variants in a interface with separate steps. While this might not seem like a big issue, choose any online configurator for a car and imagine making a variant with that myriad of options with multiple interdependencies in a single many2many/one2many widget.To me personally the biggest work in both modules revolved around these restrictions / dependencies. Whether a backend or a frontend configuration interface is used depends on the business needs but that is the core of a configurator. A interface that guides you through the process of customizing your product intuitively with no possibility of making errors. Not just a method of stopping variants from being automatically created and doing it manually.I have a example of a backend configurator done in a module for my client which as said before uses a bit of "black magic".This is the reason I did not present it from the start since in my opinion it does not meet coding or OCA standards for wide use. Also considering other alternatives for the backend but I digress:That wizard alone has over 700 lines of code. Started from the order line, you select a configurable product, and the many2one fields are dynamically generated based on the attributes set on the product.template. The domains of the fields are updated as you pick options, as well as readonly toggling both taking the attribute restrictions into consideration.For my customer the variant creation process contacts a software's API that feeds BOM and Pricing information, allows you to update if you manually wish to do so. After which you can reconfigure the product, update it and when a configuration for a product with the same attributes is made it makes a diff between the database values and API values (boms and prices in this case).This was the next module planned for OCA conversion and release since I believe quite a few manufacturers have the same method.In ending the product_configurator module handles dependencies (which is a fundamental feature), multiple selections, separate steps and images for intermediate and final configurations. It's the basis for the backend configurator you have just seen and the website configurator alikeWhile it is considered to be exactly the same as the available modules except "just" the website configurator. The main.py controller in the website module alone has 800 of lines of code.Not adding up other models, javascript etc.Also both are installable, working in production with little to no problems and doing the job.I have worked very hard on all of them to provide a solution for my customer and succeeded. And the plan was to take it a step further and change it so it would apply for everyone, as far as my customer is concerned nothing is changed and there's no added value from the previous version. Behind the curtains it's a totally different story and a large leap in my opinionKind Regards,PaulOn Thu, Mar 17, 2016 at 10:23 PM, Ermin Trevisan <trevi@twanda.com> wrote:Of course an integration/enhancement of OdooMRP would be an optimum solution. But on the other hand, many parts of OdooMRP are still 7.0, the rest is 8.0. When will/should they be ported? Especially when you think of Odoo 10.0 with a new manufacturing concept? In this light a solution like this product configurator makes a lot of sense because it provides a good solution to a badly missed feature in Odoo e-commerce. For that money it could be a good way to span a time until version 10 will have widely spread and OdooMRP has evolved accordingly. But this product configurator must absolutely cover POS also and be available in very short time also for release 9.0 Just my 2cents On 16.03.2016 15:38, Levent Karakas 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.... > -- twanda AG Ermin Trevisan Artherstrasse 19 CH-6318 Walchwil T +41 41 758 1515 M +41 79 208 7373 E trevi@twanda.com www.twanda.ch www.twanda.ch/page/restaurant_______________________________________________
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
--
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Joël Grand-Guillaume
Division ManagerBusiness Solutions
