Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • 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

    4 replies 4 replies

    • Re: requirements.txt: Repository Level vs Module Level
      I think that the number of extra external dependencies is so low (or null, as most of the modules only require Odoo Framework), that managing them manually in an extra requirements.txt per project according needed modules is affordable instead of entering in the IMO hell pip method. That's what we do in Tecnativa and Doodba scaffolding has such option in /odoo/custom/dependencies/pip.txt. Other option in v13+ is to scrap the external dependencies from manifests for getting the proper pip packages.

      Regards.
      by Pedro M. Baeza - 11:40 - 11 Feb 2021
    • 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.com
      Av 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,

      -sbi



      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

      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 Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.
      by Simone Orsi. - 11:16 - 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

    6 replies 6 replies

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

    Can 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:L48

    Thank you for your time.

    --
    Yann PAPOUIN, Ingénieur R&D | DEC
    by Yann Papouin - 12:40 - 11 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:

     

     

    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

    6 replies 6 replies

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



      camptocamp
      INNOVATIVE SOLUTIONS
      BY OPEN SOURCE EXPERTS

      Carlos Serra-Toro
      Senior Software Engineer
      Business Solutions



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

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

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

      1 attachments 1 attachments

      signature.asc
    • 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.com
      Av Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal


      by Daniel Reis - 01:16 - 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.


    My 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
  • oca/oca.recipe.odoo repository? 
    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
    by Holger Brunn - 11:01 - 4 Feb 2021

    1 attachments 1 attachments

    signature.asc

    14 replies 14 replies

    • Re: oca/oca.recipe.odoo repository? 
      > Could somebody with the appropriate permissions make the settings accessible

> to the maintainers (StefanRijnhart+hbrunn at the moment)?

> Currently permissions are managed via a GitHub team sync script, from the

> PSC members database. The current policy is that only PSC representatives

> and board have admin access to the repos. I'm not sure it still makes sense

> for tooling repos such as this one, but it's the way it is now. I gave you

> access, but it may only last until the team sync script kicks in again.

thanks Stéphane, I changed the bits that need changing currently, so it won't 
be super problematic if we lose access again.


> Generally, who is the address to ask about OCA github permission stuff? I

> try to avoid asking Alexandre about everything.

> I guess it's support@odoo-community.org [3] , but it will mostly end up with

> Alexandre and myself anyway ;) That's also something we'll need to work on,

> i.e. manage the bus factor for the OCA infrastructure. Cheers,

indeed, that's an important one.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
      by Holger Brunn - 11:30 - 22 Dec 2021

      1 attachments 1 attachments

      signature.asc
    • Re: oca/oca.recipe.odoo repository?
      Hi Holger,

      On Wed, Dec 22, 2021 at 10:46 AM Holger Brunn <mail@hunki-enterprises.com> wrote:
      we're busy with this currently, but don't have access to the settings tab of 
https://github.com/OCA/oca.recipe.odoo
Could somebody with the appropriate permissions make the settings accessible 
to the maintainers (StefanRijnhart+hbrunn at the moment)?

      Currently permissions are managed via a GitHub team sync script, from the PSC members database.
      The current policy is that only PSC representatives and board have admin access to the repos.
      I'm not sure it still makes sense for tooling repos such as this one, but it's the way it is now.

      I gave you access, but it may only last until the team sync script kicks in again.
       
      Generally, who is the address to ask about OCA github permission stuff? I try 
to avoid asking Alexandre about everything.

      I guess it's support@odoo-community.org, but it will mostly end up with Alexandre and myself anyway ;)
      That's also something we'll need to work on, i.e. manage the bus factor for the OCA infrastructure.

      Cheers,

      -sbi
      by Stéphane Bidoul - 11:01 - 22 Dec 2021
    • Re: oca/oca.recipe.odoo repository? 
      Hi all,

we're busy with this currently, but don't have access to the settings tab of 
https://github.com/OCA/oca.recipe.odoo
Could somebody with the appropriate permissions make the settings accessible 
to the maintainers (StefanRijnhart+hbrunn at the moment)?

Generally, who is the address to ask about OCA github permission stuff? I try 
to avoid asking Alexandre about everything.

Thanks in advance,
Holger


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
      by Holger Brunn - 10:45 - 22 Dec 2021

      1 attachments 1 attachments

      signature.asc
    • Re: oca/oca.recipe.odoo repository? 
      > I'll take care of this this week.

yay thanks! We're busy closing PRs on
https://github.com/anybox/anybox.recipe.odoo/pulls
currently, the plan is to also add py3 tests there and then move the whole 
thing to the OCA repo


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
      by Holger Brunn - 08:55 - 3 Mar 2021

      1 attachments 1 attachments

      signature.asc
    • Re: oca/oca.recipe.odoo repository? 
      I'll take care of this this week.

Alexandre

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.

> 

> 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 

> <https://odoo-community.org/groups/contributors-15>

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe 

> <https://odoo-community.org/groups?unsubscribe>

> 



-- 
Alexandre Fayolle
Senior Software Engineer
Tel : +33 4 58 48 20 30

Camptocamp France SAS
18 rue du Lac Saint André
73 370 Le Bourget-du-Lac
France

http://www.camptocamp.com
      by Alexandre Fayolle - 08:16 - 3 Mar 2021

  • Off line module or third party ?
    Hello,

    Some of my prospect need the off line possibility, would you be so kind as to inform me regarding the existing module or the best contractor ?

    Best regards

     Véronique

    Véronique Piveteau
    Helpdesk manager - Consultante
    veronique.piveteau@auguria.fr
    +33 6 81 45 58 53
    auguria.fr
    LinkedIn| Facebook| Twitter
    by "Véronique Piveteau" <veronique.piveteau@auguria.fr> - 10:51 - 1 Feb 2021

    1 replies 1 replies

  • How to test v14 upgrade scripts
    Hi all,

    we are porting to 14.0 the OCA/l10n-italy modules and developing some upgrade scripts, like this

    Our doubt: is this testable?
    In general, is it possible to test v14 upgrade scripts before OpenUpgrade is available for v14?

    Thanks!

    --
    by Lorenzo Battistini. - 10:06 - 29 Jan 2021

    4 replies 4 replies

    • Re: How to test v14 upgrade scripts 
      Il giorno ven 29 gen 2021 alle ore 11:27 Holger Brunn
<mail@hunki-enterprises.com> ha scritto:

>

> > In general, is it possible to test v14 upgrade scripts before OpenUpgrade is

>

> > available for v14?

>

> yes, you don't need OpenUpgrade for that.


We did some test using a pre-migrate script like the one linked by Lorenzo (*).
The main purpose is to change the name of the module, as well as
rename xmlids, model and tables.

Steps:

1) old_name module installation
2) add/change some data
3) checkout to commit containing new_name module, migration script and
version bumped
4) launch old_name_module update:
./odoo-bin -c etc/odoo14.cfg -d testdb -u old_name_module --stop-after-init

Output:
old_name_module: not installable, skipped

In fact pre-migrate script is not triggered.

We tried this also:
4) launch new_name_module update:
./odoo-bin -c etc/odoo14.cfg -d testdb -u new_name_module --stop-after-init

But it didn't work as well.


The only way (we have found so far) to trigger pre-migrate script is this:

1) old_name module installation
2) add/change some data
3) checkout to commit containing new_name module, migration script and
version bumped
4) execute odoo shell
    >>> from openupgradelib import openupgrade
    >>> openupgrade.update_module_names(env.cr, [('old_name_module',
'new_name_module'),], merge_modules=False,)
    >>> env.cr.commit()
5) launch new_name_module update:
./odoo-bin -c etc/odoo14.cfg -d testdb -u new_name_module --stop-after-init


Do you know a way to trigger the migration script without using odoo shell?

Thanks in advance.
S.


(*) https://github.com/OCA/l10n-italy/blob/0d65b1f7fa23facd9ef52749571a4a18a58f4045/l10n_it_vat_payability/migrations/14.0.1.0.0/pre-migrate.py
      by Sergio Zanchetta - 10:15 - 28 Apr 2021
    • Re: How to test v14 upgrade scripts 
      Il giorno ven 23 apr 2021 alle ore 15:20 Sergio Zanchetta
