Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • OCA module contributors and migrations
    Hi,

    This is about what counts as valid "contribution", that is, what you need to do to be added in the CONTRIBUTORS.rst file.

    In some (most?) cases, a migration is not a huge amount of work. In some cases, it can represent a lot of work.

    So it is arguable whether you should add yourself during migration commits.

    In discussions on Github, I have seen differing opinions on this subject. Some think it "cheapens" the contributor list that you add yourself if you just did a migration commit.

    I would lean towards adding yourself in any case a contributor anyways, since even if it's small it is still work, and should be recognized. Commit history is still there if you're interested in how much anyone contributed.

    Maybe there is already a consensus that I'm not aware of ? What do you think ?

    by "Kevin Khao" <kevin.khao@akretion.com.br> - 04:46 - 13 Jul 2021

    10 replies 10 replies

    • Re: OCA module contributors and migrations
      +1 Jairo

      El jue, 15 jul 2021 a las 11:07, Jairo Llopis (<jairo.llopis@tecnativa.com>) escribió:
      El jue, 15 de jul de 2021 a las 07:32:02 AM, Harald Panten Lopez <harald.panten@sygel.es> escribió:
      I think the responsibility to control these "fake contributors" shouldn't be for the modules authors but for PSC.

      Don't you think so?

      If a spammer properly migrates a module, let him spam!

      If he just fixes one typo in the readme, block that from being added to contributors.

      I think spam contributions are a valid point, but still anything like that should be recorded in the contribution guidelines too. How to identify a spammy contribution is a subject in itself that is interesting not only for OCA, so if somebody has a study on that, it would help here.

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



      --

       

      Harald Panten López

      CEO

      Sygel Technology S.L

      		 
      		+34 637 88 42 41
      		harald.panten@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona
       
       
       
      by Harald Panten Lopez - 12:06 - 15 Jul 2021
    • Re: OCA module contributors and migrations
      El jue, 15 de jul de 2021 a las 07:32:02 AM, Harald Panten Lopez <harald.panten@sygel.es> escribió:
      I think the responsibility to control these "fake contributors" shouldn't be for the modules authors but for PSC.

      Don't you think so?

      If a spammer properly migrates a module, let him spam!

      If he just fixes one typo in the readme, block that from being added to contributors.

      I think spam contributions are a valid point, but still anything like that should be recorded in the contribution guidelines too. How to identify a spammy contribution is a subject in itself that is interesting not only for OCA, so if somebody has a study on that, it would help here.
      by Jairo Llopis - 11:06 - 15 Jul 2021
    • Re: OCA module contributors and migrations
      Hi Raphaël,

      I think the responsibility to control these "fake contributors" shouldn't be for the modules authors but for PSC.

      Don't you think so?

      El mié, 14 jul 2021 a las 19:42, Raphaël Valyi (<rvalyi@akretion.com>) escribió:
      Hello,

      I think it should be up to modules authors to decide if a contribution is worth getting mentioned or not as in any open source project. Don't like it? Then fork, but make sure you can do better or go back to your place. Indeed we already see some kind of "contribution squatting". I won't give names here but I have seen people forcing new pointless features into famous modules just to drive attention to their own company. This is very real already... Usually people doing this are not serious people, their trivial work won't be missed.

      And it didn't stop there, in some project you got noobs artificially inflating their image with non relevant contribs and starting to get their noob employee destroy serious modules... In Brazil so many companies failed their project because this kind of un responsable behaviors from noobs trying to auto promote them as expert at any cost to make a dent in the saas business...

      If you state rules like any tiny contrib is with a mention, soon enough you'll have contribution trolling exploding, just like during the Hacktober fest when gazillions of people were making pointless PRs to any project just to win a free T-shirt. Now think about getting it's company named along with Tecnativa or CamToCamp...

      This is sad, but this is the wild world we live in. Instead when module authors decide, then real efforts can be rewarded and notoriety squating may be avoided.

      Also bare in mind that one can always see the number of commits and lines changed in any git(hub) repo, so it's not like it's invisible either...


      On Wed, Jul 14, 2021, 6:26 AM Harald Panten Lopez <harald.panten@sygel.es> wrote:
      I think any migration should be considered as a contribution. As some of you said before, that may encourage more users to contribute.

      Any migration (even if it's a standard migration) needs an investment of time. On the other hand, when a user starts a migration he/she is "open" to receive suggestions, changes... Any migration is liable to become a headache.

      I agree that correcting a small typo (for example) wouldn't be enough for being considered as a contributor.

      Regards.

      El mié, 14 jul 2021 a las 9:17, Jairo Llopis (<jairo.llopis@tecnativa.com>) escribió:
      El mar, 13 de jul de 2021 a las 15:37:13 PM, David Beal <david.beal@akretion.com> escribió:
      A point of view could be that contributors should be someone who can answer any questions about the module in the future.
      Then it should have the expertise on the topic to do it.

      That sounds more like a maintainer.

      El mar, 13 de jul de 2021 a las 15:37:12 PM, Tom Blauwendraat <tom@sunflowerweb.nl> escribió:

      - The "authors" list in manifest is something you want to keep small and just for important companies which contributed to the development, since it's also ugly when it's very long

      - The contributors list in README can be as long as you want because it's not directly in anyone's view IMO - and I think any "thank you" that we can give people that invest their time in OCA, should be given

      Just if people themselves feel their contribution is not worth a lot they can just not add it


      100% agree.

      As a side note, remember that there are plenty of ways to contribute to a module without writing a single line of code.

      OCA should be generous in this kind of attribution. That will encourage people to contribute more.

      This should be hardcoded in the guidelines though.

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



      --

       

      Harald Panten López

      CEO

      Sygel Technology S.L

      		 
      		+34 637 88 42 41
      		harald.panten@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona
       
       
       

      _______________________________________________
      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



      --

       

      Harald Panten López

      CEO

      Sygel Technology S.L

      		 
      		+34 637 88 42 41
      		harald.panten@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona
       
       
       
      by Harald Panten Lopez - 09:30 - 15 Jul 2021
    • Re: OCA module contributors and migrations
      Hello,

      I think it should be up to modules authors to decide if a contribution is worth getting mentioned or not as in any open source project. Don't like it? Then fork, but make sure you can do better or go back to your place. Indeed we already see some kind of "contribution squatting". I won't give names here but I have seen people forcing new pointless features into famous modules just to drive attention to their own company. This is very real already... Usually people doing this are not serious people, their trivial work won't be missed.

      And it didn't stop there, in some project you got noobs artificially inflating their image with non relevant contribs and starting to get their noob employee destroy serious modules... In Brazil so many companies failed their project because this kind of un responsable behaviors from noobs trying to auto promote them as expert at any cost to make a dent in the saas business...

      If you state rules like any tiny contrib is with a mention, soon enough you'll have contribution trolling exploding, just like during the Hacktober fest when gazillions of people were making pointless PRs to any project just to win a free T-shirt. Now think about getting it's company named along with Tecnativa or CamToCamp...

      This is sad, but this is the wild world we live in. Instead when module authors decide, then real efforts can be rewarded and notoriety squating may be avoided.

      Also bare in mind that one can always see the number of commits and lines changed in any git(hub) repo, so it's not like it's invisible either...


      On Wed, Jul 14, 2021, 6:26 AM Harald Panten Lopez <harald.panten@sygel.es> wrote:
      I think any migration should be considered as a contribution. As some of you said before, that may encourage more users to contribute.

      Any migration (even if it's a standard migration) needs an investment of time. On the other hand, when a user starts a migration he/she is "open" to receive suggestions, changes... Any migration is liable to become a headache.

      I agree that correcting a small typo (for example) wouldn't be enough for being considered as a contributor.

      Regards.

      El mié, 14 jul 2021 a las 9:17, Jairo Llopis (<jairo.llopis@tecnativa.com>) escribió:
      El mar, 13 de jul de 2021 a las 15:37:13 PM, David Beal <david.beal@akretion.com> escribió:
      A point of view could be that contributors should be someone who can answer any questions about the module in the future.
      Then it should have the expertise on the topic to do it.

      That sounds more like a maintainer.

      El mar, 13 de jul de 2021 a las 15:37:12 PM, Tom Blauwendraat <tom@sunflowerweb.nl> escribió:

      - The "authors" list in manifest is something you want to keep small and just for important companies which contributed to the development, since it's also ugly when it's very long

      - The contributors list in README can be as long as you want because it's not directly in anyone's view IMO - and I think any "thank you" that we can give people that invest their time in OCA, should be given

      Just if people themselves feel their contribution is not worth a lot they can just not add it


      100% agree.

      As a side note, remember that there are plenty of ways to contribute to a module without writing a single line of code.

      OCA should be generous in this kind of attribution. That will encourage people to contribute more.

      This should be hardcoded in the guidelines though.

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



      --

       

      Harald Panten López

      CEO

      Sygel Technology S.L

      		 
      		+34 637 88 42 41
      		harald.panten@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona
       
       
       

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

      by "Raphaël Valyi" <rvalyi@akretion.com> - 07:41 - 14 Jul 2021
    • Re: OCA module contributors and migrations
      I think any migration should be considered as a contribution. As some of you said before, that may encourage more users to contribute.

      Any migration (even if it's a standard migration) needs an investment of time. On the other hand, when a user starts a migration he/she is "open" to receive suggestions, changes... Any migration is liable to become a headache.

      I agree that correcting a small typo (for example) wouldn't be enough for being considered as a contributor.

      Regards.

      El mié, 14 jul 2021 a las 9:17, Jairo Llopis (<jairo.llopis@tecnativa.com>) escribió:
      El mar, 13 de jul de 2021 a las 15:37:13 PM, David Beal <david.beal@akretion.com> escribió:
      A point of view could be that contributors should be someone who can answer any questions about the module in the future.
      Then it should have the expertise on the topic to do it.

      That sounds more like a maintainer.

      El mar, 13 de jul de 2021 a las 15:37:12 PM, Tom Blauwendraat <tom@sunflowerweb.nl> escribió:

      - The "authors" list in manifest is something you want to keep small and just for important companies which contributed to the development, since it's also ugly when it's very long

      - The contributors list in README can be as long as you want because it's not directly in anyone's view IMO - and I think any "thank you" that we can give people that invest their time in OCA, should be given

      Just if people themselves feel their contribution is not worth a lot they can just not add it


      100% agree.

      As a side note, remember that there are plenty of ways to contribute to a module without writing a single line of code.

      OCA should be generous in this kind of attribution. That will encourage people to contribute more.

      This should be hardcoded in the guidelines though.

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



      --

       

      Harald Panten López

      CEO

      Sygel Technology S.L

      		 
      		+34 637 88 42 41
      		harald.panten@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona
       
       
       
      by Harald Panten Lopez - 11:25 - 14 Jul 2021

  • Oracle to Odoo migration

    Hi Colleagues,

    I am looking for a successful project of migration from Oracle to Odoo.

    We are on the point of decision making and the Finance team would like to get a reference call with a such customer.

    Might be anybody can share the customer contacts details with whom we can arrange a call.  

    Thank you!

    Alexey

     

     

    by Alexey - 05:51 - 12 Jul 2021
  • MS Power BI Users Database

    Hi,

     

    We’d like to know if you’re interested in acquiring the Opt-in contacts of below-mentioned technologies users which will help you grab new clients for your business.

     

    ·         Microsoft Power BI

    ·         Tableau Desktop

    ·         Qlik Sense

    ·         SAP BusinessObjects BI Suite

    ·         Sisense

    ·         Microstrategy

    ·         TIBCO Spotfire

    ·         IBM Cognos Analytics and more

     

    Data can be filtered depending on the requirements (e.g. Job title, Verticals, Geography, etc.)

     

    Please review and let me know your interest and I will provide you with detailed information.

     

    Looking forward to hearing from you.

     

    Regards,

    Laura Bishop

    Demand Generation Head

     

    Not interested reply with “Opt-Out”

    by "Laura Bishop" <laura.bishop@infradatabase.com> - 06:01 - 8 Jul 2021
  • Import data from incoming email
    Hi,

    Do we have a module in OCA that can help importing data send as an email attachment?

    Thank you

     --
    Yves Goldberg
    --

    by Yves Goldberg - 01:11 - 8 Jul 2021

    2 replies 2 replies

  • Re: Odoo automatic code documentation
    Dear, Tom, Daniel and David,

    Many thanks for your replies. 

    Generally it does work this way, and it nicely reveals which coding  artist is doing what amount of documentation to the extent of readability for the other developers. 

    However, we went into an issue, when it comes to recursions: here the running of the Python code is frequently running into an endless loop.

    Is there any kind of switch in odoo, that prevents this behavior like "maximum depth of recursion loops"


    Best, Joe


    -------- Ursprüngliche Nachricht --------
    Von: Daniel Reis <dreis@opensourceintegrators.com>
    Datum: 24.06.21 15:17 (GMT+01:00)
    An: Contributors <contributors@odoo-community.org>
    Betreff: Re: Odoo automatic code documentation

    Hello,

    Try "cd /path/to/odoo && pip install ."
    You will then be able to "import odoo"

    Thanks
    Daniel

    On 24/06/2021 09:42, Joerg Lorenz wrote:
    Hi Guys, today we are asking for your insightfullness.
    Our quest:  how the python code of odoo can be automatically documented from the code itself. 

    But the approach with the various toos that there are fails:  

    We have tested: 

    • pdoc, a simple Python 3 command line tool and library to auto-generate API documentation for Python modules. Supports Numpydoc / Google-style docstrings, doctests, reST directives, PEP 484 type annotations, custom templates ...

    • pdoc3, a fork of pdoc for Python 3 with support for Numpydoc / Google-style docstrings, doctests, LaTeX math, reST directives, PEP 484 type annotations, custom templates ...

    • PyDoc, a documentation browser (in HTML) and/or an off-line reference manual. Also in the standard library as pydoc.

    • pydoctor, a replacement for now inactive Epydoc, born for the needs of Twisted project.

    and all of them fail.  It has to do that odoo as such is not a python module itself and thus cannot be imported. 

    problem in models/res_company.py - <type 'exceptions.ImportError'>: No module named odoo

    If anyone has some experience, ideas, or pointer towards a solution, it would be highly appreaciated. 

    Best, Joe

    _______________________________________________
    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. Republica 3000, Edificio Estoril Office, B Piso 3 - 34 • 2649-517 Alcabideche, Portugal


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

    by "joergl" <joergl@itis.de> - 12:00 - 7 Jul 2021
  • l10n-italy 14.0 on apps.odoo.com

    Hi all,

    is it possible to check if there are problems or conflicts with l10n-italy 14.0 and apps.odoo.com ?

    thank you

    --
    Andrea Cometa - Presidente Associazione Odoo Italia
    Apulia Software srl - Responsabile Commerciale ed Amministrativo
    Taranto / Milano / Potenza
    Tel: 0999915404 http://www.apuliasoftware.it
    a.cometa@apuliasoftware.it pec: apulia.software@pec.it
    linkedin: http://it.linkedin.com/in/andreacometa
    by Andrea Cometa - 10:25 - 7 Jul 2021

    1 replies 1 replies

  • We found our Communication Agency!
    Hello Community,

    The board has a great news to share: 
    We found our Communication Agency!

    To discover who will share this adventure with us, read this article on our blog.
    We'll come back to you soon to get you on board.

    Have a nice day and enjoy your week-end!
    Virginie
    0477/64.17.20
    by Virginie Dewulf. - 08:06 - 2 Jul 2021
  • Odoo automatic code documentation
    Hi Guys, today we are asking for your insightfullness.
    Our quest:  how the python code of odoo can be automatically documented from the code itself. 

    But the approach with the various toos that there are fails:  

    We have tested: 

    • pdoc, a simple Python 3 command line tool and library to auto-generate API documentation for Python modules. Supports Numpydoc / Google-style docstrings, doctests, reST directives, PEP 484 type annotations, custom templates ...

    • pdoc3, a fork of pdoc for Python 3 with support for Numpydoc / Google-style docstrings, doctests, LaTeX math, reST directives, PEP 484 type annotations, custom templates ...

    • PyDoc, a documentation browser (in HTML) and/or an off-line reference manual. Also in the standard library as pydoc.

    • pydoctor, a replacement for now inactive Epydoc, born for the needs of Twisted project.

    and all of them fail.  It has to do that odoo as such is not a python module itself and thus cannot be imported. 

    problem in models/res_company.py - <type 'exceptions.ImportError'>: No module named odoo

    If anyone has some experience, ideas, or pointer towards a solution, it would be highly appreaciated. 

    Best, Joe
    by Joerg Lorenz. - 10:41 - 24 Jun 2021

    3 replies 3 replies

    • Re: Odoo automatic code documentation
      Hi,

      You may probably use https://github.com/acsone/click-odoo and build your own python package.


      Specifically about Odoo, we could imagine generating functional documentation coming from code split by models.
      We all have a lot of custom code in our projects.

      There is a major problem with custom code:
      Your colleagues who know odoo perfectly and are aware of OCA modules don't know the specificity of your project.
      Then to quickly dive into your project, it could be sufficient to read documentation from the custom part of the project.

      But as you know, documentation lies, not the code.

      So if functional doc is near the code (then attached to a model), then it could be easier to be updated.

      Everybody could win: consultant and customer.

      My 2 cts

      Regards

      David BEAL
      Consultant ERP Odoo


      Le jeu. 24 juin 2021 à 15:17, Daniel Reis <dreis@opensourceintegrators.com> a écrit :
      Hello,

      Try "cd /path/to/odoo && pip install ."
      You will then be able to "import odoo"

      Thanks
      Daniel

      On 24/06/2021 09:42, Joerg Lorenz wrote:
      Hi Guys, today we are asking for your insightfullness.
      Our quest:  how the python code of odoo can be automatically documented from the code itself. 

      But the approach with the various toos that there are fails:  

      We have tested: 

      • pdoc, a simple Python 3 command line tool and library to auto-generate API documentation for Python modules. Supports Numpydoc / Google-style docstrings, doctests, reST directives, PEP 484 type annotations, custom templates ...

      • pdoc3, a fork of pdoc for Python 3 with support for Numpydoc / Google-style docstrings, doctests, LaTeX math, reST directives, PEP 484 type annotations, custom templates ...

      • PyDoc, a documentation browser (in HTML) and/or an off-line reference manual. Also in the standard library as pydoc.

      • pydoctor, a replacement for now inactive Epydoc, born for the needs of Twisted project.

      and all of them fail.  It has to do that odoo as such is not a python module itself and thus cannot be imported. 

      problem in models/res_company.py - <type 'exceptions.ImportError'>: No module named odoo

      If anyone has some experience, ideas, or pointer towards a solution, it would be highly appreaciated. 

      Best, Joe

      _______________________________________________
      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. Republica 3000, Edificio Estoril Office, B Piso 3 - 34 • 2649-517 Alcabideche, Portugal


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

      by David BEAL - 05:05 - 24 Jun 2021
    • Re: Odoo automatic code documentation
      Hello,

      Try "cd /path/to/odoo && pip install ."
      You will then be able to "import odoo"

      Thanks
      Daniel

      On 24/06/2021 09:42, Joerg Lorenz wrote:
      Hi Guys, today we are asking for your insightfullness.
      Our quest:  how the python code of odoo can be automatically documented from the code itself. 

      But the approach with the various toos that there are fails:  

      We have tested: 

      • pdoc, a simple Python 3 command line tool and library to auto-generate API documentation for Python modules. Supports Numpydoc / Google-style docstrings, doctests, reST directives, PEP 484 type annotations, custom templates ...

      • pdoc3, a fork of pdoc for Python 3 with support for Numpydoc / Google-style docstrings, doctests, LaTeX math, reST directives, PEP 484 type annotations, custom templates ...

      • PyDoc, a documentation browser (in HTML) and/or an off-line reference manual. Also in the standard library as pydoc.

      • pydoctor, a replacement for now inactive Epydoc, born for the needs of Twisted project.

      and all of them fail.  It has to do that odoo as such is not a python module itself and thus cannot be imported. 

      problem in models/res_company.py - <type 'exceptions.ImportError'>: No module named odoo

      If anyone has some experience, ideas, or pointer towards a solution, it would be highly appreaciated. 

      Best, Joe

      _______________________________________________
      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. Republica 3000, Edificio Estoril Office, B Piso 3 - 34 • 2649-517 Alcabideche, Portugal


      by Daniel Reis - 03:16 - 24 Jun 2021
    • Re: Odoo automatic code documentation

      Hi Joerg

      when using an Odoo installation framework such as Doodba or Waft, the package "odoo" is installed in the (virtual) environment at the end, making it available to everything that runs in the venv.

      Am sure that it can also be achieved easily without using those frameworks, using 'pip install' directly, but I didn't try...

      https://github.com/Tecnativa/doodba/blob/master/build.d/700-odoo-install

      Tom


      Op 6/24/21 om 10:42 AM schreef Joerg Lorenz:
      Hi Guys, today we are asking for your insightfullness.
      Our quest:  how the python code of odoo can be automatically documented from the code itself. 

      But the approach with the various toos that there are fails:  

      We have tested: 

      • pdoc, a simple Python 3 command line tool and library to auto-generate API documentation for Python modules. Supports Numpydoc / Google-style docstrings, doctests, reST directives, PEP 484 type annotations, custom templates ...

      • pdoc3, a fork of pdoc for Python 3 with support for Numpydoc / Google-style docstrings, doctests, LaTeX math, reST directives, PEP 484 type annotations, custom templates ...

      • PyDoc, a documentation browser (in HTML) and/or an off-line reference manual. Also in the standard library as pydoc.

      • pydoctor, a replacement for now inactive Epydoc, born for the needs of Twisted project.

      and all of them fail.  It has to do that odoo as such is not a python module itself and thus cannot be imported. 

      problem in models/res_company.py - <type 'exceptions.ImportError'>: No module named odoo

      If anyone has some experience, ideas, or pointer towards a solution, it would be highly appreaciated. 

      Best, Joe

      _______________________________________________
      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 - 11:01 - 24 Jun 2021
  • OCA Codesprint 2021/2022 - help us choose the dates
    Dear OCA Contributors,

    I hope this finds you all well.

    We are getting ourselves geared for the OCA Days 2021 - 28th- 29th October.
    With the caliber of talks given during the online event in 2020 we found that the codesprint side of things wasn't as well attended due to people not wanting to miss out on the presentations.

    There has been discussion within the OCA Board about delaying the codesprint to help accommodate the busy time. We wanted to get a gauge from you, the Community, as to which dates/time of year  people think would work.

    We are conscious when having 3 events (Odoo XP, OCA Days Talks and OCA Days Codesprint) of interest so close together, it can be difficult for attendees to juggle these events with work. High on our list of criteria is trying to find a time slot close enough (but not too close to the other events) that it wouldn't interfere with expected outcomes within your companies and mean a high attendance at the codesprint.

    A quick survey has been set up below - please take a minute (it is less than a minute really) to complete to help.
    We appreciate your time in helping us get the best dates for the next OCA codesprint.

    Warmest regards,
    Rebecca
    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly - 02:30 - 22 Jun 2021
  • Proposing dalonsod as PSC for Helpdesk
    Hi!

    https://github.com/dalonsod has been actively developing the helpdesk repository for some time, being probably the most active user in contributions and reviews (https://github.com/OCA/helpdesk/issues?q=dalonsod)
    So I think he would be an active member and add a lot of value to the maintenance of the  helpdesk repository.


    by dariodafoz - 03:16 - 18 Jun 2021

    6 replies 6 replies

  • Hardware revisions in Odoo
    Dear OCA friends,

    I've been searching recently for some community modules to handle hardware revisions in Odoo. Surprisingly, I haven't found any serious module to handle hardware revisions. The only OCA module I found is this one, but it's very limited :

    Did I miss something?

    I wrote a draft specification of a potential new module to handle hardware revision :
    The main difficulty in this specification is: we want a hardware revision on BOMs, but do we want a hardware revision on BOM lines ? If yes, how do we apply this constraint ?

    I would be happy to have your input and experience on this topic.

    --
    Alexis de Lattre
    by Alexis de Lattre - 12:50 - 16 Jun 2021

    4 replies 4 replies

  • Full text search
    Hello everyone,

    I remember some discussion about implementing full text search for Odoo, but I can't find any module or work in progress.

    Do you have any pointers?

    Thanks!

    --
    by Lorenzo Battistini. - 11:26 - 15 Jun 2021

    20 replies 20 replies

    • Re: Full text search
      Hi Lorenzo,
      I agree that having an implementation of postgres full text search would be a great improvement and would solve many use cases without needed integrations and other softwares.

      The Holger module could be a good starting point https://github.com/Therp/fulltextsearch

      I believe it would be great to make an implementation of full text search configurable by the user on each model similar as done here. Basically it would be:
      * user can choose on each models fields to be included on the full text search
      * user can choose to enable that search as the "name_search" one
      * user can choose to enable "smart search" it would be the first available option on the "search view" that would implement the full text search.

      So, for eg:
      * user choose on product.product the following fields to be used: name, barcode, default_code, brand
      * user enable "smart search" + " name search"
      * then:
      a) on a sale order, user can search a product with a very flexible way
      b) on the product.product tree view user can search with same flexible way

      All this searches are already implemented with native "ilike" searches but are not so powerful and performant. It's also integrated on ecommerce here

       


      Ing. Juan José Scarafía

      (+54 9 341) 3 278039

      twitter: @jjscarafia

      github: @jjscarafia



      El mar, 22 de jun. de 2021 a la(s) 06:22, Lorenzo Battistini (elbaddy@gmail.com) escribió:
      Thanks everyone for your helpful advice.

      My primary goal is to improve search mechanisms of some frontend pages, like e-commerce products or slides.
      Of course a solution at framework level, which would allow to apply the improved search to any model, would be great.

      I like the postgres approach because
      1. It seems powerful enough to cover our needs
      2. We don't have to install other (big) softwares, hard and onerous to maintain
      So, in the first place, I will have a look at Holger's and Anders's works.

      Thanks a lot!


      On Tue, 22 Jun 2021 at 08:12, Mignon, Laurent <laurent.mignon@acsone.eu> wrote:
      Hello everyone,

      I think Simone has given a good summary of the problem. I don't have much more to say. I would however just like to clarify a technical point about https://github.com/OCA/search-engine and more specifically the module dedicated to Elasticsearch. This module has been developed based of versions of Elasticsearch licensed under Apache 2.0. This module uses a limited number of methods from the api provided by Elasticsearch to publish and synchronize data in the indexes. I have personally used it with the Opendistro distribution of ES and I am confident that it will work seamlessly with Opensearh (https://opensearch.org/) which is a fork of ES based on the latest version released under Apache 2.0. If this is not the case, it is very likely that the adaptations to be made will be minor. These are just a few technical considerations of no importance until the functional needs are clearly defined.

      Regards,

      lmi


      On Tue, Jun 22, 2021 at 7:27 AM Simone Orsi <simahawk@gmail.com> wrote:
      Hello everyone,

      guys, let's get back on track! I think none of these topics is relevant for Lorenzo. At least not at this stage.
      Nobody is asking what's the final goal. Me included ;)

      @Lorenzo: What are you looking for?

      From my perspective:

      a) if you need something pluggable in the backend, something that works w/ "normal" odoo models you should have a look at what Holger did. It's a bit complex and many implementation details should be rewritten completely but it gives you an idea on how to get there.

      b) If you need something for the frontend, I'd definitely go for ES (especially if you want faceted search). Once you have ES in place you can use SearchKit JS to easily build a search UI.

      c) If you don't want to maintain the search engine and you want a reliable and easy to use configuration you can use Algolia (yes, a proprietary servivce! :P)  but watch out because it can be very expensive.

      Both b and c are feasible w/ the search-engine framework.

      d) If you only need a full text index for one very particular model in one very particular form, I'd go for basic postgres full text indexing + some custom code.

      HTH. If you need help on setting up the search engine stuff let me know ;)

      Bests,

      On Mon, Jun 21, 2021 at 8:57 PM Frederik Kramer <frederik.kramer@initos.com> wrote:
      Holger of course you are right, 

