Archives
- By thread 1419
-
By date
- August 2019 59
- September 2019 118
- October 2019 165
- November 2019 97
- December 2019 35
- January 2020 58
- February 2020 204
- March 2020 121
- April 2020 172
- May 2020 50
- June 2020 158
- July 2020 85
- August 2020 94
- September 2020 193
- October 2020 277
- November 2020 100
- December 2020 159
- January 2021 38
- February 2021 87
- March 2021 146
- April 2021 73
- May 2021 90
- June 2021 86
- July 2021 123
- August 2021 50
- September 2021 68
- October 2021 66
- November 2021 74
- December 2021 75
- January 2022 98
- February 2022 77
- March 2022 68
- April 2022 31
- May 2022 59
- June 2022 87
- July 2022 141
- August 2022 38
- September 2022 73
- October 2022 152
- November 2022 39
- December 2022 50
- January 2023 93
- February 2023 49
- March 2023 106
- April 2023 47
- May 2023 69
- June 2023 92
- July 2023 64
- August 2023 103
- September 2023 91
- October 2023 101
- November 2023 94
- December 2023 46
- January 2024 75
- February 2024 79
- March 2024 104
- April 2024 63
- May 2024 40
- June 2024 160
- July 2024 80
- August 2024 70
- September 2024 62
- October 2024 121
- November 2024 117
- December 2024 89
- January 2025 59
- February 2025 104
- March 2025 96
- April 2025 107
- May 2025 52
- June 2025 72
- July 2025 60
- August 2025 81
- September 2025 124
- October 2025 63
- November 2025 22
Contributors
-
Re: requirements.txt: Repository Level vs Module Level
Hello Dmytro,
I feel that the best solution is to adopt pip-installed modules to your workflow.
That may need a learning curve, but it already solves all problems you describe.
I'm not the best person to get into the detail, but I'm sure there on people on this ML that can fill in.
If you prefer to go the Git way, my opinion is that you should to deploy OCA modules from their Git repos.
What I do is to have each OCA repo I need as a submodule, and then have a "link-addons" with symlinks for the modules used.
Only "link-addons" is added to the server addons path.
The requirements.txt is maintained manually - when a new "link-addons" symlink is added, is it has specific dependencies, the requirements.txt is also updated.
For requirements.txt inside modules, this is not an issue in recent Odoo versions, and external_Dependencies now supports the package name.
See https://github.com/odoo/odoo/issues/25541
I hope this is helpful
Daniel
On 11/02/2021 09:56, Dmytro Katyukha wrote:
Hi all,
As i see, usually in OCA repositories "requirements.txt" file with pip dependencies is located in the root of the repository and contains a list of all python dependencies for all addons in the repository. This way it works fine, when we clone full repository, and install all dependencies for all modules there, thus when user will try to install new module on DB, 99% that all python dependencies will be satisfied.
But, let's take for example repository partner-contact repository for Odoo 12.0 and let's try to add the module 'partner_email_check' to odoo server. For this task, i will use [odoo-helper-scripts](https://github.com/katyukha/odoo-helper-scripts) that can automatically resolve repository dependencies (including those specified by oca_dependencies.txt). So, at first i would try to fetch (clone) repository partner-contact, and in this case system will automatically fetch 42 OCA repositories following 'oca_requirements.txt', and also it will try to install python dependencies mentioned in requirements.txt. It is good for development. But installation this way on prod, may lead to a lot of unneeded modules, that polutes system with strange dependencies that are in some cases may be not installable (for example because of system dependencies).
To solve this reason, we started to use 'assembly' approach, that assumes that we have to create separate git repository with only addons needed on server. But in this case, if assembly repo created automatically, there is no way to get python requirements for module, if it is not specified in module directory. Looking for python dependencies in manifest is also not good, because there are python packages exists, that has different name for package and python module inside package.
So, may be it have sense to place requirements.txt inside module directory? Thus module's requirements will be always delivered with module, that will make easier installation of module. Also, i think this way, it will be much easier to generate setup.py files for modules, that will contain info about module's python dependencies.
Possible drawbacks may be in case, when different versions of python dep will be specified in different modules. But same is applicable for repositories.
What do you think about this?
With regards,Dmytro Katyukha_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal 



by Daniel Reis - 11:21 - 11 Feb 2021 -
Re: requirements.txt: Repository Level vs Module Level
Hi Dmytro,
You can achieve fine grained (per module) installation using pip.For OCA modules and your example: "pip install odoo12-addon-partner_email_check" should just work, as the OCA modules are available on PyPI.Dependencies on python libraries are installed automatically if they are declared in the manifest, as it is the case for that module.You can also install from git using the PEP 508 syntax for pip VCS urls: "pip install odoo12-addon-partner_email_check@git+https://github.com/OCA/partner-contact@12.0#subdirectory=setup/partner_email_check".You can find more information in this post from 2015 (time flies :) and how it is done in setuptools-odoo.> Looking for python dependencies in manifest is also not good, because there are python packages exists, that has different name for package and python module inside package.This particular problem is also resolved by setuptools-odoo (look for external dependencies override in the setuptools-odoo doc).And for Odoo >=13 you can and should declare the PyPI project name in external_dependencies in the manifest.Best regards,-sbiOn Thu, Feb 11, 2021 at 10:56 AM Dmytro Katyukha <dmytro.katyukha@gmail.com> wrote:Hi all,As i see, usually in OCA repositories "requirements.txt" file with pip dependencies is located in the root of the repository and contains a list of all python dependencies for all addons in the repository. This way it works fine, when we clone full repository, and install all dependencies for all modules there, thus when user will try to install new module on DB, 99% that all python dependencies will be satisfied.But, let's take for example repository partner-contact repository for Odoo 12.0 and let's try to add the module 'partner_email_check' to odoo server. For this task, i will use [odoo-helper-scripts](https://github.com/katyukha/odoo-helper-scripts) that can automatically resolve repository dependencies (including those specified by oca_dependencies.txt). So, at first i would try to fetch (clone) repository partner-contact, and in this case system will automatically fetch 42 OCA repositories following 'oca_requirements.txt', and also it will try to install python dependencies mentioned in requirements.txt. It is good for development. But installation this way on prod, may lead to a lot of unneeded modules, that polutes system with strange dependencies that are in some cases may be not installable (for example because of system dependencies).To solve this reason, we started to use 'assembly' approach, that assumes that we have to create separate git repository with only addons needed on server. But in this case, if assembly repo created automatically, there is no way to get python requirements for module, if it is not specified in module directory. Looking for python dependencies in manifest is also not good, because there are python packages exists, that has different name for package and python module inside package.So, may be it have sense to place requirements.txt inside module directory? Thus module's requirements will be always delivered with module, that will make easier installation of module. Also, i think this way, it will be much easier to generate setup.py files for modules, that will contain info about module's python dependencies.Possible drawbacks may be in case, when different versions of python dep will be specified in different modules. But same is applicable for repositories.What do you think about this?With regards,Dmytro Katyukha_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 11:16 - 11 Feb 2021 -
Re: requirements.txt: Repository Level vs Module Level
Hello,or... just use `pip install odoo${version}-addon-module-name` and you can forget about dependencies and about cloning over and over all the repos.Unless you want to use a local editable version, in which case you could simply do `pip install -e $repo/setup/module_name`.Extra goodie: you can pin the module version in your requirements.Hope this helps.Bests,S.On Thu, Feb 11, 2021 at 10:56 AM Dmytro Katyukha <dmytro.katyukha@gmail.com> wrote:Hi all,As i see, usually in OCA repositories "requirements.txt" file with pip dependencies is located in the root of the repository and contains a list of all python dependencies for all addons in the repository. This way it works fine, when we clone full repository, and install all dependencies for all modules there, thus when user will try to install new module on DB, 99% that all python dependencies will be satisfied.But, let's take for example repository partner-contact repository for Odoo 12.0 and let's try to add the module 'partner_email_check' to odoo server. For this task, i will use [odoo-helper-scripts](https://github.com/katyukha/odoo-helper-scripts) that can automatically resolve repository dependencies (including those specified by oca_dependencies.txt). So, at first i would try to fetch (clone) repository partner-contact, and in this case system will automatically fetch 42 OCA repositories following 'oca_requirements.txt', and also it will try to install python dependencies mentioned in requirements.txt. It is good for development. But installation this way on prod, may lead to a lot of unneeded modules, that polutes system with strange dependencies that are in some cases may be not installable (for example because of system dependencies).To solve this reason, we started to use 'assembly' approach, that assumes that we have to create separate git repository with only addons needed on server. But in this case, if assembly repo created automatically, there is no way to get python requirements for module, if it is not specified in module directory. Looking for python dependencies in manifest is also not good, because there are python packages exists, that has different name for package and python module inside package.So, may be it have sense to place requirements.txt inside module directory? Thus module's requirements will be always delivered with module, that will make easier installation of module. Also, i think this way, it will be much easier to generate setup.py files for modules, that will contain info about module's python dependencies.Possible drawbacks may be in case, when different versions of python dep will be specified in different modules. But same is applicable for repositories.What do you think about this?With regards,Dmytro Katyukha_______________________________________________
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.
by Simone Orsi - 11:16 - 11 Feb 2021 -
requirements.txt: Repository Level vs Module Level
Hi all,As i see, usually in OCA repositories "requirements.txt" file with pip dependencies is located in the root of the repository and contains a list of all python dependencies for all addons in the repository. This way it works fine, when we clone full repository, and install all dependencies for all modules there, thus when user will try to install new module on DB, 99% that all python dependencies will be satisfied.But, let's take for example repository partner-contact repository for Odoo 12.0 and let's try to add the module 'partner_email_check' to odoo server. For this task, i will use [odoo-helper-scripts](https://github.com/katyukha/odoo-helper-scripts) that can automatically resolve repository dependencies (including those specified by oca_dependencies.txt). So, at first i would try to fetch (clone) repository partner-contact, and in this case system will automatically fetch 42 OCA repositories following 'oca_requirements.txt', and also it will try to install python dependencies mentioned in requirements.txt. It is good for development. But installation this way on prod, may lead to a lot of unneeded modules, that polutes system with strange dependencies that are in some cases may be not installable (for example because of system dependencies).To solve this reason, we started to use 'assembly' approach, that assumes that we have to create separate git repository with only addons needed on server. But in this case, if assembly repo created automatically, there is no way to get python requirements for module, if it is not specified in module directory. Looking for python dependencies in manifest is also not good, because there are python packages exists, that has different name for package and python module inside package.So, may be it have sense to place requirements.txt inside module directory? Thus module's requirements will be always delivered with module, that will make easier installation of module. Also, i think this way, it will be much easier to generate setup.py files for modules, that will contain info about module's python dependencies.Possible drawbacks may be in case, when different versions of python dep will be specified in different modules. But same is applicable for repositories.What do you think about this?With regards,Dmytro Katyukha
by dmytro.katyukha - 10:56 - 11 Feb 2021 -
Any module that verify numbers, i.e., employee's citizen ID
Dear community,I have a requirement to validate hr.employee's citizen ID format in my country, but I think it would be nicer if we can just extend some base modules to be more generic.So far, I found this, https://github.com/OCA/partner-contact/tree/13.0/partner_identification, which can verify numbers but onlty to res.partner.Are the more generic base module to be used with other models yet, (or at least for hr.employee)Thank you,Kitti
by Kitti Upariphutthiphong - 06:25 - 11 Feb 2021 -
Stock valuation and property propagation on Odoo 12
Hi everyone,I need some technical help to understand if the problem comes from my production environment or if it's an Odoo bug.Starting working with stock valuation, I found that the product's `property_valuation` were not updated after changing it from the category.Technically `_compute_valuation_type` is never called when saving the category form whereas the `api.depends` decorator clearly sets `categ_id.property_valuation` as a dependency.That's a big issue because all my products stay in `manual_periodic` even if their category is set to `real_time`.@api.one@api.depends('property_valuation', 'categ_id.property_valuation')def _compute_valuation_type(self):self.valuation = self.property_valuation or self.categ_id.property_valuationCan someone try to set a breakpoint here to see if this computation function is called in its environment ?odoo/addons/stock_account/models/product.py:L48Thank you for your time.--
Yann PAPOUIN, Ingénieur R&D | DEC
by Yann Papouin - 12:40 - 11 Feb 2021 -
Re: Accelerated approval of pull requests
I'd say that rule is inspired from science, where you get three blind reviews for any research paper that you submit for publication. Here we get two transparent reviews, so the rule should be adjusted then: review 2 PRs, expect 1 PR reviewed.camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSCarlos Serra-ToroSenior Software EngineerOn Fri, 5 Feb 2021 at 14:37, Rafael Blasco <rblasco@rbnpro.com> wrote:+1
Review 3 PR and expect get reviewed 1 PR (Fayolle rules!). OCA’s traffic jump come from everyone expect reviews but don’t review.
Give fist receive later.
J
De: Holger Brunn
Enviado el: viernes, 5 de febrero de 2021 13:57
Para: Contributors <contributors@odoo-community.org>
Asunto: Re: Accelerated approval of pull requestsHi Bastian,> i am reaching out to you to request accelerated approval of two pull> requests i recently created:thank you for your efforts. As contributing as a collaborative effort, I suggestyou review some other PRs, and then politely point those PRs' authors to yourown PRs. Reviewing is work we need to share.Best regards,Holger_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Carlos Serra-Toro - 08:51 - 8 Feb 2021 -
Re: Accelerated approval of pull requests
+1
I will happy to give fist
Op 2/5/21 om 2:37 PM schreef Rafael Blasco:
+1
Review 3 PR and expect get reviewed 1 PR (Fayolle rules!). OCA’s traffic jump come from everyone expect reviews but don’t review.
Give fist receive later.
J
De: Holger Brunn
Enviado el: viernes, 5 de febrero de 2021 13:57
Para: Contributors <contributors@odoo-community.org>
Asunto: Re: Accelerated approval of pull requestsHi Bastian,> i am reaching out to you to request accelerated approval of two pull> requests i recently created:thank you for your efforts. As contributing as a collaborative effort, I suggestyou review some other PRs, and then politely point those PRs' authors to yourown PRs. Reviewing is work we need to share.Best regards,Holger_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Tom Blauwendraat - 04:46 - 5 Feb 2021 -
RE: Accelerated approval of pull requests
+1
Review 3 PR and expect get reviewed 1 PR (Fayolle rules!). OCA’s traffic jump come from everyone expect reviews but don’t review.
Give fist receive later.
J
De: Holger Brunn
Enviado el: viernes, 5 de febrero de 2021 13:57
Para: Contributors <contributors@odoo-community.org>
Asunto: Re: Accelerated approval of pull requestsHi Bastian,> i am reaching out to you to request accelerated approval of two pull> requests i recently created:thank you for your efforts. As contributing as a collaborative effort, I suggestyou review some other PRs, and then politely point those PRs' authors to yourown PRs. Reviewing is work we need to share.Best regards,Holger
by Rafael Blasco (Moduon) - 02:31 - 5 Feb 2021 -
Re: Accelerated approval of pull requests
Hi Bastian, > i am reaching out to you to request accelerated approval of two pull > requests i recently created: thank you for your efforts. As contributing as a collaborative effort, I suggest you review some other PRs, and then politely point those PRs' authors to your own PRs. Reviewing is work we need to share. Best regards, Holger -- Your partner for the hard Odoo problems https://hunki-enterprises.com
by Holger Brunn - 01:56 - 5 Feb 2021 -
Re: Accelerated approval of pull requests
Yes, this is the right direction.
I deploy from Git, but don't rely on OCA merges.
I run project specific branches where my OCA PRs are early merged, and deploy from there.
/Daniel
On 05/02/2021 12:07, Sergio Corato wrote:
Perhabs create a custom PIP server should solve the problem faster?
--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.comAv Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal 



by Daniel Reis - 01:16 - 5 Feb 2021 -
Re: Accelerated approval of pull requests
Perhabs create a custom PIP server should solve the problem faster?Il ven 5 feb 2021, 11:57 Bastian Guenther <Bastian.Guenther@ametras.com> ha scritto:Dear OCA-Maintainers,
i am reaching out to you to request accelerated approval of two pull requests i recently created:
- https://github.com/OCA/web/pull/1805
- Affected modules: web_ir_actions_close_wizard_refresh_view
- Purpose: Migration to 13.0
- https://github.com/OCA/operating-unit/pull/356/
- Affected modules: sale_stock_operating_unit, stock_account_operating_unit
- Purpose: Migration to 13.0
Both pull requests only contain simple migrations, no features were added, which need to be reviewed.
I am contacting you since it is critical for my organsation to have the resulting Wheels in Wheelhouse soon.
Many thanks in advance, you are doing a great job!Best regards,
Bastian Guenther | BI ERP Developer | AMETRAS intelligence GmbH
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sergio Corato - 01:05 - 5 Feb 2021 -
Accelerated approval of pull requests
Dear OCA-Maintainers,
i am reaching out to you to request accelerated approval of two pull requests i recently created:
- https://github.com/OCA/web/pull/1805
- Affected modules: web_ir_actions_close_wizard_refresh_view
- Purpose: Migration to 13.0
- https://github.com/OCA/operating-unit/pull/356/
- Affected modules: sale_stock_operating_unit, stock_account_operating_unit
- Purpose: Migration to 13.0
Both pull requests only contain simple migrations, no features were added, which need to be reviewed.
I am contacting you since it is critical for my organsation to have the resulting Wheels in Wheelhouse soon.
Many thanks in advance, you are doing a great job!Best regards,
Bastian Guenther | BI ERP Developer | AMETRAS intelligence GmbH
by "Bastian Guenther" <Bastian.Guenther@ametras.com> - 11:55 - 5 Feb 2021 -
Review PR, that fixes web_view_searchpanel for 12.0
Hi all,I would like to ask someone to review my PR related to the web_view_searchpanel module, that fixes incorrect behavior in case there is an extra search domain present in action.The link to PR: https://github.com/OCA/web/pull/1798My question is to decide whether it makes sense to depend on the OCA module for this functionality, or maybe it would be better to fork it and use my own version.Thanks,With regards,Dmytro Katyukha
by dmytro.katyukha - 05:51 - 4 Feb 2021 -
Re: oca/oca.recipe.odoo repository?
+1Petar Najman
Office: +381 11 328 17 18
Mobile: +381 60 625 62 62
Email: petar.najman@modoolar.com
Web: www.modoolar.comOn Thu, Feb 4, 2021 at 3:52 PM Simone Orsi <simahawk@gmail.com> wrote:+1On Thu, Feb 4, 2021 at 11:02 AM Holger Brunn <mail@hunki-enterprises.com> wrote:Hi all, I'd like to fork https://github.com/anybox/anybox.recipe.odoo which has been inactive/externally maintained (amongst others by Stefan Rijnhart and me) to a repo under the OCA umbrella, namely oca/oca.recipe.odoo. We had the discussion before in https://odoo-community.org/groups/contributors-15/contributors-27171 where the issue of branding was raised, that's why I suggest the new name. This way we also don't clash with the original on pypi etc. Please don't let this devolve into a discussion about what to use for builds/ deployment, OCA can host various alternatives in my opinion. The fork will probably happen anyways, but I prefer to have it under the OCA organization rather than some specific one just for that. Best regards, Holger Brunn -- Your partner for the hard Odoo problems https://hunki-enterprises.com
_______________________________________________
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 Petar Najman - 04:10 - 4 Feb 2021 -
Re: oca/oca.recipe.odoo repository?
+1Le jeu. 4 févr. 2021 à 15:52, Simone Orsi <simahawk@gmail.com> a écrit :+1On Thu, Feb 4, 2021 at 11:02 AM Holger Brunn <mail@hunki-enterprises.com> wrote:Hi all, I'd like to fork https://github.com/anybox/anybox.recipe.odoo which has been inactive/externally maintained (amongst others by Stefan Rijnhart and me) to a repo under the OCA umbrella, namely oca/oca.recipe.odoo. We had the discussion before in https://odoo-community.org/groups/contributors-15/contributors-27171 where the issue of branding was raised, that's why I suggest the new name. This way we also don't clash with the original on pypi etc. Please don't let this devolve into a discussion about what to use for builds/ deployment, OCA can host various alternatives in my opinion. The fork will probably happen anyways, but I prefer to have it under the OCA organization rather than some specific one just for that. Best regards, Holger Brunn -- Your partner for the hard Odoo problems https://hunki-enterprises.com
_______________________________________________
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 Denis Roussel - 04:10 - 4 Feb 2021 -
Re: oca/oca.recipe.odoo repository?
+1On Thu, Feb 4, 2021 at 11:02 AM Holger Brunn <mail@hunki-enterprises.com> wrote:Hi all, I'd like to fork https://github.com/anybox/anybox.recipe.odoo which has been inactive/externally maintained (amongst others by Stefan Rijnhart and me) to a repo under the OCA umbrella, namely oca/oca.recipe.odoo. We had the discussion before in https://odoo-community.org/groups/contributors-15/contributors-27171 where the issue of branding was raised, that's why I suggest the new name. This way we also don't clash with the original on pypi etc. Please don't let this devolve into a discussion about what to use for builds/ deployment, OCA can host various alternatives in my opinion. The fork will probably happen anyways, but I prefer to have it under the OCA organization rather than some specific one just for that. Best regards, Holger Brunn -- Your partner for the hard Odoo problems https://hunki-enterprises.com
_______________________________________________
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.
by Simone Orsi - 03:46 - 4 Feb 2021 -
Re: oca/oca.recipe.odoo repository?
+1On Thu, Feb 4, 2021 at 12:16 PM Yves Goldberg <yves@ygol.com> wrote:+1--Yves Goldberg------- Original message -----From: Pierre Verkest <pierreverkest84@gmail.com>To: Contributors <contributors@odoo-community.org>Subject: Re: oca/oca.recipe.odoo repository?Date: Thursday, February 04, 2021 12:17+1Le jeu. 4 févr. 2021 à 11:07, Stefan Rijnhart <stefan@opener.amsterdam> a écrit :On 04-02-2021 11:02, Holger Brunn wrote:Hi all, I'd like to fork https://github.com/anybox/anybox.recipe.odoo which has been inactive/externally maintained (amongst others by Stefan Rijnhart and me) to a repo under the OCA umbrella, namely oca/oca.recipe.odoo.
for the record, this is a joint initiative from Holger and meRegards,Stefan-- Opener B.V. - Business solutions driven by open source collaboration Stefan Rijnhart - Consultant/developer mail: stefan@opener.am tel: +31 (0) 6 1447 8606 web: https://opener.am
_______________________________________________Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe--Pierre_______________________________________________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-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Laurent Mignon - 03:41 - 4 Feb 2021 -
Re: oca/oca.recipe.odoo repository?
+1--Yves Goldberg------- Original message -----From: Pierre Verkest <pierreverkest84@gmail.com>To: Contributors <contributors@odoo-community.org>Subject: Re: oca/oca.recipe.odoo repository?Date: Thursday, February 04, 2021 12:17+1Le jeu. 4 févr. 2021 à 11:07, Stefan Rijnhart <stefan@opener.amsterdam> a écrit :On 04-02-2021 11:02, Holger Brunn wrote:Hi all, I'd like to fork https://github.com/anybox/anybox.recipe.odoo which has been inactive/externally maintained (amongst others by Stefan Rijnhart and me) to a repo under the OCA umbrella, namely oca/oca.recipe.odoo.
for the record, this is a joint initiative from Holger and meRegards,Stefan-- Opener B.V. - Business solutions driven by open source collaboration Stefan Rijnhart - Consultant/developer mail: stefan@opener.am tel: +31 (0) 6 1447 8606 web: https://opener.am
_______________________________________________Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe--Pierre_______________________________________________Mailing-List: https://odoo-community.org/groups/contributors-15Post to: mailto:contributors@odoo-community.orgUnsubscribe: https://odoo-community.org/groups?unsubscribe
by Yves Goldberg - 12:15 - 4 Feb 2021 -
Re: oca/oca.recipe.odoo repository?
+1Le jeu. 4 févr. 2021 à 11:07, Stefan Rijnhart <stefan@opener.amsterdam> a écrit :On 04-02-2021 11:02, Holger Brunn wrote:
Hi all, I'd like to fork https://github.com/anybox/anybox.recipe.odoo which has been inactive/externally maintained (amongst others by Stefan Rijnhart and me) to a repo under the OCA umbrella, namely oca/oca.recipe.odoo.
for the record, this is a joint initiative from Holger and me
Regards,
Stefan
-- Opener B.V. - Business solutions driven by open source collaboration Stefan Rijnhart - Consultant/developer mail: stefan@opener.am tel: +31 (0) 6 1447 8606 web: https://opener.am
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Pierre
by Pierre Verkest - 11:11 - 4 Feb 2021