<primes2h@gmail.com> ha scritto:

>

> Il giorno ven 29 gen 2021 alle ore 11:27 Holger Brunn

> <mail@hunki-enterprises.com> ha scritto:

> >


> The only way (we have found so far) to trigger pre-migrate script is this:

>

> 1) old_name module installation

> 2) add/change some data

> 3) checkout to commit containing new_name module, migration script and

> version bumped

> 4) execute odoo shell

> >>> from openupgradelib import openupgrade

> >>> openupgrade.update_module_names(env.cr, [('l10n_it_codici_carica', 'l10n_it_appointment_code'),], merge_modules=False,)

Sorry, this one is obviously:

>>> openupgrade.update_module_names(env.cr, [('old_name_module', 'new_name_module'),], merge_modules=False,)
      by Sergio Zanchetta - 10:14 - 28 Apr 2021
    • Re: How to test v14 upgrade scripts 
      Il giorno ven 29 gen 2021 alle ore 11:27 Holger Brunn
<mail@hunki-enterprises.com> ha scritto:

>

> > In general, is it possible to test v14 upgrade scripts before OpenUpgrade is

>

> > available for v14?

>

> yes, you don't need OpenUpgrade for that.


We did some test using a pre-migrate script like the one linked by Lorenzo (*).
The main purpose is to change the name of the module, as well as
rename xmlids, model and tables.

Steps:

1) old_name module installation
2) add/change some data
3) checkout to commit containing new_name module, migration script and
version bumped
4) launch old_name_module update:
./odoo-bin -c etc/odoo14.cfg -d testdb -u old_name_module --stop-after-init

Output:
old_name_module: not installable, skipped

In fact pre-migrate script is not triggered.

We tried this also:
4) launch new_name_module update:
./odoo-bin -c etc/odoo14.cfg -d testdb -u new_name_module --stop-after-init

But it didn't work as well.


The only way (we have found so far) to trigger pre-migrate script is this:

1) old_name module installation
2) add/change some data
3) checkout to commit containing new_name module, migration script and
version bumped
4) execute odoo shell

>>> from openupgradelib import openupgrade

>>> openupgrade.update_module_names(env.cr, [('l10n_it_codici_carica', 'l10n_it_appointment_code'),], merge_modules=False,)

>>> env.cr.commit()
5) launch new_name_module update:
./odoo-bin -c etc/odoo14.cfg -d testdb -u new_name_module --stop-after-init


Do you know a way to trigger the migration script without using odoo shell?

Thanks in advance.
S.


(*) https://github.com/OCA/l10n-italy/blob/0d65b1f7fa23facd9ef52749571a4a18a58f4045/l10n_it_vat_payability/migrations/14.0.1.0.0/pre-migrate.py
      by Sergio Zanchetta - 10:14 - 28 Apr 2021
    • Re: How to test v14 upgrade scripts 
      > In general, is it possible to test v14 upgrade scripts before OpenUpgrade is

> available for v14?

yes, you don't need OpenUpgrade for that.

We lack a good mechanism to test migration scripts, I'm also not sure how I 
would implement such a thing in general. The specific script looks a bit 
pointless to test to me, but you could mock the openupgradelib calls and call 
the function if you're into coverage.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
      by Holger Brunn - 11:25 - 29 Jan 2021

      1 attachments 1 attachments

      signature.asc
  • Odoo2Odoo

    Dear Community

    According to https://odoo-community.org/groups/contributors-15/contributors-153784?mode=thread&date_begin=&date_end=

    and

    https://odoo-community.org/groups/contributors-15/contributors-84164?mode=thread&date_begin=&date_end=

    the subject has been discussed before...

    Nowadays, could you please give your experience on bidirectional partial replication of Odoo data between 2 databases ?

    Our use case is :

    - Main database on land (accounting, inventory, sales, website...)

    - Secondary database on a boat that loses Internet connexion for several hours (point_of_sale only)

    We already tested https://github.com/JayVora-SerpentCS/SerpentCS_Contributions/tree/13.0/base_synchro it's very slow and have a few issues

    We are going to test bucardo.org with Multi Master Replication but it does not look like the perfect solution

    Would you go to an ESB for such a small use case ?

    Thanks in advance

    Best regards

    -- 
    Cordialement
