Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • OCA apps lift to 17.0
    Hi!

    I would like to know if you are planning on lifting below apps to 17.0.

    I have a customer that is using them and they will upgrade to 17.0 very soon. So I need to know if these apps will be lifted by OCA or not. Thanks.

    stock_move_change_source_location
    product_net_weight
    product_pricelist_simulation
    product_pricelist_simulation_margin
    account_statement_import_camt
    account_statement_import_camt54
    stock_move_location
    crm_phonecall

    Vänliga hälsningar / Kind Regards
    Cathrine Niklasson

    Phone: +46 737146240




    by Linserv Consulting AB - 09:08 - 18 Jun 2024

    2 replies 2 replies

    • Re: OCA apps lift to 17.0

      What Frederik says, I usually explain it to our customers like this "The first partner with a paying migration customer pays for the upgrade".

      So your customer can either fund it, or wait a bit with the upgrade until more of these modules are migrated by others.

      Naturally everyone will be happy if, when you fund someone to do the migration, the upgraded module gets contributed back to OCA.

      -Tom

      On 6/18/24 09:52, Frederik Kramer wrote:

      Hi Chathrine,

      Generally spoken OCA or basically its contributors will work on migrating modules if there is a direct need to (by one of their customers) AND somebody (normally the customer) is willing to fund their work. Its generally perceived a good habit, to contribute 

      not only with code but also with funds and ideas, especially if one had a substantial benefit in the first place (by using what was already there in older versions). So what you may do as an well estabilshed Odoo Partner taking advantage of these modules, is contact the PSC for

      each of the modules repositories and ask the primary contributors of the module if and how you may support them to prioritize the migration of the module.

      Usually redirecting some of the funds of your customer to those contributors will naturally speed up the process enormously for the benefit of all parties.

      I hope this helps

      Best Frederik 


      Am 18.06.24 um 09:08 schrieb Cathrine Niklasson:
      Hi!

      I would like to know if you are planning on lifting below apps to 17.0.

      I have a customer that is using them and they will upgrade to 17.0 very soon. So I need to know if these apps will be lifted by OCA or not. Thanks.

      stock_move_change_source_location
      product_net_weight
      product_pricelist_simulation
      product_pricelist_simulation_margin
      account_statement_import_camt
      account_statement_import_camt54
      stock_move_location
      crm_phonecall

      Vänliga hälsningar / Kind Regards
      Cathrine Niklasson

      Phone: +46 737146240




      _______________________________________________
      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
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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:00 - 18 Jun 2024
    • Re: OCA apps lift to 17.0

      Hi Chathrine,

      Generally spoken OCA or basically its contributors will work on migrating modules if there is a direct need to (by one of their customers) AND somebody (normally the customer) is willing to fund their work. Its generally perceived a good habit, to contribute 

      not only with code but also with funds and ideas, especially if one had a substantial benefit in the first place (by using what was already there in older versions). So what you may do as an well estabilshed Odoo Partner taking advantage of these modules, is contact the PSC for

      each of the modules repositories and ask the primary contributors of the module if and how you may support them to prioritize the migration of the module.

      Usually redirecting some of the funds of your customer to those contributors will naturally speed up the process enormously for the benefit of all parties.

      I hope this helps

      Best Frederik 


      Am 18.06.24 um 09:08 schrieb Cathrine Niklasson:
      Hi!

      I would like to know if you are planning on lifting below apps to 17.0.

      I have a customer that is using them and they will upgrade to 17.0 very soon. So I need to know if these apps will be lifted by OCA or not. Thanks.

      stock_move_change_source_location
      product_net_weight
      product_pricelist_simulation
      product_pricelist_simulation_margin
      account_statement_import_camt
      account_statement_import_camt54
      stock_move_location
      crm_phonecall

      Vänliga hälsningar / Kind Regards
      Cathrine Niklasson

      Phone: +46 737146240




      _______________________________________________
      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
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247
      by Frederik Kramer. - 09:51 - 18 Jun 2024
  • One email address for sales, another for invoices
    Hi, 

    has anyone implemented a solution for the following use case: 

    Customer1 should receive quotation/SO emails at purchases@customer1.com, and invoice emails at accounting@customer1.com

    I didn't find something for this on partner-contact or accounting

    Thanks!

    Francesco

    --

    Francesco Foresti
    Sicurpharma Srl
    +39 333 8123 790
    by Francesco Foresti - 03:26 - 17 Jun 2024

    3 replies 3 replies

  • Please share your thoughts on the use of `x_` prefix for custom fields in Odoo

    Hello Odoo contributors,

    I'd love to hear your opinion on whether or not one should consistently prefix custom fields and models with `x_`. While there are valid reasons to do so, this convention is either not general or often overlooked in the community. Please share your insights on ir ir when it is required and why it may be missing from some guidelines (e.g., https://www.odoo.com/documentation/17.0/contributing/development/coding_guidelines.html#). I'd really love discuss this topic to enhance our common understanding and best practices in the Odoo ecosystem. Thank you for sharing your opinions

    Best regards,
    Frederik

    Hint: Daniel Reis for instance claims "The field name field entry must start with the x_ prefix. This is mandatory for models and fields created from the developer tools. Customizations made through addon modules don't have this limitation."  in https://subscription.packtpub.com/book/business-and-other/9781800200067/2/ch02lvl1sec09/adding-a-custom-field-to-a-model and Odoo itself pretends "Custom model names must start with x_."  in https://www.odoo.com/documentation/17.0/developer/reference/external_api.html but leaves the convention unaddressed in https://www.odoo.com/documentation/17.0/contributing/development/coding_guidelines.html#

    For whom it may concern: SAP is requiring similar prefixes since very early versions of its ABAP programming and costumization iterface https://help.sap.com/doc/saphelp_snc700_ehp01/7.0.1/en-US/c5/e4ade6453d11d189430000e829fbbd/content.htm?no_cache=true

    -- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247
    by Frederik Kramer. - 12:16 - 17 Jun 2024

    11 replies 11 replies

    • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
      Now we reach the veterans talk and remembering. Time flies lads !

      My two cents on this topic. I confirm what Daniel and Graeme said. The reason behind was to quickly find back the custom fields and models added by the interface and avoid searching in the code for the field and model definition. 

      Anyway such modifications should be banned for the sake of the project and the mental health 😉

      Regards, 
      Houssine 


      Le mer. 19 juin 2024, 08:08, Graeme Gellatly <notifications@odoo-community.org> a écrit :

      On Wed, Jun 19, 2024 at 5:57 PM Graeme Gellatly <graeme@moahub.nz> wrote:
      Yes but it is still exactly the same case. A model or field that is not part of a module. There is zero technical difference between creating a field via RPC and via UI. Afterall the UI is just sending the same RPC calls to the server. It absolutely does not apply to community developed modules in any way whatsoever, and it is absolutely required for any field created outside of a module (such that it gets ignored rather than removed in certain operations, it is essentially treated as data). And yes it existed in v5, and it was a major feature. This was the times of OpenBravo taking primacy with their dynamic low code DDL java thing, and OpenERP had a precursor to Studio in it. They even had a website openerp.tv dedicated to tutorials on how to do it.

      On Wed, Jun 19, 2024 at 5:41 PM Frederik Kramer <notifications@odoo-community.org> wrote:
      Well, this is not the only instance of that magical x_ I came across this (at least if I remember well) already in times of OpenERP Version 5 or so. Here for instance it again seems to be more related to backend UI changes and some reasoning is also provided by Ray

      https://www.odoo.com/forum/help-1/fixing-a-custom-field-and-database-implications-90794


      Am 18. Juni 2024 23:32:27 MESZ schrieb Graeme Gellatly <notifications@odoo-community.org>:
      I took a quick read and yes it is a misunderstanding of the documentation. If reading a specific section about creating custom models over RPC calls, do not try and apply it to module development in general. All the documentation is correct as is Daniel's statement. Just a misread.

      On Wed, Jun 19, 2024 at 9:19 AM Graeme Gellatly <graeme@moahub.nz> wrote:
      Before Odoo studio, there was another frontend editor, like way back in v5. But it is only for fields created through the UI, not modules. Never modules, it would be a nonsense.  The only time you would use in a module is if it contained dynamic field creation, e.g. like studio, or you have some kind of variable dynamic model like say custom field service worksheets. I think this is simply a misunderstanding of the documentation.

      On Tue, Jun 18, 2024 at 12:16 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Thanks Pedro, thanks Christian and Francesco for your comments,

i think the first appearance of that magical "x_" was long before Odoo 
Studio even existed but i do definitely agree that backend UI changes 
done with Odoo Studio (or earlier through Developer Tools and Plain BE 
functions) should be avoided in any production grade DB. However, 
technically forbid to use that "methods" is not all too simple (if the 
customer pretends to have certain rights on his landscape) or comes from 
an origin where nobody even told them ;-)

To me it seems (i.e. would be my conclusion) that Odoo S.A. always 
wanted to have that "x_" prefix and the community mostly ignored it (if 
i remember well, i have occassionaly seen app store modules that 
followed this 'requirement').

Now what bothers me most is that Odoo S.A. isn't consistent either on 
the matter and obviously never forced to comply (would have been easily 
possible).

So probably we we better follow the "wisdom of the crowd" altogether and 
continue to ignore that "magic convention".

Best Frederik

Am 17.06.24 um 13:43 schrieb Pedro M. Baeza:




> IMO, that prefix must only apply to fields created through UI / Odoo 




> Studio, not on community modules. And if you have to maintain that DB, 




> I advise you to forbid both Odoo Studio and manual field creation.




>




> Regards.




>




> _______________________________________________




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




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




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




>