but just hiding crap in a container doesn't make it significantly less
cumbersome at the detailed level. But of course if you have a nicely
built docker-compose oder kubernetes service defintion at hand much is
done anywhere else an you only have to handle ENV variables.

Best
Frederik

Am Montag, den 21.06.2021, 18:31 +0000 schrieb Holger Brunn:





> > Neverthless all Java ;-)





> 





> when I was young I would complain about Java, but now you just stick





> it into a 





> container and be done with it





> _______________________________________________





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





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





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





-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

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



      --
      Simone Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.

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

      _______________________________________________
      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 José Scarafía - 04:16 - 23 Jun 2021
    • Re: Full text search
      Thanks everyone for your helpful advice.

      My primary goal is to improve search mechanisms of some frontend pages, like e-commerce products or slides.
      Of course a solution at framework level, which would allow to apply the improved search to any model, would be great.

      I like the postgres approach because
      1. It seems powerful enough to cover our needs
      2. We don't have to install other (big) softwares, hard and onerous to maintain
      So, in the first place, I will have a look at Holger's and Anders's works.

      Thanks a lot!


      On Tue, 22 Jun 2021 at 08:12, Mignon, Laurent <laurent.mignon@acsone.eu> wrote:
      Hello everyone,

      I think Simone has given a good summary of the problem. I don't have much more to say. I would however just like to clarify a technical point about https://github.com/OCA/search-engine and more specifically the module dedicated to Elasticsearch. This module has been developed based of versions of Elasticsearch licensed under Apache 2.0. This module uses a limited number of methods from the api provided by Elasticsearch to publish and synchronize data in the indexes. I have personally used it with the Opendistro distribution of ES and I am confident that it will work seamlessly with Opensearh (https://opensearch.org/) which is a fork of ES based on the latest version released under Apache 2.0. If this is not the case, it is very likely that the adaptations to be made will be minor. These are just a few technical considerations of no importance until the functional needs are clearly defined.

      Regards,

      lmi


      On Tue, Jun 22, 2021 at 7:27 AM Simone Orsi <simahawk@gmail.com> wrote:
      Hello everyone,

      guys, let's get back on track! I think none of these topics is relevant for Lorenzo. At least not at this stage.
      Nobody is asking what's the final goal. Me included ;)

      @Lorenzo: What are you looking for?

      From my perspective:

      a) if you need something pluggable in the backend, something that works w/ "normal" odoo models you should have a look at what Holger did. It's a bit complex and many implementation details should be rewritten completely but it gives you an idea on how to get there.

      b) If you need something for the frontend, I'd definitely go for ES (especially if you want faceted search). Once you have ES in place you can use SearchKit JS to easily build a search UI.

      c) If you don't want to maintain the search engine and you want a reliable and easy to use configuration you can use Algolia (yes, a proprietary servivce! :P)  but watch out because it can be very expensive.

      Both b and c are feasible w/ the search-engine framework.

      d) If you only need a full text index for one very particular model in one very particular form, I'd go for basic postgres full text indexing + some custom code.

      HTH. If you need help on setting up the search engine stuff let me know ;)

      Bests,

      On Mon, Jun 21, 2021 at 8:57 PM Frederik Kramer <frederik.kramer@initos.com> wrote:
      Holger of course you are right, 