--------------------------------
Cyril VINH-TUNG
INVITU
Computer & Network Engineering
BP 32 - 98713 Papeete - French Polynesia
Tél: +689 40 46 11 99
contact@invitu.com
www.invitu.com

    P Please consider the environment before printing this e-mail!

    by Cyril VINH-TUNG - 10:56 - 25 Jan 2021

    1 replies 1 replies

  • Right way to do a new OCA module that depends on EE's LGPL module.
    Dear community,

    Got some questions about licensing.

    There are modules that we want to extend but they are in EE14 --> "approvals", "approvals_purchase".
    Where approvals is a simple module for approving something. And approvals_purchase allow creating purchase order at the end of process.

    They are quite simple. But what we need is to create modules "approvals_purchase_request" and "approvals_hr_expense".

    I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

    What is the right way to deal with this?
    1. Just include approvals in OCA and continue the new module (as it is LGPL, not sure)
    2. We can't use "approvals", and so, we have to first create something similar to it, may be renaming it, add/remove some feature etc. and make it pure OCA module first before continue our needing module.

    Thank you!
    Kitti U.

    by Kitti Upariphutthiphong - 04:31 - 25 Jan 2021

    4 replies 4 replies

    • Re: Right way to do a new OCA module that depends on EE's LGPL module.
      Yes Pedro, "base_tier_validation" will serve us well, will use it with new approvals object (spending request sounds better).

      We want this approvals as a helper window only. End user can request all spending in the same place and at after approval, will create all PR, EX and AV. So, as combined amount, it can go through the right approvals steps (versus smaller documents and get away with) and also for budget check in total amount too.

      I saw, approvals and approvals_purchase, and I think it is intuitive for very end users.

      On Mon, Jan 25, 2021 at 5:27 PM Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> wrote:
      Kitti, `base_tier_validation` doesn't serve you as base for this?

      Regards.

      El lun, 25 ene 2021 a las 10:27, Kitti Upariphutthiphong (<kittiu@ecosoft.co.th>) escribió:
      Hi Stephane,

      Yes, then I think Odoo just forget it as you say, so it defaults to LGPL. But in any case, I will go with the option 2. Which is to create a new module from the beginning.

      Thanks for your prompt reply.
      Kitti U.

      On Mon, Jan 25, 2021 at 3:47 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      > I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

      Have you checked that with Odoo ? Some EE modules don't have a license key, and when you load them in a database, the license field of ir.module.module defaults to LGPL.
      But last time I reported that to Odoo it was quickly fixed.
      So unless explicitly written otherwise I would assume that all the odoo/enterprise repo is under a proprietary license.

      And you can't create a module that depends on both AGPL and proprietary code.

      In any case adding code that depends on Odoo EE in OCA is not possible because the EE code is not public so we could not run CI, runbot etc.

      Best regards,

      -sbi

      --
      Stéphane Bidoul | @SBidoul
      Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

      On Mon, Jan 25, 2021 at 4:32 AM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:
      Dear community,

      Got some questions about licensing.

      There are modules that we want to extend but they are in EE14 --> "approvals", "approvals_purchase".
      Where approvals is a simple module for approving something. And approvals_purchase allow creating purchase order at the end of process.

      They are quite simple. But what we need is to create modules "approvals_purchase_request" and "approvals_hr_expense".

      I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

      What is the right way to deal with this?
      1. Just include approvals in OCA and continue the new module (as it is LGPL, not sure)
      2. We can't use "approvals", and so, we have to first create something similar to it, may be renaming it, add/remove some feature etc. and make it pure OCA module first before continue our needing module.

      Thank you!
      Kitti U.

      _______________________________________________
      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 Kitti Upariphutthiphong - 12:21 - 25 Jan 2021
    • Re: Right way to do a new OCA module that depends on EE's LGPL module.
      Kitti, `base_tier_validation` doesn't serve you as base for this?

      Regards.

      El lun, 25 ene 2021 a las 10:27, Kitti Upariphutthiphong (<kittiu@ecosoft.co.th>) escribió:
      Hi Stephane,

      Yes, then I think Odoo just forget it as you say, so it defaults to LGPL. But in any case, I will go with the option 2. Which is to create a new module from the beginning.

      Thanks for your prompt reply.
      Kitti U.

      On Mon, Jan 25, 2021 at 3:47 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      > I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

      Have you checked that with Odoo ? Some EE modules don't have a license key, and when you load them in a database, the license field of ir.module.module defaults to LGPL.
      But last time I reported that to Odoo it was quickly fixed.
      So unless explicitly written otherwise I would assume that all the odoo/enterprise repo is under a proprietary license.

      And you can't create a module that depends on both AGPL and proprietary code.

      In any case adding code that depends on Odoo EE in OCA is not possible because the EE code is not public so we could not run CI, runbot etc.

      Best regards,

      -sbi

      --
      Stéphane Bidoul | @SBidoul
      Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

      On Mon, Jan 25, 2021 at 4:32 AM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:
      Dear community,

      Got some questions about licensing.

      There are modules that we want to extend but they are in EE14 --> "approvals", "approvals_purchase".
      Where approvals is a simple module for approving something. And approvals_purchase allow creating purchase order at the end of process.

      They are quite simple. But what we need is to create modules "approvals_purchase_request" and "approvals_hr_expense".

      I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

      What is the right way to deal with this?
      1. Just include approvals in OCA and continue the new module (as it is LGPL, not sure)
      2. We can't use "approvals", and so, we have to first create something similar to it, may be renaming it, add/remove some feature etc. and make it pure OCA module first before continue our needing module.

      Thank you!
      Kitti U.

      _______________________________________________
      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 - 11:25 - 25 Jan 2021
    • Re: Right way to do a new OCA module that depends on EE's LGPL module.
      Hi Stephane,

      Yes, then I think Odoo just forget it as you say, so it defaults to LGPL. But in any case, I will go with the option 2. Which is to create a new module from the beginning.

      Thanks for your prompt reply.
      Kitti U.

      On Mon, Jan 25, 2021 at 3:47 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      > I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

      Have you checked that with Odoo ? Some EE modules don't have a license key, and when you load them in a database, the license field of ir.module.module defaults to LGPL.
      But last time I reported that to Odoo it was quickly fixed.
      So unless explicitly written otherwise I would assume that all the odoo/enterprise repo is under a proprietary license.

      And you can't create a module that depends on both AGPL and proprietary code.

      In any case adding code that depends on Odoo EE in OCA is not possible because the EE code is not public so we could not run CI, runbot etc.

      Best regards,

      -sbi

      --
      Stéphane Bidoul | @SBidoul
      Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

      On Mon, Jan 25, 2021 at 4:32 AM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:
      Dear community,

      Got some questions about licensing.

      There are modules that we want to extend but they are in EE14 --> "approvals", "approvals_purchase".
      Where approvals is a simple module for approving something. And approvals_purchase allow creating purchase order at the end of process.

      They are quite simple. But what we need is to create modules "approvals_purchase_request" and "approvals_hr_expense".

      I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

      What is the right way to deal with this?
      1. Just include approvals in OCA and continue the new module (as it is LGPL, not sure)
      2. We can't use "approvals", and so, we have to first create something similar to it, may be renaming it, add/remove some feature etc. and make it pure OCA module first before continue our needing module.

      Thank you!
      Kitti U.

      _______________________________________________
      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 - 10:26 - 25 Jan 2021
    • Re: Right way to do a new OCA module that depends on EE's LGPL module.
      > I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

      Have you checked that with Odoo ? Some EE modules don't have a license key, and when you load them in a database, the license field of ir.module.module defaults to LGPL.
      But last time I reported that to Odoo it was quickly fixed.
      So unless explicitly written otherwise I would assume that all the odoo/enterprise repo is under a proprietary license.

      And you can't create a module that depends on both AGPL and proprietary code.

      In any case adding code that depends on Odoo EE in OCA is not possible because the EE code is not public so we could not run CI, runbot etc.

      Best regards,

      -sbi

      --
      Stéphane Bidoul | @SBidoul
      Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

      On Mon, Jan 25, 2021 at 4:32 AM Kitti Upariphutthiphong <kittiu@ecosoft.co.th> wrote:
      Dear community,

      Got some questions about licensing.

      There are modules that we want to extend but they are in EE14 --> "approvals", "approvals_purchase".
      Where approvals is a simple module for approving something. And approvals_purchase allow creating purchase order at the end of process.

      They are quite simple. But what we need is to create modules "approvals_purchase_request" and "approvals_hr_expense".

      I have checked that "approvals", although in EE source code, its license is in CE, LGPL.

      What is the right way to deal with this?
      1. Just include approvals in OCA and continue the new module (as it is LGPL, not sure)
      2. We can't use "approvals", and so, we have to first create something similar to it, may be renaming it, add/remove some feature etc. and make it pure OCA module first before continue our needing module.

      Thank you!
      Kitti U.

      _______________________________________________
      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 - 09:46 - 25 Jan 2021
  • Repository for repair module
    Hello, 

    I'll be working on a module to make a procurement from a repair order in the repair module for V14. But I don't know in which repository I can make the PR, I have searched in OCA Shop and I found modules related to repair in field-service and manufacture repositories.

    Where is the best repo to add this module?

    Thanks in advance
    by Jesús Alan Ramos Rodriguez - 09:00 - 20 Jan 2021

    1 replies 1 replies

  • Muli Cloud and Hybrid Cloud for Odoo Solutions
    Hi Contributors,


    I've been 4 months researching about IaC with Terraform for Odoo implementations at multi cloud level.

    I've also been researching in hybrid cloud with kubernetes for Odoo solutions.

    This research is cover by the open source project "TerradooCloud" (https://github.com/TerradooCloud), where I want offer a documentation reference for all the possible deployments scenarios for Odoo on Cloud.

    Recently, Google Cloud launch a course and already have a docs for SAP (https://cloud.google.com/solutions/sap/docs).

    This is like my intends to build for Odoo instead for SAP.

    At this moment, I don't have more time to spend in this research, I only can offer management of GitHub projects and reviews, but due to it is a very big and ambitious project, only can be possible with contributors interested.

    Now, I'm focusing in IoT and electronics, so I continue with microk8s and Odoo for server side of IoT, but my focus will be in electronics side.

    If there are anyone interested in participate in this project is already invited to be a member of the organization, but with external PRs is the best way to participate.

    Thank you very much, I hope this project will be interested to anyone,

    JuanDCG.
    by Juan Del Castillo Gómez - 01:36 - 20 Jan 2021

    2 replies 2 replies

    • Re: Muli Cloud and Hybrid Cloud for Odoo Solutions
      Hi,

      Sorry for the delay, but I've no time for this project.

      Naran, thanks for your feedback, it is great and you are a very early adopter of k8s with odoo.

      But, there are other study cases when k8s is too big, for example an odoo for a freelence.

      I would like cover all study cases from one instance to k8s hosting.

      But now, I don't have time for this and the project is stopped to me.

      I don't know if you are interested in share your experience and know-how at TerradooCloud documentation or you preferred maintain it as private information.

      Cheers,

      Juan.

      El jue, 21 ene 2021 a las 4:12, Naran M (<moturi12@gmail.com>) escribió:
      Hi Juan,

      Thanks for the info. 

      Did you come across an open source Rancher orchestration tool (https://rancher.com/ , now owned by Suse)...? It enables the deployments on K8's with multi-cloud providers. 

      We have been using the Rancher for the last 4+ years to deploy our Odoo productions instances on multi-cloud and the experience is amazing, it made it a lot easier to deploy & manage services.

      For IoT related, they have K3's ( lightweight K8's).

      Cheers,
      Naran

      On Wed, Jan 20, 2021 at 11:37 PM Juan DCG <juandcg314@gmail.com> wrote:
      Hi Contributors,


      I've been 4 months researching about IaC with Terraform for Odoo implementations at multi cloud level.

      I've also been researching in hybrid cloud with kubernetes for Odoo solutions.

      This research is cover by the open source project "TerradooCloud" (https://github.com/TerradooCloud), where I want offer a documentation reference for all the possible deployments scenarios for Odoo on Cloud.

      Recently, Google Cloud launch a course and already have a docs for SAP (https://cloud.google.com/solutions/sap/docs).

      This is like my intends to build for Odoo instead for SAP.

      At this moment, I don't have more time to spend in this research, I only can offer management of GitHub projects and reviews, but due to it is a very big and ambitious project, only can be possible with contributors interested.

      Now, I'm focusing in IoT and electronics, so I continue with microk8s and Odoo for server side of IoT, but my focus will be in electronics side.

      If there are anyone interested in participate in this project is already invited to be a member of the organization, but with external PRs is the best way to participate.

      Thank you very much, I hope this project will be interested to anyone,

      JuanDCG.

      _______________________________________________
      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 Juan Del Castillo Gómez - 06:51 - 1 Feb 2021
    • Re: Muli Cloud and Hybrid Cloud for Odoo Solutions
      Hi Juan,

      Thanks for the info. 

      Did you come across an open source Rancher orchestration tool (https://rancher.com/ , now owned by Suse)...? It enables the deployments on K8's with multi-cloud providers. 

      We have been using the Rancher for the last 4+ years to deploy our Odoo productions instances on multi-cloud and the experience is amazing, it made it a lot easier to deploy & manage services.

      For IoT related, they have K3's ( lightweight K8's).

      Cheers,
      Naran

      On Wed, Jan 20, 2021 at 11:37 PM Juan DCG <juandcg314@gmail.com> wrote:
      Hi Contributors,


      I've been 4 months researching about IaC with Terraform for Odoo implementations at multi cloud level.

      I've also been researching in hybrid cloud with kubernetes for Odoo solutions.

      This research is cover by the open source project "TerradooCloud" (https://github.com/TerradooCloud), where I want offer a documentation reference for all the possible deployments scenarios for Odoo on Cloud.

      Recently, Google Cloud launch a course and already have a docs for SAP (https://cloud.google.com/solutions/sap/docs).

      This is like my intends to build for Odoo instead for SAP.

      At this moment, I don't have more time to spend in this research, I only can offer management of GitHub projects and reviews, but due to it is a very big and ambitious project, only can be possible with contributors interested.

      Now, I'm focusing in IoT and electronics, so I continue with microk8s and Odoo for server side of IoT, but my focus will be in electronics side.

      If there are anyone interested in participate in this project is already invited to be a member of the organization, but with external PRs is the best way to participate.

      Thank you very much, I hope this project will be interested to anyone,

      JuanDCG.

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

      by Naran Moturi - 04:11 - 21 Jan 2021
  • Header sorting in form view
    Dear community,

    I'm looking for an addon or a way to keep user sorting choices.

    As you know, you can click on a One2Many or Many2Many header (of a stored field) to sort the lines but any action in the form (validate something or encoding quantities, etc.) reload it and reset the user sort.

    I don't have a great JS expertise that's why I'm asking here before starting to work on a new module/hook dedicated to this feature.

    Thank you.
    --
    Yann Papouin
    by Yann Papouin - 11:11 - 11 Jan 2021

    4 replies 4 replies

  • Sales terms
    Hi there !

    I wish you the best for 2021 !

    I'm on the way to add terms.template model to be able to define different terms template on
    Sale Order (maybe on invoice as well later) so that users can choose the template that will populate terms ( note fields as Html field).  Expected behaviour is what happens with email template, the user chooses a term template, the note field will be populated and the user can change it afterwards.

    Do you know a such module exists if not what do you think to create a such module in Sale Workflow repo

    Regards,

    --
    Pierre Verkest
    06 81 12 25 20
    Github: petrus-v - Twitter: petrusv84 - Linkedin: pierre-verkest
    by Pierre Verkest - 11:16 - 7 Jan 2021

    3 replies 3 replies

  • A module to add methods to convert datetime between UTC and user's timezone
    I think I've seen somewhere under OCA a module to add generic methods to convert datetime between UTC and user's timezone, but I somehow can't find it now.  A pointer would be appreciated.

    -- 
    Yoshi Tashiro

    by Yoshi Tashiro - 04:40 - 6 Jan 2021

    8 replies 8 replies

  • Odoo e2e testing with Cypress.
    Dear community,

    Just recently, I played around with Cypress e2e testing. https://www.cypress.io/

    And it looks interesting especially for functional end to end testing. Test script is in JS, but it looks easy enough to apply with Odoo. 
    Anyone have experiences using cypress with Odoo already?

    Kitti U.
    by Kitti Upariphutthiphong - 04:56 - 31 Dec 2020

    1 replies 1 replies

  • use "%d" in nginx with "dbfilter_from_header" module

    hi all,

    How may I pass the equivalent of "dbfilter = ^%d.*" (odoo conf file option) to a nginx proxy_set_header for dbfilter (using module dbfilter_from_header (odoo 13)?

    I tried to use "<subdomain>" or $subdomain in my expression but It doesn't get substituted before being sent to odoo.
    i.e. unsuccessfully tried:
    proxy_set_header X-Odoo-dbfilter \b(?<subdomain>.*)\b\S+; 
    proxy_set_header X-Odoo-dbfilter \b(?\<subdomain\>.*)\b\S+; 
    proxy_set_header X-Odoo-dbfilter \b(?\$subdomain.*)\b\S+; 
    proxy_set_header X-Odoo-dbfilter ^%d.*;


    anyone can help?

    the use case is that I would like to set this dbfilter for only some defined range of subdomains.

    TIA 



     --
    Yves Goldberg
    odoo| Official Partner - OCA delegate
    Open Source ERP, CRM & CMS
    T +972 (3) 720 8818
    M +972 (55) 966 1405
    T +32 (2) 588 2500
     
     
    --

    by Yves Goldberg - 11:00 - 31 Dec 2020

    5 replies 5 replies

    • Re: use "%d" in nginx with "dbfilter_from_header" module
      Hi Rémy. this is great. thank you. I wrongly thought that <subdomain> was a predefined nginx variable. So now I could capture and assign the value in the server_name statement and use it in the dbfilter.
      Cheers.
      Yves. 


      ----- Original message -----
      From: "Rémy Taymans" <remy@coopiteasy.be>
      Subject: Re: use "%d" in nginx with "dbfilter_from_header" module
      Date: Friday, January 01, 2021 12:32

      Dear Yves,

The value of the header X-Odoo-dbfilter should be a regular expression matching your database name. (https://github.com/OCA/server-tools/blob/13.0/dbfilter_from_header/override.py#L20)

The match performed by Odoo using the regular expression given in the dbfilter header ignore the url you are using for accessing the odoo instance.

Considering that the database is named according to the subdomain, the following nginx config should work :

  server_name foo.example.org;
  ...
  proxy_set_header X-Odoo-dbfilter foo;

This will match any database that *begins* with `foo`.

If the server_name of your nginx configuration file consist of something like :

  server_name *.example.org;

Then you should consider using a regular expression as a server_name value. With this regular expression, extract the subdomain in a variable that can be used as a value for the proxy header.

  server_name ~^(?<database>.+)\.example\.org$;
  ...
  proxy_set_header X-Odoo-dbfilter $database;

To get more info about regular expression in nginx configuration file, see : http://nginx.org/en/docs/http/server_names.html#regex_names

I have not tested the code given in this email, so use it with caution.  :)

Regards,

--
Rémy Taymans @ Coop IT Easy
+32 493 02 69 85 - <https://github.com/coopiteasy>
<https://coopiteasy.be>

Quoting Yves Goldberg (2020-12-31 11:02:05)
> hi all,
> How may I pass the equivalent of "dbfilter = *^%d.**" (odoo conf file option) to a nginx proxy_set_header for dbfilter (using module dbfilter_from_header [1]  (odoo 13)?
> I tried to use "<subdomain>" or $subdomain in my expression but It doesn't get substituted before being sent to odoo.
> i.e. unsuccessfully tried:
> proxy_set_header X-Odoo-dbfilter \b(?<subdomain>.*)\b\S+;
> proxy_set_header X-Odoo-dbfilter \b(?\<subdomain\>.*)\b\S+;  proxy_set_header X-Odoo-dbfilter \b(?\$subdomain.*)\b\S+;  proxy_set_header X-Odoo-dbfilter ^%d.*;
>
> anyone can help?
> the use case is that I would like to set this dbfilter for only some defined range of subdomains.
> TIA
>
> --  Yves Goldberg*    o   doo  * |  Official Partner   - OCA delegate      Open Source ERP, CRM & CMS         Chat with me [2]      T    +972 (3) 720 8818*  M   +972 (55) 966 1405    T  +32 (2) 588 2500       None [3] www.ygol.com       None [4]    None [5]       None [6]       None [7]     --

      _______________________________________________
      Post to: mailto:contributors@odoo-community.org


      by Yves Goldberg - 04:35 - 1 Jan 2020
    • Re: use "%d" in nginx with "dbfilter_from_header" module 
      Dear Yves,

The value of the header X-Odoo-dbfilter should be a regular expression matching your database name. (https://github.com/OCA/server-tools/blob/13.0/dbfilter_from_header/override.py#L20)

The match performed by Odoo using the regular expression given in the dbfilter header ignore the url you are using for accessing the odoo instance.

Considering that the database is named according to the subdomain, the following nginx config should work :

  server_name foo.example.org;
  ...
  proxy_set_header X-Odoo-dbfilter foo;

This will match any database that *begins* with `foo`.

If the server_name of your nginx configuration file consist of something like :

  server_name *.example.org;

Then you should consider using a regular expression as a server_name value. With this regular expression, extract the subdomain in a variable that can be used as a value for the proxy header.

  server_name ~^(?<database>.+)\.example\.org$;
  ...
  proxy_set_header X-Odoo-dbfilter $database;

To get more info about regular expression in nginx configuration file, see : http://nginx.org/en/docs/http/server_names.html#regex_names

I have not tested the code given in this email, so use it with caution.  :)

Regards,

--
Rémy Taymans @ Coop IT Easy
+32 493 02 69 85 - <https://github.com/coopiteasy>
<https://coopiteasy.be>

Quoting Yves Goldberg (2020-12-31 11:02:05)
> hi all,
> How may I pass the equivalent of "dbfilter = *^%d.**" (odoo conf file option) to a nginx proxy_set_header for dbfilter (using module dbfilter_from_header [1]  (odoo 13)?
> I tried to use "<subdomain>" or $subdomain in my expression but It doesn't get substituted before being sent to odoo.
> i.e. unsuccessfully tried:
> proxy_set_header X-Odoo-dbfilter \b(?<subdomain>.*)\b\S+;
> proxy_set_header X-Odoo-dbfilter \b(?\<subdomain\>.*)\b\S+;  proxy_set_header X-Odoo-dbfilter \b(?\$subdomain.*)\b\S+;  proxy_set_header X-Odoo-dbfilter ^%d.*;
>
> anyone can help?
> the use case is that I would like to set this dbfilter for only some defined range of subdomains.
> TIA
>
> --  Yves Goldberg*    o   doo  * |  Official Partner   - OCA delegate      Open Source ERP, CRM & CMS         Chat with me [2]      T    +972 (3) 720 8818*  M   +972 (55) 966 1405    T  +32 (2) 588 2500       None [3] www.ygol.com       None [4]    None [5]       None [6]       None [7]     --
      by Rémy Taymans - 11:30 - 1 Jan 2020
    • Re: use "%d" in nginx with "dbfilter_from_header" module
      Thanks Bruno. The second one is the one I am using and the 1st one is similar.
      My question is more about if there is a syntax I could use.

      Happy new year


      ----- Original message -----
      From: Bruno Joliveau <bruno.joliveau@numigi.com>
      Subject: Re: use "%d" in nginx with "dbfilter_from_header" module
      Date: Thursday, December 31, 2020 18:37

      I sent my mail too quickly ;-)




      Bruno Joliveau - Architecte applications - Président
      NUMIGI SOLUTIONS INC.
      (514) 317-7944

      Longueuil, Québec, Canada

      linkedin
      		youtube
      		custom-icon
      		twitter











      Le jeu. 31 déc. 2020 à 11:30, Bruno Joliveau <bruno.joliveau@numigi.com> a écrit :
      Hi Yves,


      Have a nice day!


      Bruno Joliveau - Architecte applications - Président
      NUMIGI SOLUTIONS INC.
      (514) 317-7944

      Longueuil, Québec, Canada

      linkedin
      		youtube
      		custom-icon
      		twitter











      Le jeu. 31 déc. 2020 à 05:02, Yves Goldberg <yves@ygol.com> a écrit :

      hi all,

      How may I pass the equivalent of "dbfilter = ^%d.*" (odoo conf file option) to a nginx proxy_set_header for dbfilter (using module dbfilter_from_header (odoo 13)?

      I tried to use "<subdomain>" or $subdomain in my expression but It doesn't get substituted before being sent to odoo.
      i.e. unsuccessfully tried:
      proxy_set_header X-Odoo-dbfilter \b(?<subdomain>.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter \b(?\<subdomain\>.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter \b(?\$subdomain.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter ^%d.*;


      anyone can help?

      the use case is that I would like to set this dbfilter for only some defined range of subdomains.

      TIA 



       --
      Yves Goldberg
      odoo| Official Partner - OCA delegate
      Open Source ERP, CRM & CMS
      T +972 (3) 720 8818
      M +972 (55) 966 1405
      T +32 (2) 588 2500
       
       
      --


      _______________________________________________



      _______________________________________________
      Post to: mailto:contributors@odoo-community.org



      by Yves Goldberg - 09:11 - 1 Jan 2020
    • Re: use "%d" in nginx with "dbfilter_from_header" module
      I sent my mail too quickly ;-)


      Bruno Joliveau - Architecte applications - Président
      NUMIGI SOLUTIONS INC.
      (514) 317-7944

      Longueuil, Québec, Canada

      linkedinyoutubecustom-icontwitter


      Le jeu. 31 déc. 2020 à 11:30, Bruno Joliveau <bruno.joliveau@numigi.com> a écrit :
      Hi Yves,


      Have a nice day!
      Bruno Joliveau - Architecte applications - Président
      NUMIGI SOLUTIONS INC.
      (514) 317-7944

      Longueuil, Québec, Canada

      linkedinyoutubecustom-icontwitter


      Le jeu. 31 déc. 2020 à 05:02, Yves Goldberg <yves@ygol.com> a écrit :

      hi all,

      How may I pass the equivalent of "dbfilter = ^%d.*" (odoo conf file option) to a nginx proxy_set_header for dbfilter (using module dbfilter_from_header (odoo 13)?

      I tried to use "<subdomain>" or $subdomain in my expression but It doesn't get substituted before being sent to odoo.
      i.e. unsuccessfully tried:
      proxy_set_header X-Odoo-dbfilter \b(?<subdomain>.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter \b(?\<subdomain\>.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter \b(?\$subdomain.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter ^%d.*;


      anyone can help?

      the use case is that I would like to set this dbfilter for only some defined range of subdomains.

      TIA 



       --
      Yves Goldberg
      odoo| Official Partner - OCA delegate
      Open Source ERP, CRM & CMS
      T +972 (3) 720 8818
      M +972 (55) 966 1405
      T +32 (2) 588 2500
       
       
      --

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

      by Bruno Joliveau - 05:36 - 31 Dec 2020
    • Re: use "%d" in nginx with "dbfilter_from_header" module
      Hi Yves,


      Have a nice day!
      Bruno Joliveau - Architecte applications - Président
      NUMIGI SOLUTIONS INC.
      (514) 317-7944

      Longueuil, Québec, Canada

      linkedinyoutubecustom-icontwitter


      Le jeu. 31 déc. 2020 à 05:02, Yves Goldberg <yves@ygol.com> a écrit :

      hi all,

      How may I pass the equivalent of "dbfilter = ^%d.*" (odoo conf file option) to a nginx proxy_set_header for dbfilter (using module dbfilter_from_header (odoo 13)?

      I tried to use "<subdomain>" or $subdomain in my expression but It doesn't get substituted before being sent to odoo.
      i.e. unsuccessfully tried:
      proxy_set_header X-Odoo-dbfilter \b(?<subdomain>.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter \b(?\<subdomain\>.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter \b(?\$subdomain.*)\b\S+; 
      proxy_set_header X-Odoo-dbfilter ^%d.*;


      anyone can help?

      the use case is that I would like to set this dbfilter for only some defined range of subdomains.

      TIA 



       --
      Yves Goldberg
      odoo| Official Partner - OCA delegate
      Open Source ERP, CRM & CMS
      T +972 (3) 720 8818
      M +972 (55) 966 1405
      T +32 (2) 588 2500
       
       
      --

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

      by Bruno Joliveau - 05:36 - 31 Dec 2020
  • Mailing list IoT PSC
    Hi community,

    Are there any mailing list of IoT PSC ?

    Or we can use the new discussions feature of github ?

    Thanks,

    Juan.
    by Juan Del Castillo Gómez - 04:11 - 24 Dec 2020

    2 replies 2 replies

  • OCA and security notices

    Hi community,

    Yesterday a security notices has been published.

    Stefan has begun to bring one security fix to OCB with this PR

    It raises what seems to be an important point about the handling of the security fixes for the unsupported Odoo version on OCB. Will this should be taken in charge by OCA, as OCB is under OCA umbrella or it'll remain on the goodwill of the community's members ? I don't have any problem with one of the possible responses.

    My point is how do we takle the minimum about this topic. I mean how do we organize the contribution members on this topics ?

    My first idea will be to open an issue on OCB for each security notice and organize the work as it done for modules migration. What do you think ? Creating a PSC team security could be another idea.

    Finding the security issues seems to be easy but at this point we don't have a tracking on the ones that are brought back on the unsupported version on OCB.

    Here at Coop IT Easy we'll probably focus on the versions affecting our customers it means 9.0 as 11.0 and later are still supported.

    Regards,

    Housine


    Virus-free. www.avast.com
    by Houssine BAKKALI - 11:46 - 23 Dec 2020

    12 replies 12 replies

    • Re: OCA and security notices 
      Hi Pedro,

It took a while to sink in, but yes, you have convinced me. Upgrading is 
the thing to do, instead of spending time on bugs and performance issues 
that are fixed in newer cores. I've seen my share of those and it's just 
not worth the effort to fight these rearguard battles.

It's too bad that upgrading is in many cases a big, complex operation, 
but that's just the way it is.

Thanks for your insights!

Op 1/5/21 om 9:27 AM schreef Pedro M. Baeza (Tecnativa):

> Hi, Tom,

>

> Each version can have some bugs, but it's better to handle them 

> between more people than let SaaS users or the same partners to 

> notify/fix them. You think it's "safer" to be on a previous version 

> for avoiding such bugs, but the facts are:

>

> - Such a bug is because of your use cases, and it will be found on the 

> version you are using, no matter if outdated or not. Nobody till then 

> may notify it.

> - Odoo is fixing bugs very quickly and without effort by your part on 

> the latest version (or the previous one), as they are committed to 

> "stabilize" that version, but not on very old versions. A note about 

> this: notifying properly a bug is the key for having it solved. You 

> can't expect to have the work done not doing a minimum effort on your 

> part.

> - Bugs can happen even on unsupported versions, so the maintenance 

> cost starts to rise if you need to fix them by yourself and you are 

> introducing regression risks.

> - There are even occasions where the bug is fixed or doesn't apply on 

> higher versions, but you don't have it in an outdated one. See the 

> recent CVE cases and the effort needed by Stefan and Nils.

> - Odoo continues to improve its test suite, and each version has more 

> and more stability/quality.

>

> Other facts about using outdated versions:

>

> - You need to "backport" features that are on higher versions or lack 

> them.

> - Framework evolves, and using an outdated framework makes your 

> development team to require more time to complete the same tasks, or 

> to not have available some tools. Programming in 2020 with the old API 

> or the v8/v9 hybrid for me is horrible.

> - Collaboration possibilities are reduced working on an outdated 

> version, as there are less contributors on them. You can see the same 

> examples on your 7.0 PRs, or even on the 10.0 PRs, that is more 

> recent, but the same unattended.

> - As a complement to the previous one, new contributors push newer 

> versions, not old ones.

> - Underlying libraries and dependencies are outdated as well, with the 

> problems this supposes.

>

> So at Tecnativa we deal with this not having middle positions: all our 

> customers go to latest versions (the supported ones), and we reject 

> those that don't want this approach. That way, we focus on dealing 

> with a reduced set of Odoo versions, we migrate them regularly (not 

> forcing a yearly migration, but more and more customers demand to go 

> to each version and they don't want to keep the same version 2/3 

> years), and we report bugs to Odoo constantly that makes the versions 

> stable enough.

>

> Migrating OCA modules is not a problem while you are on the wheel. The 

> keys are:

>

> - Having a team used to OCA guidelines. All our developments follow 

> strict guidelines. This makes the team to take the habit and don't 

> require more time to be "OCA". Anyway, 95% of our developments are 

> directly OCA. OCA first approach is also very important for us.

> - Having good test coverage. This is vital for easing the migrations. 

> Doing good tests is not easy, but the time spent on that will be for 

> sure gained later. This includes also JS tour/Qunit tests if needed.

> - Reviewing PRs between colleagues as part of your development cycle. 

> This raises a lot your team skills and don't stuck PRs. People 

> complain about their PRs not being reviewed, but they don't review 

> others in exchange or don't push colleagues to review them.

>

> We also take a proactive position for handling some "polemical" 

> decisions taken on the versions, creating OCA modules that fill the 

> gaps. This is better IMO than staying on an older version and 

> complaining that "Odoo has removed this or changed that". In general 

> you win more than you lose on newer versions.

>

> And finally, customers receive a refresh training on each version 

> change. Being proactive as well on the changes they have makes people 

> to not reject the new version and embrace the new features from the 

> beginning.

>

> Do I convince you, hehe?

>

> Regards.

>

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 

> <https://odoo-community.org/groups/contributors-15>

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe 

> <https://odoo-community.org/groups?unsubscribe>

>
      by Tom Blauwendraat - 05:31 - 9 Apr 2021
    • Re: OCA and security notices
      Hi, Xavier,

      The delay depends on 2 factors:

      - The technical work to be done, which is the installed core modules to be covered by OpenUpgrade + the OCA modules to be migrated. This can be complemented with use cases test suite to be checked.
      - The customer alignment for the best moment to migrate, depending on their activity.

      FYI, we are migrating our customers to v13 now, having 4 of them on 13.0 already, and the rest coming in the following months.

      Regards.

      El mié, 6 ene 2021 a las 19:07, Xavier Brochard (<xavier@alternatif.org>) escribió:
      Hi Pedro

I've found your post very interesting.
However can you elaborate a bit on the delay before migration ? 
Obviously you can't migrate before the newest version is stabilized 
enough, but you can't also migrate before OpenUpgrade is available (or 
do you migrate "by hand" ?). So, are you curently running Odoo 13 and 
planning migrations around june ?

Best regards
Xavier / zeroheure
---
Librement,
Xavier Brochard xavier@alternatif.org
La liberté est à l'homme ce que les ailes sont à l'oiseau (Jean-Pierre 
Rosnay)

Le 05.01.2021 09:27, Pedro M. Baeza (Tecnativa) a écrit :


> Hi, Tom,


> 


> Each version can have some bugs, but it's better to handle them


> between more people than let SaaS users or the same partners to


> notify/fix them. You think it's "safer" to be on a previous version


> for avoiding such bugs, but the facts are:


> 


> - Such a bug is because of your use cases, and it will be found on the


> version you are using, no matter if outdated or not. Nobody till then


> may notify it.


> - Odoo is fixing bugs very quickly and without effort by your part on


> the latest version (or the previous one), as they are committed to


> "stabilize" that version, but not on very old versions. A note about


> this: notifying properly a bug is the key for having it solved. You


> can't expect to have the work done not doing a minimum effort on your


> part.


> 


> - Bugs can happen even on unsupported versions, so the maintenance


> cost starts to rise if you need to fix them by yourself and you are


> introducing regression risks.


> - There are even occasions where the bug is fixed or doesn't apply on


> higher versions, but you don't have it in an outdated one. See the


> recent CVE cases and the effort needed by Stefan and Nils.


> - Odoo continues to improve its test suite, and each version has more


> and more stability/quality.


> 


> Other facts about using outdated versions:


> 


> - You need to "backport" features that are on higher versions or lack


> them.


> - Framework evolves, and using an outdated framework makes your


> development team to require more time to complete the same tasks, or


> to not have available some tools. Programming in 2020 with the old API


> or the v8/v9 hybrid for me is horrible.


> - Collaboration possibilities are reduced working on an outdated


> version, as there are less contributors on them. You can see the same


> examples on your 7.0 PRs, or even on the 10.0 PRs, that is more


> recent, but the same unattended.


> - As a complement to the previous one, new contributors push newer


> versions, not old ones.


> - Underlying libraries and dependencies are outdated as well, with the


> problems this supposes.


> 


> So at Tecnativa we deal with this not having middle positions: all our


> customers go to latest versions (the supported ones), and we reject


> those that don't want this approach. That way, we focus on dealing


> with a reduced set of Odoo versions, we migrate them regularly (not


> forcing a yearly migration, but more and more customers demand to go


> to each version and they don't want to keep the same version 2/3


> years), and we report bugs to Odoo constantly that makes the versions


> stable enough.


> 


> Migrating OCA modules is not a problem while you are on the wheel. The


> keys are:


> 


> - Having a team used to OCA guidelines. All our developments follow


> strict guidelines. This makes the team to take the habit and don't


> require more time to be "OCA". Anyway, 95% of our developments are


> directly OCA. OCA first approach is also very important for us.


> 


> - Having good test coverage. This is vital for easing the migrations.


> Doing good tests is not easy, but the time spent on that will be for


> sure gained later. This includes also JS tour/Qunit tests if needed.


> - Reviewing PRs between colleagues as part of your development cycle.


> This raises a lot your team skills and don't stuck PRs. People


> complain about their PRs not being reviewed, but they don't review


> others in exchange or don't push colleagues to review them.


> 


> We also take a proactive position for handling some "polemical"


> decisions taken on the versions, creating OCA modules that fill the


> gaps. This is better IMO than staying on an older version and


> complaining that "Odoo has removed this or changed that". In general


> you win more than you lose on newer versions.


> 


> And finally, customers receive a refresh training on each version


> change. Being proactive as well on the changes they have makes people


> to not reject the new version and embrace the new features from the


> beginning.


> 


> Do I convince you, hehe?


> 


> Regards.


> 


> _______________________________________________


> 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 - 12:36 - 7 Jan 2021
    • Re: OCA and security notices 
      Hi Pedro

I've found your post very interesting.
However can you elaborate a bit on the delay before migration ? 
Obviously you can't migrate before the newest version is stabilized 
enough, but you can't also migrate before OpenUpgrade is available (or 
do you migrate "by hand" ?). So, are you curently running Odoo 13 and 
planning migrations around june ?

Best regards
Xavier / zeroheure
---
Librement,
Xavier Brochard xavier@alternatif.org
La liberté est à l'homme ce que les ailes sont à l'oiseau (Jean-Pierre 
Rosnay)

Le 05.01.2021 09:27, Pedro M. Baeza (Tecnativa) a écrit :

> Hi, Tom,

> 

> Each version can have some bugs, but it's better to handle them

> between more people than let SaaS users or the same partners to

> notify/fix them. You think it's "safer" to be on a previous version

> for avoiding such bugs, but the facts are:

> 

> - Such a bug is because of your use cases, and it will be found on the

> version you are using, no matter if outdated or not. Nobody till then

> may notify it.

> - Odoo is fixing bugs very quickly and without effort by your part on

> the latest version (or the previous one), as they are committed to

> "stabilize" that version, but not on very old versions. A note about

> this: notifying properly a bug is the key for having it solved. You

> can't expect to have the work done not doing a minimum effort on your

> part.

> 

> - Bugs can happen even on unsupported versions, so the maintenance

> cost starts to rise if you need to fix them by yourself and you are

> introducing regression risks.

> - There are even occasions where the bug is fixed or doesn't apply on

> higher versions, but you don't have it in an outdated one. See the

> recent CVE cases and the effort needed by Stefan and Nils.

> - Odoo continues to improve its test suite, and each version has more

> and more stability/quality.

> 

> Other facts about using outdated versions:

> 

> - You need to "backport" features that are on higher versions or lack

> them.

> - Framework evolves, and using an outdated framework makes your

> development team to require more time to complete the same tasks, or

> to not have available some tools. Programming in 2020 with the old API

> or the v8/v9 hybrid for me is horrible.

> - Collaboration possibilities are reduced working on an outdated

> version, as there are less contributors on them. You can see the same

> examples on your 7.0 PRs, or even on the 10.0 PRs, that is more

> recent, but the same unattended.

> - As a complement to the previous one, new contributors push newer

> versions, not old ones.

> - Underlying libraries and dependencies are outdated as well, with the

> problems this supposes.

> 

> So at Tecnativa we deal with this not having middle positions: all our

> customers go to latest versions (the supported ones), and we reject

> those that don't want this approach. That way, we focus on dealing

> with a reduced set of Odoo versions, we migrate them regularly (not

> forcing a yearly migration, but more and more customers demand to go

> to each version and they don't want to keep the same version 2/3

> years), and we report bugs to Odoo constantly that makes the versions

> stable enough.

> 

> Migrating OCA modules is not a problem while you are on the wheel. The

> keys are:

> 

> - Having a team used to OCA guidelines. All our developments follow

> strict guidelines. This makes the team to take the habit and don't

> require more time to be "OCA". Anyway, 95% of our developments are

> directly OCA. OCA first approach is also very important for us.

> 

> - Having good test coverage. This is vital for easing the migrations.

> Doing good tests is not easy, but the time spent on that will be for

> sure gained later. This includes also JS tour/Qunit tests if needed.

> - Reviewing PRs between colleagues as part of your development cycle.

> This raises a lot your team skills and don't stuck PRs. People

> complain about their PRs not being reviewed, but they don't review

> others in exchange or don't push colleagues to review them.

> 

> We also take a proactive position for handling some "polemical"

> decisions taken on the versions, creating OCA modules that fill the

> gaps. This is better IMO than staying on an older version and

> complaining that "Odoo has removed this or changed that". In general

> you win more than you lose on newer versions.

> 

> And finally, customers receive a refresh training on each version

> change. Being proactive as well on the changes they have makes people

> to not reject the new version and embrace the new features from the

> beginning.

> 

> Do I convince you, hehe?

> 

> Regards.

> 

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe
      by xavier - 07:05 - 6 Jan 2021
    • Re: OCA and security notices
      Hi, Tom,

      Each version can have some bugs, but it's better to handle them between more people than let SaaS users or the same partners to notify/fix them. You think it's "safer" to be on a previous version for avoiding such bugs, but the facts are:

      - Such a bug is because of your use cases, and it will be found on the version you are using, no matter if outdated or not. Nobody till then may notify it.
      - Odoo is fixing bugs very quickly and without effort by your part on the latest version (or the previous one), as they are committed to "stabilize" that version, but not on very old versions. A note about this: notifying properly a bug is the key for having it solved. You can't expect to have the work done not doing a minimum effort on your part.
      - Bugs can happen even on unsupported versions, so the maintenance cost starts to rise if you need to fix them by yourself and you are introducing regression risks.
      - There are even occasions where the bug is fixed or doesn't apply on higher versions, but you don't have it in an outdated one. See the recent CVE cases and the effort needed by Stefan and Nils.
      - Odoo continues to improve its test suite, and each version has more and more stability/quality.

      Other facts about using outdated versions:

      - You need to "backport" features that are on higher versions or lack them.
      - Framework evolves, and using an outdated framework makes your development team to require more time to complete the same tasks, or to not have available some tools. Programming in 2020 with the old API or the v8/v9 hybrid for me is horrible.
      - Collaboration possibilities are reduced working on an outdated version, as there are less contributors on them. You can see the same examples on your 7.0 PRs, or even on the 10.0 PRs, that is more recent, but the same unattended.
      - As a complement to the previous one, new contributors push newer versions, not old ones.
      - Underlying libraries and dependencies are outdated as well, with the problems this supposes.

      So at Tecnativa we deal with this not having middle positions: all our customers go to latest versions (the supported ones), and we reject those that don't want this approach. That way, we focus on dealing with a reduced set of Odoo versions, we migrate them regularly (not forcing a yearly migration, but more and more customers demand to go to each version and they don't want to keep the same version 2/3 years), and we report bugs to Odoo constantly that makes the versions stable enough.

      Migrating OCA modules is not a problem while you are on the wheel. The keys are:

      - Having a team used to OCA guidelines. All our developments follow strict guidelines. This makes the team to take the habit and don't require more time to be "OCA". Anyway, 95% of our developments are directly OCA. OCA first approach is also very important for us.
      - Having good test coverage. This is vital for easing the migrations. Doing good tests is not easy, but the time spent on that will be for sure gained later. This includes also JS tour/Qunit tests if needed.
      - Reviewing PRs between colleagues as part of your development cycle. This raises a lot your team skills and don't stuck PRs. People complain about their PRs not being reviewed, but they don't review others in exchange or don't push colleagues to review them.

      We also take a proactive position for handling some "polemical" decisions taken on the versions, creating OCA modules that fill the gaps. This is better IMO than staying on an older version and complaining that "Odoo has removed this or changed that". In general you win more than you lose on newer versions.

      And finally, customers receive a refresh training on each version change. Being proactive as well on the changes they have makes people to not reject the new version and embrace the new features from the beginning.

      Do I convince you, hehe?

      Regards.
      by Pedro M. Baeza - 09:21 - 5 Jan 2021
    • Re: OCA and security notices 
      @Pedro: Upgrading the Odoo version inevitably leads to a period of 
employees adjusting to UI/workflow changes, as well as running into 
bugs: new Odoo releases have bugs, OpenUpgrade has bugs, ported OCA 
modules have bugs.. etc. Employees are not looking for this kind of 
instability in the ERP that they work with every day.

How do you deal with this at Tecnativa?

Op 12/31/20 om 3:12 PM schreef Pedro M. Baeza (Tecnativa):

> For me the path is clear: upgrade to the latest possible Odoo version, 

> and that's why OpenUpgrade is done and funded by OCA itself, and the 

> most famous OCA modules are migrated to all versions by regular 

> contributors.

>

> Regards.

>

> _______________________________________________

> Mailing-List: https://odoo-community.org/groups/contributors-15 

> <https://odoo-community.org/groups/contributors-15>

> Post to: mailto:contributors@odoo-community.org

> Unsubscribe: https://odoo-community.org/groups?unsubscribe 

> <https://odoo-community.org/groups?unsubscribe>

>
      by Tom Blauwendraat - 06:11 - 3 Jan 2020

  • Pywebdriver in the OCA 
    Hello everyone,


As some of you might know, at Akretion we use a replacement tool for
the IoT box, which is called Pywebdriver.

We are currently maintaining it with other OCA members like Acsone or
GRAP.

We thought this could be a good idea to have this tool under the OCA
umbrella to ease the workflows around it.


Since this differs from the usual repositories the OCA manages, I
created an issue to discuss around this possible inclusion:
https://github.com/akretion/pywebdriver/issues/57


Looking forward to read from you about this !



-- 
Pierrick Brun
Akretion
    by Pierrick Brun - 03:15 - 22 Dec 2020

    4 replies 4 replies

    • Re: Pywebdriver in the OCA 
      +1

I briefly discussed that with fkantelberg of our team and for now its
seem arguments are for instance

- no need for local postgres installation
- windows support
- flask usage
- extensible architecture
- ....

But there is probaly much more.

Best Frederik

Am Dienstag, den 22.12.2020, 14:52 +0000 schrieb Pedro M. Baeza
(Tecnativa):

> Yeah, it could be interesting. I think the minimum for having it in

> OCA is:

> 

> - Having a decent CI for not lowering contribution quality.

> - Extended README, explaining the reasoning for having it and

> advantages over existing IoTBox.

> 

> Regards.

> _______________________________________________

> 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:56 - 22 Dec 2020
    • Re: Pywebdriver in the OCA
      Yeah, it could be interesting. I think the minimum for having it in OCA is:

      - Having a decent CI for not lowering contribution quality.
      - Extended README, explaining the reasoning for having it and advantages over existing IoTBox.

      Regards.
      by Pedro M. Baeza - 03:50 - 22 Dec 2020
    • Re: Pywebdriver in the OCA
      Great, thanks Pierrick!
      --
      Virginie
      0477/64.17.20
      --
      Si vous avez un contrat de support, posez-nous vos question à l'adresse "support@coopiteasy.be"
      --
      Lors de l'envoi d'un mail, renseignez le nom de la structure pour laquelle vous travaillez. Merci.

      -------- Message initial --------
      De: "Roussel, Denis" <denis.roussel@acsone.eu>
      Répondre à: Odoo Community Association (OCA) Contributors <contributors@odoo-community.org>
      Objet: Re: Pywebdriver in the OCA
      Date: Tue, 22 Dec 2020 14:32:01 -0000

      Great!

      Thanks for digging up that subject.

      IMHO, this could be an interesting value added for OCA.



      On Tue, Dec 22, 2020 at 3:16 PM Pierrick Brun <pierrick.brun@akretion.com> wrote:
      Hello everyone,


      As some of you might know, at Akretion we use a replacement tool for
      the IoT box, which is called Pywebdriver.

      We are currently maintaining it with other OCA members like Acsone or
      GRAP.

      We thought this could be a good idea to have this tool under the OCA
      umbrella to ease the workflows around it.


      Since this differs from the usual repositories the OCA manages, I
      created an issue to discuss around this possible inclusion:
      https://github.com/akretion/pywebdriver/issues/57


      Looking forward to read from you about this !


      -- 
      Pierrick Brun
      Akretion

      


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



      
        
      
        
            
                by
                Virginie Dewulf.
            
            -
            
                
                03:36 - 22 Dec 2020
            
        
        
      
            
      
                
            
      
        
      
                            
      
                        
      
                    
      
                
    • 
                    
      
                        
      
                            
      
                                
      
                                    
                                    Re: Pywebdriver in the OCA
                                
      
                                
      Great!

      Thanks for digging up that subject.

      IMHO, this could be an interesting value added for OCA.



      On Tue, Dec 22, 2020 at 3:16 PM Pierrick Brun <pierrick.brun@akretion.com> wrote:
      Hello everyone,


As some of you might know, at Akretion we use a replacement tool for
the IoT box, which is called Pywebdriver.

We are currently maintaining it with other OCA members like Acsone or
GRAP.

We thought this could be a good idea to have this tool under the OCA
umbrella to ease the workflows around it.


Since this differs from the usual repositories the OCA manages, I
created an issue to discuss around this possible inclusion:
https://github.com/akretion/pywebdriver/issues/57


Looking forward to read from you about this !




-- 
Pierrick Brun
Akretion


      


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



      -- 
      __________________________________________
      Denis Roussel
      Software Engineer
      Acsone SA, Succursale de Liège (Val Benoît)
      Tel    : +32 2 888 31 49
      Fax   : +32 2 888 31 59
      Gsm : +32 472 22 00 57 

      Acsone sa/nv
      Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels  | Belgium
      Quai Banning, 6 (Val Benoît) | B-4000 Liège | Belgium
      Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
      

      
        
      
        
            
                by
                Denis Roussel.
            
            -
            
                
                03:30 - 22 Dec 2020
            
        
        
      
            
      
                
            
      
        
      
                            
      
                        
      
                    
      
                
      • 
            
    
        
    
                            
    
                        
    
                    
    
                
    •