-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-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: Buchholz i.d.N.
      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

      by Houssine BAKKALI - 10:00 - 19 Jun 2024
    • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo

      On Wed, Jun 19, 2024 at 5:57 PM Graeme Gellatly <graeme@moahub.nz> wrote:
      Yes but it is still exactly the same case. A model or field that is not part of a module. There is zero technical difference between creating a field via RPC and via UI. Afterall the UI is just sending the same RPC calls to the server. It absolutely does not apply to community developed modules in any way whatsoever, and it is absolutely required for any field created outside of a module (such that it gets ignored rather than removed in certain operations, it is essentially treated as data). And yes it existed in v5, and it was a major feature. This was the times of OpenBravo taking primacy with their dynamic low code DDL java thing, and OpenERP had a precursor to Studio in it. They even had a website openerp.tv dedicated to tutorials on how to do it.

      On Wed, Jun 19, 2024 at 5:41 PM Frederik Kramer <notifications@odoo-community.org> wrote:
      Well, this is not the only instance of that magical x_ I came across this (at least if I remember well) already in times of OpenERP Version 5 or so. Here for instance it again seems to be more related to backend UI changes and some reasoning is also provided by Ray

      https://www.odoo.com/forum/help-1/fixing-a-custom-field-and-database-implications-90794


      Am 18. Juni 2024 23:32:27 MESZ schrieb Graeme Gellatly <notifications@odoo-community.org>:
      I took a quick read and yes it is a misunderstanding of the documentation. If reading a specific section about creating custom models over RPC calls, do not try and apply it to module development in general. All the documentation is correct as is Daniel's statement. Just a misread.

      On Wed, Jun 19, 2024 at 9:19 AM Graeme Gellatly <graeme@moahub.nz> wrote:
      Before Odoo studio, there was another frontend editor, like way back in v5. But it is only for fields created through the UI, not modules. Never modules, it would be a nonsense.  The only time you would use in a module is if it contained dynamic field creation, e.g. like studio, or you have some kind of variable dynamic model like say custom field service worksheets. I think this is simply a misunderstanding of the documentation.

      On Tue, Jun 18, 2024 at 12:16 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Thanks Pedro, thanks Christian and Francesco for your comments,

i think the first appearance of that magical "x_" was long before Odoo 
Studio even existed but i do definitely agree that backend UI changes 
done with Odoo Studio (or earlier through Developer Tools and Plain BE 
functions) should be avoided in any production grade DB. However, 
technically forbid to use that "methods" is not all too simple (if the 
customer pretends to have certain rights on his landscape) or comes from 
an origin where nobody even told them ;-)

To me it seems (i.e. would be my conclusion) that Odoo S.A. always 
wanted to have that "x_" prefix and the community mostly ignored it (if 
i remember well, i have occassionaly seen app store modules that 
followed this 'requirement').

Now what bothers me most is that Odoo S.A. isn't consistent either on 
the matter and obviously never forced to comply (would have been easily 
possible).

So probably we we better follow the "wisdom of the crowd" altogether and 
continue to ignore that "magic convention".

Best Frederik

Am 17.06.24 um 13:43 schrieb Pedro M. Baeza:



> IMO, that prefix must only apply to fields created through UI / Odoo 



> Studio, not on community modules. And if you have to maintain that DB, 



> I advise you to forbid both Odoo Studio and manual field creation.



>



> Regards.



>



> _______________________________________________



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



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



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



>



-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-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: Buchholz i.d.N.
      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 "Graeme Gellatly" <graeme@moahub.nz> - 08:08 - 19 Jun 2024
    • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
      Yes but it is still exactly the same case. A model or field that is not part of a module. There is zero technical difference between creating a field via RPC and via UI. Afterall the UI is just sending the same RPC calls to the server. It absolutely does not apply to community developed modules in any way whatsoever, and it is absolutely required for any field created outside of a module (such that it gets ignored rather than removed in certain operations, it is essentially treated as data). And yes it existed in v5, and it was a major feature. This was the times of OpenBravo taking primacy with their dynamic low code DDL java thing, and OpenERP had a precursor to Studio in it. They even had a website openerp.tv dedicated to tutorials on how to do it.

      On Wed, Jun 19, 2024 at 5:41 PM Frederik Kramer <notifications@odoo-community.org> wrote:
      Well, this is not the only instance of that magical x_ I came across this (at least if I remember well) already in times of OpenERP Version 5 or so. Here for instance it again seems to be more related to backend UI changes and some reasoning is also provided by Ray

      https://www.odoo.com/forum/help-1/fixing-a-custom-field-and-database-implications-90794


      Am 18. Juni 2024 23:32:27 MESZ schrieb Graeme Gellatly <notifications@odoo-community.org>:
      I took a quick read and yes it is a misunderstanding of the documentation. If reading a specific section about creating custom models over RPC calls, do not try and apply it to module development in general. All the documentation is correct as is Daniel's statement. Just a misread.

      On Wed, Jun 19, 2024 at 9:19 AM Graeme Gellatly <graeme@moahub.nz> wrote:
      Before Odoo studio, there was another frontend editor, like way back in v5. But it is only for fields created through the UI, not modules. Never modules, it would be a nonsense.  The only time you would use in a module is if it contained dynamic field creation, e.g. like studio, or you have some kind of variable dynamic model like say custom field service worksheets. I think this is simply a misunderstanding of the documentation.

      On Tue, Jun 18, 2024 at 12:16 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Thanks Pedro, thanks Christian and Francesco for your comments,

i think the first appearance of that magical "x_" was long before Odoo 
Studio even existed but i do definitely agree that backend UI changes 
done with Odoo Studio (or earlier through Developer Tools and Plain BE 
functions) should be avoided in any production grade DB. However, 
technically forbid to use that "methods" is not all too simple (if the 
customer pretends to have certain rights on his landscape) or comes from 
an origin where nobody even told them ;-)

To me it seems (i.e. would be my conclusion) that Odoo S.A. always 
wanted to have that "x_" prefix and the community mostly ignored it (if 
i remember well, i have occassionaly seen app store modules that 
followed this 'requirement').

Now what bothers me most is that Odoo S.A. isn't consistent either on 
the matter and obviously never forced to comply (would have been easily 
possible).

So probably we we better follow the "wisdom of the crowd" altogether and 
continue to ignore that "magic convention".

Best Frederik

Am 17.06.24 um 13:43 schrieb Pedro M. Baeza:



> IMO, that prefix must only apply to fields created through UI / Odoo 



> Studio, not on community modules. And if you have to maintain that DB, 



> I advise you to forbid both Odoo Studio and manual field creation.



>



> Regards.



>



> _______________________________________________



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



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



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



>



-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-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: Buchholz i.d.N.
      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 "Graeme Gellatly" <graeme@moahub.nz> - 08:07 - 19 Jun 2024
    • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
      Well, this is not the only instance of that magical x_ I came across this (at least if I remember well) already in times of OpenERP Version 5 or so. Here for instance it again seems to be more related to backend UI changes and some reasoning is also provided by Ray

      https://www.odoo.com/forum/help-1/fixing-a-custom-field-and-database-implications-90794


      Am 18. Juni 2024 23:32:27 MESZ schrieb Graeme Gellatly <notifications@odoo-community.org>:
      I took a quick read and yes it is a misunderstanding of the documentation. If reading a specific section about creating custom models over RPC calls, do not try and apply it to module development in general. All the documentation is correct as is Daniel's statement. Just a misread.

      On Wed, Jun 19, 2024 at 9:19 AM Graeme Gellatly <graeme@moahub.nz> wrote:
      Before Odoo studio, there was another frontend editor, like way back in v5. But it is only for fields created through the UI, not modules. Never modules, it would be a nonsense.  The only time you would use in a module is if it contained dynamic field creation, e.g. like studio, or you have some kind of variable dynamic model like say custom field service worksheets. I think this is simply a misunderstanding of the documentation.

      On Tue, Jun 18, 2024 at 12:16 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Thanks Pedro, thanks Christian and Francesco for your comments,

i think the first appearance of that magical "x_" was long before Odoo 
Studio even existed but i do definitely agree that backend UI changes 
done with Odoo Studio (or earlier through Developer Tools and Plain BE 
functions) should be avoided in any production grade DB. However, 
technically forbid to use that "methods" is not all too simple (if the 
customer pretends to have certain rights on his landscape) or comes from 
an origin where nobody even told them ;-)

To me it seems (i.e. would be my conclusion) that Odoo S.A. always 
wanted to have that "x_" prefix and the community mostly ignored it (if 
i remember well, i have occassionaly seen app store modules that 
followed this 'requirement').

Now what bothers me most is that Odoo S.A. isn't consistent either on 
the matter and obviously never forced to comply (would have been easily 
possible).

So probably we we better follow the "wisdom of the crowd" altogether and 
continue to ignore that "magic convention".

Best Frederik

Am 17.06.24 um 13:43 schrieb Pedro M. Baeza:


> IMO, that prefix must only apply to fields created through UI / Odoo 


> Studio, not on community modules. And if you have to maintain that DB, 


> I advise you to forbid both Odoo Studio and manual field creation.


>


> Regards.


>


> _______________________________________________


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


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


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


>


-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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

      --
      Dr.-Ing. Frederik Kramer
      Geschäftsführer
              
      initOS GmbH
      Innungsstraße 7
      21244 Buchholz i.d.N.
              
      Phone:  +49 4181 13503-12
      Fax:    +49 4181 13503-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: Buchholz i.d.N.
      Amtsgericht Tostedt, HRB 205226
      Steuer-Nr: 15/200/53247
      USt-IdNr.: DE815580155
      by Frederik Kramer. - 07:35 - 19 Jun 2024
    • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
      I took a quick read and yes it is a misunderstanding of the documentation. If reading a specific section about creating custom models over RPC calls, do not try and apply it to module development in general. All the documentation is correct as is Daniel's statement. Just a misread.

      On Wed, Jun 19, 2024 at 9:19 AM Graeme Gellatly <graeme@moahub.nz> wrote:
      Before Odoo studio, there was another frontend editor, like way back in v5. But it is only for fields created through the UI, not modules. Never modules, it would be a nonsense.  The only time you would use in a module is if it contained dynamic field creation, e.g. like studio, or you have some kind of variable dynamic model like say custom field service worksheets. I think this is simply a misunderstanding of the documentation.

      On Tue, Jun 18, 2024 at 12:16 AM Frederik Kramer <notifications@odoo-community.org> wrote:
      Thanks Pedro, thanks Christian and Francesco for your comments,

i think the first appearance of that magical "x_" was long before Odoo 
Studio even existed but i do definitely agree that backend UI changes 
done with Odoo Studio (or earlier through Developer Tools and Plain BE 
functions) should be avoided in any production grade DB. However, 
technically forbid to use that "methods" is not all too simple (if the 
customer pretends to have certain rights on his landscape) or comes from 
an origin where nobody even told them ;-)

To me it seems (i.e. would be my conclusion) that Odoo S.A. always 
wanted to have that "x_" prefix and the community mostly ignored it (if 
i remember well, i have occassionaly seen app store modules that 
followed this 'requirement').