but just hiding crap in a container doesn't make it significantly less
cumbersome at the detailed level. But of course if you have a nicely
built docker-compose oder kubernetes service defintion at hand much is
done anywhere else an you only have to handle ENV variables.

Best
Frederik

Am Montag, den 21.06.2021, 18:31 +0000 schrieb Holger Brunn:




> > Neverthless all Java ;-)




> 




> when I was young I would complain about Java, but now you just stick




> it into a 




> container and be done with it




> _______________________________________________




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




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




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




-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

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



      --
      Simone Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.

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

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



      --
      by Lorenzo Battistini. - 11:21 - 22 Jun 2021
    • Re: Full text search
      Hello everyone,

      I think Simone has given a good summary of the problem. I don't have much more to say. I would however just like to clarify a technical point about https://github.com/OCA/search-engine and more specifically the module dedicated to Elasticsearch. This module has been developed based of versions of Elasticsearch licensed under Apache 2.0. This module uses a limited number of methods from the api provided by Elasticsearch to publish and synchronize data in the indexes. I have personally used it with the Opendistro distribution of ES and I am confident that it will work seamlessly with Opensearh (https://opensearch.org/) which is a fork of ES based on the latest version released under Apache 2.0. If this is not the case, it is very likely that the adaptations to be made will be minor. These are just a few technical considerations of no importance until the functional needs are clearly defined.

      Regards,

      lmi


      On Tue, Jun 22, 2021 at 7:27 AM Simone Orsi <simahawk@gmail.com> wrote:
      Hello everyone,

      guys, let's get back on track! I think none of these topics is relevant for Lorenzo. At least not at this stage.
      Nobody is asking what's the final goal. Me included ;)

      @Lorenzo: What are you looking for?

      From my perspective:

      a) if you need something pluggable in the backend, something that works w/ "normal" odoo models you should have a look at what Holger did. It's a bit complex and many implementation details should be rewritten completely but it gives you an idea on how to get there.

      b) If you need something for the frontend, I'd definitely go for ES (especially if you want faceted search). Once you have ES in place you can use SearchKit JS to easily build a search UI.

      c) If you don't want to maintain the search engine and you want a reliable and easy to use configuration you can use Algolia (yes, a proprietary servivce! :P)  but watch out because it can be very expensive.

      Both b and c are feasible w/ the search-engine framework.

      d) If you only need a full text index for one very particular model in one very particular form, I'd go for basic postgres full text indexing + some custom code.

      HTH. If you need help on setting up the search engine stuff let me know ;)

      Bests,

      On Mon, Jun 21, 2021 at 8:57 PM Frederik Kramer <frederik.kramer@initos.com> wrote:
      Holger of course you are right, 

