1. Mailing Lists
  2. Contributors
  3. Re: New Odoo Product Configurator Module

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: New Odoo Product Configurator Module

Re: New Odoo Product Configurator Module

Avatar

Re: New Odoo Product Configurator Module

by
Camptocamp SA, Joël Grand Guillaume
- 21/03/2016 09:18:24
Hi Paul,


I never doubted about your motivation or intentions. I trust you. I have no issue at all with you doing this campaign, the OCA neither. You did a great job and wants to finance the port to OCA, if we can help we will.

My only point is the one raised by some people on this list. I think as there are already some other work in there about the same topic, we'd better find a way to merge them. So my last post was about to know if that is something we can do. If we want to gather the funds from most people , they will want to be secure about the future of the work they support. So, my suggestion here would be something like:

 * Contact the OdooMRP to gather the modules that may already been published under the OCA (or under review)
 * See on your side if you can integrate your work with them
 * Estimate if you can do it with the same budget that you asked for in the funding campaign
 * If yes, change the scope and claim to everyone that this campaign finance the integration of your work with OdooMRP's one

If we get there, that's just great for everyone in here right ?

My2cents,

Joël




On Fri, Mar 18, 2016 at 4:23 PM, Paul Catinean <paulcatinean@gmail.com> wrote:
Joël,

We are on the same page on this one.I reiterate once more just for the record that at no point in time have I ever had the intention of competing with the OCA, members, modules or launching separate work under my name in the detriment of others.

Converging with existing work (if any and no matter how advanced) was always the plan from the start and I agreed with Pedro as I do with you that communication and timing could have been better on my part. It is just that work began before OCA or OdooMRP repository for that matter and finished a bit after. I also did not want to announce anything until I was convinced I could convert the module to a generic form. By the time I was done progress was already made on this repository, I noticed it late and did not study it too deeply either.

Regarding the cohesion of the modules by looking at the OdooMRP ones should not be difficult imo since the design of my module is non-invasive.It just adds extra logic on the product.template and product.product module that do not change the behavior in any way and is merely a set of instructions for the configurators accessing information about the product.

Though in order be sure give me some time to study it a bit better over the weekend and maybe even try to make a quick merge of the modules as a proof of concept.Also I'm thinking about setting up a online instance of my modules for people to try out first hand.

Regarding the campaign there's is nothing that cannot be undone, it's fixed funding meaning it will refund everything (I can do it manually too) and no harm done.Even though I've spent quite a bit of time, energy and finances in setting it up it doesn't matter now.

For all I care we can make a OCA campaign and derive from that or just go the route it started now. In the end I just want to reach my two goals:

1. Have the code, knowledge and help given to OCA to be shared with everyone

2. Cover the expenses derived from conversion of the module

The means by which it is reached is not that important to me.I am also open to other suggestions as well

Kind Regards,
Paul

On Fri, Mar 18, 2016 at 3:22 PM, Levent Karakas <levent@mektup.at> wrote:
I agree with Joel. That was exactly my point when I pointed out OdooMRP modules. We need to focus how we can get the best use of these developments. It's best to check the new configurator code before taking any action.

I appreciate all the work done here and I hope campaign goes well to cover your investment.

2016-03-18 14:53 GMT+02:00 Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com>:
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).

What I can say is: Try to share you work early, even from the beginning, to avoid such a situation.

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 Ermin

Regardin 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 alike

While 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 opinion

Kind Regards,
Paul


On 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 Manager


_______________________________________________
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 Manager
Business Solutions

+41 21 619 10 28


Reference