Now what bothers me most is that Odoo S.A. isn't consistent either on 
the matter and obviously never forced to comply (would have been easily 
possible).

So probably we we better follow the "wisdom of the crowd" altogether and 
continue to ignore that "magic convention".

Best Frederik

Am 17.06.24 um 13:43 schrieb Pedro M. Baeza:


> IMO, that prefix must only apply to fields created through UI / Odoo 


> Studio, not on community modules. And if you have to maintain that DB, 


> I advise you to forbid both Odoo Studio and manual field creation.


>


> Regards.


>


> _______________________________________________


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


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


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


>


-- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

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

      by "Graeme Gellatly" <graeme@moahub.nz> - 11:31 - 18 Jun 2024

  • OCA Weblate, why the lack of speed? 
    

Greetings!
I've done plenty of translating for Odoo in Sweden. Modules and 
documentation for Odoo mainly in Transifex but also some for OCA, using 
Weblate.

I like the tool Weblate. Sometimes it's more helpful than Transifex!

But I've always wondered why it's so slow. I often get the "500 time 
out" -error and it's more frequently before lunch than after!

Who's in charge? What's the plan, if any...?

I assume others has experienced the same. I'm new to this e-mailing list 
and maybe this has been discussed recently? If so, my apology for 
highlighting the issue!

regards,

// jakob





-- 
Med vänlig hälsning / Best regards/ 顺祝商祺,
Jakob Krabbe

VERTEL AB | Jakob Krabbe | jakob.krabbe@vertel.se
+46 (0)13 99 19 480 | +46 (0) 709 24 54 75 | vertel.se
    by Jakob Krabbe - 09:06 - 17 Jun 2024

    17 replies 17 replies

    • Re: OCA Weblate, why the lack of speed?
      Thanks Stéphane for all your efforts and the clear feedback!

      Regards,

      Le mer. 26 juin 2024 à 11:22, Stéphane Bidoul <notifications@odoo-community.org> a écrit :
      Hi Pierre,

      Thanks a lot for proposing your help.

      I think it is (was) simply an issue with the 10 years old spinning disks being too slow for the kind of weblate workload we have.
      Now we have SSD and more RAM for caching so thing should be better much better.

      The next step now is indeed the Weblate 5 upgrade, for which Remy Cazenave has already proposed his support.
      You may want to get in touch with him to see if some collaboration makes sense.

      After that we'll see what can be done, as there are many possible avenues for improvements such as translation memories, approval workflow for communities who need it, rewriting the project and component creation scripts using the REST API (if they are still needed), etc.

      -sbi

      On Wed, Jun 26, 2024 at 11:07 AM Pierre Verkest <notifications@odoo-community.org> wrote:
      > While the root cause is still unclear it still seems related to weblate.

      I don't really know weblate (only over a few translations I've done). However it's a python project and I would be very happy to help with performance issues topics, I guess the OCA weblate instance is probably quite an importante one.

      Are there already techies introspecting such issues or are you confident with new servers ? Do you need help to understand and fix the issue ?

      Le mar. 25 juin 2024 à 23:37, Stéphane Bidoul <notifications@odoo-community.org> a écrit :
      The performance issues on the OCA server have been acute again today.

      While the root cause is still unclear it still seems related to weblate.

      So I have had to take weblate down and started the move to the new machine.

      Thank you all for your patience.

      Best regards,


      --
      Stéphane Bidoul
      http://acsone.eu/

      On Sun, Jun 23, 2024 at 6:51 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi everyone,

      Back from holidays, I indeed notice a lot of alerts and a very high load on our poor weblate instance that is already stretching our server past reasonable limits.

      As a short term measure, I have banned a couple of IP addresses that clearly abused the system.

      Now the good news is that I started configuring the new OCA server and we will progressively start moving the services to the new machine. This will also unblock the weblate upgrade to 5.x.

      I'll post here as this progresses, over the coming weeks and months.

      Best regards,

      --
      Stéphane Bidoul
      http://acsone.eu/

      On Thu, Jun 20, 2024 at 4:23 PM Frederik Kramer <notifications@odoo-community.org> wrote:

      Hi Jakob,

      sorry you are right. I can share your pain today as i was also trying to interact with part of our infrastructure that was equally lacking reliability and peformance. However, i am pretty sure that we will soon (as in volountary soon) have solutions for these problems. In the meantime thank you for your willingsness to help

      Best Frederik

      Am 20.06.24 um 16:03 schrieb Jakob Krabbe:
      Thank you for your reply!
After a few days with Weblate and 504 Gateway Time-out, I'm now moving 
on with other tasks. I hope you or maybe Stephané could post a notice on 
this list when such upgrade has been made!

regards,

// jakob



Den 2024-06-17 kl. 09:37, skrev Frederik Kramer:





> Hi Jakob,





> 





> afaik, OCA uses weblate because it doesn't just us as much as Transifex 





> charged us. If i am not mistaken we run Weblate ourselfes and if i 





> understood (Stephané Bidoul, who is the master of OCAs hardware 





> architecture) we are about to migrate on a more powerful hardware server 





> (also for that purpose). But Stephané can certainly be more precise on 





> that. So in the best case it should improve somewhen soon :-)





> 





> Best and thanks for the question





> 





> Frederik





> 





> Am 17.06.24 um 09:07 schrieb Jakob Krabbe:





>> Greetings!





>> I've done plenty of translating for Odoo in Sweden. Modules and





>> documentation for Odoo mainly in Transifex but also some for OCA, using





>> Weblate.





>>





>> I like the tool Weblate. Sometimes it's more helpful than Transifex!





>>





>> But I've always wondered why it's so slow. I often get the "500 time





>> out" -error and it's more frequently before lunch than after!





>>





>> Who's in charge? What's the plan, if any...?





>>





>> I assume others has experienced the same. I'm new to this e-mailing list





>> and maybe this has been discussed recently? If so, my apology for





>> highlighting the issue!





>>





>> regards,





>>





>> // jakob





>>





>>





>>





>>





>> -- Med vänlig hälsning / Best regards/ 顺祝商祺, Jakob Krabbe VERTEL 





>> AB | Jakob Krabbe | jakob.krabbe@vertel.se 





>> <mailto:jakob.krabbe@vertel.se> +46 (0)13 99 19 480 | +46 (0) 709 24 





>> 54 75 | vertel.se





>>





>> _______________________________________________





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





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





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





>> <mailto:contributors@odoo-community.org>





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





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





>>





> -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH Innungsstraße 7 





> 21244 Buchholz i.d.N. Tel: +49 (0) 4181 13503 12 Fax: +49 (0) 4181 13503 





> 10 Mobil: +49 (0) 179 3901819 Email: frederik.kramer@initos.com  <mailto:frederik.kramer@initos.com>





> Internet:www.initos.com  <http://www.initos.com>





> 





> Geschäftsführung:





> Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke





> 





> Sitz der Gesellschaft: Buchholz i.d.N.





> Amtsgericht Tostedt, HRB 205226





> USt-IdNr.: DE815580155





> Steuer-Nr: 15/200/53247





> 





> _______________________________________________





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





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





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





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





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





> 






-- 
Med vänlig hälsning / Best regards/ 顺祝商祺,
Jakob Krabbe

VERTEL AB | Jakob Krabbe | jakob.krabbe@vertel.se
+46 (0)13 99 19 480 | +46 (0) 709 24 54 75 | vertel.se

      _______________________________________________
      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
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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



      --
      Pierre

      _______________________________________________
      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



      --
      Pierre
      by Pierre Verkest - 01:51 - 26 Jun 2024
    • Re: OCA Weblate, why the lack of speed?
      Thanks Stéphane, it seems very fast!

      PS: remind the locked modules, as you know...

      Da "Stéphane Bidoul" notifications@odoo-community.org
      A "Contributors" contributors@odoo-community.org
      Cc
      Data Wed, 26 Jun 2024 07:57:41 -0000
      Oggetto Re: OCA Weblate, why the lack of speed?

      And weblate is back online, on the new machine.

      Let me know of any issue.

      Happy translation!

      -sbi

      On Tue, Jun 25, 2024 at 11:32 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      The performance issues on the OCA server have been acute again today.

      While the root cause is still unclear it still seems related to weblate.

      So I have had to take weblate down and started the move to the new machine.

      Thank you all for your patience.

      Best regards,


      --
      Stéphane Bidoul


      Stefano Consolaro
      www.mymage.it
      by Stefano Consolaro - 11:56 - 26 Jun 2024
    • Re: OCA Weblate, why the lack of speed?
      Hi Pierre,

      Thanks a lot for proposing your help.

      I think it is (was) simply an issue with the 10 years old spinning disks being too slow for the kind of weblate workload we have.
      Now we have SSD and more RAM for caching so thing should be better much better.

      The next step now is indeed the Weblate 5 upgrade, for which Remy Cazenave has already proposed his support.
      You may want to get in touch with him to see if some collaboration makes sense.

      After that we'll see what can be done, as there are many possible avenues for improvements such as translation memories, approval workflow for communities who need it, rewriting the project and component creation scripts using the REST API (if they are still needed), etc.

      -sbi

      On Wed, Jun 26, 2024 at 11:07 AM Pierre Verkest <notifications@odoo-community.org> wrote:
      > While the root cause is still unclear it still seems related to weblate.

      I don't really know weblate (only over a few translations I've done). However it's a python project and I would be very happy to help with performance issues topics, I guess the OCA weblate instance is probably quite an importante one.

      Are there already techies introspecting such issues or are you confident with new servers ? Do you need help to understand and fix the issue ?

      Le mar. 25 juin 2024 à 23:37, Stéphane Bidoul <notifications@odoo-community.org> a écrit :
      The performance issues on the OCA server have been acute again today.

      While the root cause is still unclear it still seems related to weblate.

      So I have had to take weblate down and started the move to the new machine.

      Thank you all for your patience.

      Best regards,


      --
      Stéphane Bidoul
      http://acsone.eu/

      On Sun, Jun 23, 2024 at 6:51 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi everyone,

      Back from holidays, I indeed notice a lot of alerts and a very high load on our poor weblate instance that is already stretching our server past reasonable limits.

      As a short term measure, I have banned a couple of IP addresses that clearly abused the system.

      Now the good news is that I started configuring the new OCA server and we will progressively start moving the services to the new machine. This will also unblock the weblate upgrade to 5.x.

      I'll post here as this progresses, over the coming weeks and months.

      Best regards,

      --
      Stéphane Bidoul
      http://acsone.eu/

      On Thu, Jun 20, 2024 at 4:23 PM Frederik Kramer <notifications@odoo-community.org> wrote:

      Hi Jakob,

      sorry you are right. I can share your pain today as i was also trying to interact with part of our infrastructure that was equally lacking reliability and peformance. However, i am pretty sure that we will soon (as in volountary soon) have solutions for these problems. In the meantime thank you for your willingsness to help

      Best Frederik

      Am 20.06.24 um 16:03 schrieb Jakob Krabbe:
      Thank you for your reply!