but just hiding crap in a container doesn't make it significantly less
cumbersome at the detailed level. But of course if you have a nicely
built docker-compose oder kubernetes service defintion at hand much is
done anywhere else an you only have to handle ENV variables.

Best
Frederik

Am Montag, den 21.06.2021, 18:31 +0000 schrieb Holger Brunn:



> > Neverthless all Java ;-)



> 



> when I was young I would complain about Java, but now you just stick



> it into a 



> container and be done with it



> _______________________________________________



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



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



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



-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

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



      --
      Simone Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.

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

      by Laurent Mignon - 08:11 - 22 Jun 2021
    • Re: Full text search
      Hello everyone,

      guys, let's get back on track! I think none of these topics is relevant for Lorenzo. At least not at this stage.
      Nobody is asking what's the final goal. Me included ;)

      @Lorenzo: What are you looking for?

      From my perspective:

      a) if you need something pluggable in the backend, something that works w/ "normal" odoo models you should have a look at what Holger did. It's a bit complex and many implementation details should be rewritten completely but it gives you an idea on how to get there.

      b) If you need something for the frontend, I'd definitely go for ES (especially if you want faceted search). Once you have ES in place you can use SearchKit JS to easily build a search UI.

      c) If you don't want to maintain the search engine and you want a reliable and easy to use configuration you can use Algolia (yes, a proprietary servivce! :P)  but watch out because it can be very expensive.

      Both b and c are feasible w/ the search-engine framework.

      d) If you only need a full text index for one very particular model in one very particular form, I'd go for basic postgres full text indexing + some custom code.

      HTH. If you need help on setting up the search engine stuff let me know ;)

      Bests,

      On Mon, Jun 21, 2021 at 8:57 PM Frederik Kramer <frederik.kramer@initos.com> wrote:
      Holger of course you are right, 

