Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • 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
  • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
    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:21 - 18 Jun 2024
  • Re: OCA Mailing-list and Weblate rate limit issue 
    
Hello!
To solve this, the same is for me with Swedish... press BACK in your 
browser and reload the page and do the same again and then it works.

I don't remember the exact procedure, it was a while ago, but do some 
clicking to solve the error and to continue where you left off.


> 

> *Your request was rejected because you have performed too many 

> operations recently. You have been signed out, please sign in and try 

> again later. *

> 

> 

-- 
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 - 01:54 - 18 Jun 2024
  • OCA Mailing-list and Weblate rate limit issue
    Hello everyone,

    First, this message has already been posted on transbot@odoo-community.org but after looking on https://odoo-community.org/groups, it looks like there is only 1 mailing-list now ? all others are dropped ?
    Secondly, did you know that you can login on https://odoo-community.org with admin/admin ?

    So I'm reposting here my message:

    I started working on translating some modules in the maintenance repository.
    But now I'm stuck (10 min cooldown ) when I want to add a new FR translation with this error:

    Your request was rejected because you have performed too many operations recently. You have been signed out, please sign in and try again later.



    Technically, only 8 translations have been created this morning (17 jun 2023) before this auto-signout appears, and it looks like it is related to this rate limits:

    I can create 2 translations every 5 minutes ... that's too long but the lockout period (10 minutes) is worse because it looks like it is reset after each attempt ...
    Could you decrease this rate ( RATELIMIT_LANGUAGE_ATTEMPTS ) to the minimum or at least 1 minute ? because this step is recurrent and it is really frustrating to be locked out when so many modules needs translating for a few words

    Thank you,
    by Yann Papouin - 11:14 - 18 Jun 2024
  • 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
  • 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
  • Re: One email address for sales, another for invoices
    Thank you!

    Years and years and I'm still confused about odoo contacts structure...

    Francesco

    Il giorno lun 17 giu 2024 alle ore 15:42 Frederik Kramer <notifications@odoo-community.org> ha scritto:

    +1

    Am 17.06.24 um 15:32 schrieb Nils Coenen | NICO SOLUTIONS - ENGINEERING & IT:
    Activate customer addresses in settings and define invoice contact for the customer with the appropriate details. 

    Von: Francesco Foresti <notifications@odoo-community.org>
    Gesendet: Monday, June 17, 2024 3:27:28 PM
    An: Contributors <contributors@odoo-community.org>
    Betreff: One email address for sales, another for invoices
     

    ACHTUNG! Diese E-Mail stammt von außerhalb der Organisation. Klicken Sie nicht auf Links und öffnen Sie keine Anhänge, es sei denn, Sie kennen den Absender und wissen, dass der Inhalt sicher ist.

    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

    _______________________________________________
    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 - 04:16 - 17 Jun 2024
  • Re: One email address for sales, another for invoices

    +1

    Am 17.06.24 um 15:32 schrieb Nils Coenen | NICO SOLUTIONS - ENGINEERING & IT:
    Activate customer addresses in settings and define invoice contact for the customer with the appropriate details. 

    Von: Francesco Foresti <notifications@odoo-community.org>
    Gesendet: Monday, June 17, 2024 3:27:28 PM
    An: Contributors <contributors@odoo-community.org>
    Betreff: One email address for sales, another for invoices
     

    ACHTUNG! Diese E-Mail stammt von außerhalb der Organisation. Klicken Sie nicht auf Links und öffnen Sie keine Anhänge, es sei denn, Sie kennen den Absender und wissen, dass der Inhalt sicher ist.

    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

    _______________________________________________
    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 - 03:41 - 17 Jun 2024
  • Re: One email address for sales, another for invoices
    Activate customer addresses in settings and define invoice contact for the customer with the appropriate details. 

    Von: Francesco Foresti <notifications@odoo-community.org>
    Gesendet: Monday, June 17, 2024 3:27:28 PM
    An: Contributors <contributors@odoo-community.org>
    Betreff: One email address for sales, another for invoices
     

    ACHTUNG! Diese E-Mail stammt von außerhalb der Organisation. Klicken Sie nicht auf Links und öffnen Sie keine Anhänge, es sei denn, Sie kennen den Absender und wissen, dass der Inhalt sicher ist.

    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

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

    by Nils Coenen - 03:31 - 17 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
  • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
    👍
    Von: Pedro M. Baeza <notifications@odoo-community.org>
    Gesendet: Monday, June 17, 2024 1:43:28 PM
    An: Contributors <contributors@odoo-community.org>
    Betreff: Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
     

    ACHTUNG! Diese E-Mail stammt von außerhalb der Organisation. Klicken Sie nicht auf Links und öffnen Sie keine Anhänge, es sei denn, Sie kennen den Absender und wissen, dass der Inhalt sicher ist.

    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

    by Nils Coenen - 03:20 - 17 Jun 2024
  • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo 
    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
    by Frederik Kramer - 02:15 - 17 Jun 2024
  • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
    I think only Elon Musk needs to use "x_" to identify a field...

    Il giorno lun 17 giu 2024 alle ore 13:43 Pedro M. Baeza <notifications@odoo-community.org> ha scritto:
    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



    --

    Francesco Apruzzese

    Profilo professionale: http://it.linkedin.com/in/francescoapruzzese

    Il contenuto di questo messaggio elettronico è riservato e tutelato dal segreto professionale ed è rivolto esclusivamente al/ai destinatario/i identificato/i. Pertanto è proibito leggerlo, copiarlo, divulgarlo o utilizzarlo da parte di chiunque salvo il/i destinatario/i. Se non siete il destinatario, vi invitiamo a cancellare il messaggio ed eventuali allegati dandocene immediatamente comunicazione scritta a mezzo posta elettronica.
    This e-mail and any attachments are confidential and may contain information intended for the addressee(s) only. Reading, copying, disclosure or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail.

    Non stampare questa email se non strettamente necessario. Aiuta te ed aiuta l'ambiente.
    by Francesco Apruzzese - 01:56 - 17 Jun 2024
  • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
    +10

    Kind Regards
    Christian

    Von: "Pedro M. Baeza" <notifications@odoo-community.org>
    An: "Odoo Community Association, (OCA) Contributors" <contributors@odoo-community.org>
    Gesendet: Montag, 17. Juni 2024 13:43:13
    Betreff: Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo

    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


    by Christian Zöllner - 01:51 - 17 Jun 2024
  • Re: Please share your thoughts on the use of `x_` prefix for custom fields in Odoo
    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.
    by Pedro M. Baeza - 01:43 - 17 Jun 2024
  • 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
  • Re: OCA Weblate, why the lack of speed?

    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
+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
    by Frederik Kramer - 09:36 - 17 Jun 2024