After a few days with Weblate and 504 Gateway Time-out, I'm now moving 
on with other tasks. I hope you or maybe Stephané could post a notice on 
this list when such upgrade has been made!

regards,

// jakob



Den 2024-06-17 kl. 09:37, skrev Frederik Kramer:




> Hi Jakob,




> 




> afaik, OCA uses weblate because it doesn't just us as much as Transifex 




> charged us. If i am not mistaken we run Weblate ourselfes and if i 




> understood (Stephané Bidoul, who is the master of OCAs hardware 




> architecture) we are about to migrate on a more powerful hardware server 




> (also for that purpose). But Stephané can certainly be more precise on 




> that. So in the best case it should improve somewhen soon :-)




> 




> Best and thanks for the question




> 




> Frederik




> 




> Am 17.06.24 um 09:07 schrieb Jakob Krabbe:




>> Greetings!




>> I've done plenty of translating for Odoo in Sweden. Modules and




>> documentation for Odoo mainly in Transifex but also some for OCA, using




>> Weblate.




>>




>> I like the tool Weblate. Sometimes it's more helpful than Transifex!




>>




>> But I've always wondered why it's so slow. I often get the "500 time




>> out" -error and it's more frequently before lunch than after!




>>




>> Who's in charge? What's the plan, if any...?




>>




>> I assume others has experienced the same. I'm new to this e-mailing list




>> and maybe this has been discussed recently? If so, my apology for




>> highlighting the issue!




>>




>> regards,




>>




>> // jakob




>>




>>




>>




>>




>> -- Med vänlig hälsning / Best regards/ 顺祝商祺, Jakob Krabbe VERTEL 




>> AB | Jakob Krabbe | jakob.krabbe@vertel.se 




>> <mailto:jakob.krabbe@vertel.se> +46 (0)13 99 19 480 | +46 (0) 709 24 




>> 54 75 | vertel.se




>>




>> _______________________________________________




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




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




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




>> <mailto:contributors@odoo-community.org>




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




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




>>




> -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH Innungsstraße 7 




> 21244 Buchholz i.d.N. Tel: +49 (0) 4181 13503 12 Fax: +49 (0) 4181 13503 




> 10 Mobil: +49 (0) 179 3901819 Email: frederik.kramer@initos.com  <mailto:frederik.kramer@initos.com>




> Internet:www.initos.com  <http://www.initos.com>




> 




> Geschäftsführung:




> Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke




> 




> Sitz der Gesellschaft: Buchholz i.d.N.




> Amtsgericht Tostedt, HRB 205226




> USt-IdNr.: DE815580155




> Steuer-Nr: 15/200/53247




> 




> _______________________________________________




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




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




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




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




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




> 





-- 
Med vänlig hälsning / Best regards/ 顺祝商祺,
Jakob Krabbe

VERTEL AB | Jakob Krabbe | jakob.krabbe@vertel.se
+46 (0)13 99 19 480 | +46 (0) 709 24 54 75 | vertel.se

      _______________________________________________
      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
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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



      --
      Pierre

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

      by Stéphane Bidoul - 11:21 - 26 Jun 2024
    • Re: OCA Weblate, why the lack of speed?
      Indeed, very appreciated!

      Let's wait for v5.x to be implemented to suggest further possible improvements.

      Cheers!

      Il giorno mer 26 giu 2024 alle ore 11:02 Frederik Kramer <notifications@odoo-community.org> ha scritto:

      Great Stéphane,

      thanks for this effort.

      Best Frederik

      Am 26.06.24 um 09:57 schrieb Stéphane Bidoul:
      And weblate is back online, on the new machine.

      Let me know of any issue.

      Happy translation!

      -sbi

      On Tue, Jun 25, 2024 at 11:32 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      The performance issues on the OCA server have been acute again today.

      While the root cause is still unclear it still seems related to weblate.

      So I have had to take weblate down and started the move to the new machine.

      Thank you all for your patience.

      Best regards,


      --
      Stéphane Bidoul
      http://acsone.eu/

      On Sun, Jun 23, 2024 at 6:51 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi everyone,

      Back from holidays, I indeed notice a lot of alerts and a very high load on our poor weblate instance that is already stretching our server past reasonable limits.

      As a short term measure, I have banned a couple of IP addresses that clearly abused the system.

      Now the good news is that I started configuring the new OCA server and we will progressively start moving the services to the new machine. This will also unblock the weblate upgrade to 5.x.

      I'll post here as this progresses, over the coming weeks and months.

      Best regards,

      --
      Stéphane Bidoul
      http://acsone.eu/

      On Thu, Jun 20, 2024 at 4:23 PM Frederik Kramer <notifications@odoo-community.org> wrote:

      Hi Jakob,

      sorry you are right. I can share your pain today as i was also trying to interact with part of our infrastructure that was equally lacking reliability and peformance. However, i am pretty sure that we will soon (as in volountary soon) have solutions for these problems. In the meantime thank you for your willingsness to help

      Best Frederik

      Am 20.06.24 um 16:03 schrieb Jakob Krabbe:
      Thank you for your reply!
After a few days with Weblate and 504 Gateway Time-out, I'm now moving 
on with other tasks. I hope you or maybe Stephané could post a notice on 
this list when such upgrade has been made!

regards,

// jakob



Den 2024-06-17 kl. 09:37, skrev Frederik Kramer:



> Hi Jakob,



> 



> afaik, OCA uses weblate because it doesn't just us as much as Transifex 



> charged us. If i am not mistaken we run Weblate ourselfes and if i 



> understood (Stephané Bidoul, who is the master of OCAs hardware 



> architecture) we are about to migrate on a more powerful hardware server 



> (also for that purpose). But Stephané can certainly be more precise on 



> that. So in the best case it should improve somewhen soon :-)



> 



> Best and thanks for the question



> 



> Frederik



> 



> Am 17.06.24 um 09:07 schrieb Jakob Krabbe:



>> Greetings!



>> I've done plenty of translating for Odoo in Sweden. Modules and



>> documentation for Odoo mainly in Transifex but also some for OCA, using



>> Weblate.



>>



>> I like the tool Weblate. Sometimes it's more helpful than Transifex!



>>



>> But I've always wondered why it's so slow. I often get the "500 time



>> out" -error and it's more frequently before lunch than after!



>>



>> Who's in charge? What's the plan, if any...?



>>



>> I assume others has experienced the same. I'm new to this e-mailing list



>> and maybe this has been discussed recently? If so, my apology for



>> highlighting the issue!



>>



>> regards,



>>



>> // jakob



>>



>>



>>



>>



>> -- Med vänlig hälsning / Best regards/ 顺祝商祺, Jakob Krabbe VERTEL 



>> AB | Jakob Krabbe | jakob.krabbe@vertel.se 



>> <mailto:jakob.krabbe@vertel.se> +46 (0)13 99 19 480 | +46 (0) 709 24 



>> 54 75 | vertel.se



>>



>> _______________________________________________



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



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



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



>> <mailto:contributors@odoo-community.org>



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



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



>>



> -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH Innungsstraße 7 



> 21244 Buchholz i.d.N. Tel: +49 (0) 4181 13503 12 Fax: +49 (0) 4181 13503 



> 10 Mobil: +49 (0) 179 3901819 Email: frederik.kramer@initos.com  <mailto:frederik.kramer@initos.com>



> Internet:www.initos.com  <http://www.initos.com>



> 



> Geschäftsführung:



> Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke



> 



> Sitz der Gesellschaft: Buchholz i.d.N.



> Amtsgericht Tostedt, HRB 205226



> USt-IdNr.: DE815580155



> Steuer-Nr: 15/200/53247



> 



> _______________________________________________



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



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



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



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



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



> 




-- 
Med vänlig hälsning / Best regards/ 顺祝商祺,
Jakob Krabbe

VERTEL AB | Jakob Krabbe | jakob.krabbe@vertel.se
+46 (0)13 99 19 480 | +46 (0) 709 24 54 75 | vertel.se

      _______________________________________________
      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
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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

      -- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

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



      --

      Francesco Foresti
      Sicurpharma Srl
      +39 333 8123 790
      by Francesco Foresti - 11:07 - 26 Jun 2024
    • Re: OCA Weblate, why the lack of speed?
      > While the root cause is still unclear it still seems related to weblate.

      I don't really know weblate (only over a few translations I've done). However it's a python project and I would be very happy to help with performance issues topics, I guess the OCA weblate instance is probably quite an importante one.

      Are there already techies introspecting such issues or are you confident with new servers ? Do you need help to understand and fix the issue ?

      Le mar. 25 juin 2024 à 23:37, Stéphane Bidoul <notifications@odoo-community.org> a écrit :
      The performance issues on the OCA server have been acute again today.

      While the root cause is still unclear it still seems related to weblate.

      So I have had to take weblate down and started the move to the new machine.

      Thank you all for your patience.

      Best regards,


      --
      Stéphane Bidoul
      http://acsone.eu/

      On Sun, Jun 23, 2024 at 6:51 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi everyone,

      Back from holidays, I indeed notice a lot of alerts and a very high load on our poor weblate instance that is already stretching our server past reasonable limits.

      As a short term measure, I have banned a couple of IP addresses that clearly abused the system.

      Now the good news is that I started configuring the new OCA server and we will progressively start moving the services to the new machine. This will also unblock the weblate upgrade to 5.x.

      I'll post here as this progresses, over the coming weeks and months.

      Best regards,

      --
      Stéphane Bidoul
      http://acsone.eu/

      On Thu, Jun 20, 2024 at 4:23 PM Frederik Kramer <notifications@odoo-community.org> wrote:

      Hi Jakob,

      sorry you are right. I can share your pain today as i was also trying to interact with part of our infrastructure that was equally lacking reliability and peformance. However, i am pretty sure that we will soon (as in volountary soon) have solutions for these problems. In the meantime thank you for your willingsness to help

      Best Frederik

      Am 20.06.24 um 16:03 schrieb Jakob Krabbe:
      Thank you for your reply!