but just hiding crap in a container doesn't make it significantly less
cumbersome at the detailed level. But of course if you have a nicely
built docker-compose oder kubernetes service defintion at hand much is
done anywhere else an you only have to handle ENV variables.

Best
Frederik

Am Montag, den 21.06.2021, 18:31 +0000 schrieb Holger Brunn:


> > Neverthless all Java ;-)


> 


> when I was young I would complain about Java, but now you just stick


> it into a 


> container and be done with it


> _______________________________________________


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


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


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


-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

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



      --
      Simone Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
      by Simone Orsi. - 07:26 - 22 Jun 2021
    • Re: Full text search 
      Holger of course you are right, 

but just hiding crap in a container doesn't make it significantly less
cumbersome at the detailed level. But of course if you have a nicely
built docker-compose oder kubernetes service defintion at hand much is
done anywhere else an you only have to handle ENV variables.

Best
Frederik

Am Montag, den 21.06.2021, 18:31 +0000 schrieb Holger Brunn:

> > Neverthless all Java ;-)

> 

> when I was young I would complain about Java, but now you just stick

> it into a 

> container and be done with it

> _______________________________________________

> 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. - 08:55 - 21 Jun 2021

  • Odoo Customer List.

    Hello,

     

    I would like to know if you are interested in acquiring Odoo Customer List.

    Information fields: Names, Title, Email, Phone, Company Name, Company URL, Company physical address, SIC Code, Industry and Specialty (Revenue and Employee).

     

    Let me know if you are interested and I will get back to you with the counts and pricing.                                

                                                                                                                     

    Shanika Rathnayake

    Marketing Executive

     

    Please get back to me with your target market criteria in the subject line.

                                                                                                                                                                              

     

     

                   

     

     

     

     

     

     

     

                                            

    by "Shanika Rathnayake" <shanika.rathnayake@instantleads.tech> - 07:51 - 10 Jun 2021
  • European Union One-Stop-Shop
    Hi Community,

    As you know, a major tax change will be implemented shortly (1st of July) that will affect all EU countries.

    More info:
    https://ec.europa.eu/taxation_customs/business/vat/oss_en

    For the newest versions, (from V14) Odoo is planning a "kind of solution", but what happens with older versions? Is any European partner working on this?

    Some of the Spanish partners started this project, and we were wondering if anybody else will do the same. The main idea is to "join our efforts" and offer a global solution according to the ideology proposed by OCA.

    Regards,
    --

    Harald Panten López

    CEO

    Sygel Technology S.L

    		+34 637 88 42 41
    		harald.panten@sygel.es
    		https://www.sygel.es
    		C/ Àlaba 61, 5ª planta, 08005, Barcelona
    by Harald Panten Lopez - 12:26 - 10 Jun 2021

    22 replies 22 replies

    • Re: European Union One-Stop-Shop
      Hello all,

      A quick update on this.

      There was a great team effort on this feature, to develop, review and port across multiple Odoo versions.
      The l10n_eu_oss module can be found at:
      https://github.com/OCA/account-fiscal-rule

      In the meanwhile, Odoo released their support for this.
      It is an improvement to the l10n_eu_service module, available in Odoo CE.
      There were later fixes, but the main implementation is here:
      https://github.com/odoo/odoo/commit/d347eae1646639e2b346d404d1eb68ce9eac005c#diff-6299170bf4eb194cb23d4b799e0ce09b17a250b11e6eeb6aa3c58f63cea04c95

      So there are two different solutions right now.
      I started an Issue to discuss the differences.
      Right now contributors feeling is that the OCA version probably does a better job.
      You can check the details here:
      https://github.com/OCA/account-fiscal-rule/issues/226

      Have a nice day
      Daniel


      Às 11:27 de 10/06/21, Harald Panten Lopez escreveu:
      Hi Community,

      As you know, a major tax change will be implemented shortly (1st of July) that will affect all EU countries.

      More info:
      https://ec.europa.eu/taxation_customs/business/vat/oss_en

      For the newest versions, (from V14) Odoo is planning a "kind of solution", but what happens with older versions? Is any European partner working on this?

      Some of the Spanish partners started this project, and we were wondering if anybody else will do the same. The main idea is to "join our efforts" and offer a global solution according to the ideology proposed by OCA.

      Regards,
      --


      Harald Panten López

      CEO

      Sygel Technology S.L


      		+34 637 88 42 41
      		harald.panten@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona



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


      by Daniel Reis - 05:51 - 6 Jul 2021
    • Re: [28078] Re: European Union One-Stop-Shop

      Hi all,

      We didn't do the meeting today because there was lack of attendance,
      would you like to do a meeting tomorrow 22.06 at 15:00? or if you like please suggest
      other dates.

      Kind regards,

      Usama

      On 14.06.21 23:42, Frederik Kramer wrote:
      Hi all, 

