Skip to Content

Contributors

  • 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
  • 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
  • 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
  • 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
  • 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
  • Re: Full text search
    > 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

    by "Holger Brunn" <holger@brunn.email> - 08:31 - 21 Jun 2021
  • Re: Full text search
    Hi Holger, hi all, 
    
    more so as Elasticsearch isn'T Open Source any longer. If you can
    afford to do the whole Scaling and Usability / Json convenience stuff
    with other software or own development Lucene is probably the purest
    you can get. Otherwise there is (or will be) OpenSearch
    
    https://t3n.de/news/opensearch-amazon-elasticsearch-fork-1372115/
    
    Neverthless all Java ;-)
    
    Best Frederik
    
    Am Montag, den 21.06.2021, 18:06 +0000 schrieb Holger Brunn:
    
    > > Have you by any chance - allready started covering some of the
    
    > 
    
    > > topics you marked as open in your presentation, like ranking,
    
    > highlighting,
    
    > 
    
    > > proximity, parser tuning and dictionary training?
    
    > 
    
    > none at all, the first PoC was good enough for what the customer
    
    > wanted back 
    
    > then unfortunately. But I'm very confident that with just postgres'
    
    > gist/gin 
    
    > indexes we can already come very far.
    
    > And yes, I more thought of using some lucene thing than elasticsearch
    
    > itself, 
    
    > I made the mistake of getting to know the former through the latter
    
    > 
    
    > 
    
    > -- 
    
    > Your partner for the hard Odoo problems
    
    > https://hunki-enterprises.com
    
    > _______________________________________________
    
    > Mailing-List: https://odoo-community.org/groups/contributors-15
    
    > Post to: mailto:contributors@odoo-community.org
    
    > Unsubscribe: https://odoo-community.org/groups?unsubscribe
    
    -- 
    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:16 - 21 Jun 2021
  • Re: Full text search
    Hi,

    From an open source point of view, I suggest use https://opendistro.github.io/for-elasticsearch/

    It is an interesting project, and if you want a PCI DSS compliant server or GDPR with https://documentation.wazuh.com/current/getting-started/index.html you can.

    And for e-commerce full text search we'll need some custom integration with another ES index with products and with like a kibana-odoo-ui integration, maybe something around could be possible...

    Juan

    El lun, 21 jun 2021 a las 19:27, Joerg Lorenz (<jlorenz@itis.de>) escribió:
    Hi Holger, 

    Personally, I found your approach of using pure PostGreSQL insteresting here, given that elasticsearch requires an addtl service stack (docker container, or alike), and (as I learned the other day from Fred) Elasticsearch is developed in Java  (boo :-() Maybe not so much boo for me, as some of you know). For us, if connected with ITISeasy.docs, Solr comes as an option, too (built on lucene as well). 

    Also a quick search retrieved this: https://rocky.dev/full-text-search. Performance is important. 

    Have you by any chance - allready started covering some of the topics you marked as open in your presentation, like ranking, highlighting, proximity, parser tuning and dictionary training? 
    Best, Joe 


    Von: "Holger Brunn" <mail@hunki-enterprises.com>
    An: "Odoo Community Association, (OCA) Contributors" <contributors@odoo-community.org>
    Gesendet: Montag, 21. Juni 2021 18:46:45
    Betreff: Re: Full text search

    I did some work on this a long time ago in
    https://github.com/Therp/fulltextsearch
    That's basically a framework to make the postgres fulltext search operators 
    usable via the Odoo UI. Something like this could still be helpful in v14 I 
    think, but if I was tasked to start something from scratch I'd go the 
    elasticsearch route nowadays I guess if there weren't any constraints.
    
    
    
    -- 
    Your partner for the hard Odoo problems
    https://hunki-enterprises.com

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


    _______________________________________________
    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 - 08:11 - 21 Jun 2021
  • Re: Full text search
    > Have you by any chance - allready started covering some of the
    
    > topics you marked as open in your presentation, like ranking, highlighting,
    
    > proximity, parser tuning and dictionary training?
    
    none at all, the first PoC was good enough for what the customer wanted back 
    then unfortunately. But I'm very confident that with just postgres' gist/gin 
    indexes we can already come very far.
    And yes, I more thought of using some lucene thing than elasticsearch itself, 
    I made the mistake of getting to know the former through the latter
    
    
    -- 
    Your partner for the hard Odoo problems
    https://hunki-enterprises.com

    by Holger Brunn - 08:05 - 21 Jun 2021
  • Re: Full text search
    Hi Holger, 

    Personally, I found your approach of using pure PostGreSQL insteresting here, given that elasticsearch requires an addtl service stack (docker container, or alike), and (as I learned the other day from Fred) Elasticsearch is developed in Java  (boo :-() Maybe not so much boo for me, as some of you know). For us, if connected with ITISeasy.docs, Solr comes as an option, too (built on lucene as well). 

    Also a quick search retrieved this: https://rocky.dev/full-text-search. Performance is important. 

    Have you by any chance - allready started covering some of the topics you marked as open in your presentation, like ranking, highlighting, proximity, parser tuning and dictionary training? 
    Best, Joe 


    Von: "Holger Brunn" <mail@hunki-enterprises.com>
    An: "Odoo Community Association, (OCA) Contributors" <contributors@odoo-community.org>
    Gesendet: Montag, 21. Juni 2021 18:46:45
    Betreff: Re: Full text search

    I did some work on this a long time ago in
    https://github.com/Therp/fulltextsearch
    That's basically a framework to make the postgres fulltext search operators 
    usable via the Odoo UI. Something like this could still be helpful in v14 I 
    think, but if I was tasked to start something from scratch I'd go the 
    elasticsearch route nowadays I guess if there weren't any constraints.
    
    
    -- 
    Your partner for the hard Odoo problems
    https://hunki-enterprises.com

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



    by Joerg Lorenz. - 07:26 - 21 Jun 2021
  • Re: Full text search
    I did some work on this a long time ago in
    https://github.com/Therp/fulltextsearch
    That's basically a framework to make the postgres fulltext search operators 
    usable via the Odoo UI. Something like this could still be helpful in v14 I 
    think, but if I was tasked to start something from scratch I'd go the 
    elasticsearch route nowadays I guess if there weren't any constraints.
    
    
    -- 
    Your partner for the hard Odoo problems
    https://hunki-enterprises.com

    by Holger Brunn - 06:46 - 21 Jun 2021
  • Re: Full text search
    Ciao,

    you have to create indexes related to specific models and provide an ir.exports (OCA/server-tools/base_jsonify is used under the hood) record to compute data for the index.

    Please note that  this module does not give any search feature for either backend or frontend. You'll have to plug your own UI to search records from ES.

    HTH,
    S.

    On Mon, Jun 21, 2021 at 5:52 PM Lorenzo Battistini <elbaddy@gmail.com> wrote:
    Hi Frederik,

    how should it be configured and used? What is the basic use case?
    I can't understand it from the README.

    Thanks!


    On Tue, 15 Jun 2021 at 11:52, Frederik Kramer <frederik.kramer@initos.com> wrote:
    Take this
    
    https://github.com/OCA/search-engine/tree/14.0/connector_elasticsearch
    
    
    Am Dienstag, den 15.06.2021, 09:36 +0000 schrieb Holze, Jens:
    
    
    
    > I would be interested as well. Something like Alfred on Mac :)
    
    
    
    > 
    
    
    
    > On Tue, Jun 15, 2021 at 11:26 AM Lorenzo Battistini <
    
    
    
    > elbaddy@gmail.com> wrote:
    
    
    
    > > 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!
    
    
    
    > > 
    
    
    
    -- 
    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



    --

    _______________________________________________
    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 - 06:20 - 21 Jun 2021
  • Re: Full text search
    Hi Frederik,

    how should it be configured and used? What is the basic use case?
    I can't understand it from the README.

    Thanks!


    On Tue, 15 Jun 2021 at 11:52, Frederik Kramer <frederik.kramer@initos.com> wrote:
    Take this
    
    https://github.com/OCA/search-engine/tree/14.0/connector_elasticsearch
    
    
    Am Dienstag, den 15.06.2021, 09:36 +0000 schrieb Holze, Jens:
    
    
    > I would be interested as well. Something like Alfred on Mac :)
    
    
    > 
    
    
    > On Tue, Jun 15, 2021 at 11:26 AM Lorenzo Battistini <
    
    
    > elbaddy@gmail.com> wrote:
    
    
    > > 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!
    
    
    > > 
    
    
    -- 
    Dr.-Ing. Frederik Kramer
    Geschäftsführer
            
    initOS GmbH
    An der Eisenbahn 1
    21224 Rosengarten
            
    Phone:  +49 4105 56156-12
    Fax:    +49 4105 56156-10
    Mobil:  +49 179 3901819
            
    Email: frederik.kramer@initos.com
    Web:   www.initos.com
            
    Geschäftsführung:
    Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke
    
    Sitz der Gesellschaft: Rosengarten – Klecken
    Amtsgericht Tostedt, HRB 205226
    Steuer-Nr: 15/200/53247
    USt-IdNr.: DE815580155
    
    

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



    --

    by Lorenzo Battistini. - 05:51 - 21 Jun 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: Proposing dalonsod as PSC for Helpdesk
    +1 and good work.
    SANDIP MANGUKIYA
    TEAM LEAD MANAGER
    O: 1.855.877.2377
    E: SMangukiya@OpenSourcelntegrators.com
    P.O. BOX 940, HIGLEY, AZ 85236


    On Fri, Jun 18, 2021 at 6:16 AM Darío <dariodafoz@gmail.com> wrote:
    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.


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


    by Sandip Mangukiya - 10:21 - 18 Jun 2021