Archives
Contributors
-
Re: black version upgrade for v14 ?
+1, I agree with #3El dom., 4 de oct. de 2020 a la(s) 23:41, Saran Limpajitkutaporn (saranl@ecosoft.co.th) escribió:+1, I agree with #3On Mon, Oct 5, 2020 at 7:12 AM Jean-Charles Drubay <jc@komit-consulting.com> wrote:+1 for #3On Sun, Oct 4, 2020 at 9:32 PM Simone Orsi <simahawk@gmail.com> wrote:+1 for #3On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
_______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Jesús Alan Ramos Rodriguez - 08:10 - 5 Oct 2020 -
[Delivery]: Scan packages instead of products in Shipping
Hi all contributors,In Odoo 13 CE, I have implemented the 3 steps delivery process.
In this process we scan products or the picking itself in order to manage quantities...
In Pack, products are packed in packages so that in Ship, operators should scan the packages and make sure everything is Ok. That is to say, at this level, operators shouldn't scan products of each package because:
1- Package is already done and Zebra labels are already printed and attached.
2- Even if 1 is not done, scanning all products again is time consuming and should be held by package scanning only. (Each package has its EAN-13)I have searched in OCA modules for a module that meets this feature but couldn't find any.
Maybe i did not look well into the modules..Does anyone have an idea ? Any lead is appreciated.
Regards.ᐧ
by bdmibra - 11:30 - 5 Oct 2020 -
Re: New PSC: Animal
Sure it wasn't pest register?I thought we did something here already for farms, but I don't think just because it involves animals it is necessarily separate or for that matter 1 repo. Each example for me is like a sub category of existing repos or areas. ConsiderZoos are analogous to prisons.Kennels to hotels/daycare/schools even.Vets to doctors/hospitals.Circuses to events.Farms, well they really are separate but encompass more than animals.Pet care is basically e-commerce.I know it might sound stupid but I'd consider first part in partner-contact repo.On Mon, 5 Oct 2020, 3:32 am Simone Orsi, <simahawk@gmail.com> wrote:Yeah, that's probably a better name :)On Sun, Oct 4, 2020, 14:52 Daniel Reis <dreis@opensourceintegrators.com> wrote:For all things animal related, it could be named OCA/zoology.--drNo dia 03/10/2020, às 19:27, Maxime Chambreuil <mchambreuil@opensourceintegrators.com> escreveu:
Hello,I need to manage a pets register in my neighborhood with information like species, races, size, color, name, photo and owner. I didn't find anything in the OCA or maybe I missed something...Is anyone interested to contribute? I think we could host modules for veterinarians, petcare businesses, zoos, circuses, farms, national parks, etc...What do you think?MAXIME CHAMBREUIL
PROJECT MANAGER/CONSULTANTO: 1.855.877.2377 EXT. 710
M: 602.427.5632
E: MChambreuil@OpenSourcelntegrators.comP.O. BOX 940, HIGLEY, AZ 85236 
_______________________________________________
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 Graeme Gellatly - 08:21 - 5 Oct 2020 -
Re: black version upgrade for v14 ?
+1, I agree with #3On Mon, Oct 5, 2020 at 7:12 AM Jean-Charles Drubay <jc@komit-consulting.com> wrote:+1 for #3On Sun, Oct 4, 2020 at 9:32 PM Simone Orsi <simahawk@gmail.com> wrote:+1 for #3On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
_______________________________________________
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 saranl - 06:40 - 5 Oct 2020 -
Re: black version upgrade for v14 ?
+1 for #3On Sun, Oct 4, 2020 at 9:32 PM Simone Orsi <simahawk@gmail.com> wrote:+1 for #3On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
_______________________________________________
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 Jean-Charles Drubay - 02:10 - 5 Oct 2020 -
Re: Snippet examples
Hi SimoneYes, I have seen it but I got a bit lost at the options. The thing is that my data is so static that it could just as well be entered by the website editor, but I'm not sure if I can do that, technically. So I think I will follow the route of the Odoo Experience presentation and render the data serverside.-Torvaldfre. 2. okt. 2020 kl. 06:57 skrev Simone Orsi <simahawk@gmail.com>:Hi,have you seen this?Cheers,On Thu, Oct 1, 2020 at 10:57 AM Torvald Baade Bringsvor <torvald@bringsvor.com> wrote:HiThis might be the wrong email list but pointers appreciated...Working on a small website project and one requirement is making a page with some airbnb properties. So I was adding the HTML from Airbnb for each one, but it is cumbersome so I wanted to make a snippet where one could edit the description and the property ID. But I have not been able to find a working description of how to create a snippet for the website builder, let alone one that has editable properties like that. An alternative to adding each property as a snippet would be to make a domain object with the info and then display that on a page, but have not come across any easy examples of web views for that either...Torvald Baade BringsvorBringsvor Consulting AS - Consulting and Odoo implementorTel (+47) 4548 2848_______________________________________________
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, Freelance in love with open source._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Torvald Bringsvor - 11:16 - 4 Oct 2020 -
Re: New PSC: Animal
Yeah, that's probably a better name :)On Sun, Oct 4, 2020, 14:52 Daniel Reis <dreis@opensourceintegrators.com> wrote:For all things animal related, it could be named OCA/zoology.--drNo dia 03/10/2020, às 19:27, Maxime Chambreuil <mchambreuil@opensourceintegrators.com> escreveu:
Hello,I need to manage a pets register in my neighborhood with information like species, races, size, color, name, photo and owner. I didn't find anything in the OCA or maybe I missed something...Is anyone interested to contribute? I think we could host modules for veterinarians, petcare businesses, zoos, circuses, farms, national parks, etc...What do you think?MAXIME CHAMBREUIL
PROJECT MANAGER/CONSULTANTO: 1.855.877.2377 EXT. 710
M: 602.427.5632
E: MChambreuil@OpenSourcelntegrators.comP.O. BOX 940, HIGLEY, AZ 85236 _______________________________________________
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 Simone Orsi - 04:31 - 4 Oct 2020 -
Re: black version upgrade for v14 ?
+1 for #3On Sun, Oct 4, 2020, 14:22 Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Simone Orsi - 04:30 - 4 Oct 2020 -
Re: black version upgrade for v14 ?
+1 for option #3----- Original message -----From: "Pedro M. Baeza (Tecnativa)" <pedro.baeza@tecnativa.com>To: Contributors <contributors@odoo-community.org>Subject: Re: black version upgrade for v14 ?Date: Sunday, October 04, 2020 16:06I also go for option 3, and the steps to migrate to v14 will keep the pre-commit step for any possible difference between 13 and 14.Regards.El dom., 4 oct. 2020 14:52, Yannick Vaucher <yannick.vaucher@camptocamp.com> escribió:As I understand you are asking about the default. 3. Seems the best option.Let's go with newer version an 14.0.13.0 branches are in different shapes depending on the activity of each PSC.And as it's hard to predict the effect of the black upgrade on branch 13.0 we shouldn't enforce it on the main branch. However, we could automate the creation of an OCA branch 13.0-black-20.8b1 to make a PR that requires the PSC approval in version 13.0 on each repo.Would that qualify to a 3b option ?YannickLe dim. 4 oct. 2020 à 14:22, Stéphane Bidoul <stephane.bidoul@acsone.eu> a écrit :Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
_______________________________________________Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe
by Yves Goldberg - 03:26 - 4 Oct 2020 -
Re: black version upgrade for v14 ?
I also go for option 3, and the steps to migrate to v14 will keep the pre-commit step for any possible difference between 13 and 14.Regards.El dom., 4 oct. 2020 14:52, Yannick Vaucher <yannick.vaucher@camptocamp.com> escribió:As I understand you are asking about the default. 3. Seems the best option.Let's go with newer version an 14.0.13.0 branches are in different shapes depending on the activity of each PSC.And as it's hard to predict the effect of the black upgrade on branch 13.0 we shouldn't enforce it on the main branch. However, we could automate the creation of an OCA branch 13.0-black-20.8b1 to make a PR that requires the PSC approval in version 13.0 on each repo.Would that qualify to a 3b option ?YannickLe dim. 4 oct. 2020 à 14:22, Stéphane Bidoul <stephane.bidoul@acsone.eu> a écrit :Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
_______________________________________________
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 Pedro M. Baeza - 03:05 - 4 Oct 2020 -
Re: black version upgrade for v14 ?
As I understand you are asking about the default. 3. Seems the best option.Let's go with newer version an 14.0.13.0 branches are in different shapes depending on the activity of each PSC.And as it's hard to predict the effect of the black upgrade on branch 13.0 we shouldn't enforce it on the main branch. However, we could automate the creation of an OCA branch 13.0-black-20.8b1 to make a PR that requires the PSC approval in version 13.0 on each repo.Would that qualify to a 3b option ?YannickLe dim. 4 oct. 2020 à 14:22, Stéphane Bidoul <stephane.bidoul@acsone.eu> a écrit :Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Yannick Payot - 02:51 - 4 Oct 2020 -
Re: New PSC: Animal
For all things animal related, it could be named OCA/zoology.--drNo dia 03/10/2020, às 19:27, Maxime Chambreuil <mchambreuil@opensourceintegrators.com> escreveu:
Hello,I need to manage a pets register in my neighborhood with information like species, races, size, color, name, photo and owner. I didn't find anything in the OCA or maybe I missed something...Is anyone interested to contribute? I think we could host modules for veterinarians, petcare businesses, zoos, circuses, farms, national parks, etc...What do you think?MAXIME CHAMBREUIL
PROJECT MANAGER/CONSULTANTO: 1.855.877.2377 EXT. 710
M: 602.427.5632
E: MChambreuil@OpenSourcelntegrators.comP.O. BOX 940, HIGLEY, AZ 85236 _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Daniel Reis - 02:51 - 4 Oct 2020 -
Re: black version upgrade for v14 ?
I vote for #3--dr
No dia 04/10/2020, às 13:42, Frederik Kramer <frederik.kramer@initos.com> escreveu:
Hi Stephané, i'd go for updating black to the new version, if we can somehow run an trial on v13 how much manual corrections would be necessary on already green PRs (i.e. option 2). If the number is high (say > 100) i'd go for option 1 (i.e. stayin on the old version of black and wait for more stability). It the number < 100 id update for v13 AND v14 (with a nice message for developers what changes for them and of course an apologies to those who have to rework PRs already green). Option 3 only adds complexity through case difference so i tend to rule that option out. Best Frederik Am Sonntag, den 04.10.2020, 12:22 +0000 schrieb Stéphane Bidoul: > Hi contributors, > > I have a question for you, before creating the 14.0 branches. (I hope > it will not degenerate into a religious war, but I want to ask > nevertheless :) > > The black code formatter we use has a new version that, among other > fixes and improvements, resolves the infamous trailing comma issue > [1]. It also does some reformatting in the docstrings. When we use > it, > it therefore applies some different code reformatting here and there. > > In the long run, using it is definitely a good thing. In the short > term I'm not so sure, hence this message. > > So I see 3 possibilities: > > 1. keep black to the same version in 13 and 14 and wait until black > hits 1.0 to upgrade > > This is the less disruptive approach right now but we need to > continue > coping with the trailing comma "bug". This postpones the moment when > we will need to decide between options 2 and 3 below (possibly > involving more branches). > > 2. upgrade black now in 13 and 14 > > We can automate that but it will have the drawback of making some > existing 13.0 green PRs unmergeable, requiring manual intervention on > them before merging. > > 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in > 13 if they want to. > > With this approach there will be some code formatting differences > between branches 13 and 14 which may make code migration slightly > more > difficult, and may create some cherry-pick conflicts in forward- and > backports. > > What are your thoughts / vote? In doubt, update > .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with > 20.8b1 and run "pre-commit run -a" to see what it does exactly. > > [Note A similar reasoning exists for prettier but it mostly impacts > javascript-heavy repos only. So there I believe it's ok to upgrade > prettier in 14 and keep it as is in 13, especially since there were > some hacks necessary to use it in 13 that we don't want to carry over > in 14] > > -sbi > > [1] > https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma > _______________________________________________ > 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
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Daniel Reis - 02:51 - 4 Oct 2020 -
Re: black version upgrade for v14 ?
Hi Stephané, i'd go for updating black to the new version, if we can somehow run an trial on v13 how much manual corrections would be necessary on already green PRs (i.e. option 2). If the number is high (say > 100) i'd go for option 1 (i.e. stayin on the old version of black and wait for more stability). It the number < 100 id update for v13 AND v14 (with a nice message for developers what changes for them and of course an apologies to those who have to rework PRs already green). Option 3 only adds complexity through case difference so i tend to rule that option out. Best Frederik Am Sonntag, den 04.10.2020, 12:22 +0000 schrieb Stéphane Bidoul: > Hi contributors, > > I have a question for you, before creating the 14.0 branches. (I hope > it will not degenerate into a religious war, but I want to ask > nevertheless :) > > The black code formatter we use has a new version that, among other > fixes and improvements, resolves the infamous trailing comma issue > [1]. It also does some reformatting in the docstrings. When we use > it, > it therefore applies some different code reformatting here and there. > > In the long run, using it is definitely a good thing. In the short > term I'm not so sure, hence this message. > > So I see 3 possibilities: > > 1. keep black to the same version in 13 and 14 and wait until black > hits 1.0 to upgrade > > This is the less disruptive approach right now but we need to > continue > coping with the trailing comma "bug". This postpones the moment when > we will need to decide between options 2 and 3 below (possibly > involving more branches). > > 2. upgrade black now in 13 and 14 > > We can automate that but it will have the drawback of making some > existing 13.0 green PRs unmergeable, requiring manual intervention on > them before merging. > > 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in > 13 if they want to. > > With this approach there will be some code formatting differences > between branches 13 and 14 which may make code migration slightly > more > difficult, and may create some cherry-pick conflicts in forward- and > backports. > > What are your thoughts / vote? In doubt, update > .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with > 20.8b1 and run "pre-commit run -a" to see what it does exactly. > > [Note A similar reasoning exists for prettier but it mostly impacts > javascript-heavy repos only. So there I believe it's ok to upgrade > prettier in 14 and keep it as is in 13, especially since there were > some hacks necessary to use it in 13 that we don't want to carry over > in 14] > > -sbi > > [1] > https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma > _______________________________________________ > 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 - 02:41 - 4 Oct 2020 -
Re: black version upgrade for v14 ?
Hi Stephane,For me option 3 will be better, right now for v 13 there are a lot of modules, which will require extra work, for v14 since the differences from v13 are low, we can spend a little bit more time for formatting.Regards,
Mihai Fekete
NextERP Romania S.R.L.
600B, Peciu Nou, Romania
E-mail: feketemihai@nexterp.ro
Telefon: 0788-749989
Website: https://nexterp.ro
-------- Original message --------
From: Stéphane Bidoul <stephane.bidoul@acsone.eu>
Date: Sun, 4 Oct 2020, 15:22
To: Contributors <contributors@odoo-community.org>
Subject: black version upgrade for v14 ?Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Mihai Fekete - 02:30 - 4 Oct 2020 -
black version upgrade for v14 ?
Hi contributors, I have a question for you, before creating the 14.0 branches. (I hope it will not degenerate into a religious war, but I want to ask nevertheless :) The black code formatter we use has a new version that, among other fixes and improvements, resolves the infamous trailing comma issue [1]. It also does some reformatting in the docstrings. When we use it, it therefore applies some different code reformatting here and there. In the long run, using it is definitely a good thing. In the short term I'm not so sure, hence this message. So I see 3 possibilities: 1. keep black to the same version in 13 and 14 and wait until black hits 1.0 to upgrade This is the less disruptive approach right now but we need to continue coping with the trailing comma "bug". This postpones the moment when we will need to decide between options 2 and 3 below (possibly involving more branches). 2. upgrade black now in 13 and 14 We can automate that but it will have the drawback of making some existing 13.0 green PRs unmergeable, requiring manual intervention on them before merging. 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in 13 if they want to. With this approach there will be some code formatting differences between branches 13 and 14 which may make code migration slightly more difficult, and may create some cherry-pick conflicts in forward- and backports. What are your thoughts / vote? In doubt, update .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with 20.8b1 and run "pre-commit run -a" to see what it does exactly. [Note A similar reasoning exists for prettier but it mostly impacts javascript-heavy repos only. So there I believe it's ok to upgrade prettier in 14 and keep it as is in 13, especially since there were some hacks necessary to use it in 13 that we don't want to carry over in 14] -sbi [1] https://black.readthedocs.io/en/stable/the_black_code_style.html?highlight=comma#the-magic-trailing-comma
by Stéphane Bidoul - 02:21 - 4 Oct 2020 -
New PSC: Animal
Hello,I need to manage a pets register in my neighborhood with information like species, races, size, color, name, photo and owner. I didn't find anything in the OCA or maybe I missed something...Is anyone interested to contribute? I think we could host modules for veterinarians, petcare businesses, zoos, circuses, farms, national parks, etc...What do you think?MAXIME CHAMBREUIL
PROJECT MANAGER/CONSULTANTO: 1.855.877.2377 EXT. 710
M: 602.427.5632
E: MChambreuil@OpenSourcelntegrators.comP.O. BOX 940, HIGLEY, AZ 85236
by Maxime Chambreuil - 08:25 - 3 Oct 2020 -
Re: [26137] Usage of Py3o templating engine in Odoo projects
Thanks Manuel, to clarify the questions at stake of my colleague a bit more precise: An ERP-System is meant to be the single source of truth. That's why we we would ideally retain all the structured data components (e.g. price, uom,...) that go into a Py3o report in the first place parsed back in the ERP-system (of course with changed content if it got changed in the Word / LibreOffice world). Actually this is what Sharepoint is trying to cover. So our questions are: Are there use cases out there that use Py3o to generate odt documents, let the user manipulate its content in a visual way and store back at least the structured part of the information "on safe" in the system and if yes where an how? For now and for us Py3o is seems to be too clumsy for that and the technical challenges to solve too vast so that we can hardly imagine that somebody ever tried to use it in such a use case, but we are definitely eager to know and would love to hear about alternatives. An no doing the entire unstructured part of a potential report document in 1..n text field in the Odoo backend isn't a really god idea either, we think. Best Frederik Am Freitag, den 02.10.2020, 12:16 +0000 schrieb Manuel Engel: > Dear contributors, > we wanted to have the ability to generate sales and invoice > documents > based on document templates in one of our Odoo projects. > For this purpose, we decided to give the template engine Py3o a try. > In > the end, we came up with some questions > we would like to ask you. > > > * Have you been able to realize a similar workflow compared to the > application Microsoft Sharepoint? If that is the case, how did you do > this? > * What means did you use the store the data Py3o needs to access > during > filling the template? > * In which way did you store an already generated generated report? > > We are looking forward to your feedback and thank you for this in > advance. > > Best regards, > Manuel > > > -- > Mit freundlichen Grüßen > > Manuel Engel > Trainee Anwendungsentwicklung > > > initOS GmbH > An der Eisenbahn 1 > 21224 Rosengarten > > Phone: +49 4105 56156-22 > Fax: +49 4105 56156-10 > > Email: manuel.engel@initos.com > Web: http://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 -- 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 - 03:26 - 2 Oct 2020 -
Re: Embed existing PDF into QWeb report
Joerg, please don't advertise in this list private things that are outside OCA unless you plan to contribute them to OCA.I'm also surprised by the paragraph in https://odoo-partner.org/ about OCA supporting the aim of such an alliance where that's not true and I can know it at first hand as I was on the OCA board at that time. Please remove it for not giving incorrect messages trying to get more support. It's correct and great that you want to launch the initiative, but don't bind it to us.Regards.El vie., 2 oct. 2020 a las 13:07, Joerg Lorenz (<jlorenz@itis.de>) escribió:Hi Peter:We have developed such module since V8 and up to V12. V14 is just beeing migrated. Sorry for this elder website,it is just reworked."PDF-attach" is an integral part of our new distribution called ITISeasy.business, among many, many other useful modules and improvements.We will launch this in a few days and you can see the free launch event at https://odoo-partner.org/ just, navigate to events.PDF-attach is very flexible, you also can use to attach many documents, and shift then up and down to re-order the sequence.You can define standard attachements like GTC (General terms and Conditions), which are always put.There is more: With the PDF-extend it also works with regular doc templates that can be prefilled or put with variables so the text is customized according to the quote data. There it plays nicely togheter with ITISeasy.docs, which is an alfresco based document managment syste,Both modules are available in English and German languageFurther details please see https://itis-odoo.de/en_US/page/pdf-extend-11Please don't hesitate to ask for a demoBest; JoeJoe LorenzIT IS AGVon: "Axel Mendoza" <aekroft@gmail.com>
An: "Contributors" <contributors@odoo-community.org>
Gesendet: Donnerstag, 1. Oktober 2020 17:42:39
Betreff: Re: Embed existing PDF into QWeb reportCheck the usage of this Odoo examplesorThe idea is to be able of generate the PDF from the Qweb report and merge it with the static PDF Pages from another file contentI think that It's simpler than the SVG wayMsc. Axel Mendoza PupoOn Thu, Oct 1, 2020 at 10:27 AM Peter Hahn <peter.hahn@initos.com> wrote:I had a look into the code to check how it’s working, but thought it’s not exactly what I’m looking for, because I had to trick around with the placement. I there is nothing obvious to try frirst out there I think I’ll try out the SVG approach first. Am 01.10.20 um 14:47 schrieb Sergio Corato: > Hi Peter, did you try report_qweb_pdf_watermark? Sergio Corato_______________________________________________
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 Pedro M. Baeza - 01:41 - 2 Oct 2020