what you all makes absolute sense. In Germany we have the probably
slightly different case that most SME still use Datev for their
financial accounting, so looking at that specific thing its desireable
to follow Datev' habit on creating accounts for specific accounting
practices. Having said this meanwhile i checked the "German" Datev
habit with regard to intra-trade and found out, that most probably we
accumulate all but the domestic trades on 1! revenue account and 1! tax
account. I'll wait final approval by the tax advisors but if that holds
true, than yes certainly no reason to rework the design for more
flexibility / complexity here.

Best Frederik 

Am Montag, den 14.06.2021, 20:26 +0000 schrieb Valentin Vinagre
Urteaga:

> Hi Daniel,

> As Pedro has commented, we thought about that option but it was much

> more complicated, so we opted for an option that is easier to

> implement and more versatile.

> 

> El lun, 14 jun 2021 a las 22:18, Valentin Vinagre Urteaga (<

> valentin.vinagre@sygel.es>) escribió:

> > Hi Frederik,

> > At first we also thought about being able to define which account

> > to take the new taxes to ... but we thought it was better to take

> > it to the same accounts that had the local taxes configured and

> > then change it manually if necessary. Later an extension could be

> > carried out with this functionality.

> > 

> > El lun, 14 jun 2021 a las 21:57, Pedro M. Baeza (Tecnativa) (<

> > pedro.baeza@tecnativa.com>) escribió:

> > > The XML-ID thing is something that Valentín, Harald and I

> > > discussed in the initial kick-off we did, and the

> > > `oss_country_id` field is far more versatile for the needed

> > > things than going to the XML-ID schema that will feel weird and

> > > restricting.

> > > 

> > > Regards.

> > > _______________________________________________

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

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

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

> > 

> > 

> > -- 

> > 

> > Valentín Vinagre Urteaga

> > CTO

> > Sygel Technology S.L

> > 

> > +34 662 68 78 95

> > 

> > valentin.vinagre@sygel.es

> > 

> > https://www.sygel.es

> > 

> > C/ Àlaba 61, 5ª planta, 08005, Barcelona

> > 

> 

> 

-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

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

      -- 
Mit freundlichen Grüßen

Usama Albgaghdady
Softwareentwickler


initOS GmbH
An der Eisenbahn 1
21224 Rosengarten

Phone:   +49 4105 56156-39
Fax:     +49 4105 56156-10

Email:   usama.albaghdady@initos.com
Web:     http://www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr: DE815580155
      by Usama Albaghdady - 03:36 - 21 Jun 2021
    • Re: [28078] Re: European Union One-Stop-Shop 
      Hi all, 

what you all makes absolute sense. In Germany we have the probably
slightly different case that most SME still use Datev for their
financial accounting, so looking at that specific thing its desireable
to follow Datev' habit on creating accounts for specific accounting
practices. Having said this meanwhile i checked the "German" Datev
habit with regard to intra-trade and found out, that most probably we
accumulate all but the domestic trades on 1! revenue account and 1! tax
account. I'll wait final approval by the tax advisors but if that holds
true, than yes certainly no reason to rework the design for more
flexibility / complexity here.

Best Frederik 

Am Montag, den 14.06.2021, 20:26 +0000 schrieb Valentin Vinagre
Urteaga:

> Hi Daniel,

> As Pedro has commented, we thought about that option but it was much

> more complicated, so we opted for an option that is easier to

> implement and more versatile.

> 

> El lun, 14 jun 2021 a las 22:18, Valentin Vinagre Urteaga (<

> valentin.vinagre@sygel.es>) escribió:

> > Hi Frederik,

> > At first we also thought about being able to define which account

> > to take the new taxes to ... but we thought it was better to take

> > it to the same accounts that had the local taxes configured and

> > then change it manually if necessary. Later an extension could be

> > carried out with this functionality.

> > 

> > El lun, 14 jun 2021 a las 21:57, Pedro M. Baeza (Tecnativa) (<

> > pedro.baeza@tecnativa.com>) escribió:

> > > The XML-ID thing is something that Valentín, Harald and I

> > > discussed in the initial kick-off we did, and the

> > > `oss_country_id` field is far more versatile for the needed

> > > things than going to the XML-ID schema that will feel weird and

> > > restricting.

> > > 

> > > Regards.

> > > _______________________________________________

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

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

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

> > 

> > 

> > -- 

> > 

> > Valentín Vinagre Urteaga

> > CTO

> > Sygel Technology S.L

