Archives
Contributors
-
Re: New module derived from Odoo CE licensing/credits question
Hi,A couple things from what happens in practice.Firstly in this case it seems unnecessary. So it is better not to. It is always preferable not to.Secondly, the purpose of that clause in CLA is mostly 3 fold.1 it allows us to change a license to another OSI approved license without having to gain approval of all copyright holders.2 it allows us to defend the copyrights in court (in many jurisdictions including the US you must have a 100% claim to be able to take a court case).3 it gives us protection over the history of the copyright and licence (e.g. that the code isn't "stolen" from a private code base, basically that it is licensed correctly)For Odoo SA derived code, of which we have quite a bit, not just OCB, we effectively have option 1 off the table. We just notate the README as such for those modules that we cannot change license without Odoo SA approval. In practice, this is a minor concern. If Odoo SA relicenses, and the module is still current, then we can relicense to the same to be compatible. Otherwise, we might need to ask their permission, which is in their interest.For the second case, in any such action, Odoo SA is a) going to take action themselves, b) we'd have to join them in court action and it is likely to be in their interest, c) it isn't worth it.It is kind of 1 of the 2 exceptions for pragmatic purposes to the CLA. And in large part it is because in any enforcement we either don't care or our interests are aligned. The other exception is where 3rd party content is bundled, such as js libs. But again, we don't care, because we wouldn't want to defend or change license.The 3rd case doesn't matter, as Odoo SA has an upstream CLA and we can check the license.On Sat, Jul 31, 2021 at 9:37 PM Frederik Kramer <frederik.kramer@initos.com> wrote:Am Freitag, den 30.07.2021, 18:29 +0200 schrieb Radovan Skolnik: > Frederik, HI Radovan, > > it will be interesting to hear on this licensing-vise. Regarding > this: > > but they also inheretly hand over rights (that they > > don't own) to the OCA in the first place. > From my understanding you can fork/modify all you want provided you > keep the > original author and license as well and distribute such work further. yes for the LGPL that is perfectly fine. > For me > this seems like this scenario: someone (in this case S.A.) publishes > module > under LGPLv3. Someone else (in this case me) takes it, modifies its > functionality retaining original copyright as well and submits it to > be > included in some other project (OCA) with the same licensing. I fail > to see > where a problem could be in this scenario. But I am not alawyer ;-) The problem here is https://raw.githubusercontent.com/OCA/odoo-community.org/master/the-association/ICLA.pdf Section 3.b: "You own the Copyright and patent claims covering the Contribution which are required to grant the rights under Section 2." As you "own" only your contribution but the code that you contribute is, as you said 90% done elsewere and by somebody else not filling this ICLA (i.e. S.A.), this paragraph is simply not applying. Anyway as i said this is the very same problem (as Holger pointed out) with the OCB code, so i wonder how we as a community deal with that. Thats why am loudly asking for others' opinion. Disclaimer: I am no lawyer mayself either but i have dealt with these matters in my scientific carreer quite a bit. Best and have a nice weekend Frederik > > However what Holger suggested is probably much better approach. My > module > will: > 1) depend on the Odoo one > 2) only modify stuff that is different > 3) disable what is not needed from the original one > > This will provide pretty simple/dense module. > > Best regards > > Radovan > > On piatok 30. júla 2021 18:17:04 CEST Frederik Kramer wrote: > > Hi Radovan, > > i tend to agree to what Holger just said, but you hit a general > > problem > > that to me is somewhat unsolved. This is as follows: > > OCA is requiring (and checking) if contributions are made by > > contributors that have signed the ICLA / CLA. By signing these > > documents one claims that the code he or she add to he baseline is > > his > > / her own in its entirety. > > Now afaik S.A. itself (though publishing its core code in LGPLv3) > > isn't > > officially contributing to the OCA but other OCA contributors do. > > This > > means by pushing the OCB code these contributors already work in a > > grey > > zone because what they do is legally absolutely fine (i.e. > > contributing > > to LGPLed code) but they also inheretly hand over rights (that they > > don't own) to the OCA in the first place. > > I might be wrong but OCB is a special case and your contribution > > would > > be like OCB (as Holger just said) but it cannot be treated an > > ordinary > > contribution to an arbitrary OCA repo, at least if we as the > > community > > would retain the right to defend the IPR of the entire set of code > > against uncompliant use (example Flectra). > > With that having said, i kindly ask you to wait pushing the code > > until > > some other (prefierably long term contributors and members have > > added > > their interpretation of the legal case). Ususally our vice > > president > > Graeme has some nice and valuable thoughts on these matters. > > Best and have a nice weekend > > Frederik > > > > Am Freitag, den 30.07.2021, 15:56 +0000 schrieb Radovan Skolnik: > > > Holger, > > > > > > thanx for an input. I initially thought to make it in a way so > > > that > > > both modules can work side-by-side. But that is probably pretty > > > useless so your idea is actually pretty good and would make the > > > module really small. > > > > > > The code and templates I removed are for > > > product.attribute.category > > > for product.attribute to group them. I think I cannot (can I?) > > > disable the code so the additional object/table/column will be > > > there. > > > However I would like to disable the templates relating to these > > > so > > > they do not confuse the user. According to a Google search it can > > > be > > > done in this way: > > > > > > <record id="full_external_id_of_the_template" model="ir.ui.view"> > > > > > > <field name="active" eval="False"/> > > > > > > </record> > > > > > > If I uninstall my module will the active statu return to its > > > previous > > > state? Should I use anything like that or just document in the > > > readme > > > that the product.attribute.category is useless while using > > > custom.info? > > > > > > Best regards > > > > > > Radovan > > > > > > On piatok 30. júla 2021 13:47:19 CEST Holger Brunn wrote: > > > > > Would such module be acceptable for OCA? Any comments > > > > > are welcome. Best regards > > > > > > > > shouldn't be very different than backporting an Odoo SA module, > > > > > > right? > > > > > > https://github.com/OCA/odoo-community.org/blob/master/website/Contribution > > > / > > > > > > > CONTRIBUTING.rst#backporting-odoo-modules > > > > But if there's so little changes, why can't you just depend on > > > > the > > > > > > module > > > > > > > and change what's to be changed in your code? > > > > _______________________________________________ > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > > [1] > > > > Post to: mailto:contributors@odoo-community.org > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2] > > > > > > > > > > > > > > > > [1] https://odoo-community.org/groups/contributors-15 > > > > [2] https://odoo-community.org/groups?unsubscribe > > > > > > _______________________________________________ > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > Post to: mailto:contributors@odoo-community.org > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > > > -- > > Dr.-Ing. Frederik Kramer > > Geschäftsführer > > initOS GmbH > > An der Eisenbahn 1 > > 21224 Rosengarten > > Phone: +49 4105 56156-12 > > Fax: +49 4105 56156-10 > > Mobil: +49 179 3901819 > > Email: frederik.kramer@initos.com > > Web: www.initos.com > > Geschäftsführung: > > Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke > > Sitz der Gesellschaft: Rosengarten – Klecken > > Amtsgericht Tostedt, HRB 205226 > > Steuer-Nr: 15/200/53247 > > USt-IdNr.: DE815580155 > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [1] > > Post to: mailto:contributors@odoo-community.org > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2] > > > > > > > > [1] https://odoo-community.org/groups/contributors-15 > > [2] https://odoo-community.org/groups?unsubscribe > > > -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-10 Mobil: +49 179 3901819 Email: frederik.kramer@initos.com Web: www.initos.com Geschäftsführung: Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke Sitz der Gesellschaft: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 09:11 - 31 Jul 2021 -
Re: New module derived from Odoo CE licensing/credits question
Am Freitag, den 30.07.2021, 18:29 +0200 schrieb Radovan Skolnik: > Frederik, HI Radovan, > > it will be interesting to hear on this licensing-vise. Regarding > this: > > but they also inheretly hand over rights (that they > > don't own) to the OCA in the first place. > From my understanding you can fork/modify all you want provided you > keep the > original author and license as well and distribute such work further. yes for the LGPL that is perfectly fine. > For me > this seems like this scenario: someone (in this case S.A.) publishes > module > under LGPLv3. Someone else (in this case me) takes it, modifies its > functionality retaining original copyright as well and submits it to > be > included in some other project (OCA) with the same licensing. I fail > to see > where a problem could be in this scenario. But I am not alawyer ;-) The problem here is https://raw.githubusercontent.com/OCA/odoo-community.org/master/the-association/ICLA.pdf Section 3.b: "You own the Copyright and patent claims covering the Contribution which are required to grant the rights under Section 2." As you "own" only your contribution but the code that you contribute is, as you said 90% done elsewere and by somebody else not filling this ICLA (i.e. S.A.), this paragraph is simply not applying. Anyway as i said this is the very same problem (as Holger pointed out) with the OCB code, so i wonder how we as a community deal with that. Thats why am loudly asking for others' opinion. Disclaimer: I am no lawyer mayself either but i have dealt with these matters in my scientific carreer quite a bit. Best and have a nice weekend Frederik > > However what Holger suggested is probably much better approach. My > module > will: > 1) depend on the Odoo one > 2) only modify stuff that is different > 3) disable what is not needed from the original one > > This will provide pretty simple/dense module. > > Best regards > > Radovan > > On piatok 30. júla 2021 18:17:04 CEST Frederik Kramer wrote: > > Hi Radovan, > > i tend to agree to what Holger just said, but you hit a general > > problem > > that to me is somewhat unsolved. This is as follows: > > OCA is requiring (and checking) if contributions are made by > > contributors that have signed the ICLA / CLA. By signing these > > documents one claims that the code he or she add to he baseline is > > his > > / her own in its entirety. > > Now afaik S.A. itself (though publishing its core code in LGPLv3) > > isn't > > officially contributing to the OCA but other OCA contributors do. > > This > > means by pushing the OCB code these contributors already work in a > > grey > > zone because what they do is legally absolutely fine (i.e. > > contributing > > to LGPLed code) but they also inheretly hand over rights (that they > > don't own) to the OCA in the first place. > > I might be wrong but OCB is a special case and your contribution > > would > > be like OCB (as Holger just said) but it cannot be treated an > > ordinary > > contribution to an arbitrary OCA repo, at least if we as the > > community > > would retain the right to defend the IPR of the entire set of code > > against uncompliant use (example Flectra). > > With that having said, i kindly ask you to wait pushing the code > > until > > some other (prefierably long term contributors and members have > > added > > their interpretation of the legal case). Ususally our vice > > president > > Graeme has some nice and valuable thoughts on these matters. > > Best and have a nice weekend > > Frederik > > > > Am Freitag, den 30.07.2021, 15:56 +0000 schrieb Radovan Skolnik: > > > Holger, > > > > > > thanx for an input. I initially thought to make it in a way so > > > that > > > both modules can work side-by-side. But that is probably pretty > > > useless so your idea is actually pretty good and would make the > > > module really small. > > > > > > The code and templates I removed are for > > > product.attribute.category > > > for product.attribute to group them. I think I cannot (can I?) > > > disable the code so the additional object/table/column will be > > > there. > > > However I would like to disable the templates relating to these > > > so > > > they do not confuse the user. According to a Google search it can > > > be > > > done in this way: > > > > > > <record id="full_external_id_of_the_template" model="ir.ui.view"> > > > > > > <field name="active" eval="False"/> > > > > > > </record> > > > > > > If I uninstall my module will the active statu return to its > > > previous > > > state? Should I use anything like that or just document in the > > > readme > > > that the product.attribute.category is useless while using > > > custom.info? > > > > > > Best regards > > > > > > Radovan > > > > > > On piatok 30. júla 2021 13:47:19 CEST Holger Brunn wrote: > > > > > Would such module be acceptable for OCA? Any comments > > > > > are welcome. Best regards > > > > > > > > shouldn't be very different than backporting an Odoo SA module, > > > > > > right? > > > > > > https://github.com/OCA/odoo-community.org/blob/master/website/Contribution > > > / > > > > > > > CONTRIBUTING.rst#backporting-odoo-modules > > > > But if there's so little changes, why can't you just depend on > > > > the > > > > > > module > > > > > > > and change what's to be changed in your code? > > > > _______________________________________________ > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > > [1] > > > > Post to: mailto:contributors@odoo-community.org > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2] > > > > > > > > > > > > > > > > [1] https://odoo-community.org/groups/contributors-15 > > > > [2] https://odoo-community.org/groups?unsubscribe > > > > > > _______________________________________________ > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > > Post to: mailto:contributors@odoo-community.org > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > > > -- > > Dr.-Ing. Frederik Kramer > > Geschäftsführer > > initOS GmbH > > An der Eisenbahn 1 > > 21224 Rosengarten > > Phone: +49 4105 56156-12 > > Fax: +49 4105 56156-10 > > Mobil: +49 179 3901819 > > Email: frederik.kramer@initos.com > > Web: www.initos.com > > Geschäftsführung: > > Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke > > Sitz der Gesellschaft: Rosengarten – Klecken > > Amtsgericht Tostedt, HRB 205226 > > Steuer-Nr: 15/200/53247 > > USt-IdNr.: DE815580155 > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [1] > > Post to: mailto:contributors@odoo-community.org > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2] > > > > > > > > [1] https://odoo-community.org/groups/contributors-15 > > [2] https://odoo-community.org/groups?unsubscribe > > > -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-10 Mobil: +49 179 3901819 Email: frederik.kramer@initos.com Web: www.initos.com Geschäftsführung: Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke Sitz der Gesellschaft: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
by Frederik Kramer - 11:36 - 31 Jul 2021 -
Re: Looking for best approach of changing description_sale of product.template from fields.Text to fields.Html
add an init_hook that calls odoo.tools.(somewhere there in mail I think is a text2html function) on the column, and redefine it as html. Or if the module already exists increase the version number and do the same in a migration script. Rémi's point stays valid, there are places where templates or code assume text and not html, that you'll have to change to t-raw etc. -- Your partner for the hard Odoo problems https://hunki-enterprises.com
by Holger Brunn - 10:21 - 30 Jul 2021 -
Re: Looking for best approach of changing description_sale of product.template from fields.Text to fields.Html
Dear Radovan,
We changed the field to HTML for both sale ordre line and account invoice lines (on v9 then v10 then v12) for a customer. It works fine if you then use proper widget for views and templates.
However it creates a number of side effects if yoy use the functions to create automatically tasks from sale order (since it takes the first line from sol as task name or related sol on task)...
Best Regards,
Rémi CAZENAVE
SCOP Le FilamentLe July 30, 2021 12:41:45 PM UTC, Radovan Skolnik <radovan@skolnik.info> a écrit :Hello, the users require that products description is at least somewhat "rich" - i.e. allow for some formatting that would be displayed in various places like: quotations, website, ... We already have more than 5000 products. Most of the descriptions were imported, some few hundreds have been manually edited to contain some plain text pseudo formatting. For simplicity we want to keep one description that goes out of company - i.e. quotations, website, ... We are not able to edit all of them at the same time so we need to take iterative approach to this meaning for some (long) time there will be products with plain text descriptions and some already HTML formatted (I plan to ask users to edit them whenever they add them to quotation). However this brings forward another issue: what would be the best approach? Because few issues come to mind: 1) I can either force different widget in product (and other) form(s) or (I guess) it should be possible to re-define the field as HTML. 2) If I just force different widget on forms I need to modify all the web templates that use the field to use t-raw instead of t-field and there is lot of them. It's doable but if I want to keep the changes in one place (module) there would be many dependencies across many modules which I do not consider healthy. 3) I also need to take into consideration that in the process I need to treat descriptions that weren't updated yet - i.e. put <pre> around them to get at least some formatting. Should I detect that in templates or is it possible to write a getter method that would do that automatically? So I would welcome any suggestions here. Which way would you recommend to go here? Thank you very much. Best regards Radovan Skolnik
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Rémi Cazenave - 06:41 - 30 Jul 2021 -
Re: New module derived from Odoo CE licensing/credits question
Frederik, it will be interesting to hear on this licensing-vise. Regarding this: > but they also inheretly hand over rights (that they > don't own) to the OCA in the first place. From my understanding you can fork/modify all you want provided you keep the original author and license as well and distribute such work further. For me this seems like this scenario: someone (in this case S.A.) publishes module under LGPLv3. Someone else (in this case me) takes it, modifies its functionality retaining original copyright as well and submits it to be included in some other project (OCA) with the same licensing. I fail to see where a problem could be in this scenario. But I am not alawyer ;-) However what Holger suggested is probably much better approach. My module will: 1) depend on the Odoo one 2) only modify stuff that is different 3) disable what is not needed from the original one This will provide pretty simple/dense module. Best regards Radovan On piatok 30. júla 2021 18:17:04 CEST Frederik Kramer wrote: > Hi Radovan, > i tend to agree to what Holger just said, but you hit a general problem > that to me is somewhat unsolved. This is as follows: > OCA is requiring (and checking) if contributions are made by > contributors that have signed the ICLA / CLA. By signing these > documents one claims that the code he or she add to he baseline is his > / her own in its entirety. > Now afaik S.A. itself (though publishing its core code in LGPLv3) isn't > officially contributing to the OCA but other OCA contributors do. This > means by pushing the OCB code these contributors already work in a grey > zone because what they do is legally absolutely fine (i.e. contributing > to LGPLed code) but they also inheretly hand over rights (that they > don't own) to the OCA in the first place. > I might be wrong but OCB is a special case and your contribution would > be like OCB (as Holger just said) but it cannot be treated an ordinary > contribution to an arbitrary OCA repo, at least if we as the community > would retain the right to defend the IPR of the entire set of code > against uncompliant use (example Flectra). > With that having said, i kindly ask you to wait pushing the code until > some other (prefierably long term contributors and members have added > their interpretation of the legal case). Ususally our vice president > Graeme has some nice and valuable thoughts on these matters. > Best and have a nice weekend > Frederik > > Am Freitag, den 30.07.2021, 15:56 +0000 schrieb Radovan Skolnik: > > Holger, > > > > thanx for an input. I initially thought to make it in a way so that > > both modules can work side-by-side. But that is probably pretty > > useless so your idea is actually pretty good and would make the > > module really small. > > > > The code and templates I removed are for product.attribute.category > > for product.attribute to group them. I think I cannot (can I?) > > disable the code so the additional object/table/column will be there. > > However I would like to disable the templates relating to these so > > they do not confuse the user. According to a Google search it can be > > done in this way: > > > > <record id="full_external_id_of_the_template" model="ir.ui.view"> > > > > <field name="active" eval="False"/> > > > > </record> > > > > If I uninstall my module will the active statu return to its previous > > state? Should I use anything like that or just document in the readme > > that the product.attribute.category is useless while using > > custom.info? > > > > Best regards > > > > Radovan > > > > On piatok 30. júla 2021 13:47:19 CEST Holger Brunn wrote: > > > > Would such module be acceptable for OCA? Any comments > > > > are welcome. Best regards > > > > > > shouldn't be very different than backporting an Odoo SA module, > > > > right? > > > > https://github.com/OCA/odoo-community.org/blob/master/website/Contribution > > / > > > > > CONTRIBUTING.rst#backporting-odoo-modules > > > But if there's so little changes, why can't you just depend on the > > > > module > > > > > and change what's to be changed in your code? > > > _______________________________________________ > > > Mailing-List: https://odoo-community.org/groups/contributors-15 [1] > > > Post to: mailto:contributors@odoo-community.org > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2] > > > > > > > > > > > > [1] https://odoo-community.org/groups/contributors-15 > > > [2] https://odoo-community.org/groups?unsubscribe > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > Post to: mailto:contributors@odoo-community.org > > Unsubscribe: https://odoo-community.org/groups?unsubscribe > > -- > Dr.-Ing. Frederik Kramer > Geschäftsführer > initOS GmbH > An der Eisenbahn 1 > 21224 Rosengarten > Phone: +49 4105 56156-12 > Fax: +49 4105 56156-10 > Mobil: +49 179 3901819 > Email: frederik.kramer@initos.com > Web: www.initos.com > Geschäftsführung: > Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke > Sitz der Gesellschaft: Rosengarten – Klecken > Amtsgericht Tostedt, HRB 205226 > Steuer-Nr: 15/200/53247 > USt-IdNr.: DE815580155 > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [1] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2] > > > > [1] https://odoo-community.org/groups/contributors-15 > [2] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 06:31 - 30 Jul 2021 -
Re: New module derived from Odoo CE licensing/credits question
Hi Radovan, i tend to agree to what Holger just said, but you hit a general problem that to me is somewhat unsolved. This is as follows: OCA is requiring (and checking) if contributions are made by contributors that have signed the ICLA / CLA. By signing these documents one claims that the code he or she add to he baseline is his / her own in its entirety. Now afaik S.A. itself (though publishing its core code in LGPLv3) isn't officially contributing to the OCA but other OCA contributors do. This means by pushing the OCB code these contributors already work in a grey zone because what they do is legally absolutely fine (i.e. contributing to LGPLed code) but they also inheretly hand over rights (that they don't own) to the OCA in the first place. I might be wrong but OCB is a special case and your contribution would be like OCB (as Holger just said) but it cannot be treated an ordinary contribution to an arbitrary OCA repo, at least if we as the community would retain the right to defend the IPR of the entire set of code against uncompliant use (example Flectra). With that having said, i kindly ask you to wait pushing the code until some other (prefierably long term contributors and members have added their interpretation of the legal case). Ususally our vice president Graeme has some nice and valuable thoughts on these matters. Best and have a nice weekend Frederik Am Freitag, den 30.07.2021, 15:56 +0000 schrieb Radovan Skolnik: > Holger, > > thanx for an input. I initially thought to make it in a way so that > both modules can work side-by-side. But that is probably pretty > useless so your idea is actually pretty good and would make the > module really small. > > The code and templates I removed are for product.attribute.category > for product.attribute to group them. I think I cannot (can I?) > disable the code so the additional object/table/column will be there. > However I would like to disable the templates relating to these so > they do not confuse the user. According to a Google search it can be > done in this way: > > <record id="full_external_id_of_the_template" model="ir.ui.view"> > <field name="active" eval="False"/> > </record> > > If I uninstall my module will the active statu return to its previous > state? Should I use anything like that or just document in the readme > that the product.attribute.category is useless while using > custom.info? > > Best regards > > Radovan > > On piatok 30. júla 2021 13:47:19 CEST Holger Brunn wrote: > > > Would such module be acceptable for OCA? Any comments > > > are welcome. Best regards > > > > shouldn't be very different than backporting an Odoo SA module, > right? > > > https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/ > > CONTRIBUTING.rst#backporting-odoo-modules > > But if there's so little changes, why can't you just depend on the > module > > and change what's to be changed in your code? > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [1] > > Post to: mailto:contributors@odoo-community.org > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [2] > > > > > > > > [1] https://odoo-community.org/groups/contributors-15 > > [2] https://odoo-community.org/groups?unsubscribe > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-10 Mobil: +49 179 3901819 Email: frederik.kramer@initos.com Web: www.initos.com Geschäftsführung: Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke Sitz der Gesellschaft: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
by Frederik Kramer - 06:15 - 30 Jul 2021 -
Re: New module derived from Odoo CE licensing/credits question
> The code and templates I removed are for product.attribute.category for > product.attribute to group them. I think I cannot (can I?) disable the code > so the additional object/table/column will be there. However I would like > to disable the templates relating to these so they do not confuse the user. > According to a Google search it can be done in this way: you can rewrite any qweb template with inheritance before it's evaluated, so probably you can have some xpath and change the t-attributes, but > <record id="full_external_id_of_the_template" model="ir.ui.view"> > <field name="active" eval="False"/> > </record> this seems much cleaner to me if it's the intention of this module to undo something the other module does entirely. > If I uninstall my module will the active statu return to its previous state? > Should I use anything like that or just document in the readme that the > product.attribute.category is useless while using custom.info? it doesn't, but you can add an uninstall_hook to your module that sets the active flag again. -- Your partner for the hard Odoo problems https://hunki-enterprises.com
by Holger Brunn - 06:15 - 30 Jul 2021 -
Re: New set of module "Requests".
Thank you, request_flow sound awesome.Thanks for sharing ideas! :)On Fri, Jul 30, 2021, 19:22 iBees Consulting <go4site@gmail.com> wrote:If this is related to projects then below could be considered as well:project_request_flowOr more generic like:request_flow_baserequest_flow_base_exception...Another 2 cents :)On Fri, Jul 30, 2021 at 12:57 PM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:Thanks all for the suggestion. I think we will go with "request_document", for its straight meaning.May be I will land it to,- server-tools --> request_document, request_document_exception, request_document_tier_validation, etc....
and specific repo, i.e.,,- hr-expense --> request_document_hr_expense
- purchase-workflow --> request_document_purchase_request
- etc...
Is this ok?On Thu, Jul 29, 2021 at 3:07 PM Lois Rilo Antelo <lois.rilo@forgeflow.com> wrote:Hi,"request" also sounds misleading to me and overlaps with the modules Pedro pointed out, one more proposal: "solicitude".My 2 cents,El jue, 29 jul 2021 a las 9:56, Pedro M. Baeza (Tecnativa) (<pedro.baeza@tecnativa.com>) escribió:What about `request_document`?_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Lois Rilo AnteloOdoo consultant at ForgeFlow S.L._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Kitti Upariphutthiphong - 06:05 - 30 Jul 2021 -
Re: New module derived from Odoo CE licensing/credits question
Holger,
thanx for an input. I initially thought to make it in a way so that both modules can work side-by-side. But that is probably pretty useless so your idea is actually pretty good and would make the module really small.
The code and templates I removed are for product.attribute.category for product.attribute to group them. I think I cannot (can I?) disable the code so the additional object/table/column will be there. However I would like to disable the templates relating to these so they do not confuse the user. According to a Google search it can be done in this way:
<record id="full_external_id_of_the_template" model="ir.ui.view">
<field name="active" eval="False"/>
</record>If I uninstall my module will the active statu return to its previous state? Should I use anything like that or just document in the readme that the product.attribute.category is useless while using custom.info?
Best regards
Radovan
On piatok 30. júla 2021 13:47:19 CEST Holger Brunn wrote:
> > Would such module be acceptable for OCA? Any comments
> > are welcome. Best regards
>
> shouldn't be very different than backporting an Odoo SA module, right?
> https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/
> CONTRIBUTING.rst#backporting-odoo-modules
> But if there's so little changes, why can't you just depend on the module
> and change what's to be changed in your code?
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [1]
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [2]
>
>
>
> [1] https://odoo-community.org/groups/contributors-15
> [2] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 05:56 - 30 Jul 2021 -
Tests failing - related non dependent modules and bridging module.
Hello, all,
I am facing an issue which I hope someone else in the OCA has encountered and solved.
We have a module that depends on product and changes the behaviour of costing.We have another module, auto installed, which depends on that module and on sale_stock_margin
So loosely, the tree is
product|+------------------------------------------+| |sale_stock_margin extension_module_basic| |
+------------------------------------------+
|extension_module_sale_stock
In "production" everything works fine - as soon as both modules are installed, the extension module which makes them work together is installed and we are happy.
But we are using runbot, and sale_stock_margin tests are failing.
Essentially, I have finally worked out, that when it runs the tests for sale_stock_margin, it does not execute the code from extension_module_sale_stock. BUT, it does run the code from extension_module_basic when it is setting the costs (unrelated to the sale_stock_margin tests, but related to their values)
The tests work if both modules are "known" and executed, or neither.
Obviously, we don't want to make extension_module_basic dependent on sale_stock_margin - it isn't and can be run independent. And that is the purpose of the bridging module, to unify the behaviour of the two independent modules.
There is no code problem being highlighted, but we would obviously like the tests to pass.
Any help appreciated.
Richard
Richard deMeester
Senior Development Analyst
WilldooIT Pty Ltd
E: richard.demeester@willdooit.com
M: +61 403 76 76 76
P: +61 3 9135 1900
A: 10/435 Williamstown Road, Port Melbourne, Vic 3207
Making growth through technology easy
DISCLAIMER | This electronic message together with any attachments is confidential. If you are not the recipient, do not copy, disclose, or use the contents in any way. Please also advise us by e-mail that you have received this message in error and then please destroy this email and any of its attachments. WilldooIT Pty. Ltd. is not responsible for any changes made to this message and/or any attachments after sending by WilldooIT Pty. Ltd. WilldooIT Pty. Ltd. use virus scanning software but exclude all liability for virus or anything similar in this email or attachment.
by "Richard deMeester" <richard.demeester@willdooit.com> - 05:50 - 30 Jul 2021 -
Looking for best approach of changing description_sale of product.template from fields.Text to fields.Html
Hello, the users require that products description is at least somewhat "rich" - i.e. allow for some formatting that would be displayed in various places like: quotations, website, ... We already have more than 5000 products. Most of the descriptions were imported, some few hundreds have been manually edited to contain some plain text pseudo formatting. For simplicity we want to keep one description that goes out of company - i.e. quotations, website, ... We are not able to edit all of them at the same time so we need to take iterative approach to this meaning for some (long) time there will be products with plain text descriptions and some already HTML formatted (I plan to ask users to edit them whenever they add them to quotation). However this brings forward another issue: what would be the best approach? Because few issues come to mind: 1) I can either force different widget in product (and other) form(s) or (I guess) it should be possible to re-define the field as HTML. 2) If I just force different widget on forms I need to modify all the web templates that use the field to use t-raw instead of t-field and there is lot of them. It's doable but if I want to keep the changes in one place (module) there would be many dependencies across many modules which I do not consider healthy. 3) I also need to take into consideration that in the process I need to treat descriptions that weren't updated yet - i.e. put <pre> around them to get at least some formatting. Should I detect that in templates or is it possible to write a getter method that would do that automatically? So I would welcome any suggestions here. Which way would you recommend to go here? Thank you very much. Best regards Radovan Skolnik
by Radovan Skolnik - 02:41 - 30 Jul 2021 -
Re: New set of module "Requests".
If this is related to projects then below could be considered as well:project_request_flowOr more generic like:request_flow_baserequest_flow_base_exception...Another 2 cents :)On Fri, Jul 30, 2021 at 12:57 PM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:Thanks all for the suggestion. I think we will go with "request_document", for its straight meaning.May be I will land it to,
- server-tools --> request_document, request_document_exception, request_document_tier_validation, etc....
and specific repo, i.e.,,- hr-expense --> request_document_hr_expense
- purchase-workflow --> request_document_purchase_request
- etc...
Is this ok?On Thu, Jul 29, 2021 at 3:07 PM Lois Rilo Antelo <lois.rilo@forgeflow.com> wrote:Hi,"request" also sounds misleading to me and overlaps with the modules Pedro pointed out, one more proposal: "solicitude".My 2 cents,El jue, 29 jul 2021 a las 9:56, Pedro M. Baeza (Tecnativa) (<pedro.baeza@tecnativa.com>) escribió:What about `request_document`?_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Lois Rilo AnteloOdoo consultant at ForgeFlow S.L._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Syed Kamran Ali - 02:21 - 30 Jul 2021 -
Re: New set of module "Requests".
Thanks all for the suggestion. I think we will go with "request_document", for its straight meaning.May be I will land it to,
- server-tools --> request_document, request_document_exception, request_document_tier_validation, etc....
and specific repo, i.e.,,- hr-expense --> request_document_hr_expense
- purchase-workflow --> request_document_purchase_request
- etc...
Is this ok?On Thu, Jul 29, 2021 at 3:07 PM Lois Rilo Antelo <lois.rilo@forgeflow.com> wrote:Hi,"request" also sounds misleading to me and overlaps with the modules Pedro pointed out, one more proposal: "solicitude".My 2 cents,El jue, 29 jul 2021 a las 9:56, Pedro M. Baeza (Tecnativa) (<pedro.baeza@tecnativa.com>) escribió:What about `request_document`?_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Lois Rilo AnteloOdoo consultant at ForgeFlow S.L._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Kitti Upariphutthiphong - 01:56 - 30 Jul 2021 -
Re: New module derived from Odoo CE licensing/credits question
> Would such module be acceptable for OCA? Any comments > are welcome. Best regards shouldn't be very different than backporting an Odoo SA module, right? https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/ CONTRIBUTING.rst#backporting-odoo-modules But if there's so little changes, why can't you just depend on the module and change what's to be changed in your code?
by Holger Brunn - 01:46 - 30 Jul 2021 -
New module derived from Odoo CE licensing/credits question
Hello, I have modified module website_sale_comparison from Odoo CE into website_sale_custom_info_comparison to work with website_sale_custom_info (based on PR from 9.0 by Jairo Llopis - will create PR for 13.0 soon) which uses product_custom_info. The modifications are really minimal: removed some unneeded code and templates (as these are already present in custom_info), rework of method _prepare_categories_for_display of product.product to work with custom info and slight changes to template displaying the comparison table. So basically it is 90% Odoo code, 10% of modifications. Licensing-vise it should be OK as Odoo is LGPL v3. However my understanding is that original author should be kept there if this was to be included in OCA repository. Any comments on how to do this properly? I mean shoudl I just put Odoo as one of the authors or look up commits to these files in git? Would such module be acceptable for OCA? Any comments are welcome. Best regards Radovan Skolnik
by Radovan Skolnik - 01:21 - 30 Jul 2021 -
Re: Propose João Marques as PSC for several areas
Thanks, all set!On Fri, Jul 30, 2021 at 8:27 AM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:OK, done through Action > Grant portal access.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
by Simone Orsi - 08:50 - 30 Jul 2021 -
Re: Propose João Marques as PSC for several areas
OK, done through Action > Grant portal access.Regards.
by Pedro M. Baeza - 08:26 - 30 Jul 2021 -
Re: Propose João Marques as PSC for several areas
the partner yes, but not the user. I cannot select any ;)On Fri, Jul 30, 2021 at 8:12 AM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:Simone, it's already there:Regards.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
by Simone Orsi - 08:16 - 30 Jul 2021 -
Re: Propose João Marques as PSC for several areas
Simone, it's already there:Regards.
by Pedro M. Baeza - 08:11 - 30 Jul 2021 -
Re: Propose João Marques as PSC for several areas
On Thu, Jul 29, 2021 at 11:42 AM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:I can assure you that the migration of the modules has meant the learning about the proper areas, for also unraveling the changes upstream on the functions that make the modules to work properly.Regards.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
by Simone Orsi - 08:01 - 30 Jul 2021