After a few days with Weblate and 504 Gateway Time-out, I'm now moving 
on with other tasks. I hope you or maybe Stephané could post a notice on 
this list when such upgrade has been made!

regards,

// jakob



Den 2024-06-17 kl. 09:37, skrev Frederik Kramer:



> Hi Jakob,



> 



> afaik, OCA uses weblate because it doesn't just us as much as Transifex 



> charged us. If i am not mistaken we run Weblate ourselfes and if i 



> understood (Stephané Bidoul, who is the master of OCAs hardware 



> architecture) we are about to migrate on a more powerful hardware server 



> (also for that purpose). But Stephané can certainly be more precise on 



> that. So in the best case it should improve somewhen soon :-)



> 



> Best and thanks for the question



> 



> Frederik



> 



> Am 17.06.24 um 09:07 schrieb Jakob Krabbe:



>> Greetings!



>> I've done plenty of translating for Odoo in Sweden. Modules and



>> documentation for Odoo mainly in Transifex but also some for OCA, using



>> Weblate.



>>



>> I like the tool Weblate. Sometimes it's more helpful than Transifex!



>>



>> But I've always wondered why it's so slow. I often get the "500 time



>> out" -error and it's more frequently before lunch than after!



>>



>> Who's in charge? What's the plan, if any...?



>>



>> I assume others has experienced the same. I'm new to this e-mailing list



>> and maybe this has been discussed recently? If so, my apology for



>> highlighting the issue!



>>



>> regards,



>>



>> // jakob



>>



>>



>>



>>



>> -- Med vänlig hälsning / Best regards/ 顺祝商祺, Jakob Krabbe VERTEL 



>> AB | Jakob Krabbe | jakob.krabbe@vertel.se 



>> <mailto:jakob.krabbe@vertel.se> +46 (0)13 99 19 480 | +46 (0) 709 24 



>> 54 75 | vertel.se



>>



>> _______________________________________________



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



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



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



>> <mailto:contributors@odoo-community.org>



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



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



>>



> -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH Innungsstraße 7 



> 21244 Buchholz i.d.N. Tel: +49 (0) 4181 13503 12 Fax: +49 (0) 4181 13503 



> 10 Mobil: +49 (0) 179 3901819 Email: frederik.kramer@initos.com  <mailto:frederik.kramer@initos.com>



> Internet:www.initos.com  <http://www.initos.com>



> 



> Geschäftsführung:



> Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke



> 



> Sitz der Gesellschaft: Buchholz i.d.N.



> Amtsgericht Tostedt, HRB 205226



> USt-IdNr.: DE815580155



> Steuer-Nr: 15/200/53247



> 



> _______________________________________________



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



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



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



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



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



> 




-- 
Med vänlig hälsning / Best regards/ 顺祝商祺,
Jakob Krabbe

VERTEL AB | Jakob Krabbe | jakob.krabbe@vertel.se
+46 (0)13 99 19 480 | +46 (0) 709 24 54 75 | vertel.se

      _______________________________________________
      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
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

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

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247

      _______________________________________________
      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



      --
      Pierre
      by Pierre Verkest - 11:06 - 26 Jun 2024

  • dms not published at apps.odoo.com 
    
Greetings!
In a project, we depend on an OCA module, dms

https://github.com/OCA/dms/tree/14.0


When posting our project, we keep getting errors and we suspect that the 
unpublished OCA project dms is the reason!

https://apps.odoo.com/apps/modules/browse?series=14.0&price=Free&search=dms

What's the procedure!? Who's in charge!? Would it be possible to publish?

// jakob





-- 
Med vänlig hälsning / Best regards/ 顺祝商祺,
Jakob Krabbe

VERTEL AB | Jakob Krabbe | jakob.krabbe@vertel.se
+46 (0)13 99 19 480 | +46 (0) 709 24 54 75 | vertel.se
    by Jakob Krabbe - 02:41 - 14 Jun 2024

    1 replies 1 replies

    • Re: dms not published at apps.odoo.com
      Hello Jacob,

      I can try to help.
      I think the problem is the App Sotre inability to deal with modules than moved between repos:



      Transcript:

      ssh://git@github.com/OCA/dms.git#17.0
      Edit Scan Draft

      No module found in repository ssh://git@github.com/OCA/dms.git#17.0.
      Each module needs to be in a separate folder at the root of the repository, even if there is only one module.
      If you have all the files of your module at the root of your repository, you need to create a new folder with the name of your module and move all the files in it.
      ssh://git@github.com/OCA/dms.git#16.0
      Edit Scan Active

      Module dms already exists for another serie. Please select a free module name or use the right user account.
      dms_storage: unmet dependency dms for series 16.0. Dependency might be invalid.
      dms_user_role: unmet dependency dms for series 16.0. Dependency might be invalid.
      dms_auto_classification: unmet dependency dms for series 16.0. Dependency might be invalid.
      ssh://git@github.com/OCA/dms.git#15.0
      Edit Scan Active

      Module dms already exists for another serie. Please select a free module name or use the right user account.
      dms_field: unmet dependency dms for series 15.0. Dependency might be invalid.
      hr_dms_field: unmet dependency dms_field for series 15.0. Dependency might be invalid.
      dms_user_role: unmet dependency dms for series 15.0. Dependency might be invalid.
      dms_field_auto_classification is updated before its dependency dms_auto_classification. Throw back to the end of the queue.
      dms_auto_classification: unmet dependency dms for series 15.0. Dependency might be invalid.
      dms_attachment_link: unmet dependency dms for series 15.0. Dependency might be invalid.



      On 14/06/2024 13:42, Jakob Krabbe wrote:
      Greetings!
In a project, we depend on an OCA module, dms

https://github.com/OCA/dms/tree/14.0


When posting our project, we keep getting errors and we suspect that the 
unpublished OCA project dms is the reason!

https://apps.odoo.com/apps/modules/browse?series=14.0&price=Free&search=dms

What's the procedure!? Who's in charge!? Would it be possible to publish?

// jakob





-- 
Med vänlig hälsning / Best regards/ 顺祝商祺,
Jakob Krabbe

VERTEL AB | Jakob Krabbe | jakob.krabbe@vertel.se
+46 (0)13 99 19 480 | +46 (0) 709 24 54 75 | vertel.se

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

      Meet with me.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]

      by Daniel Reis - 03:06 - 14 Jun 2024

      1 attachments 1 attachments

      UfYfVNVg0Jv4MlSJ.png
  • apologies for mass PR creation 
    Hello everyone,

I asked yesterday Vincent to fix the name of Camptocamp in the manifest 
of the OCA addons, without realizing the impact this would have on the CI.

We are sorry for the disruption caused, and I should have checked before 
acting about the proper way to do this. Please accept our humble apologies.

Now if you have a recommendation on how to deal with the update in the 
proper way, we will be happy to get your feedback.

Kind regards,


-- 
Alexandre Fayolle
    by Alexandre Fayolle - 12:21 - 14 Jun 2024

    6 replies 6 replies

    • Re: apologies for mass PR creation
      Thanks for the apologies. I think this kind of massive changes that has nothing to do with the community and that involves a lot of repositories, should be planned with the community (like now you are doing with this message).

      Following that, anything done massively should have a pilot test to check that everything is OK instead of blindly performing 100 PRs. The commit message was not following the conventions, and that meant to double the number of pipelines to execute. I know this is not something that costs us directly (apart from a delay in all the real contributions checks), but we should also see for the environment not wasting CPU resources.

      Well, I don't want to dig more into something that has no remedy. Just for future actions. Now, a less impacting way to do this is as some proposals:

      - To be changed only for newer branches or when an update is done, like ForgeFlow did to pass from Eficent.
      - Do it progressively.
      - Do it directly for not having 3 checks: the PR one + the ocabot one + the merge one.

      And I add another one: you can put `[ci skip]` at the end of the commit message for avoiding the check at all, but this only serves if you do directly the write or merge the PR without ocabot.

      Regards.
      by Pedro M. Baeza - 01:51 - 14 Jun 2024
    • Re: apologies for mass PR creation 
      We can possibly find someone. Still, it would be nice to avoid 
triggering a full CI chain of all the affected branches. I'm not sure if 
there is a way to tell the gihub actions to skip all or parts of the checks?

Alexandre

On 14/06/2024 13:07, Alexey Pelykh wrote:

> IMHO, there's no other way to do that unless someone with write access 

> to the repos will exceptionally commit/merge those changes from local repo

> 

> Thus maybe just balancing a-repo-a-day?
      by Alexandre Fayolle - 01:25 - 14 Jun 2024
    • Re: apologies for mass PR creation 
      We can possibly find someone. Still, it would be nice to avoid 
triggering a full CI chain of all the affected branches. I'm not sure if 
there is a way to tell the gihub actions to skip all or parts of the checks?

Alexandre

On 14/06/2024 13:07, Alexey Pelykh wrote:

> IMHO, there's no other way to do that unless someone with write access 

> to the repos will exceptionally commit/merge those changes from local repo

> 

> Thus maybe just balancing a-repo-a-day?

> 

>> On 14 Jun 2024, at 12:47, Vincent Van Rossem 

>> <notifications@odoo-community.org> wrote:

>>

>> Hello dear Community and Contributors,

>>

>> My apologies for mass creating PRs and for wasting resources.

>>

>> Kind regards,

>>

>> Vincent

>>

>> On Fri, Jun 14, 2024 at 12:22 PM Alexandre Fayolle 

>> <notifications@odoo-community.org 

>> <mailto:notifications@odoo-community.org>> wrote:

>>

>>     Hello everyone,

>>

>>     I asked yesterday Vincent to fix the name of Camptocamp in the manifest

>>     of the OCA addons, without realizing the impact this would have on the CI.

>>

>>     We are sorry for the disruption caused, and I should have checked before

>>     acting about the proper way to do this. Please accept our humble apologies.

>>

>>     Now if you have a recommendation on how to deal with the update in the

>>     proper way, we will be happy to get your feedback.