> > 

> > +34 662 68 78 95

> > 

> > valentin.vinagre@sygel.es

> > 

> > https://www.sygel.es

> > 

> > C/ Àlaba 61, 5ª planta, 08005, Barcelona

> > 

> 

> 

-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155
      by Frederik Kramer. - 11:41 - 14 Jun 2021
    • Re: [28078] Re: European Union One-Stop-Shop
      Hi Daniel,
      As Pedro has commented, we thought about that option but it was much more complicated, so we opted for an option that is easier to implement and more versatile.

      El lun, 14 jun 2021 a las 22:18, Valentin Vinagre Urteaga (<valentin.vinagre@sygel.es>) escribió:
      Hi Frederik,
      At first we also thought about being able to define which account to take the new taxes to ... but we thought it was better to take it to the same accounts that had the local taxes configured and then change it manually if necessary. Later an extension could be carried out with this functionality.

      El lun, 14 jun 2021 a las 21:57, Pedro M. Baeza (Tecnativa) (<pedro.baeza@tecnativa.com>) escribió:
      The XML-ID thing is something that Valentín, Harald and I discussed in the initial kick-off we did, and the `oss_country_id` field is far more versatile for the needed things than going to the XML-ID schema that will feel weird and restricting.

      Regards.

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



      --

      Valentín Vinagre Urteaga

      CTO

      Sygel Technology S.L

      		+34 662 68 78 95
      		valentin.vinagre@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona


      --

      Valentín Vinagre Urteaga

      CTO

      Sygel Technology S.L

      		+34 662 68 78 95
      		valentin.vinagre@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona
      by Valentín Vinagre - 10:26 - 14 Jun 2021
    • Re: [28078] Re: European Union One-Stop-Shop
      Hi Frederik,
      At first we also thought about being able to define which account to take the new taxes to ... but we thought it was better to take it to the same accounts that had the local taxes configured and then change it manually if necessary. Later an extension could be carried out with this functionality.

      El lun, 14 jun 2021 a las 21:57, Pedro M. Baeza (Tecnativa) (<pedro.baeza@tecnativa.com>) escribió:
      The XML-ID thing is something that Valentín, Harald and I discussed in the initial kick-off we did, and the `oss_country_id` field is far more versatile for the needed things than going to the XML-ID schema that will feel weird and restricting.

      Regards.

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



      --

      Valentín Vinagre Urteaga

      CTO

      Sygel Technology S.L

      		+34 662 68 78 95
      		valentin.vinagre@sygel.es
      		https://www.sygel.es
      		C/ Àlaba 61, 5ª planta, 08005, Barcelona
      by Valentín Vinagre - 10:20 - 14 Jun 2021

  • Transfer/Migrate Product with Variants Keeping External Identifier for product.product

    Hello everyone

    I need to transfer products with variants from one Odoo database to another and have one requirement:

    To keep the exact external identifier for both product.template and product.product records. 

    I need specially to preserve the external identifier for product.product (Product Variants) because later on I'll have to transfer stock moves and, yes, what is referenced in stock moves, sales, purchases, is product.product (and not product.template).

    I've successfully exported products with variants (exported "attribute_line_ids/attribute_id/id" and "attribute_line_ids/value_ids/id") and import them in the destination database and everything is OK, products with variants are replicated but at the end variants (product.product records) have no external identifier, and I need them.

    Can someone help, please?

    Regards

    --
    ALIEN GROUP LDA

    Aires Silvestre

    COO | Odoo Consultant

    em.aires.silvestre@alien-group.com

    tm.+244 913 728 650

    		 Código QR

    Rua Doutor Agostinho Neto, 156, Bairro Azul, Luanda - Angola, Tel: +244 913 728 600 | +244 913 728 650,
    Website: www.alien-group.com, Email: geral@alien-group.com

    Não imprima este email caso não seja estritamente necessário. A Terra agradece-lhe!

    by Aires Silvestre - 09:56 - 10 Jun 2021

    4 attachments 4 attachments

    qr_aires_silvestre.png
    s_facebook.png
    s_linkedin.png
    alien_logo.png

    2 replies 2 replies

    • Re: Transfer/Migrate Product with Variants Keeping External Identifier for product.product
      Hello Aires,

      It is not clear, but I feel that you are doing the export based on Product Template + Attributes, that will later trigger the Variant creation.
      I suggest you to instead export/import the Product Variants (product.product), along with the related attribute data, and let the implicit Product Template record be automatically created.

      For the record I did a quick test (14.0), and:
      - if you import a "MYPRODUCT" Product Template, it has a __import__.MYPRODUCT XMLId and creates a related Product Variant with no XMLId.
      - if you import a "MYPRODUCT" Product Variant,  it has a __import__.MYPRODUCT XMLId and creates a related Product Template with XMLId __import__.MYPRODUCT_product_template.

      This is helpful for that cases where you have relations to Product Template records (BoMs for example).

      I hope this helps.

      Thanks
      Daniel

      On 10/06/2021 08:57, Aires Silvestre wrote:

      Hello everyone

      I need to transfer products with variants from one Odoo database to another and have one requirement:

      To keep the exact external identifier for both product.template and product.product records. 

      I need specially to preserve the external identifier for product.product (Product Variants) because later on I'll have to transfer stock moves and, yes, what is referenced in stock moves, sales, purchases, is product.product (and not product.template).

      I've successfully exported products with variants (exported "attribute_line_ids/attribute_id/id" and "attribute_line_ids/value_ids/id") and import them in the destination database and everything is OK, products with variants are replicated but at the end variants (product.product records) have no external identifier, and I need them.

      Can someone help, please?

      Regards

      --
      ALIEN GROUP LDA

      Aires Silvestre

      COO | Odoo Consultant

      em.aires.silvestre@alien-group.com

      tm.+244 913 728 650

      		 Código QR

      Rua Doutor Agostinho Neto, 156, Bairro Azul, Luanda - Angola, Tel: +244 913 728 600 | +244 913 728 650,
      Website: www.alien-group.com, Email: geral@alien-group.com

      Não imprima este email caso não seja estritamente necessário. A Terra agradece-lhe!

      _______________________________________________
      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 - 01:00 - 10 Jun 2021
    • Re: Transfer/Migrate Product with Variants Keeping External Identifier for product.product

      Hi,

      Are you having trouble with generating your own identifiers when you create the products?

      Remember, they are just in a table.

      If you have data in a module, the external identifiers are fixed by the id in the xml.

      When you export anything in Odoo, it will use that identifier, or it will look for what identifier has been used, and if it is not there, will create its own?

      So after importing your products in your new database, you could set / override the external identifier to be what it was in your export?

      Without knowing what you have done, and what the endgame is exactly, I would have thought it a not too difficult task to replace the identifiers in your new db with what they were in the old db, ensuring that future exports from either source would have the same identifier.

      Richard

      Richard deMeester

      Senior Development Analyst

      WilldooIT Pty Ltd

      E: richard.demeester@willdooit.com

      M: +61 403 76 76 76

      P: +61 3 9135 1900

      A: 10/435 Williamstown Road, Port Melbourne, Vic 3207

       

       

      Making growth through technology easy

       

       

      DISCLAIMER | This electronic message together with any attachments is confidential. If you are not the recipient, do not copy, disclose, or use the contents in any way. Please also advise us by e-mail that you have received this message in error and then please destroy this email and any of its attachments. WilldooIT Pty. Ltd. is not responsible for any changes made to this message and/or any attachments after sending by WilldooIT Pty. Ltd. WilldooIT Pty. Ltd. use virus scanning software but exclude all liability for virus or anything similar in this email or attachment.

      From: Aires Silvestre <aires.silvestre@alien-group.com>
      Sent: Thursday, 10 June 2021 5:57 PM
      To: Contributors <contributors@odoo-community.org>
      Subject: Transfer/Migrate Product with Variants Keeping External Identifier for product.product
       

      Hello everyone

      I need to transfer products with variants from one Odoo database to another and have one requirement:

      To keep the exact external identifier for both product.template and product.product records. 

      I need specially to preserve the external identifier for product.product (Product Variants) because later on I'll have to transfer stock moves and, yes, what is referenced in stock moves, sales, purchases, is product.product (and not product.template).

      I've successfully exported products with variants (exported "attribute_line_ids/attribute_id/id" and "attribute_line_ids/value_ids/id") and import them in the destination database and everything is OK, products with variants are replicated but at the end variants (product.product records) have no external identifier, and I need them.

      Can someone help, please?

      Regards

      --
      ALIEN GROUP LDA

      Aires Silvestre

      COO | Odoo Consultant

      em.aires.silvestre@alien-group.com

      tm.+244 913 728 650

      		 Código QR

      Rua Doutor Agostinho Neto, 156, Bairro Azul, Luanda - Angola, Tel: +244 913 728 600 | +244 913 728 650,
      Website: www.alien-group.com, Email: geral@alien-group.com

      Não imprima este email caso não seja estritamente necessário. A Terra agradece-lhe!

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

      by "Richard deMeester" <richard.demeester@willdooit.com> - 10:41 - 10 Jun 2021

      2 attachments 2 attachments

      Outlook-rhv1bt40.png
      Outlook-bkc43m3q.jpg
  • Proposing myself as PSC for Document
    Hello, I'm recently quite active on the dms repo, and I see it could use an extra maintainer. I propose myself.


    Thanks everyone!
    by Jairo Llopis - 08:31 - 10 Jun 2021

    13 replies 13 replies

  • where can I list/edit bankaccounts in V14 in the community edition? 
    Hi there

