Contributors mailing list archives

Hi,

I'm happy to know that they can co-exists without conflicts, but we need to do better IMO. From what I understood, we need a unique way to store the "attributes" on product.template. Then people can use one method or the other to generate the variants.

What I try to avoid is:

 * Loosing such a good contribution as yours

 * Create a common base to this problematic

 * Let people choose what solution is best suited to them when it comes to the variants generation (product configurator or OdooMRP sets of module)

Personally I like that in your case you generate all possible combinations in advance. In all cases, I think that even without conflicts, it is no good to have two ways of managing those attributes.

@Perdo or @OdooMRP team: What do you say about that ?

I'm sorry, I do not have the time to spend more time on the design here. I let you manage this with the OdooMRP team. Alos, remember that not all their work are under the OCA umbrella currently, so may be you should first make the inventory of them...

Regards,

Joël

On Mon, Mar 21, 2016 at 1:38 PM, Paul Catinean <paulcatinean@gmail.com> wrote:

Hello,

Thank you for your candor Joël and the suggestions you made sound like the right approach to me.

Regarding integration with existing module I have just installed all the OdooMRP variant modules alongside the product_configurator and website_product_config. They both work in parallel with no apparent problem on initial tests.

The reason for this is because the modules have different approaches to generating variants from the same source:

- OdooMRP modules attach to models such as sale.order, mrp.production, purchase.order and provide a product.template as a base with the attributes in a separate field. When the document is confirmed the variant is generated with the selected attributes. This is the main focus of the modules from what I noticed during a quick overview, integration of attributes and variants with existing backend models.

- Product_configurator sets extra fields on the product.template (configuration restrictions, configuration steps, configuration images) and a separate module (in this case the website_product_config and the backend configurator shown in the uploaded video) generates a website form / backend wizard which creates the variant using the restrictions and the rest of the information available.

As such we have two methods of generating variants without any apparent collision. Only few fields are similar like the "required" and "custom" attributes that we should only keep in one module.

Regarding the merge, as of now except for the small bits like the fields it should not be a big deal to have them work together and can be solved fairly quick. If we are talking about merging the functionality that my modules bring with the existing design of OdooMRP is best discussed with the MRP team as you said.

In ending, so far everything seems to work together without problem and we can build up from there. It is just a matter of the approach which will determine my personal workload. Fixes, updates, reviews and knowledge transfer were all a given from day 1, I'm referring to my unaided work only.

I have to bare in mind the fact that I need to make a documentation, offer the hours of training/support offered in the perks to deliver them.

Also will try to find the time to make a online instance with both modules installed as a showcase for anyone who is curious.

I will return with more details, in the meantime your feedback is welcome.

Kind Regards,

Paul

On Mon, Mar 21, 2016 at 11:08 AM, Ermin Trevisan <trevi@twanda.com> wrote:

Right!

On 21.03.2016 09:23, Joël Grand-Guillaume wrote:
> 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

> <mailto: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

>     <mailto: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
>         <mailto: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
>             <mailto: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
>                 :
> 
>                     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:
> 
>                     https://www.youtube.com/watch?v=V1DNtAC-Qeg&feature=youtu.be
> 
>                     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
>                      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
>                         <mailto: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
>                         <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
>                     <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
>                 <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 
>             www.camptocamp.com 
> 
> 
>             _______________________________________________
>             Mailing-List: http://odoo-community.org/groups/contributors-15
>             Post to: mailto:contributors@odoo-community.org
>             <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
>         <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
>     <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
> www.camptocamp.com 
> 
> 
> _______________________________________________
> Mailing-List: http://odoo-community.org/groups/contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: http://odoo-community.org/groups?unsubscribe
> 

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

--

camptocamp

INNOVATIVE SOLUTIONS

BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume

Division Manager

Business Solutions

+41 21 619 10 28

www.camptocamp.com

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe