Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • Migrations scripts from MuK DMS to OCA DMS 
    Hello everybody,

we need to migrate some customers from the original MuK DMS modules to
the OCA modules. I seem to remember having seen something about ready
migration scripts several years ago when the DMS modules were first imported
into the OCA repository, but am not able to find that again.

Can anybody help?

Thanks in advance for any hint,

Olaf

-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
    by Olaf Wagner - 12:05 - 24 Mar 2025

    6 replies 6 replies

    • Re: Migrations scripts from MuK DMS to OCA DMS 
      On 25 Mar 2025, at 15:52, Pedro M. Baeza wrote:


> It seems there should be an initial problem that leads to the one you 

> are including. Please inspect the complete log, and any further thing, 

> put it on the GitHub repo.

> Regards.

I’ve opened this issue on the OpenUpgrade github repo with more 
information including a complete log:
https://github.com/OCA/OpenUpgrade/issues/4881

I think this is what you suggested.


> _______________________________________________

> 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

Regards,
Olaf

-- 
Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, 
Germany
Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: 
DE163214194
      by Olaf Wagner - 05:11 - 25 Mar 2025
    • Re: Migrations scripts from MuK DMS to OCA DMS
      It seems there should be an initial problem that leads to the one you are including. Please inspect the complete log, and any further thing, put it on the GitHub repo.

      Regards.
      by Pedro M. Baeza - 03:50 - 25 Mar 2025
    • Re: Migrations scripts from MuK DMS to OCA DMS

      Thank you very much everybody for the information and the great work on openupgrade.
      I wasn’t aware that everything is already integrated into the existing scripts.
      However, when I run the migration in 13.0, it fails in the postmigration step for the
      dms. Im am using the latest versions of the openupgradelib and the 13.0 branch from
      openupgrade itself.

      2025-03-24 16:20:03,420 2372 INFO elego_v13 odoo.modules.migration: module dms: Running migration [13.0.8.1.0>] post-migration
2025-03-24 16:20:03,422 2372 INFO elego_v13 OpenUpgrade: dms: post-migration script called with version 12.0.2.0.1
2025-03-24 16:20:03,579 2372 ERROR elego_v13 OpenUpgrade: dms: error in migration script /opt/odoo/lib/addons/oca-mirror-dms/dms/migrations/13.0.8.1.0/post-migration.py: ('dms.file(3249,).content', None)
2025-03-24 16:20:03,579 2372 ERROR elego_v13 OpenUpgrade: ('dms.file(3249,).content', None)
Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/api.py", line 748, in get
    value = self._data[field][record._ids[0]]
KeyError: 3249

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/fields.py", line 1038, in __get__
    value = env.cache.get(record, self)
  File "/opt/odoo/lib/odoo/odoo/api.py", line 754, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: ('dms.file(3249,).content', None)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/api.py", line 748, in get
    value = self._data[field][record._ids[0]]
KeyError: 3249

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/openupgradelib/openupgrade.py", line 2331, in wrapped_function
    version,
  File "/opt/odoo/lib/addons/oca-mirror-dms/dms/migrations/13.0.8.1.0/post-migration.py", line 9, in migrate
    env["dms.file"].search([])._compute_mimetype()
  File "/opt/odoo/lib/addons/oca-mirror-dms/dms/models/dms_file.py", line 379, in _compute_mimetype
    record.res_mimetype = guess_mimetype(base64.b64decode(record.content or ""))
  File "/opt/odoo/lib/odoo/odoo/fields.py", line 1065, in __get__
    value = env.cache.get(record, self)
  File "/opt/odoo/lib/odoo/odoo/api.py", line 754, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: ('dms.file(3249,).content', None)
2025-03-24 16:20:03,584 2372 ERROR elego_v13 odoo.modules.loading: Error executing post migration script for module dms
: ('dms.file(3249,).content', None)
2025-03-24 16:20:03,596 2372 ERROR elego_v13 odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/api.py", line 748, in get
    value = self._data[field][record._ids[0]]
KeyError: 3249

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/fields.py", line 1038, in __get__
    value = env.cache.get(record, self)
  File "/opt/odoo/lib/odoo/odoo/api.py", line 754, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: ('dms.file(3249,).content', None)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/api.py", line 748, in get
    value = self._data[field][record._ids[0]]
KeyError: 3249

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/modules/registry.py", line 87, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/opt/odoo/lib/odoo/odoo/modules/loading.py", line 489, in load_modules
    force, status, report, loaded_modules, update_module, models_to_check, upg_registry)
  File "/opt/odoo/lib/odoo/odoo/modules/loading.py", line 368, in load_marked_modules
    upg_registry=upg_registry,
  File "/opt/odoo/lib/odoo/odoo/modules/loading.py", line 256, in load_module_graph
    migrations.migrate_module(package, 'post')
  File "/opt/odoo/lib/odoo/odoo/modules/migration.py", line 191, in migrate_module
    migrate(self.cr, installed_version)
  File "/usr/local/lib/python3.7/dist-packages/openupgradelib/openupgrade.py", line 2331, in wrapped_function
    version,
  File "/opt/odoo/lib/addons/oca-mirror-dms/dms/migrations/13.0.8.1.0/post-migration.py", line 9, in migrate
    env["dms.file"].search([])._compute_mimetype()
  File "/opt/odoo/lib/addons/oca-mirror-dms/dms/models/dms_file.py", line 379, in _compute_mimetype
    record.res_mimetype = guess_mimetype(base64.b64decode(record.content or ""))
  File "/opt/odoo/lib/odoo/odoo/fields.py", line 1065, in __get__
    value = env.cache.get(record, self)
  File "/opt/odoo/lib/odoo/odoo/api.py", line 754, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: ('dms.file(3249,).content', None)