>>

>>     Kind regards,

>>

>>     -- Alexandre Fayolle

>>

>>     _______________________________________________

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

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

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

>>     <mailto:contributors@odoo-community.org>

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

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

>>

>> _______________________________________________

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

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

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

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

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

>>

> 

> _______________________________________________

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

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

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

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

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

> 


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

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

http://www.camptocamp.com
      by Alexandre Fayolle - 01:25 - 14 Jun 2024
    • Re: apologies for mass PR creation
      Hi,

      That reflects the amount of work you did 'til now :-)

      I would say, at that time, code was done by 'Camptocamp SA'. So, it should not be changed before a new module update. I think the approach used by Forgeflow. You can have a talk with Jordi or Lois.

      My two cents

      Le ven. 14 juin 2024, 13:07, Alexey Pelykh <notifications@odoo-community.org> a écrit :

      IMHO, there's no other way to do that unless someone with write access to the repos will exceptionally commit/merge those changes from local repo

      Thus maybe just balancing a-repo-a-day?

      On 14 Jun 2024, at 12:47, Vincent Van Rossem <notifications@odoo-community.org> wrote:

      Hello dear Community and Contributors,

      My apologies for mass creating PRs and for wasting resources.

      Kind regards,

      Vincent

      On Fri, Jun 14, 2024 at 12:22 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:
      Hello everyone,

I asked yesterday Vincent to fix the name of Camptocamp in the manifest 
of the OCA addons, without realizing the impact this would have on the CI.

We are sorry for the disruption caused, and I should have checked before 
acting about the proper way to do this. Please accept our humble apologies.

Now if you have a recommendation on how to deal with the update in the 
proper way, we will be happy to get your feedback.

Kind regards,




-- 
Alexandre Fayolle

      _______________________________________________
      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 Denis Roussel. - 01:25 - 14 Jun 2024
    • Re: apologies for mass PR creation

      IMHO, there's no other way to do that unless someone with write access to the repos will exceptionally commit/merge those changes from local repo

      Thus maybe just balancing a-repo-a-day?

      On 14 Jun 2024, at 12:47, Vincent Van Rossem <notifications@odoo-community.org> wrote:

      Hello dear Community and Contributors,

      My apologies for mass creating PRs and for wasting resources.

      Kind regards,

      Vincent

      On Fri, Jun 14, 2024 at 12:22 PM Alexandre Fayolle <notifications@odoo-community.org> wrote:
      Hello everyone,

I asked yesterday Vincent to fix the name of Camptocamp in the manifest 
of the OCA addons, without realizing the impact this would have on the CI.

We are sorry for the disruption caused, and I should have checked before 
acting about the proper way to do this. Please accept our humble apologies.

Now if you have a recommendation on how to deal with the update in the 
proper way, we will be happy to get your feedback.

Kind regards,



-- 
Alexandre Fayolle

      _______________________________________________
      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 Alexey Pelykh - 01:06 - 14 Jun 2024

  • Contributors Odoo community
    Good afternoon,
     
    I am writing to the Association to estimate my income as an OCA collaborator, to participate in everything that the community demands and needs and can help us collaborate in this important collaborative project.
    Best regards from Seville (Spain)
     
    Jose Luis Baños
    CEO I Senior Lean Service Consultan
     
    by Jose Luis Baños - 06:50 - 13 Jun 2024

    1 attachments 1 attachments

    attachment

    1 replies 1 replies

  • Collaborate with OCA 
    Good afternoon,

I am writing to the Association to estimate my income as an OCA collaborator, to participate in everything that the community demands and needs and can help us collaborate in this important collaborative project.

Best regards from Seville (Spain)

Jose Luis Baños 
CEO I Senior Lean Service Consultan
    by "Jose Baños Bellido" <jlbb1955@icloud.com> - 06:26 - 13 Jun 2024

    1 replies 1 replies

  • Medical vertical 
    G'day all, hope this week is treating all of you well!

I wanted to check what's up with medical vertical repo - clearly it's abandoned and I guess there was a just reason to do that (as in, use X instead of Odoo).
So whoever worked with medical domain - please chime in.

Cheers,
Alexey
    by Alexey Pelykh - 06:16 - 12 Jun 2024

    6 replies 6 replies

  • Module to notify via mail of new login
    Hi,

    we are looking for an odoo module that will send an email to the user each time a new login is done (similar to what happens with social media, banking, etc.).

    Is there something ready-available in OCA?

    Thanks!

    --

    Francesco Foresti
    Sicurpharma Srl
    +39 333 8123 790
    by Francesco Foresti - 11:16 - 12 Jun 2024

    3 replies 3 replies

  • OCA Days 2024 - Call for Speakers and Early Bird Member Registration
    Hello OCA Contributors

    I hope this message finds you well.

    As you know our OCA Days 2024 are coming up in few months time:
    OCA Days 2024
    30th September - 1st October
    Val Benoit, Liège

    I just wanted to remind our paid upOCA members, that the Early Bird registration for OCA Days 2024 finishes at the end of June, after that the price increases:
    If you aren't an OCA member already, you can still become one here for €50, then you can take advantage of the early bird discount.

    If you don't wish to become a member but would still like to attend the OCA Days 2024 - you can purchase a:
    Our call for speakers is also open, if you have a proposal to submit, we would love to hear from you. Just fill in the form on this page.

    Please, if you have any questions, do not hesitate to get in touch.
    Rebecca
    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly (OCA) - 02:31 - 11 Jun 2024
  • odoo14 website mega-menu unexpected mobile behaviour?
    Hello,

    In odoo14 website if we add a mega-menu to the navbar then switch to mobile simulation, we get a non-expanded drop-down menu by default (see attachment megamenu1.png), I've made this screenshot made from OCA runboat.

    I'm having some sort of bug from mobile simulation in my current database: my custom mega-menu is loaded as already expanded when the website navbar is loaded.

    A few weeks ago, in a previous version of the database, that mega menu drop-down was properly loaded as non-expanded.

    I've noticed that this behaviour also applies if I create an entirely new mega-menu, so it's not strictly related to the specific item.

    I have tried to regenerate asset bundles and use the "-u all" command in order to resync database, however this pretty standard procedure didn't help for this situation.

    Do you have any hint to solve this problem?

    Thank you

    --
    Francesco Ballerini
    by Francesco Ballerini - 04:05 - 10 Jun 2024

    1 attachments 1 attachments

    megamenu1.png

    3 replies 3 replies

  • contribution request
    Hi, I am Mohamed!

    I am using web_notify module for version 17 as I had to upgrade it from version 16, and there was no any module for version 17.

    I would like to contribute to your repository in order to add the upgraded module for version 17, thanks 🙏
    by Mohamed Alkobrosly - 10:46 - 10 Jun 2024

    2 replies 2 replies

    • Re: contribution request
      Hello Mohamed,

      Please do so, your contribution is welcome.
      Make sure you review the migration guide here:

      Thanks
      Daniel

      On Mon, Jun 10, 2024 at 9:47 AM mohamed alkobrosly <notifications@odoo-community.org> wrote:
      Hi, I am Mohamed!

      I am using web_notify module for version 17 as I had to upgrade it from version 16, and there was no any module for version 17.

      I would like to contribute to your repository in order to add the upgraded module for version 17, thanks 🙏

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



      --
      Click to book a conversation with me.

      DANIEL REIS
      MANAGING DIRECTOR 

      M: +351 919991307
      E: dreis@OpenSourceIntegrators.com

      by Daniel Reis - 11:01 - 10 Jun 2024
    • Re: contribution request 
      Hi Mohamed,

Normally, you would have to sign the OCA CLA and then open up a PR on 
github.com/OCA/web, and follow these guidelines:

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-17.0

However, someone else already did all that:

https://github.com/OCA/web/pull/2747

So, maybe you can leave your review for his work. It always needs 2 
reviews in order to get merged, so your review will be welcomed.

-Tom

On 6/10/24 10:47, mohamed alkobrosly wrote:

> Hi, I am Mohamed!

>

> I am using web_notify module for version 17 as I had to upgrade it 

> from version 16, and there was no any module for version 17.

>

> I would like to contribute to your repository in order to add the 

> upgraded module for version 17, thanks 🙏

>

> _______________________________________________

> 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 - 10 Jun 2024
  • Setting up a Higher education ERP with Odoo Community version
    Good morning, 
    I am new to Odoo and would like to learn and set up an ERP with the Odoo community version using the OpenEducate modules. Can anyone help with a guide on how to install an Odoo instance with a cloud service provider?
    Thank you 
    Gabriel
    by Gabriel Aloho - 07:56 - 9 Jun 2024

    2 replies 2 replies

    • Re: Setting up a Higher education ERP with Odoo Community version
      Thank you for your email. It does help me a lot 

      On Mon, 10 Jun 2024 at 12:17, Tom Blauwendraat <notifications@odoo-community.org> wrote:
      Hi Gabriel,

there are a whole lot of ways to set up Odoo on a VM - there's Odoo's 
Docker image, there's Doodba which is a well-documented Docker method by 
Tecnativa, there's "dob" which is also a Docker method, .. there's also 
a script by Yenthe van Ginneken that some people like to use, ... all of 
which are easily found via your favourite search engine.

You could also consider contacting OpenEducat themselves to set up a 
demo instance for you.

Hope this helps,

-Tom

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

      by Gabriel Aloho - 12:20 - 10 Jun 2024
    • Re: Setting up a Higher education ERP with Odoo Community version 
      Hi Gabriel,

there are a whole lot of ways to set up Odoo on a VM - there's Odoo's 
Docker image, there's Doodba which is a well-documented Docker method by 
Tecnativa, there's "dob" which is also a Docker method, .. there's also 
a script by Yenthe van Ginneken that some people like to use, ... all of 
which are easily found via your favourite search engine.

You could also consider contacting OpenEducat themselves to set up a 
demo instance for you.

Hope this helps,