I would like to edit an existing bank account for a V14 community installation.

I can not find out where to do this, and the documentation I find online 
assumes, that Accounting is installed, which only is available for the 
enterprise version.


thanks

Robert
    by Robert Rottermann - 02:56 - 4 Jun 2021

    1 replies 1 replies

  • where can I list/edit bankaccounts in V14 in the community edition? 
    Hi there

I would like to edit an existing bank account for a V14 community installation.

I can not find out where to do this, and the documentation I find online 
assumes, that Accounting is installed, which only is available for the 
enterprise version.


thanks

Robert
    by robert - 02:56 - 4 Jun 2021
  • recurring report
    Hi,

    I am looking to provide an interface to generate reports periodically.

    context:
    From an agreement, manage the generation and sending of monthly or quarterly report to a party set in the agreement. 

    Do we have something that could help in OCA?

    thank you

     --
    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 - 08:30 - 2 Jun 2021

    2 replies 2 replies

    • Re: recurring report
      Tnx for the feedback Holger & sorry if I wasn't clear enough.

      There is a custom model "consumptions" and I would like to give the user the ability to configure the periodic generation and sending of some specific report to a res_partner defined in the agreement.

      The user would click to add a new periodic report. Fill in the settings and select a report to be sent.

       --
      Yves Goldberg
      --


      ----- Original message -----
      From: Holger Brunn <mail@hunki-enterprises.com>
      Subject: Re: recurring report
      Date: Wednesday, June 02, 2021 18:27

      > From an agreement, manage the generation and sending of monthly or quarterly

> report to a party set in the agreement. Do we have something that could

> help in OCA?

I think that's pretty much standard Odoo: Create a server action of type email 
(https://github.com/OCA/OCB/blob/14.0/addons/mail/models/ir_actions.py#L17), 
create a mail template pointing to your report (https://github.com/OCA/OCB/
blob/14.0/addons/mail/models/mail_template.py#L56), and stick the whole thing 
into an automated action (https://github.com/OCA/OCB/blob/14.0/addons/
base_automation/models/base_automation.py#L39) calling the action based on 
your period.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com


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



      Attachments:
      • signature.asc

      by Yves Goldberg - 09:10 - 4 Jun 2021

      1 attachments 1 attachments

      image.png
    • Re: recurring report 
      > From an agreement, manage the generation and sending of monthly or quarterly

> report to a party set in the agreement. Do we have something that could

> help in OCA?

I think that's pretty much standard Odoo: Create a server action of type email 
(https://github.com/OCA/OCB/blob/14.0/addons/mail/models/ir_actions.py#L17), 
create a mail template pointing to your report (https://github.com/OCA/OCB/
blob/14.0/addons/mail/models/mail_template.py#L56), and stick the whole thing 
into an automated action (https://github.com/OCA/OCB/blob/14.0/addons/
base_automation/models/base_automation.py#L39) calling the action based on 
your period.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
      by Holger Brunn - 05:26 - 2 Jun 2021

      1 attachments 1 attachments

      signature.asc
  • Access to runbot1, runbot1-2 and runbot1-3 
    Hello everyone,

Our hoster informed me this morning that a network switch fault is 
causing an outage on one of the runbot servers of the OCA. I redirected 
the web frontend to a different server, but builds on runbot1, runbot1-2 
and runbot1-3 could be unreachable until the equipment is replaced.

I'm sorry for the inconvenience and will post an update when I get more 
information from the hoster.


-- 
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:25 - 31 May 2021

    2 replies 2 replies

    • Re: Access to runbot1, runbot1-2 and runbot1-3
      Thanks, Alexandre!

      --
      Virginie
      0477/64.17.20

      -------- Message initial --------
      De: Alexandre Fayolle <alexandre.fayolle@camptocamp.com>
      Répondre à: Odoo Community Association (OCA) Contributors <contributors@odoo-community.org>
      Objet: Re: Access to runbot1, runbot1-2 and runbot1-3
      Date: Mon, 31 May 2021 13:16:54 -0000

      Hello,

      situation is back to normal.

      Best regards

      Alexandre

      On 31/05/2021 08:24, Alexandre Fayolle wrote:
      > Hello everyone,
      > 
      > Our hoster informed me this morning that a network switch fault is 
      > causing an outage on one of the runbot servers of the OCA. I redirected 
      > the web frontend to a different server, but builds on runbot1, runbot1-2 
      > and runbot1-3 could be unreachable until the equipment is replaced.
      > 
      > I'm sorry for the inconvenience and will post an update when I get more 
      > information from the hoster.
      > 


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


      _______________________________________________
                              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:21 - 31 May 2021
            
        
        
      
            
      
                
            
      
        
      
                            
      
                        
      
                    
      
                
    • 
                    
      
                        
      
                            
      
                                
      
                                    
                                    Re: Access to runbot1, runbot1-2 and runbot1-3
                                
      
                                
      Hello,

situation is back to normal.

Best regards

Alexandre

On 31/05/2021 08:24, Alexandre Fayolle wrote:

> Hello everyone,

> 

> Our hoster informed me this morning that a network switch fault is 

> causing an outage on one of the runbot servers of the OCA. I redirected 

> the web frontend to a different server, but builds on runbot1, runbot1-2 

> and runbot1-3 could be unreachable until the equipment is replaced.

> 

> I'm sorry for the inconvenience and will post an update when I get more 

> information from the hoster.

> 



-- 
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
            
            -
            
                
                03:15 - 31 May 2021
            
        
        
      
            
      
                
            
      
        
      
                            
      
                        
      
                    
      
                
      • 
            
    
        
    
                            
    
                        
    
                    
    
                
    •