2025-03-24 16:20:03,597 2372 CRITICAL elego_v13 odoo.service.server: Failed to initialize database `elego_v13`.
Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/api.py", line 748, in get
    value = self._data[field][record._ids[0]]
KeyError: 3249

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/fields.py", line 1038, in __get__
    value = env.cache.get(record, self)
  File "/opt/odoo/lib/odoo/odoo/api.py", line 754, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: ('dms.file(3249,).content', None)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/api.py", line 748, in get
    value = self._data[field][record._ids[0]]
KeyError: 3249

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/lib/odoo/odoo/service/server.py", line 1194, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/opt/odoo/lib/odoo/odoo/modules/registry.py", line 87, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/opt/odoo/lib/odoo/odoo/modules/loading.py", line 489, in load_modules
    force, status, report, loaded_modules, update_module, models_to_check, upg_registry)
  File "/opt/odoo/lib/odoo/odoo/modules/loading.py", line 368, in load_marked_modules
    upg_registry=upg_registry,
  File "/opt/odoo/lib/odoo/odoo/modules/loading.py", line 256, in load_module_graph
    migrations.migrate_module(package, 'post')
  File "/opt/odoo/lib/odoo/odoo/modules/migration.py", line 191, in migrate_module
    migrate(self.cr, installed_version)
  File "/usr/local/lib/python3.7/dist-packages/openupgradelib/openupgrade.py", line 2331, in wrapped_function
    version,
  File "/opt/odoo/lib/addons/oca-mirror-dms/dms/migrations/13.0.8.1.0/post-migration.py", line 9, in migrate
    env["dms.file"].search([])._compute_mimetype()
  File "/opt/odoo/lib/addons/oca-mirror-dms/dms/models/dms_file.py", line 379, in _compute_mimetype
    record.res_mimetype = guess_mimetype(base64.b64decode(record.content or ""))
  File "/opt/odoo/lib/odoo/odoo/fields.py", line 1065, in __get__
    value = env.cache.get(record, self)
  File "/opt/odoo/lib/odoo/odoo/api.py", line 754, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: ('dms.file(3249,).content', None)