-Tom
      by Tom Blauwendraat - 12:16 - 10 Jun 2024
  • Importing v17 Journal Entries with analytic account info
    Hello, I might be missing something obvious, but here it goes:

    Odoo 17 uses the Analytic Distribution to store analytic account information on Journal Items.
    I would expect to be able to import journal entries including this analytic information.
    But it looks like the Analytic Distribution field is a JSON format and I can't find a user friendly way to import it.

    Is this an oversight on the Analytic Distribution  design, or am I missing something?
    Any recipe out there that can help with this?

    Thank you!

    --
    DANIEL REIS
    MANAGING PARTNER

    Meet with me.
    M: +351 919 991 307
    E: dreis@OpenSourceIntegrators.com
    A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

    [Logo OpenSourceIntegrators.com]

    by Daniel Reis - 05:07 - 7 Jun 2024

    1 replies 1 replies

  • Paperformat issues (Odoo14)

    Hi, 


    I am using this module report_qweb_element_page_visibility to be able to show footer conditionally in reports, but I'm having issues with paperformat.


    I need to define  a "margin botton" paperformat parameter in order to let the footer get the proper space when it needs to be rendered, although by defining a static paperformat margin bottom the space of the footer will always be occupied in the report, even if the footer is not displayed by the class last-page/first-page


    So the OCA module works properly, but I think that the margin bottom paperformat parameter is not flexible enough to support this situation.

    Did you ever come up with a solution to this ? Any kind of workaround is fine :)

    Thank you
    --
    Francesco Ballerini

    by Francesco Ballerini - 12:11 - 7 Jun 2024

    5 replies 5 replies

    • Re: Paperformat issues (Odoo14)
      Hi Tom, I've never looked closely at wkhtmltopdf and odoo report rendering methods so I've found your answer useful, at least I get a more precise idea of the limitations.
      Thanks for the detailed explanation.

      --
      Francesco Ballerini


      Il giorno ven 7 giu 2024 alle ore 20:03 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:

      Hi Francesco,

      thanks for the more detailed explanation, I get your wish now, I didn't before. You basically want the margin-bottom to differ per page.

      I think that's not easy because of the way things are implemented in Odoo - header, content and footer are passed to wkhtmltopdf as separate html blobs, and the margins are global parameters that define the space between them. The header and footer are repeated on each page and get passed a page numbering variable, which is what enables report_qwb_element_page_visibility to work. For the content, it flows across the whole document and generally you don't know while rendering on which page you are.

      So in essence, these are constraints of wkhtmltopdf.

      -Tom


      On 6/7/24 15:02, Francesco Ballerini wrote:
      One last note I forgot to report: it might be obvious, but although this issue might not be really problematic on standard report layouts, It will become an issue when you manage 4x or 5x higher footers, as the occupied space becomes relevant. 
      I posted an example with standard reports only for reproducibility.

      --
      Francesco Ballerini

      Il giorno ven 7 giu 2024 alle ore 14:44 Francesco Ballerini <francescobl.lavoro@gmail.com> ha scritto:

      Hi Tom,


      Thanks for the super quick response.

      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated


      That actually make sense for me, so since I was testing a custom report I've tried to reproduced the situation on OCA/reporting-engine odoo14 instance, unfortunately I must confirm what I've said in previous message: if you leave paper format margin bottom value to 0px the footer will not be rendered with or without the installation of module report_qweb_element_page_visibility .

      I've taken notes of all steps to reproduce this behaviour, you can read detailed steps below. Is there anything we can do? Should I open an issue for the module?

      I don't think it's strictly related, so I'm not sure what to do here.


      Steps to reproduce (example with sale order report)


      ADD VISIBILITY CLASS (render footer only in last page)

      - go on Settings > search for > search for "Document Layout", ensure the "external_layout_standard" or another layout is set

      - open the document layout by "external-link" window, find the "div" with footer class and add class "last-page"


      ENSURE PAPER FORMAT USAGE ON REPORT

      - go on Technical > Actions > Reports , select the one named "Quotation / Order"

      - set "A4" record as value for "Paperperformat" field, then click to open the paperformat (or go on Technical > Reporting > Paper Format, and select the A4 paperformat)


      CHANGE PAPER FORMAT PARAMETER

      - set margin bottom to 0px


      PREPARE SALE ORDER DOCUMENT

      - make a sale order that will have enough products to generate a report of at least 2 pages (around 25 products should be fine for the standard report)


      PRINT DOCUMENT

      - on the sale order click "Print" > Quotation / Order


      CURRENT BEHAVIOUR

      Footer will not be rendered on last page (I posted the report in attachments)


      Thank you,
      Francesco Ballerini
      --------------

      Il giorno ven 7 giu 2024 alle ore 12:22 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:

      It sounds a bit paradoxical that you define a bottom margin for the report which is then occupied :)

      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated

      Do you perhaps have a screenshot with some arrows and circles highlighting what you mean

      On 6/7/24 12:13, Francesco Ballerini wrote:

      Hi, 


      I am using this module report_qweb_element_page_visibility to be able to show footer conditionally in reports, but I'm having issues with paperformat.


      I need to define  a "margin botton" paperformat parameter in order to let the footer get the proper space when it needs to be rendered, although by defining a static paperformat margin bottom the space of the footer will always be occupied in the report, even if the footer is not displayed by the class last-page/first-page


      So the OCA module works properly, but I think that the margin bottom paperformat parameter is not flexible enough to support this situation.

      Did you ever come up with a solution to this ? Any kind of workaround is fine :)

      Thank you
      --
      Francesco Ballerini

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

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

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

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

      by Francesco Ballerini - 10:31 - 10 Jun 2024
    • Re: Paperformat issues (Odoo14)

      Hi Francesco,

      thanks for the more detailed explanation, I get your wish now, I didn't before. You basically want the margin-bottom to differ per page.

      I think that's not easy because of the way things are implemented in Odoo - header, content and footer are passed to wkhtmltopdf as separate html blobs, and the margins are global parameters that define the space between them. The header and footer are repeated on each page and get passed a page numbering variable, which is what enables report_qwb_element_page_visibility to work. For the content, it flows across the whole document and generally you don't know while rendering on which page you are.

      So in essence, these are constraints of wkhtmltopdf.

      -Tom


      On 6/7/24 15:02, Francesco Ballerini wrote:
      One last note I forgot to report: it might be obvious, but although this issue might not be really problematic on standard report layouts, It will become an issue when you manage 4x or 5x higher footers, as the occupied space becomes relevant. 
      I posted an example with standard reports only for reproducibility.

      --
      Francesco Ballerini

      Il giorno ven 7 giu 2024 alle ore 14:44 Francesco Ballerini <francescobl.lavoro@gmail.com> ha scritto:

      Hi Tom,


      Thanks for the super quick response.

      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated


      That actually make sense for me, so since I was testing a custom report I've tried to reproduced the situation on OCA/reporting-engine odoo14 instance, unfortunately I must confirm what I've said in previous message: if you leave paper format margin bottom value to 0px the footer will not be rendered with or without the installation of module report_qweb_element_page_visibility .

      I've taken notes of all steps to reproduce this behaviour, you can read detailed steps below. Is there anything we can do? Should I open an issue for the module?

      I don't think it's strictly related, so I'm not sure what to do here.


      Steps to reproduce (example with sale order report)


      ADD VISIBILITY CLASS (render footer only in last page)

      - go on Settings > search for > search for "Document Layout", ensure the "external_layout_standard" or another layout is set

      - open the document layout by "external-link" window, find the "div" with footer class and add class "last-page"


      ENSURE PAPER FORMAT USAGE ON REPORT

      - go on Technical > Actions > Reports , select the one named "Quotation / Order"

      - set "A4" record as value for "Paperperformat" field, then click to open the paperformat (or go on Technical > Reporting > Paper Format, and select the A4 paperformat)


      CHANGE PAPER FORMAT PARAMETER

      - set margin bottom to 0px


      PREPARE SALE ORDER DOCUMENT

      - make a sale order that will have enough products to generate a report of at least 2 pages (around 25 products should be fine for the standard report)


      PRINT DOCUMENT

      - on the sale order click "Print" > Quotation / Order


      CURRENT BEHAVIOUR

      Footer will not be rendered on last page (I posted the report in attachments)


      Thank you,
      Francesco Ballerini
      --------------

      Il giorno ven 7 giu 2024 alle ore 12:22 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:

      It sounds a bit paradoxical that you define a bottom margin for the report which is then occupied :)

      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated

      Do you perhaps have a screenshot with some arrows and circles highlighting what you mean

      On 6/7/24 12:13, Francesco Ballerini wrote:

      Hi, 


      I am using this module report_qweb_element_page_visibility to be able to show footer conditionally in reports, but I'm having issues with paperformat.


      I need to define  a "margin botton" paperformat parameter in order to let the footer get the proper space when it needs to be rendered, although by defining a static paperformat margin bottom the space of the footer will always be occupied in the report, even if the footer is not displayed by the class last-page/first-page


      So the OCA module works properly, but I think that the margin bottom paperformat parameter is not flexible enough to support this situation.

      Did you ever come up with a solution to this ? Any kind of workaround is fine :)

      Thank you
      --
      Francesco Ballerini

      _______________________________________________
      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 Tom Blauwendraat - 08:02 - 7 Jun 2024
    • Re: Paperformat issues (Odoo14)
      One last note I forgot to report: it might be obvious, but although this issue might not be really problematic on standard report layouts, It will become an issue when you manage 4x or 5x higher footers, as the occupied space becomes relevant. 
      I posted an example with standard reports only for reproducibility.

      --
      Francesco Ballerini

      Il giorno ven 7 giu 2024 alle ore 14:44 Francesco Ballerini <francescobl.lavoro@gmail.com> ha scritto:

      Hi Tom,


      Thanks for the super quick response.


      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated


      That actually make sense for me, so since I was testing a custom report I've tried to reproduced the situation on OCA/reporting-engine odoo14 instance, unfortunately I must confirm what I've said in previous message: if you leave paper format margin bottom value to 0px the footer will not be rendered with or without the installation of module report_qweb_element_page_visibility .


      I've taken notes of all steps to reproduce this behaviour, you can read detailed steps below. Is there anything we can do? Should I open an issue for the module?


      I don't think it's strictly related, so I'm not sure what to do here.


      Steps to reproduce (example with sale order report)


      ADD VISIBILITY CLASS (render footer only in last page)

      - go on Settings > search for > search for "Document Layout", ensure the "external_layout_standard" or another layout is set

      - open the document layout by "external-link" window, find the "div" with footer class and add class "last-page"


      ENSURE PAPER FORMAT USAGE ON REPORT

      - go on Technical > Actions > Reports , select the one named "Quotation / Order"

      - set "A4" record as value for "Paperperformat" field, then click to open the paperformat (or go on Technical > Reporting > Paper Format, and select the A4 paperformat)


      CHANGE PAPER FORMAT PARAMETER

      - set margin bottom to 0px


      PREPARE SALE ORDER DOCUMENT

      - make a sale order that will have enough products to generate a report of at least 2 pages (around 25 products should be fine for the standard report)


      PRINT DOCUMENT

      - on the sale order click "Print" > Quotation / Order


      CURRENT BEHAVIOUR

      Footer will not be rendered on last page (I posted the report in attachments)


      Thank you,
      Francesco Ballerini
      --------------

      Il giorno ven 7 giu 2024 alle ore 12:22 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:

      It sounds a bit paradoxical that you define a bottom margin for the report which is then occupied :)

      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated

      Do you perhaps have a screenshot with some arrows and circles highlighting what you mean

      On 6/7/24 12:13, Francesco Ballerini wrote:

      Hi, 


      I am using this module report_qweb_element_page_visibility to be able to show footer conditionally in reports, but I'm having issues with paperformat.


      I need to define  a "margin botton" paperformat parameter in order to let the footer get the proper space when it needs to be rendered, although by defining a static paperformat margin bottom the space of the footer will always be occupied in the report, even if the footer is not displayed by the class last-page/first-page


      So the OCA module works properly, but I think that the margin bottom paperformat parameter is not flexible enough to support this situation.

      Did you ever come up with a solution to this ? Any kind of workaround is fine :)

      Thank you
      --
      Francesco Ballerini

      _______________________________________________
      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 Francesco Ballerini - 03:01 - 7 Jun 2024
    • Re: Paperformat issues (Odoo14)

      Hi Tom,


      Thanks for the super quick response.


      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated


      That actually make sense for me, so since I was testing a custom report I've tried to reproduced the situation on OCA/reporting-engine odoo14 instance, unfortunately I must confirm what I've said in previous message: if you leave paper format margin bottom value to 0px the footer will not be rendered with or without the installation of module report_qweb_element_page_visibility .


      I've taken notes of all steps to reproduce this behaviour, you can read detailed steps below. Is there anything we can do? Should I open an issue for the module?


      I don't think it's strictly related, so I'm not sure what to do here.


      Steps to reproduce (example with sale order report)


      ADD VISIBILITY CLASS (render footer only in last page)

      - go on Settings > search for > search for "Document Layout", ensure the "external_layout_standard" or another layout is set

      - open the document layout by "external-link" window, find the "div" with footer class and add class "last-page"


      ENSURE PAPER FORMAT USAGE ON REPORT

      - go on Technical > Actions > Reports , select the one named "Quotation / Order"

      - set "A4" record as value for "Paperperformat" field, then click to open the paperformat (or go on Technical > Reporting > Paper Format, and select the A4 paperformat)


      CHANGE PAPER FORMAT PARAMETER

      - set margin bottom to 0px


      PREPARE SALE ORDER DOCUMENT

      - make a sale order that will have enough products to generate a report of at least 2 pages (around 25 products should be fine for the standard report)


      PRINT DOCUMENT

      - on the sale order click "Print" > Quotation / Order


      CURRENT BEHAVIOUR

      Footer will not be rendered on last page (I posted the report in attachments)


      Thank you,
      Francesco Ballerini
      --------------

      Il giorno ven 7 giu 2024 alle ore 12:22 Tom Blauwendraat <notifications@odoo-community.org> ha scritto:

      It sounds a bit paradoxical that you define a bottom margin for the report which is then occupied :)

      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated

      Do you perhaps have a screenshot with some arrows and circles highlighting what you mean

      On 6/7/24 12:13, Francesco Ballerini wrote:

      Hi, 


      I am using this module report_qweb_element_page_visibility to be able to show footer conditionally in reports, but I'm having issues with paperformat.


      I need to define  a "margin botton" paperformat parameter in order to let the footer get the proper space when it needs to be rendered, although by defining a static paperformat margin bottom the space of the footer will always be occupied in the report, even if the footer is not displayed by the class last-page/first-page


      So the OCA module works properly, but I think that the margin bottom paperformat parameter is not flexible enough to support this situation.

      Did you ever come up with a solution to this ? Any kind of workaround is fine :)

      Thank you
      --
      Francesco Ballerini

      _______________________________________________
      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 Francesco Ballerini - 02:46 - 7 Jun 2024

      1 attachments 1 attachments

      Quotation - S00023 (2).pdf
    • Re: Paperformat issues (Odoo14)

      It sounds a bit paradoxical that you define a bottom margin for the report which is then occupied :)

      AFAIK the report_qweb_element_page_visibility operates on the area outside the margins of the "content area" so the two things should be clearly separated

      Do you perhaps have a screenshot with some arrows and circles highlighting what you mean

      On 6/7/24 12:13, Francesco Ballerini wrote:

      Hi, 


      I am using this module report_qweb_element_page_visibility to be able to show footer conditionally in reports, but I'm having issues with paperformat.


      I need to define  a "margin botton" paperformat parameter in order to let the footer get the proper space when it needs to be rendered, although by defining a static paperformat margin bottom the space of the footer will always be occupied in the report, even if the footer is not displayed by the class last-page/first-page


      So the OCA module works properly, but I think that the margin bottom paperformat parameter is not flexible enough to support this situation.

      Did you ever come up with a solution to this ? Any kind of workaround is fine :)

      Thank you
      --
      Francesco Ballerini

      _______________________________________________
      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 - 12:21 - 7 Jun 2024
  • e-Commerce categories template on another page (Odoo14)
    Hi,

    I'd like to bring the category template of e-Commerce (this one) on the Homepage route.

    Did someone else ever did it on public repository? (currently working on odoo14 so nearest versions are fine)

    I think I could literally re-use the original template and a new controller in order to send categories data on the home page, but having an example of implementation would be great.

    Regards,
    --
    Francesco Ballerini

    by Francesco Ballerini - 04:41 - 6 Jun 2024
  • Mass ir.attachment export 
    Greetings,

I'm looking for a module that could export all attachments from bills and invoices, preferably sorted by month - for archival purposes. Any in existence?

Cheers,
Alexey
    by Alexey Pelykh - 09:22 - 5 Jun 2024

    3 replies 3 replies

  • Outgoing quantity from draft/sent or not fully delivered confirmed orders (odoo14)
    Hi,

    I am looking for way to compute a field on products that shows the "free quantity" in a slightly different way compared to Odoo:
    Odoo will show free quantity as "qty on hand - reserved qty", but the reserved quantity is related to stock moves so the evaluation involves an order confirmation.

    I have been asked to add a new "free quantity" field that is computed instead as "qty on hand - outgoing qty" where the outgoing quantity should be computed from

    •  'draft' (quotations) orders
    • 'sent' (e-Commerce) orders
    • 'confirm' orders but only for those lines that hasn't been fully delivered

    I might have found an approach to this, which I'll describe below, but I'd like to ask if you have a better suggestion (in best case a field that I've missed or maybe a module introducing this), as I was looking for an easier or better way to achieve this task. 

    Otherwise I think I can do the following:

    I think I can use this module maybe in combination with its parent sale_delivery_state, in order to filter out the majority of orders and evaluate the remaining order lines, filtered by active product: 
    the sum of `demanded quantity - delivered quantity` for all those lines should match the needed computation I need for the "outgoing" quantity at this point.

    Do you have any hint for a shorter and/or better way?

    Thanks in advance

    --
    Francesco Ballerini
    by Francesco Ballerini - 05:21 - 4 Jun 2024

    4 replies 4 replies

  • Contracts for different subsequent prices 
    Hi!
We sell a service contract which costs more in the first year (because 
of installation service) and less in subsequent years (license costs 
only). Ideally this would be configured as a single product which can 
simply be offered in the online shop. Is it possible to configure these 
different prices with Contracts?

Best regards
Jan
    by Jan Suhr - 06:45 - 3 Jun 2024

    4 replies 4 replies

    • Re: Contracts for different subsequent prices

      Hello Jan,

      Do you use the product_contract module to make contract subscription available in the webshop ?

      If yes, you should be able to set up the contract template linked to the product with different lines with different recurrence/end date.  

      Victor Champonnois - Coop IT Easy
Tel : +32 475 81 01 12
      On 4/06/24 09:59, Jan Suhr | Nitrokey wrote:
      Hi Pablo!
Yes, I see this is possible in a sales order. But can this be configured 
in the product or contract or contract template so that it automatically 
applies to all products/contracts bought in the online shop?

Best regards
Jan

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

      by Victor Champonnois - 11:16 - 5 Jun 2024
    • Re: Contracts for different subsequent prices
      Jan, with OCA Contracts you use a Contract Template, whith Recurrence at Line Level, and specific Date End for that line only for one year.




      El 2024-06-04 04:59, Jan Suhr | Nitrokey escribió:
      Hi Pablo!
      Yes, I see this is possible in a sales order. But can this be configured
      in the product or contract or contract template so that it automatically
      applies to all products/contracts bought in the online shop?
      Best regards
      Jan

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



      [1] https://odoo-community.org/groups/contributors-15
      [2] https://odoo-community.org/groups?unsubscribe
      by info - 09:45 - 4 Jun 2024

      1 attachments 1 attachments

      6de5bac3.png
    • Re: Contracts for different subsequent prices 
      Hi Pablo!
Yes, I see this is possible in a sales order. But can this be configured 
in the product or contract or contract template so that it automatically 
applies to all products/contracts bought in the online shop?

Best regards
Jan
      by Jan Suhr - 09:58 - 4 Jun 2024
    • Re: Contracts for different subsequent prices 
      Hello Jan

Yes, you can specify diferente recurrence for each line, and you can set 
an end date for each individual line.

Regards



El 2024-06-03 13:47, Jan Suhr | Nitrokey escribió:

> Hi!

> We sell a service contract which costs more in the first year (because

> of installation service) and less in subsequent years (license costs

> only). Ideally this would be configured as a single product which can

> simply be offered in the online shop. Is it possible to configure these

> different prices with Contracts?

> Best regards

> Jan

> 

> _______________________________________________

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

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

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

> 

> 

> 

> [1] https://odoo-community.org/groups/contributors-15

> [2] https://odoo-community.org/groups?unsubscribe
      by info - 05:03 - 4 Jun 2024