2025-03-24 16:20:03,599 2372 INFO elego_v13 odoo.service.server: Stopping gracefully
openupgrade failed

      This may be a subsequent error, as I see some of these error logs before:

      2025-03-24 16:20:03,383 2372 ERROR elego_v13 OpenUpgrade: Pass argument 'env_or_cr' as Cursor parameter until 16.0

      I haven’t been able to isolate the problem further yet.
      The actual data — dms.file(3249) — is there and should be correct (at least in the MuK tables); content is
      one of the columns that are new or migrated.

      Looking forward for any hints how best to proceed again.

      Olaf

      On 24 Mar 2025, at 13:33, Enric Tobella Alomar wrote:

      When we ported the module, we made it compatible with MUK DMS. You should need to use OpenUpgrade on the migration and set the rename of the module on the apriori file.

      Kind regards,

      El lun, 24 mar 2025 a las 13:17, Radovan Skolnik (<notifications@odoo-community.org>) escribió:

      Hi,


      I believe it is already part of the migration scripts. Check https://github.com/OCA/dms/tree/13.0/dms/migrations/13.0.1 and/or https://github.com/tegin/dms/commits/13.0-dms-migration/


      Best regards


          Radovan Skolnik


      On pondelok 24. marca 2025 12:07:13 CET Olaf Wagner wrote:

      > Hello everybody,

      > we need to migrate some customers from the original MuK DMS modules to

      > the OCA modules. I seem to remember having seen something about ready

      > migration scripts several years ago when the DMS modules were first imported

      > into the OCA repository, but am not able to find that again.

      > Can anybody help?

      > Thanks in advance for any hint,

      > Olaf

      > --

      > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com

      > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany

      > Geschäftsführer: Olaf Wagner | Sitz: Berlin

      > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

      >

      > _______________________________________________

      > 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



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



      --
      Enric Tobella Alomar
      CEO & Founder

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

      --
      Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com
      Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
      Geschäftsführer: Olaf Wagner | Sitz: Berlin
      Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

      by Olaf Wagner - 09:11 - 25 Mar 2025
    • Re: Migrations scripts from MuK DMS to OCA DMS
      When we ported the module, we made it compatible with MUK DMS. You should need to use OpenUpgrade on the migration and set the rename of the module on the apriori file.

      Kind regards,

      El lun, 24 mar 2025 a las 13:17, Radovan Skolnik (<notifications@odoo-community.org>) escribió:

      Hi,


      I believe it is already part of the migration scripts. Check https://github.com/OCA/dms/tree/13.0/dms/migrations/13.0.1 and/or https://github.com/tegin/dms/commits/13.0-dms-migration/


      Best regards


          Radovan Skolnik


      On pondelok 24. marca 2025 12:07:13 CET Olaf Wagner wrote:

      > Hello everybody,

      > we need to migrate some customers from the original MuK DMS modules to

      > the OCA modules. I seem to remember having seen something about ready

      > migration scripts several years ago when the DMS modules were first imported

      > into the OCA repository, but am not able to find that again.

      > Can anybody help?

      > Thanks in advance for any hint,

      > Olaf

      > --

      > Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com

      > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany

      > Geschäftsführer: Olaf Wagner | Sitz: Berlin

      > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

      >

      > _______________________________________________

      > 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



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



      --
      Enric Tobella Alomar
      CEO & Founder

      by Enric Tobella Alomar - 01:32 - 24 Mar 2025
    • Re: Migrations scripts from MuK DMS to OCA DMS
      Yes, I confirm that's it!
      by Pedro M. Baeza - 01:25 - 24 Mar 2025

  • Late Purchase Bill
    Esteemed Contributors,

    A client presents a complex billing scenario. They enjoy a strong vendor relationship, receiving goods on credit for production, with payments consistently delayed (6-10 months) after goods are consumed and sold. Pricing is uniquely determined at the time of payment. Which module optimally addresses this situation?

    Best regards, 
    Abdulbasit Suleiman 
    by basit.suleiman91 - 11:51 - 24 Mar 2025

    1 replies 1 replies

    • Re: Late Purchase Bill
      i don't think you need anything special.

      either:
      - update the purchase price unit before issuing the vendor bill
      - or add a discount on the vendor bill to reflect the actual amount paid




      On Mon, 24 Mar 2025 at 6:53 PM, Abdulbasit Suleiman <notifications@odoo-community.org> wrote:
      Esteemed Contributors,

      A client presents a complex billing scenario. They enjoy a strong vendor relationship, receiving goods on credit for production, with payments consistently delayed (6-10 months) after goods are consumed and sold. Pricing is uniquely determined at the time of payment. Which module optimally addresses this situation?

      Best regards, 
      Abdulbasit Suleiman 

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

      by dominique.k - 04:35 - 24 Mar 2025
  • odoo CE to OCB
    Dear Contributors,

    We are deploying odoo17 CE with OCA modules. Using  docker-compose However we want to migrate our customers to OCB image without affecting the persistent volume. 

    Kindly recommend the OCB docker image that the docker file is most similar to odoo CE image.

    Best Regards,
    Abdulbasit Suleiman 
    by basit.suleiman91 - 11:46 - 24 Mar 2025

    3 replies 3 replies

    • Re: odoo CE to OCB
      Dear Tom,

      Thanks for this, I am currently working with version 17.0, the doodba image didn't work directly from my docker compose. I am also using traefik for reverse proxy because of mixed content error while editing website over cloudflare tunnel. 

      Kindly Advise.

      Warm regards, 
      Abdulbasit 

      From: Pedro M. Baeza <notifications@odoo-community.org>
      Sent: Tuesday, March 25, 2025 9:09:22 AM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: odoo CE to OCB
       
      You can try Doodba (https://github.com/Tecnativa/doodba) for using Docker and there, OCB is used by default (but you can also use odoo/odoo if you want).

      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 basit.suleiman91 - 10:25 - 25 Mar 2025
    • Re: odoo CE to OCB
      You can try Doodba (https://github.com/Tecnativa/doodba) for using Docker and there, OCB is used by default (but you can also use odoo/odoo if you want).

      Regards.
      by Pedro M. Baeza - 09:06 - 25 Mar 2025
    • Re: odoo CE to OCB 
      Hi Abdulbasit,

Just get the most recent OCA/OCB, that's always the best idea anyway - 
it's based on the latest odoo/odoo and has the most fixes available.

Only thing is that if you were stuck on an older image, you might have 
to "upgrade base" and in some databases this can overwrite some records. 
Make sure you test this on a test database first before doing it in 
production.

-Tom


On 3/24/25 11:47, Abdulbasit Suleiman wrote:

> Dear Contributors,

>

> We are deploying odoo17 CE with OCA modules. Using  docker-compose 

> However we want to migrate our customers to OCB image without 

> affecting the persistent volume.

>

> Kindly recommend the OCB docker image that the docker file is most 

> similar to odoo CE image.

>

> Best Regards,

> Abdulbasit Suleiman

>

> _______________________________________________

> 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 - 09:01 - 25 Mar 2025
  • Manage odoo automatic mails with recipients anti spam
    Dear OCA contributors,

    How do you manage automatic mailings from odoo when the recipient uses an anti-spam solution that requires the sender to be validated by a return mail that requires clicking on a link or filling a captcha ?
    I have a customer who uses the https://www.mailinblack.com/en solution.
    Mails returned by recipients who have mailinblack are not returned in Odoo in the original mail thread and are invisible in Odoo.

    What are the best practices in this case?

    Thanks a lot

    Regards

    David BEAL
    by David BEAL - 01:00 - 21 Mar 2025

    2 replies 2 replies

    • Re: Manage odoo automatic mails with recipients anti spam

      Hi David,

       

      We are using an external mailbox via SMTP. Any delivery issues - such as mailinblack - appear in the inbox of the external mailbox. Actual delivery can be managed from the dedicated inbox. We did not find an automated solution yet, probably because that is the intention behind the use of mailinblack 😊.
      Set-up of such a mailbox is via Technical > email > outgoing mail servers.

      Hope this helps.

       

      Kind Regards,

       

      Piet Hendriks

      Icon Description automatically generated

      Phone +31 646 0905 87                                

      Email Piet.Hendriks@quadronics.com

       

       

      From: David Beal <notifications@odoo-community.org>
      Date: Friday, 21 March 2025 at 13:03
      To: Contributors <contributors@odoo-community.org>
      Subject: Manage odoo automatic mails with recipients anti spam

      Dear OCA contributors,

       

      How do you manage automatic mailings from odoo when the recipient uses an anti-spam solution that requires the sender to be validated by a return mail that requires clicking on a link or filling a captcha ?
      I have a customer who uses the https://www.mailinblack.com/en solution.
      Mails returned by recipients who have mailinblack are not returned in Odoo in the original mail thread and are invisible in Odoo.


      What are the best practices in this case?

       

      Thanks a lot

       

      Regards

       

      David BEAL

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

      by Piet Hendriks - 01:21 - 21 Mar 2025
    • Re: Manage odoo automatic mails with recipients anti spam
      The first thing that I would do is look at the Message-Id and References headers in the response email to determine if you are suffering from an issue like

      """Issue: when using Amazon's SES SMTP service they rewrite the Message-Id of all
      outgoing messages. When someone replies, In-Reply-To contains the SES Message-Id
      which we don't know. Threading is therefore broken. Amazon requires to remember
      new Message-Id and handle it ourself, which is complicated [1]."""



      On Fri, Mar 21, 2025 at 8:02 AM David Beal <notifications@odoo-community.org> wrote:
      Dear OCA contributors,

      How do you manage automatic mailings from odoo when the recipient uses an anti-spam solution that requires the sender to be validated by a return mail that requires clicking on a link or filling a captcha ?
      I have a customer who uses the https://www.mailinblack.com/en solution.
      Mails returned by recipients who have mailinblack are not returned in Odoo in the original mail thread and are invisible in Odoo.

      What are the best practices in this case?

      Thanks a lot

      Regards

      David BEAL

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

      by Adam Heinz - 01:15 - 21 Mar 2025
  • Request for Review and Feedback on PR #3189: Enhancement to views_migration_17 Module

    Subject: Request for Review and Feedback on PR #3189: Enhancement to views_migration_17 Module

    Dear OCA Contributors,

    I hope this message finds you well. I am writing to kindly request your review and feedback on a recent pull request I have submitted to the server-tools repository: PR #3189.

    Pull Request Overview:

    • Title: [IMP] views_migration_17: support alternative output directory for transformed views instead of in-place write
    • Description: This improvement introduces the ability to specify an alternative output directory for transformed views in the views_migration_17 module, rather than performing in-place modifications. This enhancement aims to provide greater flexibility in managing transformed views for example when using doodba image from Tecnatica where addons path is readonly.

    Your insights and feedback are invaluable to ensure the quality and functionality of this enhancement. I would greatly appreciate it if you could take the time to review the proposed changes and share your thoughts or suggestions.

    Thank you for your attention and support.

    Best regards,

    \rrebollo

    by Ing. Rolando Pérez Rebollo - 11:51 - 21 Mar 2025
  • Request for Information on Using connector_importer and connector_importer_product

    Dear OCA Contributors,

    I hope you are all doing well.

    I am currently exploring the connector_importer and connector_importer_product addons and would like to better understand their intended use, configuration, and best practices. While I have reviewed the source code and available documentation, I would appreciate any additional insights from the community.

    If you have:

    • Any official or unofficial documentation,
    • Example implementations or case studies,
    • Guidance on best practices for setting up and using these modules,

    I would be grateful if you could share them. Any pointers to existing discussions, blog posts, or repositories with relevant examples would also be highly valuable.

    Thank you in advance for your time and assistance!

    Best regards,

    \rrebollo

    by Ing. Rolando Pérez Rebollo - 10:41 - 21 Mar 2025
  • SAVE THE DATE - OCA DAYS 2025 - 15-17 SEPTEMBER

    Hello OCA Contributors!


    We are excited to finally be able to announce the dates for the OCA Days 2025.
    We will be in Liège again at Val Benoit - this year over the course of 3 days - 15th - 17th September.

    • Monday 15th - Trainings and Code Sprint

    • Tuesday 16th - Presentations and Code Sprint

    • Wednesday 17th - Presentations and Code Sprint.


    You’ll be able to purchase tickets soon - I'll be in touch again to let you know when they are ready online.

    If you are interested in joining the OCA Days 2024 workgroup to help with the planning of the event please get in touch with me directly at rebecca@odoo-communityorg


    We are looking forward to creating another great event for you this year.
    Warm regards,

    Rebecca



    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly (OCA) - 05:11 - 17 Mar 2025
  • Odoo base_external_dbsource usage examples

    Hello community,

    I installed the base_external_dbsource Odoo module and am able to connect to an external postgresql database. However, I am not able to find any examples of how the base_external_dbsource module should be used. I would like to create a model and access data from the external database in similar ways as the native Odoo database.

    Any examples of how to use this module would be appreciated. It might also be wise to add some to the readme of this module.

    Thanks,

    Marcus Myer

    by Marcus Myer - 02:31 - 12 Mar 2025

    4 replies 4 replies

  • Odoo - Internal Transfer in Payments
    Dear,

    In Odoo versions 15 and 16, internal transfers could be done directly in payments.
    However, in version 18, I can't find the option to use internal transfers in payments.
    Maybe it has been changed to internal transfers via bank reconciliation.

    Should we migrate the account_payment_paired_internal_transfer module to v18, or is there another way to handle internal transfers?

    Thank you,
    Saran Lim.
    by saranl - 08:21 - 12 Mar 2025

    2 replies 2 replies

  • Introducing pofiletranslate – A Tool for Translating PO Files

    Dear Odoo Community,  

    I’ve developed a straightforward tool to translate PO files directly from a local codebase. I noticed that translations often follow a pattern within each project, and leveraging existing translations tends to produce better results than relying on Google Translate or AI-based tools.  

    **PyPI:** [https://pypi.org/project/pofiletranslate/](https://pypi.org/project/pofiletranslate/)  
    **GitHub:** [https://github.com/RachidAlassir/po-translate](https://github.com/RachidAlassir/po-translate)  

    I’d love to hear your feedback and suggestions!  

    Best regards,  
    Rachid Alassir
    by Rachid Alassir - 08:45 - 11 Mar 2025

    8 replies 8 replies

  • financial reports
    Dear Odoo Community,

    How can I create financial reports without new programming to specify which account should be shown in which item? For example, suppose I have 4 types of prepayment accounts, but 3 of them are recorded as receivables, and now in the balance sheet, when I want to get a report, it shows 1 account in prepayments. Where can I set up accounts whose types are also recorded in one month and another to be viewed in a specific group in financial reports?

    Regards
    Amir Akbari
    by Amir Akbari - 01:25 - 11 Mar 2025

    1 replies 1 replies

  • Webinars for OCA Members: learn how to navigate the OCA world
    Hello everyone,

    I am happy to share with you the list of the next OCA Webinars for the 2025 members.

    💡02 & 03 April: How to start to contribute? 

    💡 16 & 17 April: How to search for an OCA module? 

    💡 30 April & 1st May: How to test an OCA module? 

    💡 14 & 15 May: How to translate an OCA module?

    Those are the first steps for anyone wanting to understand the basics of the OCA tools and start contributing.

    I am sure that even people who have been around for a long time will learn useful tips as well!

    Each webinar is 30 minutes long with a presentation by Julie LeBrun followed by Questions & Answers.

    There are 2 sessions organized for each topic to arrange for different timezone.

    Register here:

    Other topics will follow, stay tuned! And tell us what you would like to see in the future: julie@odoo-community.org

    Have a nice week,
    Virginie Dewulf
    Executive Director
    +32 477 64 17 20
    by Virginie Dewulf (OCA) - 05:41 - 10 Mar 2025
  • Existing OCA Module for Concurrent User Tracking‏

    Dear Odoo community,

    I am currently looking for a module that allows users to see if other users are viewing or editing the same record in Odoo, such as a service request or any other document. The functionality I am looking for includes:

    Real-time visibility of other active users on the same record/page.
    Notifications or indicators when multiple users are working on the same document.

    I would like to note that the feature I am looking for exists in the system within the Project module. When two users are active on the same task screen, each of them receives a notification and sees a visual indication that another user is active on the same page and edit.

    Picture attached:
    image.png

    Before considering custom development, I wanted to check if there is an existing OCA module that provides this functionality. If such a module exists, I would appreciate it if you could provide its name or a link to its repository.

    Thank you in advance for your help!

    Best regards,
    Sagi Achiel
    Layline Tech



    by Sagi - 05:35 - 10 Mar 2025

    1 attachments 1 attachments

    image.png
  • Looking for solution partner in the world of Odoo

    Dear Odoo community,

    do you have a general or industry specific solution built on Odoo? 

    We are currently searching for those solutions to make them more visible in the Odoo world and give the opportunity to scale them internationally. The aim is to jointly open up new business opportunities, exploit synergies and further develop best practices within the Odoo community.

    What does this mean in concrete terms? We are looking for solution and industry partners:
    • Solution partners benefit from an extended reach for their Odoo-based solution, additional marketing opportunities and presentation opportunities within the network.
    • Industry partners gain access to a global market, can strategically position themselves in the Odoo ecosystem and benefit from targeted branding and marketing options.
    Further details can be found in the attached flyer or on our website. If you have any questions, please do not hesitate to contact us.

    Thanks and kind regards,

    Tobias Hammeke
    Managing Partner

    +49 172 265 3729



    BOP Logo.png



    		   

    Stronger Together
    emailAddress
    		info@best-odoo-partners.com  
    website
    		www.bop-alliance.com

    		linkedin instagram 
     
     
     
     
     



    This message is exclusively intended for its addressee and may contain information that is confidential and protected by professional privilege. If you are not the intended recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received by error, please immediately notify us via e-mail and delete it.
    by OBS Holding GmbH - 04:06 - 4 Mar 2025

    2 attachments 2 attachments

    BOP digital Flyer (solution partner).pdf
    C2_signature_boplogo_53e1547a-2721-4b84-948b-f6913dd681b3.png
  • New e-commerce module for product attributes
    Dear OCA community 

    Allow me to introduce this new module for product attribute sets.

    I am happy to hear from you suggestions and ideas and opinions.

    For me it is a good occasion as this is the second day of the holly month Ramadan, and I feel blessings.

    Here is the open pull request of our new module:


    best regards

    Mohamed Alkobrosli 

    by Mohamed Alkobrosly - 07:26 - 2 Mar 2025

    1 replies 1 replies

  • Weblate 5.10
    Hi everyone,

    translation.odoo-community.org has been upgraded to Weblate 5.10.

    Let me know of any issue.

    Best regards,

    -Stéphane

    --
    Stéphane Bidoul
    http://acsone.eu/
    by Stéphane Bidoul - 12:16 - 1 Mar 2025

    4 replies 4 replies

  • Add me in the telegram channel
    by "Shaheedullah khan" <shaheedullahkhan7@gmail.com> - 11:31 - 1 Mar 2025
  • Translations

    Hey OCA,

    I have a kind of „basic“ question I guess, regarding the handling of mail templates and its translations.

     

    If I need to overwrite email templates that are used „hard-coded“ in Odoo core create/write methods, what is the best way to do so.

     

    - 1st: Set the email template noupdate flag to false using the write function, then overwrite the template with your own record and set the noupdate flag back to true.

     

    The new template is now correct using create method of Odoo core. But here I have the problem that I cannot process the translations for the template correctly as they are referred to the Odoo core module. 

     

    - 2nd: Create „my module“-specific mail templates and load the records on module installation in addition to the original Odoo mail templates. This makes things easier concerning the translation po files.

     

    The Problem: as the original core code is using the hard-coded mail templates, I need to rebuild the whole logic from Odoo core in create and writes method in my module and include my adaptions.

     

     

    So in general… what is the better approach… or maybe a totally different one?

     

    Is it possible to override the Core module translations properly when a template is “replaced” by custom module?

     

    All the best

    Nils

    by Nils Coenen - 08:50 - 28 Feb 2025
  • Issue with ir.actions.server in Coverage Report – Curious About Others' Experience

    Dear OCA Community,

    I am using https://github.com/oca/oca-ci to run automated test cases in my GitLab pipeline, and I encountered a strange issue today.

    In one of the modules in my current repository, I am creating a Server Action (ir.actions.server) and executing it via the run method. However, during test execution, coverage.py mistakenly treated ir.actions.server as a file (might be because it is using safe_eval) and attempted to include it in the .coverage report. This resulted in the following error while generating coverage report:

    No source for code: '/builds/GIT_REPO/ir.actions.server(576,)'.

    I was able to resolve this by adding a .coveragerc file with the following configuration:

    [run]
    omit =
        *ir.actions.server*

    While this fix works, I am curious to know if others have encountered a similar issue, how it has been handled in other setups, and whether my solution is the proper way to address it.

    Looking forward to insights!

    BizzAppDev
    Erudite of Business Solutions
    With Kind Regards,
    Ruchir Y Shukla
    Founder & CTO
    BizzAppDev Systems Pvt. Ltd.
    M:
    +91 98 980 78748
    W:
    E:
    ruchir@bizzappdev.com

    Book time to meet with me
    by Ruchir Shukla. - 04:56 - 25 Feb 2025

    2 attachments 2 attachments

    Outlook-dfrr03sc.png
    Outlook-tsvh2lgl.png
  • Tests failure when invoicing is involved after a change in Odoo upstream
    I write to inform you that Odoo has performed a change in "stable" 16.0 in this commit:


    that is affecting CIs, specially on those integration ones that OCA implementers perform combining all the modules of a specific instance.

    This change avoids the auto-install of one CoA on the existing demo main company, as it doesn't comply with a country CoA unless you have l10n_us installed. Some tests inheriting from  AccountTestInvoicingCommon won't fail if l10n_generic_coa is installed, but it's also a requirement that can't always be fulfilled.

    The impact of this is huge across OCA, as basically every test creating an invoice is affected. OCA CI may not be red, but use it in other place and you may be doomed.


    Thus, from Tecnativa, we have started a massive pull request campaign fixing most of the common modules with this problem.

    The strategy has been to force a load of the generic CoA or the first existing one into the main company if starting the test, it doesn't have any. Check the minimum example at:


    If you are inheriting from AccountTestInvoicingCommon, the strategy should be different. By default, you won't have a red CI, but the tests are skipped, which is also undesirable. Thus, you have to do the work before calling super. Check an example here:


    v17 is not affected for now. Let's hope it continues this way...

    Regards.
    by Pedro M. Baeza - 03:41 - 25 Feb 2025

    7 replies 7 replies

    • Re: Tests failure when invoicing is involved after a change in Odoo upstream
      Well, that only fixes the problem in specific repositories OCA CIs, and you still needed to make some changes in tests. The problem we had was when using the modules in our own Ci, and the proposed patch was a good balance for not disturbing current OCA status and don't fail in our scenario.

      Regards.
      by Pedro M. Baeza - 05:07 - 12 Mar 2025
    • Re: Tests failure when invoicing is involved after a change in Odoo upstream
      While fixing the 16.0 branch for l10n_belgium I have done some more research on this.

      In 16.0, something like `odoo -i l10n_be` gives you two companies with main company without CoA (that's the problem mentioned in OP)

      - Your Company (base.main_company), country=US, no CoA
      - BE Company, country=BE, BE CoA

      In 17.0 and 18.0, the generic CoA is loaded on main_company even though a localization was loaded:

      - Your Company (base.main_company), country=US, Generic CoA
      - BE Company, country=BE, BE CoA

      This is why we only see the problem in 16.

      So I now think pre-loading l10n_generic_coa before running the tests in 16.0 is an easy fix, and also a good solution (and the one I prefer), because it sets up the main company identically to what we get in later versions.

      IMO, tests that really depend on a CoA should use a company initialized with that CoA, and not base.main_company.

      This is what I did in l10n_belgium: https://github.com/OCA/l10n-belgium/pull/243

      Best regards,

      -Stéphane

      On Fri, Feb 28, 2025 at 7:33 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      I have hit this issue in one of my projects where I run all tests post-install.

      Instead of changing all my tests, I chose to install l10n_generic_coa in CI, which was an easy solution in my specific situation.
      Maybe this can help others hitting the same problem.

      Best regards,

      -Stéphane


      On Wed, Feb 26, 2025 at 4:53 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
      Stefan and Denis, the reason for the Odoo patch may be legit, and it is. The problem is that it comes too late for the lifecycle of this version IMO, and more having in version 17 integrated the generic CoA into account for better practices. Anyway, this is just undisclosing a problem that has been hidden in the design of our OCA tests, them not being deterministic and really unit tests, as they are relying on previous state of data for being successful:

      - The company used is the one populated by default instead of using a full set of data including the company. This may be reasonable for execution times, and that's why the decision to just fix this condition installing an existing CoA instead of populating on each test a new company.
      - There's no guarantee a CoA is loaded at the time of performing the tests, but creating an invoice requires it. That's why the post-install thing (and it's also a requirement if inheriting AccountTestInvoicingCommon).


      Inheriting from AccountTestInvoicingCommon, as explained in the commit message I linked in my first message, it's not improving the thing (at least in 16, in 17 it's more ironized), because it still requires `l10n_generic_coa` installed (and installed before the execution of this test), and its setup is very heavy, creating 2 companies (even if you only require one), so this would increase the test execution times a lot in the best case, or skipped without you really noticing in the worst (when generic CoA is not available).

      The added code is NOT boilerplate. It's legit code for making deterministic tests, the same as you may remove currency rates for having a deterministic environment. And it's totally harmless if you don't need it, because starting with, it's in test code, not in business code, and if you keep the previous status quo, the if it's not executed, so it doesn't affect any previous condition. This can only uncover other hidden defects on the modules being executed in post-install, and this is being patched at the same time.

      Replying to other threads answers, I don't think this will reverted, as AFAIK Odoo.sh is auto-installing the modules that hides the problem, and not installing any localization module, but I'm not expert of that platform, so I may be wrong.

      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 Stéphane Bidoul - 04:11 - 12 Mar 2025
    • Re: Tests failure when invoicing is involved after a change in Odoo upstream
      I have hit this issue in one of my projects where I run all tests post-install.

      Instead of changing all my tests, I chose to install l10n_generic_coa in CI, which was an easy solution in my specific situation.
      Maybe this can help others hitting the same problem.

      Best regards,

      -Stéphane


      On Wed, Feb 26, 2025 at 4:53 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
      Stefan and Denis, the reason for the Odoo patch may be legit, and it is. The problem is that it comes too late for the lifecycle of this version IMO, and more having in version 17 integrated the generic CoA into account for better practices. Anyway, this is just undisclosing a problem that has been hidden in the design of our OCA tests, them not being deterministic and really unit tests, as they are relying on previous state of data for being successful:

      - The company used is the one populated by default instead of using a full set of data including the company. This may be reasonable for execution times, and that's why the decision to just fix this condition installing an existing CoA instead of populating on each test a new company.
      - There's no guarantee a CoA is loaded at the time of performing the tests, but creating an invoice requires it. That's why the post-install thing (and it's also a requirement if inheriting AccountTestInvoicingCommon).


      Inheriting from AccountTestInvoicingCommon, as explained in the commit message I linked in my first message, it's not improving the thing (at least in 16, in 17 it's more ironized), because it still requires `l10n_generic_coa` installed (and installed before the execution of this test), and its setup is very heavy, creating 2 companies (even if you only require one), so this would increase the test execution times a lot in the best case, or skipped without you really noticing in the worst (when generic CoA is not available).

      The added code is NOT boilerplate. It's legit code for making deterministic tests, the same as you may remove currency rates for having a deterministic environment. And it's totally harmless if you don't need it, because starting with, it's in test code, not in business code, and if you keep the previous status quo, the if it's not executed, so it doesn't affect any previous condition. This can only uncover other hidden defects on the modules being executed in post-install, and this is being patched at the same time.

      Replying to other threads answers, I don't think this will reverted, as AFAIK Odoo.sh is auto-installing the modules that hides the problem, and not installing any localization module, but I'm not expert of that platform, so I may be wrong.

      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 Stéphane Bidoul - 07:36 - 28 Feb 2025
    • Re: Tests failure when invoicing is involved after a change in Odoo upstream
      Stefan and Denis, the reason for the Odoo patch may be legit, and it is. The problem is that it comes too late for the lifecycle of this version IMO, and more having in version 17 integrated the generic CoA into account for better practices. Anyway, this is just undisclosing a problem that has been hidden in the design of our OCA tests, them not being deterministic and really unit tests, as they are relying on previous state of data for being successful:

      - The company used is the one populated by default instead of using a full set of data including the company. This may be reasonable for execution times, and that's why the decision to just fix this condition installing an existing CoA instead of populating on each test a new company.
      - There's no guarantee a CoA is loaded at the time of performing the tests, but creating an invoice requires it. That's why the post-install thing (and it's also a requirement if inheriting AccountTestInvoicingCommon).


      Inheriting from AccountTestInvoicingCommon, as explained in the commit message I linked in my first message, it's not improving the thing (at least in 16, in 17 it's more ironized), because it still requires `l10n_generic_coa` installed (and installed before the execution of this test), and its setup is very heavy, creating 2 companies (even if you only require one), so this would increase the test execution times a lot in the best case, or skipped without you really noticing in the worst (when generic CoA is not available).

      The added code is NOT boilerplate. It's legit code for making deterministic tests, the same as you may remove currency rates for having a deterministic environment. And it's totally harmless if you don't need it, because starting with, it's in test code, not in business code, and if you keep the previous status quo, the if it's not executed, so it doesn't affect any previous condition. This can only uncover other hidden defects on the modules being executed in post-install, and this is being patched at the same time.

      Replying to other threads answers, I don't think this will reverted, as AFAIK Odoo.sh is auto-installing the modules that hides the problem, and not installing any localization module, but I'm not expert of that platform, so I may be wrong.

      Regards.
      by Pedro M. Baeza - 04:52 - 26 Feb 2025
    • Re: Tests failure when invoicing is involved after a change in Odoo upstream
      Thanks Pedro for pointing that out.

      But as Stefan said, the changes you propose should be applied in particular modules that do pull particular localisation, not every.

      As said also, a lead could be using AccountTestInvoicingCommon.

      Moreover, I think proposing a hook in Odoo's tests should be great to lower the code we need to introduce in our modules, or... What do you think?

      Thanks

      Le mer. 26 févr. 2025, 11:27, Stefan Rijnhart <notifications@odoo-community.org> a écrit :
      Yes, but the reason given by the Odoo devs for this change (https://github.com/odoo/odoo/pull/194799) is that CI can break on other CoAs than the generic one. That implies that it is considered bad practise to encourage it, and maybe we should not be doing this in (potentially, a lot of) OCA modules. Maybe using AccountTestInvoicingCommon is still the best solution?

      Like you say, OCA CI should mostly not be affected because l10n_generic_coa is still installed automatically if you don't depend on a localized chart. Do you really *need* to test these modules on databases with l10n_es? Maybe you can enforce the installation of it on the main company with an extra step in your CI.

      On 25-02-2025 15:42, Pedro M. Baeza wrote:
      I write to inform you that Odoo has performed a change in "stable" 16.0 in this commit:


      that is affecting CIs, specially on those integration ones that OCA implementers perform combining all the modules of a specific instance.

      This change avoids the auto-install of one CoA on the existing demo main company, as it doesn't comply with a country CoA unless you have l10n_us installed. Some tests inheriting from  AccountTestInvoicingCommon won't fail if l10n_generic_coa is installed, but it's also a requirement that can't always be fulfilled.

      The impact of this is huge across OCA, as basically every test creating an invoice is affected. OCA CI may not be red, but use it in other place and you may be doomed.


      Thus, from Tecnativa, we have started a massive pull request campaign fixing most of the common modules with this problem.

      The strategy has been to force a load of the generic CoA or the first existing one into the main company if starting the test, it doesn't have any. Check the minimum example at:


      If you are inheriting from AccountTestInvoicingCommon, the strategy should be different. By default, you won't have a red CI, but the tests are skipped, which is also undesirable. Thus, you have to do the work before calling super. Check an example here:


      v17 is not affected for now. Let's hope it continues this way...

      Regards.

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



      -- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail: stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web: https://opener.amsterdam

      _______________________________________________
      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. - 04:21 - 26 Feb 2025