Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • tests are failing because odoo-test-helper not found 
    Dear community,

I have a test that fails because the pip library odoo-test-helper can not be installed.

2025-04-07T09:16:23.7423537Z WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x7feea05a1900>: Failed to establish a new connection: [Errno 101] Network is unreachable')': /oca-simple-and-pypi/odoo-test-helper/
2025-04-07T09:16:23.9240823Z ERROR: Could not find a version that satisfies the requirement odoo-test-helper (from versions: none)
2025-04-07T09:16:23.9243356Z ERROR: No matching distribution found for odoo-test-helper

Apparently it should be installed from this site that is not active:

2025-04-07T09:16:15.2064228Z Looking in indexes: https://wheelhouse.odoo-community.org/oca-simple-and-pypi

Is this a permanent condition?

I could go for the easy way and just remove test-requirements.txt from the project root (social)
as it seems not te be used in any of the modules currently migrated to 16.0. But maybe other modules yet to be
migrated need it.

Anybody an idea how to solve this problem the right way?

Here the link to the failing tests:
https://productionresultssa18.blob.core.windows.net/actions-results/170f686c-f2dd-4b6a-8da3-7ff616da43d5/workflow-job-run-ca583373-12df-5ee5-b1f1-ce1864425fa4/logs/job/job-logs.txt?rsct=text%2Fplain&se=2025-04-07T12%3A50%3A23Z&sig=PhJGruBVIkmp%2FuwjPgulLrTbWjPmgDAOIA8NO3lFlEc%3D&ske=2025-04-08T00%3A30%3A33Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2025-04-07T12%3A30%3A33Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-01-05&sp=r&spr=https&sr=b&st=2025-04-07T12%3A40%3A18Z&sv=2025-01-05

Kind regards, Ronald

    by Ronald Portier - 03:24 - 7 Apr 2025

    2 replies 2 replies

  • cant install cooperative module
    from odoo 18, i reinstalled odoo 16, to install cooperative vertical module, after app update listing, the odoo cooperative module, show, but when im about to activate cooperative module, another module is missing, may i kindly ask where can i get this module?  
    partner_contact_birthdate image.png
    by buboy2k6@gmail.com - 04:36 - 4 Apr 2025

    1 attachments 1 attachments

    image.png

    2 replies 2 replies

  • OCA Days 2025 - Which training topics would help you?
    Hello OCA Contributors

    With registrations for OCA Days 2025 starting in the next couple of weeks we are reaching out to find out what sort of training sessions people might find beneficial this year.

    The agenda for the 3 day event this year is:
    - Monday 15th September - Training and Code sprint
    - Tuesday 16th  September - Presentations and Code Sprint
    - Wednesday 17th September - Presentations and Code Sprint

    To help us deliver training content that will be valuable to you, could we ask please that you take a minute or two to fill in our survey telling us what sort of content you might find useful this year? 
    We want to hear from technical and non-technical profiles.

    Take the survey here: https://odoo-community.org/survey/start/79a8fd49-1831-4838-8149-b9251c9ca8f3

    Thanking you in advance.
    Rebecca

    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly (OCA) - 02:31 - 4 Apr 2025

    2 replies 2 replies

  • HR Attendance - Performance Issue in "Theoretical vs Attended Time Analysis"
    Hello Contributors,

    We are using the module hr_attendance_report_theoretical_time for checking our employees working time balance (extra or minus hours), but are facing performance issues (on Odoo 14 at the moment).

    We’ve noticed that the report in the module can be slow, especially when handling a large number of attendances. In our setup, it computes all attendances since we started using the module, which significantly impacts performance.
    While we sometimes need to analyze attendance over a limited period (e.g., the current year or semester), most of the time we need to retrieve the complete balance of an employee since their start date to assess total (=current) extra or missing hours.

    Questions for the Community
    1. Have others experienced similar performance issues with this report?
    2. How do you optimize performance? Have you implemented any workarounds?
    3. Would there be interest in adding a mechanism to store computed balances at a pivot date to reduce the number of records processed?
    4. Do you use another method for computing the total extra hours of any employee? What is your approach?
    Any insights or suggestions would be greatly appreciated!

    Thanks,
    Emanuel
    by "Emanuel Cino" <emanuel@compassion.ch> - 11:20 - 3 Apr 2025

    7 replies 7 replies

    • Re: HR Attendance - Performance Issue in "Theoretical vs Attended Time Analysis"
      I'm afraid the included feature in core is not taking into account missing attendance records, and as a note, the pointed extra module is not part of OCA.

      Regards.
      by Pedro M. Baeza - 12:07 - 3 Apr 2025
    • Re: HR Attendance - Performance Issue in "Theoretical vs Attended Time Analysis"
      Hi Janik,

      Thank you for this valuable answer! I will definitely check this in the newer versions.

      On Apr 3 2025, at 11:53 am, Janik von Rotz <notifications@odoo-community.org> wrote:
      Hey Emanuel

      The `hr_attendance_report_theoretical_time` functionality is part of Odoo 15 and newer. See "hr.attendance.overtime" model for reference

      I highly recommend you to upgrade your Odoo instance.

      To detect missing attendances there is https://www.odoo-wiki.org/hr-attendance-missing.html#hr-attendance-missing for Odoo 15 to 17. Missing attendances is supported by Odoo 18.

      Cheers, Janik

      On 4/3/25 11:22 AM, Emanuel Cino wrote:
      Hello Contributors,

      We are using the module hr_attendance_report_theoretical_time for checking our employees working time balance (extra or minus hours), but are facing performance issues (on Odoo 14 at the moment).

      We’ve noticed that the report in the module can be slow, especially when handling a large number of attendances. In our setup, it computes all attendances since we started using the module, which significantly impacts performance.
      While we sometimes need to analyze attendance over a limited period (e.g., the current year or semester), most of the time we need to retrieve the complete balance of an employee since their start date to assess total (=current) extra or missing hours.

      Questions for the Community
      1. Have others experienced similar performance issues with this report?
      2. How do you optimize performance? Have you implemented any workarounds?
      3. Would there be interest in adding a mechanism to store computed balances at a pivot date to reduce the number of records processed?
      4. Do you use another method for computing the total extra hours of any employee? What is your approach?
      Any insights or suggestions would be greatly appreciated!

      Thanks,
      Emanuel
      -- 
      Suggest a meeting: https://apmt.day/janikvonrotz/999120f2/
      We are hiring: https://www.mint-system.ch/jobs

      CTO Mint System GmbH 
      Tel: +41 44 244 7222
      _______________________________________________
      Post to: mailto:contributors@odoo-community.org
      by "Emanuel Cino" <emanuel@compassion.ch> - 12:01 - 3 Apr 2025
    • Re: HR Attendance - Performance Issue in "Theoretical vs Attended Time Analysis"

      Hey Emanuel

      The `hr_attendance_report_theoretical_time` functionality is part of Odoo 15 and newer. See "hr.attendance.overtime" model for reference

      I highly recommend you to upgrade your Odoo instance.

      To detect missing attendances there is https://www.odoo-wiki.org/hr-attendance-missing.html#hr-attendance-missing for Odoo 15 to 17. Missing attendances is supported by Odoo 18.

      Cheers, Janik

      On 4/3/25 11:22 AM, Emanuel Cino wrote:
      Hello Contributors,

      We are using the module hr_attendance_report_theoretical_time for checking our employees working time balance (extra or minus hours), but are facing performance issues (on Odoo 14 at the moment).

      We’ve noticed that the report in the module can be slow, especially when handling a large number of attendances. In our setup, it computes all attendances since we started using the module, which significantly impacts performance.
      While we sometimes need to analyze attendance over a limited period (e.g., the current year or semester), most of the time we need to retrieve the complete balance of an employee since their start date to assess total (=current) extra or missing hours.

      Questions for the Community
      1. Have others experienced similar performance issues with this report?
      2. How do you optimize performance? Have you implemented any workarounds?
      3. Would there be interest in adding a mechanism to store computed balances at a pivot date to reduce the number of records processed?
      4. Do you use another method for computing the total extra hours of any employee? What is your approach?
      Any insights or suggestions would be greatly appreciated!

      Thanks,
      Emanuel

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

      -- 
Suggest a meeting: https://apmt.day/janikvonrotz/999120f2/
We are hiring: https://www.mint-system.ch/jobs

CTO Mint System GmbH 
Tel: +41 44 244 7222
      by Janik von Rotz - 11:51 - 3 Apr 2025
    • Re: HR Attendance - Performance Issue in "Theoretical vs Attended Time Analysis"
      You can start a new thread here for that question: "Hey, how do you compute extra hours on your side?" for getting a general conversation, but having a thread titled "HR Attendance - Performance Issue in "Theoretical vs Attended Time Analysis"" won't attract people that may be able to answer you and it will be misleading when doing searches.

      Regards.
      by Pedro M. Baeza - 11:51 - 3 Apr 2025
    • Re: HR Attendance - Performance Issue in "Theoretical vs Attended Time Analysis"
      Hi Pedro,

      Got it, that makes sense. I’ll continue the technical discussion directly in the issue. However, I’m still interested in the fourth question from my message, as it’s not directly related—I'd like to explore if there are alternative ways to achieve the same functionality.

      Thanks for the clarification!

      Best,
      Emanuel
      by "Emanuel Cino" <emanuel@compassion.ch> - 11:46 - 3 Apr 2025

  • A bit of marketing: LinkedIn Banners for OCA contributors/members/delegates...
    Hello everyone,

    We notice that many Odoo people are active on LinkedIn and are interested in the OCA content. 

    With the Marketing Working Group, we have decided to create banners for our community members to show on their LinkedIn profile that they are part of the OCA.

    We designed 2 types of banners:
    - generic ones, that you can use as is on your profile
    - customizable ones, on top of which you can add your name, contact details, company logo... anything you want to make it look more like you but with the background and badge related to your OCA activity.

    For each of those types, they are mention of various labels: contributor, member, delegate and board member (only to use if you are one of them, we trust you of course to choose the one that is best for you).

    The result is available in PNG format on the marketing resources page:

    I customized one of those for my personal profile to have a concrete example:
    (screenshot in attachment).

    I hope you will find those banners nice and useful and that you will make use of them, for the ones of you having LinkedIn accounts!

    Special thanks to Thibault Rey and Dora Jurcevic (Akretion) active in the Marketing WG for this little project!

    Virginie Dewulf
    Executive Director
    +32 477 64 17 20
    by Virginie Dewulf (OCA) - 11:01 - 2 Apr 2025

    1 attachments 1 attachments

    Sélection_039.png
  • Container Import Workflow
    Hi everyone,

    We’re working with a client that requires improvements to the container import process in Odoo, and we’re preparing to start development soon. As many of you may know, container imports typically involve a specific workflow, including:

    Import documentation
    Import type (air, sea, consolidated, etc.)
    Landed costs allocation
    Container tracking and scheduling
    Customs and clearance milestones
    Follow-ups on estimated arrival/departure dates

    Our current approach is to extend the purchase order model to serve as the foundation of this workflow, allowing us to maintain a familiar structure while introducing the additional logic and tracking needed for container-level visibility and process automation.

    Before we begin, we’d like to ask the community:
    Is anyone else currently working on something similar or interested in collaborating on this?
    Are there existing OCA modules or partial solutions we should consider extending?

    We see potential value in making this a broader OCA-compliant project, especially as container tracking and landed cost accuracy are pain points for many companies working with international suppliers.

    Happy to share a more detailed spec or jump on a call to discuss use cases. Looking forward to hearing your thoughts and ideas.

    Best regards,

    --
    Binhex Logo
    Jorge Elena Poblet
    Founder & CEO
    Binhex
    j.elena@binhex.cloud
    Office (Spain) : +34 622 40 08 08
    Office (USA): +1 561 403 4406
    Offices:
    Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
    Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
    Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
    Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
    LinkedIn Twitter Facebook YouTube
    Start for free: Try Odoo Community in the cloud

    This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
    Privacy Policy
    by Jorge Elena Poblet - 04:21 - 1 Apr 2025

    4 replies 4 replies

    • Re: Container Import Workflow
      Thanks for this, we'll take a look and provide feedback

      On Tue, Apr 8, 2025 at 5:42 PM David Beal <notifications@odoo-community.org> wrote:
      Hi Jorge Rubén,

      An akretion contribution on this topic

      Draft for now, but the migration process started.

      Regards

      David BEAL
      Consultant ERP Odoo


      Le lun. 7 avr. 2025 à 15:25, Daniel Reis <notifications@odoo-community.org> a écrit :
      Hello Jorge,

      I once did a customization for a customer to track shipping containers.
      It didn't feel generic enough for a reusable module and our choice was to extend the Package object.

      A sexta, 4/04/2025, 03:38, 张 飞虎 <notifications@odoo-community.org> escreveu:

      Dear Jorge，


      Thank you for sharing this initiative. We’ve actually developed a similar solution since Odoo 12, where we introduced an import.container document to centralize the linkage between purchase orders, sales orders, and payment information.

      However, our implementation was heavily customized for our specific business needs, so it may not be readily adaptable for other clients.

      I’ll definitely keep an eye on this discussion. If there are any updates or a repository link for the development progress, please do share it—I’d be very interested to follow along.

      Looking forward to seeing how this evolves!



      Best regards,

      feihu.zhang



      2025年4月1日 22:22，Jorge Rubén Elena Poblet <notifications@odoo-community.org> 写道：

      Hi everyone,

      We’re working with a client that requires improvements to the container import process in Odoo, and we’re preparing to start development soon. As many of you may know, container imports typically involve a specific workflow, including:

      Import documentation
      Import type (air, sea, consolidated, etc.)
      Landed costs allocation
      Container tracking and scheduling
      Customs and clearance milestones
      Follow-ups on estimated arrival/departure dates

      Our current approach is to extend the purchase order model to serve as the foundation of this workflow, allowing us to maintain a familiar structure while introducing the additional logic and tracking needed for container-level visibility and process automation.

      Before we begin, we’d like to ask the community:
      Is anyone else currently working on something similar or interested in collaborating on this?
      Are there existing OCA modules or partial solutions we should consider extending?

      We see potential value in making this a broader OCA-compliant project, especially as container tracking and landed cost accuracy are pain points for many companies working with international suppliers.

      Happy to share a more detailed spec or jump on a call to discuss use cases. Looking forward to hearing your thoughts and ideas.

      Best regards,

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


      Security Notice: Don't be too quick to click!
      Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator.

      _______________________________________________
      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



      --
      Binhex Logo
      Jorge Elena Poblet
      Founder & CEO
      Binhex
      j.elena@binhex.cloud
      Office (Spain) : +34 622 40 08 08
      Office (USA): +1 561 403 4406
      Offices:
      Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
      Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
      Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
      Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
      LinkedIn Twitter Facebook YouTube
      Start for free: Try Odoo Community in the cloud

      This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
      Privacy Policy
      by Jorge Elena Poblet - 07:26 - 8 Apr 2025
    • Re: Container Import Workflow
      Hi Jorge Rubén,

      An akretion contribution on this topic

      Draft for now, but the migration process started.

      Regards

      David BEAL
      Consultant ERP Odoo


      Le lun. 7 avr. 2025 à 15:25, Daniel Reis <notifications@odoo-community.org> a écrit :
      Hello Jorge,

      I once did a customization for a customer to track shipping containers.
      It didn't feel generic enough for a reusable module and our choice was to extend the Package object.

      A sexta, 4/04/2025, 03:38, 张 飞虎 <notifications@odoo-community.org> escreveu:

      Dear Jorge，


      Thank you for sharing this initiative. We’ve actually developed a similar solution since Odoo 12, where we introduced an import.container document to centralize the linkage between purchase orders, sales orders, and payment information.

      However, our implementation was heavily customized for our specific business needs, so it may not be readily adaptable for other clients.

      I’ll definitely keep an eye on this discussion. If there are any updates or a repository link for the development progress, please do share it—I’d be very interested to follow along.

      Looking forward to seeing how this evolves!



      Best regards,

      feihu.zhang



      2025年4月1日 22:22，Jorge Rubén Elena Poblet <notifications@odoo-community.org> 写道：

      Hi everyone,

      We’re working with a client that requires improvements to the container import process in Odoo, and we’re preparing to start development soon. As many of you may know, container imports typically involve a specific workflow, including:

      Import documentation
      Import type (air, sea, consolidated, etc.)
      Landed costs allocation
      Container tracking and scheduling
      Customs and clearance milestones
      Follow-ups on estimated arrival/departure dates

      Our current approach is to extend the purchase order model to serve as the foundation of this workflow, allowing us to maintain a familiar structure while introducing the additional logic and tracking needed for container-level visibility and process automation.

      Before we begin, we’d like to ask the community:
      Is anyone else currently working on something similar or interested in collaborating on this?
      Are there existing OCA modules or partial solutions we should consider extending?

      We see potential value in making this a broader OCA-compliant project, especially as container tracking and landed cost accuracy are pain points for many companies working with international suppliers.

      Happy to share a more detailed spec or jump on a call to discuss use cases. Looking forward to hearing your thoughts and ideas.

      Best regards,

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


      Security Notice: Don't be too quick to click!
      Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator.

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

      by David BEAL - 06:41 - 8 Apr 2025
    • Re: Container Import Workflow
      Hello Jorge,

      I once did a customization for a customer to track shipping containers.
      It didn't feel generic enough for a reusable module and our choice was to extend the Package object.

      A sexta, 4/04/2025, 03:38, 张 飞虎 <notifications@odoo-community.org> escreveu:

      Dear Jorge，


      Thank you for sharing this initiative. We’ve actually developed a similar solution since Odoo 12, where we introduced an import.container document to centralize the linkage between purchase orders, sales orders, and payment information.

      However, our implementation was heavily customized for our specific business needs, so it may not be readily adaptable for other clients.

      I’ll definitely keep an eye on this discussion. If there are any updates or a repository link for the development progress, please do share it—I’d be very interested to follow along.

      Looking forward to seeing how this evolves!



      Best regards,

      feihu.zhang



      2025年4月1日 22:22，Jorge Rubén Elena Poblet <notifications@odoo-community.org> 写道：

      Hi everyone,

      We’re working with a client that requires improvements to the container import process in Odoo, and we’re preparing to start development soon. As many of you may know, container imports typically involve a specific workflow, including:

      Import documentation
      Import type (air, sea, consolidated, etc.)
      Landed costs allocation
      Container tracking and scheduling
      Customs and clearance milestones
      Follow-ups on estimated arrival/departure dates

      Our current approach is to extend the purchase order model to serve as the foundation of this workflow, allowing us to maintain a familiar structure while introducing the additional logic and tracking needed for container-level visibility and process automation.

      Before we begin, we’d like to ask the community:
      Is anyone else currently working on something similar or interested in collaborating on this?
      Are there existing OCA modules or partial solutions we should consider extending?

      We see potential value in making this a broader OCA-compliant project, especially as container tracking and landed cost accuracy are pain points for many companies working with international suppliers.

      Happy to share a more detailed spec or jump on a call to discuss use cases. Looking forward to hearing your thoughts and ideas.

      Best regards,

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


      Security Notice: Don't be too quick to click!
      Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator.
      by Daniel Reis - 03:24 - 7 Apr 2025
    • Re: Container Import Workflow

      Dear Jorge，


      Thank you for sharing this initiative. We’ve actually developed a similar solution since Odoo 12, where we introduced an import.container document to centralize the linkage between purchase orders, sales orders, and payment information.

      However, our implementation was heavily customized for our specific business needs, so it may not be readily adaptable for other clients.

      I’ll definitely keep an eye on this discussion. If there are any updates or a repository link for the development progress, please do share it—I’d be very interested to follow along.

      Looking forward to seeing how this evolves!



      Best regards,

      feihu.zhang



      2025年4月1日 22:22，Jorge Rubén Elena Poblet <notifications@odoo-community.org> 写道：

      Hi everyone,

      We’re working with a client that requires improvements to the container import process in Odoo, and we’re preparing to start development soon. As many of you may know, container imports typically involve a specific workflow, including:

      Import documentation
      Import type (air, sea, consolidated, etc.)
      Landed costs allocation
      Container tracking and scheduling
      Customs and clearance milestones
      Follow-ups on estimated arrival/departure dates

      Our current approach is to extend the purchase order model to serve as the foundation of this workflow, allowing us to maintain a familiar structure while introducing the additional logic and tracking needed for container-level visibility and process automation.

      Before we begin, we’d like to ask the community:
      Is anyone else currently working on something similar or interested in collaborating on this?
      Are there existing OCA modules or partial solutions we should consider extending?

      We see potential value in making this a broader OCA-compliant project, especially as container tracking and landed cost accuracy are pain points for many companies working with international suppliers.

      Happy to share a more detailed spec or jump on a call to discuss use cases. Looking forward to hearing your thoughts and ideas.

      Best regards,

      by feihu.zhang - 04:36 - 4 Apr 2025
  • New module for uuid fields

    Hello everyone,

     

    I am currently working on a project where I wanted to use the native postgres type uuid, instead of storing the uuids in plain char fields. Since such a field does not seem to be available in Odoo yet, I threw together a very simple module: https://github.com/mkoeck/base-uuid-field/

     

    Since I saw that there are some existing OCA modules using uuid’s (but storing them in plain char fields), I thought this module might also be interesting to others. I would be happy to integrate this into an existing OCA repo, if someone guides me what the best direction for this would be.

    Do note, that I am quite the novice with JS / owl, so any feedback, but especially on that is appreciated J

     

    Best regards,

    Michael

    by mkoeck - 01:15 - 1 Apr 2025

    4 replies 4 replies

    • AW: New module for uuid fields

      Yes, for sure in most cases you will set the field to be readonly. Still using a native uuid type over a char type can have various benefits. I am certainly not an expert but you can refer to this stackoverflow post, why you would want to use a uuid field over a char field even if only for display reasons: https://stackoverflow.com/questions/32189129/performance-difference-between-uuid-char-and-varchar-in-postgresql-table

       

      Von: Vincent Hatakeyama [mailto:notifications@odoo-community.org]
      Gesendet: Mittwoch, 2. April 2025 11:58
      An: Contributors
      Betreff: Re: New module for uuid fields

       

      Hi,

       

      I’ve had the need to use an uuid column in the past. The column was not meant to be filled by users. The table was built manually and a Char field was used to display the content.

       

      I believe the server-tools repository is the place to put a module adding UUID fields.

       

      Regards,

       

      --

      Vincent Hatakeyama

      Directeur du pôle développement " Orbeet

      Tel

      +33 1 83 62 72 88

      Email

      vincent.hatakeyama@orbeet.io

      Adresse

      27, boulevard Saint-Martin
      75003 Paris

      Site web

      https://orbeet.io

      Image bannière

       

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

      by mkoeck - 12:25 - 2 Apr 2025
    • Re: New module for uuid fields
      Hi,

      I’ve had the need to use an uuid column in the past. The column was not meant to be filled by users. The table was built manually and a Char field was used to display the content.

      I believe the server-tools repository is the place to put a module adding UUID fields.

      Regards,

      --
      Vincent Hatakeyama
      Directeur du pôle développement " Orbeet
      Tel +33 1 83 62 72 88 Email vincent.hatakeyama@orbeet.io
      Adresse 27, boulevard Saint-Martin
      75003 Paris             		Site web https://orbeet.io
      Image bannière

      by "Vincent Hatakeyama" <vincent.hatakeyama@orbeet.io> - 11:56 - 2 Apr 2025
    • AW: New module for uuid fields

      Ah yes, sorry forgot to make the repo public. Should work now!

       

      Von: friedrich.sauer@servicum.com [mailto:notifications@odoo-community.org]
      Gesendet: Dienstag, 1. April 2025 16:13
      An: Contributors
      Betreff: AW: New module for uuid fields

       

      Hi Michael, 

       

      this sounds interesting to me! Unfortunately, I can't access the repo.

      Can you share it?

       

       

      Best, 

      Friedrich

       

       

       

      Email: friedrich.sauer@servicum.com

      Phone: 01721324603

       

       

       

       

      Von: Elektro-Shop Köck GmbH - Michael Köck
      Gesendet: Dienstag, 01. April 2025 13:17
      Bis: Contributors
      Betreff: New module for uuid fields

       

      Hello everyone,

       

      I am currently working on a project where I wanted to use the native postgres type uuid, instead of storing the uuids in plain char fields. Since such a field does not seem to be available in Odoo yet, I threw together a very simple module: https://github.com/mkoeck/base-uuid-field/

       

      Since I saw that there are some existing OCA modules using uuid’s (but storing them in plain char fields), I thought this module might also be interesting to others. I would be happy to integrate this into an existing OCA repo, if someone guides me what the best direction for this would be.

      Do note, that I am quite the novice with JS / owl, so any feedback, but especially on that is appreciated J

       

      Best regards,

      Michael

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

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

      by mkoeck - 05:11 - 1 Apr 2025
    • AW: New module for uuid fields
      Hi Michael, 
       
      this sounds interesting to me! Unfortunately, I can't access the repo.
      Can you share it?


      Best, 
      Friedrich



      Email: friedrich.sauer@servicum.com
      Phone: 01721324603




      Von: Elektro-Shop Köck GmbH - Michael Köck
      Gesendet: Dienstag, 01. April 2025 13:17
      Bis: Contributors
      Betreff: New module for uuid fields

      Hello everyone,

       

      I am currently working on a project where I wanted to use the native postgres type uuid, instead of storing the uuids in plain char fields. Since such a field does not seem to be available in Odoo yet, I threw together a very simple module: https://github.com/mkoeck/base-uuid-field/

       

      Since I saw that there are some existing OCA modules using uuid’s (but storing them in plain char fields), I thought this module might also be interesting to others. I would be happy to integrate this into an existing OCA repo, if someone guides me what the best direction for this would be.

      Do note, that I am quite the novice with JS / owl, so any feedback, but especially on that is appreciated J

       

      Best regards,

      Michael

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

      by Friedrich Sauer - 04:11 - 1 Apr 2025
  • OWL Trainers Wanted (RFQ Deadline 17th April) by the OCA and AEOdoo

    Hello contributors,

    The OCA and the Spanish Association (Asociación Española de Odoo ) join forces to organize training on OWL in 2025, in English and in Spanish, with the same content, by the same trainers or different trainers (but the general content must be the same: collaboration to prepare the content will be needed).


    ⌛ Deadline for submission of your offer: 17th April midnight CET.

    English:

    The corresponding call on the AEOdoo website in Spanish is here:

    https://www.aeodoo.org/blog/licitaciones-abiertas-2/licitacion-curso-tecnico-owl-94


    We are looking forward to receiving your proposals and to organizing this demanded content this year!

    Virginie Dewulf
    Executive Director
    +32 477 64 17 20
    by Virginie Dewulf (OCA) - 09:51 - 1 Apr 2025

    1 replies 1 replies

  • Generic "sequence" and "display_name"
    Hello!

    I have just opened a server-ux issue to discuss two new generic modules sequence and display_name which are currently in this repo. I would like to get some feedback in the issue before I make pull requests to the OCA, since it is easier to develop all modules in the same branch when they depend on each other.

    Best regards,
    Henrik Norlin

    by Henrik Norlin - 08:26 - 31 Mar 2025
  • OCA Construction Symposium & Trade Show 2025 : Complete Attendee List

    OCA Construction Symposium & Trade Show 2025

    Greetings Exhibitor,

    Are you looking to expand your network? We have the registrants list available for OCA Construction Symposium & Trade Show 2025, which is scheduled for 16 Apr 2025 in EY Centre, Ottawa, Canada.

    The list includes detailed contact information for 7,330 attendees, such as names, emails, companies, and more.


    Thanks & Regards,
    Dawn
    by dawn.ross@datapulseinfo.live - 04:11 - 29 Mar 2025
  • Re: Contributors
    I'm working with cooperative in the Philippines, I'm  trying to install cooperative module in odoo 18, community edition. Anybody to help. 

    Help will very appreciated. 
    by buboy2k6@gmail.com - 12:16 - 29 Mar 2025

    9 replies 9 replies

  • report_py3o

    Hello everyone,

     

    we are currently using report_py3o under odoo 16. Is it possible to use report_py3o under odoo 18 or will it be possible in the future?

     

    Please do not hesitate to contact us if you have any questions.

     

    With kind regards

     

    Martin Bando

     

     

    Computer Science Expert - Software Development | OPAL Solutions GmbH

    martin.bando@opal-solutions.de | https://opal-solutions.de

    Niederlassung Bochum | T +49 (0)234 541 444 06

     

     

    Technische Probleme?:

    Schreiben Sie direkt eine Email an helpdesk@opal-solutions.de.

     

    Hauptsitz Rheinland | Karl-Heinz-Beckurts-Straße 13 | 52428 Jülich

    Niederlassung Ruhrgebiet/Sauerland | Heinrichstraße 67 | 44805 Bochum

    Niederlassung Münster/Osnabrück | Gewerbepark 18 | 49143 Bissendorf

    T +49 (0)2461 690 280 | F +49 (0)2461 690 284

    Amtsgericht Düren | HRB 5889 | Geschäftsführung: Michael von Steht
    OPAL Solutions GmbH ist ein Unternehmen der OPAL Associates Holding AG

    AGB  |  Impressum  |  Informationen zum Datenschutz

     

     

    Follow us on

     

                    

     

     

    WICHTIGE MITTEILUNG
    Diese E-Mail und deren Anlagen enthalten vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser E-Mail und deren Anlagen sind nicht gestattet. OPAL haftet nicht für Schäden, die durch den unerlaubten Gebrauch dieser E-Mail und deren Anlagen entstehen.

    IMPORTANT MESSAGE
    This e-mail and their attachments may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this e-mail. Unauthorized copying and unauthorized distribution of this e-mail and their attachments are not allowed. OPAL is not liable for damages caused by unauthorized use of this e-mail and attachments.

     

    by Martin Bando - 09:01 - 28 Mar 2025

    6 attachments 6 attachments

    image006.png
    image005.png
    image004.png
    image003.png
    image002.jpg
    image001.png

    2 replies 2 replies

    • Re: report_py3o
      Actually, the migration PR for report_py3o is ready to review. I have linked it in https://github.com/OCA/reporting-engine/issues/934

      Best regards,

      -Stéphane


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

      On Wed, Apr 2, 2025 at 7:17 PM Virginie Dewulf <virginie@odoo-community.org> wrote:
      Hello,

      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. The is no "OCA Teams being paid to provide the OCA Apps".

      It's 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.

      In your case, you can followup the advancement of migration to v18 in this issue in this repo: https://github.com/OCA/reporting-engine/issues/934
      I see the py3o module is not in this list of work to do... This would be a good question to ask to the PSC's.

      To find the PSC's, you can check this website: https://oca.github.io/repo-maintainer-conf/
      In your case, the PSC team can be found here: https://oca.github.io/repo-maintainer-conf/reporting.html

      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.

      As you are using OCA modules, you are also invited to contribute back to the association (if it is not already the case!) who supports the collaborative work and provides rules and a context for the OCA modules to being created and maintained, by buying a yearly membership for your employees (60€/year) or by becoming an OCA sponsor.
      https://odoo-community.org/get-involved/become-a-member
      https://odoo-community.org/get-involved/become-a-sponsor

      All the best,
      Virginie Dewulf
      Executive Director
      +32 477 64 17 20


      Le ven. 28 mars 2025 à 21:02, Martin Bando <notifications@odoo-community.org> a écrit :

      Hello everyone,

       

      we are currently using report_py3o under odoo 16. Is it possible to use report_py3o under odoo 18 or will it be possible in the future?

       

      Please do not hesitate to contact us if you have any questions.

       

      With kind regards

       

      Martin Bando

       

       

      Computer Science Expert - Software Development | OPAL Solutions GmbH

      martin.bando@opal-solutions.de | https://opal-solutions.de

      Niederlassung Bochum | T +49 (0)234 541 444 06

       

       

      Technische Probleme?:

      Schreiben Sie direkt eine Email an helpdesk@opal-solutions.de.

       

      Hauptsitz Rheinland | Karl-Heinz-Beckurts-Straße 13 | 52428 Jülich

      Niederlassung Ruhrgebiet/Sauerland | Heinrichstraße 67 | 44805 Bochum

      Niederlassung Münster/Osnabrück | Gewerbepark 18 | 49143 Bissendorf

      T +49 (0)2461 690 280 | F +49 (0)2461 690 284

      Amtsgericht Düren | HRB 5889 | Geschäftsführung: Michael von Steht
      OPAL Solutions GmbH ist ein Unternehmen der OPAL Associates Holding AG

      AGB  |  Impressum  |  Informationen zum Datenschutz

       

       

      Follow us on

       

                      

       

       

      WICHTIGE MITTEILUNG
      Diese E-Mail und deren Anlagen enthalten vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser E-Mail und deren Anlagen sind nicht gestattet. OPAL haftet nicht für Schäden, die durch den unerlaubten Gebrauch dieser E-Mail und deren Anlagen entstehen.

      IMPORTANT MESSAGE
      This e-mail and their attachments may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this e-mail. Unauthorized copying and unauthorized distribution of this e-mail and their attachments are not allowed. OPAL is not liable for damages caused by unauthorized use of this e-mail and attachments.

       

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

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

      by Stéphane Bidoul - 07:46 - 2 Apr 2025
    • Re: report_py3o
      Hello,

      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. The is no "OCA Teams being paid to provide the OCA Apps".

      It's 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.

      In your case, you can followup the advancement of migration to v18 in this issue in this repo: https://github.com/OCA/reporting-engine/issues/934
      I see the py3o module is not in this list of work to do... This would be a good question to ask to the PSC's.

      To find the PSC's, you can check this website: https://oca.github.io/repo-maintainer-conf/
      In your case, the PSC team can be found here: https://oca.github.io/repo-maintainer-conf/reporting.html

      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.

      As you are using OCA modules, you are also invited to contribute back to the association (if it is not already the case!) who supports the collaborative work and provides rules and a context for the OCA modules to being created and maintained, by buying a yearly membership for your employees (60€/year) or by becoming an OCA sponsor.
      https://odoo-community.org/get-involved/become-a-member
      https://odoo-community.org/get-involved/become-a-sponsor

      All the best,
      Virginie Dewulf
      Executive Director
      +32 477 64 17 20


      Le ven. 28 mars 2025 à 21:02, Martin Bando <notifications@odoo-community.org> a écrit :

      Hello everyone,

       

      we are currently using report_py3o under odoo 16. Is it possible to use report_py3o under odoo 18 or will it be possible in the future?

       

      Please do not hesitate to contact us if you have any questions.

       

      With kind regards

       

      Martin Bando

       

       

      Computer Science Expert - Software Development | OPAL Solutions GmbH

      martin.bando@opal-solutions.de | https://opal-solutions.de

      Niederlassung Bochum | T +49 (0)234 541 444 06

       

       

      Technische Probleme?:

      Schreiben Sie direkt eine Email an helpdesk@opal-solutions.de.

       

      Hauptsitz Rheinland | Karl-Heinz-Beckurts-Straße 13 | 52428 Jülich

      Niederlassung Ruhrgebiet/Sauerland | Heinrichstraße 67 | 44805 Bochum

      Niederlassung Münster/Osnabrück | Gewerbepark 18 | 49143 Bissendorf

      T +49 (0)2461 690 280 | F +49 (0)2461 690 284

      Amtsgericht Düren | HRB 5889 | Geschäftsführung: Michael von Steht
      OPAL Solutions GmbH ist ein Unternehmen der OPAL Associates Holding AG

      AGB  |  Impressum  |  Informationen zum Datenschutz

       

       

      Follow us on

       

                      

       

       

      WICHTIGE MITTEILUNG
      Diese E-Mail und deren Anlagen enthalten vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser E-Mail und deren Anlagen sind nicht gestattet. OPAL haftet nicht für Schäden, die durch den unerlaubten Gebrauch dieser E-Mail und deren Anlagen entstehen.

      IMPORTANT MESSAGE
      This e-mail and their attachments may contain confidential and / or privileged information. If you are not the intended recipient or have received this email in error, please notify the sender immediately and destroy this e-mail. Unauthorized copying and unauthorized distribution of this e-mail and their attachments are not allowed. OPAL is not liable for damages caused by unauthorized use of this e-mail and attachments.

       

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

      by Virginie Dewulf (OCA) - 07:16 - 2 Apr 2025
  • Odoo Vulnerability Scanner (Security) – Seeking Ideas & Feedback

    Hello,

    I’m working on OdooScan, a project inspired by WPScan, designed to identify design flaws and security misconfigurations in Odoo instances:
    🔗 https://github.com/cyberwave-odoo/odooscan

    I’m looking for guidance and ideas to make this project more fun, and engaging for security professionals.

    Current Features & Areas for Improvement:

    ✔️ Detecting the installed Odoo version and related vulnerabilities
    ✔️ Identifying vulnerable installed modules
    ✔️ Username enumeration
    ✔️ Weak password detection via brute force
    ✔️ Publicly accessible config files and database dumps
    ✔️ Exposed error logs
    ✔️ Media file enumeration
    ✔️ Checking if Odoo-Cron is enabled
    ✔️ Detecting open user registration

    Future Enhancements:

    🚀 Static Code Analysis – Identify vulnerabilities in custom Odoo modules
    🚀 API Fuzzing – Test the robustness of exposed APIs

    I’d love to hear your thoughts on improving OdooScan! Any feedback, suggestions, or feature ideas would be greatly appreciated.

    Looking forward to your insights!

    Kind regards,
    Jérôme

    by "Jerôme Dewandre" <jerome.dewandre.mail@gmail.com> - 11:15 - 28 Mar 2025
  • Peppol 2026 Belgium
    Hello,

    Does OCA have any plans to comply with the PEPPOL 2026 requirements in Belgium?

    We have customers on versions 11.0, 13.0, 15.0, and 16.0, and we cannot migrate all of them before 2026.

    Kind regards,

    François WYAIME
    Odoo Expert @ ABAKUS IT-SOLUTIONS
    by franz.wyaime - 11:11 - 27 Mar 2025

    15 replies 15 replies

  • Compatibility OCA OCB + OpenUpgrade
    Hello everybody,

    I want to know if it is possible to use OpenUpgrade with OCB. For example, if I use OCB v16 and want to update to OCB v17.

    Thanks.
    by Aboubacar TRAORE - 02:36 - 27 Mar 2025

    1 replies 1 replies

  • Work centers planning gantt chart and other planning tools
    Hello!

    We have a client who's working with v17 CE. Their main issue right now is planning and managing their manufacturing capacity, as in work center availability and determining how many machines they'd actually need to fulfill manufacturing demand. We showed them Enterprise's work center planning gantt chart, and they seemed to like it. With that in mind, could you recommend some alternatives as well as complimentary tools available for Community?

    Thank you!

    --

    SAMUEL MACIAS OROPEZA

    TECH LEAD

    smacias@opensourceintegrators.com

    P.O. BOX 940, HIGLEY, AZ 85236





    Security Notice: Don't be too quick to click!
    Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator.
    by Samuel Macias Oropeza - 10:26 - 26 Mar 2025

    1 replies 1 replies

    • Re: Work centers planning gantt chart and other planning tools
      Hi Samuel,
      That’s a great use case. We actually developed a planning tool for HR resource management that might serve as inspiration for your client's manufacturing planning needs. You can check it out here:
      https://github.com/OCA/resource/pull/5

      It uses the web_timeline module (https://github.com/OCA/web/tree/17.0/web_timeline) to provide a Gantt-style view for scheduling personnel. While it’s designed for HR purposes, the same structure could potentially be adapted to visualize work center availability and manufacturing capacity.

      As far as I know, a dedicated Gantt for manufacturing planning in CE doesn't currently exist, but this could be a solid starting point if you're considering a custom solution. Happy to chat further if you'd like help shaping that idea.

      Best,

      On Wed, Mar 26, 2025 at 5:28 PM Samuel Macias Oropeza <notifications@odoo-community.org> wrote:
      Hello!

      We have a client who's working with v17 CE. Their main issue right now is planning and managing their manufacturing capacity, as in work center availability and determining how many machines they'd actually need to fulfill manufacturing demand. We showed them Enterprise's work center planning gantt chart, and they seemed to like it. With that in mind, could you recommend some alternatives as well as complimentary tools available for Community?

      Thank you!

      --

      SAMUEL MACIAS OROPEZA

      TECH LEAD

      smacias@opensourceintegrators.com

      P.O. BOX 940, HIGLEY, AZ 85236





      Security Notice: Don't be too quick to click!
      Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator.

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



      --
      Binhex Logo
      Jorge Elena Poblet
      Founder & CEO
      Binhex
      j.elena@binhex.cloud
      Office (Spain) : +34 622 40 08 08
      Office (USA): +1 561 403 4406
      Offices:
      Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
      Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
      Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
      Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
      LinkedIn Twitter Facebook YouTube
      Start for free: Try Odoo Community in the cloud

      This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
      Privacy Policy
      by Jorge Elena Poblet - 11:06 - 26 Mar 2025
  • The future of oca/bank-payment
    Hi everyone,

    The oca/bank-payment repository has the essential modules to prepare and generate SEPA (and more) payment orders for credit transfer and direct debit.

    Today, there are important decisions to make about the future of this module.

    18 months ago, Alexis de Lattre, (one of) the original authors of these modules, started a huge effort to modernize these modules and improve their overall quality.
    He explained his approach in this PR 1174 for 16.0  [1]. 
    Naturally, that PR was not merged because it came too late in the 16.0 release cycle. 

    Now Alexis continues this effort with a series of 18.0 pull requests, with the important addition that he proposes to replace the Payment Mode object by the now native object from Odoo. 

    In Odoo v18, Odoo SA introduced new "Payment mode" M2O fields in the "account" module (cf this commit [6]):
    - on res.partner : one property field "Customer Payment Method" and one property field "Supplier Payment Method"
    - on invoices (account.move) : one field "Payment Method", copied from res.partner and that can be modified
    Up to Odoo v17, these "Payment mode" fields were not native ; they were added by the OCA module account_payment_partner from OCA/bank-payment.
    These new native "Payment mode" fields use the model account.payment.method.line (which was introduced in v15).

    Migrating to use these native fields makes a lot of sense to align with Odoo to avoid duplication of fields and logic.

    For more context, There was some discussion in the 16.0 PR [1], the 18.0 migration issue [4], as well as [5].

    I personally very much welcome this effort as I think the quality of Alexis' work is excellent (as usual), and this will create a solid foundation for the future.
    Indeed, over the many years of history of these modules, the only significant refactoring was Pedro's important work to adapt them to use Account Payment, and these modules start to show their great age.

    Alexis' work can be tested on runboat PR 1406 for direct debit [2] and PR 1405 for credit transfer [3]. From the preliminary tests we have done at Acsone it works fine.

    Of course, such work is not a traditional migration, and is difficult to review due to the importance of the changes. This will also create some additional migration work for maintainers of modules that depend on it (for instance the migration from Payment Mode to native Payment Methods will require some effort, although not difficult).

    On the other hand, reaching the same result by incremental improvements is going to be impossible, because as soon as a module is merged it starts to be extended, and some evolutions will not be possible in a backward-compatible way.

    So Akretion and Acsone propose to add migration scripts, and merge Alexis' work in 18.0 and rapidly iterate from there to review and add possible features that would have been missed in the transition. At Acsone we plan to put significant effort on this repo in the coming 3-4 months.

    Would there be agreement on such an approach?

    Best regards,

    -Stéphane

    by Stéphane Bidoul - 11:45 - 26 Mar 2025

    42 replies 42 replies

    • Re: The future of oca/bank-payment
      Hello, all colleagues!
       
      First of all, I want to greet you, and with my comment, I'm only trying to calm and soothe the moods, which are sometimes milestones that I honestly believe are of great merit. Ultimately, if we're involved in these discussions, it's because we care about our OCA Organization and contribute the best of each of us... but that doesn't mean that sometimes we don't agree, or for whatever reasons the responses and disagreements have been, we end up questioning something that doesn't convince us, or because someone has a point of view that differs from ours.
       
      That said, what we do need to safeguard is that in these discussions, we must be restrained in our comments that impact us all in some way, and because in the end, those who benefit from our public and honest disagreements that lead nowhere are the same ones who are rubbing their hands together trying to get us out of this, our common home, and move on to examples of how we don't understand each other... and that's not the case... because, I believe, sometimes our honesty and clarity in communications are the very reason we are immersed in the OCA project, and it's taking its toll on us.
       
      I would like to address this message to all colleagues in general, and especially to those involved in these recent debates. This is why I have participated in these comments. I apologize if my message is misunderstood. With the best of intentions, it only seeks to maintain the differences we deem appropriate, as is the law, but also to safeguard offensive comments and disagreements with the best possible tone and in the best possible harmony, which is how I consider all members of our OCA Organization.
       
      A hug to everyone, and I send you health and brotherhood from Andalusia (Spain).
       
      El 18/04/2025 18:52 CEST Enric Tobella Alomar <notifications@odoo-community.org> escribió:
       
       
      Hi Stéphane and everyone,
       
      I understand that creating a fork is not the best outcome, but it seems inevitable right now. If we need to create it, I would call it experimental. As I explained several times, the native use of this fields is not the use that you are proposing (you can check on Odoos commits to see that it just a field for help on the creation of payments, nothing else). Odoo's approach is completly different in this topic and we are trying to enforce our system in something different. Also, using the word native is a way of saying that the original work is not "native". Obviously, this is not correct and you are enforcing an opinionated option as the "native". Also, we have no confirmation on this topic from Odoo (and I think they will never give an answer on this topic). For these reasons, I would never call it native, as Graeme said, calling it experimental seems a good approach. In any case, my vote is to avoid the creation of this fork. I understand that this might be rude, but you are trying to enforce a specific way of doing without taking care of PSC comments. Reviews were added on this PRs and we received no answers, we raised concerns about it and you couldn't give any compromises. In my opinion, this a rude way to act on a community environment.
       
      Personally, it seems that you are enforcing a picture where people against Alexis solution are "bad people" that are against community health. But, IMO, we delivered comments and opinions and we were ignored everytime. Even so, in the explanation of how the meeting was, it was something like: Some people opinons, but it is just opinions... Alexis thinks that his code is better, so his code is better(without proofs)... However, even Alexis confesed that he was not doing a proper work as maintainer of the tool. Sorry if some people thinks I am too direct or rude, but sometimes people need to be clear and expose their fears and concerns.
       
      Also, some PSC offered their help (Pedro and myself for example) in order to get a a middle solution, but we received no answer on that again. 
       
      Maybe merging the PRs directly was not the best option, but it was clear that it was a "all or nothing" approach from Alexis side as he refused to get a middle solution no matter the comments or problems raised from the other side. IMO, merging Tecnativa's PRs was a good way to proceed, as Alexis was not giving any options to get a common ground and we have been waiting several months for this.
       
      Personally, I have been in similar situations where two people offered different solutions for the same problem and both parties tried to converge. In this case, only one of them proposed things to converge. The other one, made a fork and tried to enforce their opinion no matter what (even loosing work from other people...)
       
      Kind regards,

      El vie, 18 abr 2025 a las 17:43, Stéphane Bidoul (<notifications@odoo-community.org>) escribió:
      Hi everyone,
       
      As we are Friday 18th, have we obtained more information from Odoo about their intentions with these fields?
       
      Pedro, I find it really rude that you closed PRs without waiting for the conclusion of this conversation.
       
      Anyway, since this is done, I conclude that the decision is taken, and it is not possible to converge for 18.
      I am disappointed and I see that as a kind of failure for our community that a fork has to happen, but this is the only way forward I see. 
       
      The only possible solution that our tooling supports is creating modules with new names. Since these modules will contain models with identical names, we need to declare them conflicting with the existing ones in their manifests.
       
      A new repo is not strictly necessary but seems useful to reduce confusion. As I re-read the thread, there was agreement on that.
       
      I don't have a strong opinion on the name of the new repo. Alexis' proposal of bank-payment-native is better that anything else I can think of so far. Let's open the PR on repo-maintainer-conf. We can still adapt the name if a better one emerges.
       
      Could the READMEs of each repo (and if possible each addons) reference each other so users can make informed decisions and encourage future convergence?
       
      Ah, one last thing. I'm also saddened by the ad-hominem attacks in this thread. This is definitely not what we want in a thriving community. Maintaining open source projects is not easy, and if perfect maintainers exist I don't know them.
       
      To conclude, let's recognize that if convergence is not possible, exploring different approaches is also healthy, and OCA can provide room for that.
       
      Wishing you a nice weekend,
       
      -Stéphane
       

      On Wed, Apr 16, 2025 at 11:06 AM Graeme Gellatly <notifications@odoo-community.org> wrote:
      Just ping me if you need review, unfortunately we get failure trying to test locally, but we are in the middle of a 450 module migration, down to last dozen or so, most ultimately depending on payment order. We have production data, freshly migrated via enterprise to do real proper testing on. Only problem we face is we can't aggregate the current merge requests.  Although maybe there is a better way we can do that.
       
      merges:
          - origin $ODOO_VERSION
          # Can't merge 1439 at the moment because of this
          # test-requirements.txt commit:
          # befd64bd07aaa293026b648bc06494d6f1b466fc
          #- origin refs/pull/1438/head # 'account_payment_mode'
          #- origin refs/pull/1439/head # 'account_payment_partner'
          #- origin refs/pull/1440/head # 'account_payment_order'

      On Wed, Apr 16, 2025 at 7:22 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
      I'm disappointed that both Virginie's summary and Alexis' reply appears to say "Alexis' proposal is better, but...", when I exposed clearly in the meeting and previously written on the threads that the main problems are:
       
      - The switch to account.payment.method.line is not better. It provokes a lot of work to do, user adaptation, etc, with no clear benefit.
      - The current proposed code starts from a fork done 2 years ago, not having all the work done meanwhile in the main branch.
      - It contains a lot of datamodel changes apart from the main question, which are the same problematic.
       
      And again, I'm not saying the current code quality on the XML export is the best, but that it should be worked on as a separate proposal, not trying to impose all the changes together. I even offered to help him to extract that improvement to be proposed over current OCA code, but my offering seems to not serve for anything...
       
      I'm also surprised about the washing done on Alexis' attitude, while he clearly recognized it.
       
      Anyway, I continue with the merging of the current modules that is blocking me and a lot of other good contributors, and I have already spent a lot of time on this topic.
       
      Regards.

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

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

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

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

      by Jose Luis Baños - 09:34 - 18 Apr 2025

      1 attachments 1 attachments

      Logo para contestación de correos y reenvios JLBB.png
    • Re: The future of oca/bank-payment
      And again, you are reflecting that Alexis' time is precious, while ours is simply rejected or put on background. He has spent that time because he wanted to. Since the beginning, I expressed that I think it was a bad idea, with no replies on his part, so who's having inadequate behaviors?

      Regards.
      by Pedro M. Baeza - 07:47 - 18 Apr 2025
    • Re: The future of oca/bank-payment
      > I merely pointed out a couple of things I found inadequate in this thread, and saddened me.

      Stéphane. I had already answered to this, as there's no inadequate behavior not having to wait more time if things are clear.

      > My understanding on that is that there was no alternative option that would have not cost him a huge effort on top of what he had done already. If everyone had an infinite budget and time available things would be easier :)

      That's not true, as all my offerings put time on my side, not him, and I have already expressed that several times. What I see inadequate is that you, Stéphane, not being part of the meeting we took, or even the conversations, seen that all that I wrote is being ignored, and given your reputation inside OCA ecosystem, throws out to me personally bad behaviors, while softening other even worst behaviors by Alexis admitted by him, like having a code that has not follow community guidelines nor collaborative minimum rules (I remind you that the proposed branch is a fork of 16.0 done 2 years ago, excluding all the community improvements meanwhile).

      Regards.
      by Pedro M. Baeza - 07:41 - 18 Apr 2025
    • Re: The future of oca/bank-payment
      Hi Enric,

      > Personally, it seems that you are enforcing a picture where people against Alexis solution are "bad people" that are against community health

      That is absolutely not my intent!

      I merely pointed out a couple of things I found inadequate in this thread, and saddened me.

      > Alexis was not giving any options to get a common ground

      My understanding on that is that there was no alternative option that would have not cost him a huge effort on top of what he had done already. If everyone had an infinite budget and time available things would be easier :)

      For the rest I simply notice that no agreement was found and we now need to move forward, if possible without losing valuable contributions and contributors.
      So the fork is the next best solution so each approach can compete on its own merit (with of course an advantage to the incumbent and that's normal - but let's not make things harder than necessary for the new approach).

      Best regards,

      -Stéphane


      On Fri, Apr 18, 2025 at 6:52 PM Enric Tobella Alomar <notifications@odoo-community.org> wrote:
      Hi Stéphane and everyone,

      I understand that creating a fork is not the best outcome, but it seems inevitable right now. If we need to create it, I would call it experimental. As I explained several times, the native use of this fields is not the use that you are proposing (you can check on Odoos commits to see that it just a field for help on the creation of payments, nothing else). Odoo's approach is completly different in this topic and we are trying to enforce our system in something different. Also, using the word native is a way of saying that the original work is not "native". Obviously, this is not correct and you are enforcing an opinionated option as the "native". Also, we have no confirmation on this topic from Odoo (and I think they will never give an answer on this topic). For these reasons, I would never call it native, as Graeme said, calling it experimental seems a good approach. In any case, my vote is to avoid the creation of this fork. I understand that this might be rude, but you are trying to enforce a specific way of doing without taking care of PSC comments. Reviews were added on this PRs and we received no answers, we raised concerns about it and you couldn't give any compromises. In my opinion, this a rude way to act on a community environment.

      Personally, it seems that you are enforcing a picture where people against Alexis solution are "bad people" that are against community health. But, IMO, we delivered comments and opinions and we were ignored everytime. Even so, in the explanation of how the meeting was, it was something like: Some people opinons, but it is just opinions... Alexis thinks that his code is better, so his code is better(without proofs)... However, even Alexis confesed that he was not doing a proper work as maintainer of the tool. Sorry if some people thinks I am too direct or rude, but sometimes people need to be clear and expose their fears and concerns.

      Also, some PSC offered their help (Pedro and myself for example) in order to get a a middle solution, but we received no answer on that again. 

      Maybe merging the PRs directly was not the best option, but it was clear that it was a "all or nothing" approach from Alexis side as he refused to get a middle solution no matter the comments or problems raised from the other side. IMO, merging Tecnativa's PRs was a good way to proceed, as Alexis was not giving any options to get a common ground and we have been waiting several months for this.

      Personally, I have been in similar situations where two people offered different solutions for the same problem and both parties tried to converge. In this case, only one of them proposed things to converge. The other one, made a fork and tried to enforce their opinion no matter what (even loosing work from other people...)

      Kind regards,

      El vie, 18 abr 2025 a las 17:43, Stéphane Bidoul (<notifications@odoo-community.org>) escribió:
      Hi everyone,

      As we are Friday 18th, have we obtained more information from Odoo about their intentions with these fields?

      Pedro, I find it really rude that you closed PRs without waiting for the conclusion of this conversation.

      Anyway, since this is done, I conclude that the decision is taken, and it is not possible to converge for 18.

      I am disappointed and I see that as a kind of failure for our community that a fork has to happen, but this is the only way forward I see. 

      The only possible solution that our tooling supports is creating modules with new names. Since these modules will contain models with identical names, we need to declare them conflicting with the existing ones in their manifests.

      A new repo is not strictly necessary but seems useful to reduce confusion. As I re-read the thread, there was agreement on that.

      I don't have a strong opinion on the name of the new repo. Alexis' proposal of bank-payment-native is better that anything else I can think of so far. Let's open the PR on repo-maintainer-conf. We can still adapt the name if a better one emerges.

      Could the READMEs of each repo (and if possible each addons) reference each other so users can make informed decisions and encourage future convergence?

      Ah, one last thing. I'm also saddened by the ad-hominem attacks in this thread. This is definitely not what we want in a thriving community. Maintaining open source projects is not easy, and if perfect maintainers exist I don't know them.

      To conclude, let's recognize that if convergence is not possible, exploring different approaches is also healthy, and OCA can provide room for that.

      Wishing you a nice weekend,

      -Stéphane


      On Wed, Apr 16, 2025 at 11:06 AM Graeme Gellatly <notifications@odoo-community.org> wrote:
      Just ping me if you need review, unfortunately we get failure trying to test locally, but we are in the middle of a 450 module migration, down to last dozen or so, most ultimately depending on payment order. We have production data, freshly migrated via enterprise to do real proper testing on. Only problem we face is we can't aggregate the current merge requests.  Although maybe there is a better way we can do that.

      merges:
          - origin $ODOO_VERSION
          # Can't merge 1439 at the moment because of this
          # test-requirements.txt commit:
          # befd64bd07aaa293026b648bc06494d6f1b466fc
          #- origin refs/pull/1438/head # 'account_payment_mode'
          #- origin refs/pull/1439/head # 'account_payment_partner'
          #- origin refs/pull/1440/head # 'account_payment_order'

      On Wed, Apr 16, 2025 at 7:22 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
      I'm disappointed that both Virginie's summary and Alexis' reply appears to say "Alexis' proposal is better, but...", when I exposed clearly in the meeting and previously written on the threads that the main problems are:

      - The switch to account.payment.method.line is not better. It provokes a lot of work to do, user adaptation, etc, with no clear benefit.
      - The current proposed code starts from a fork done 2 years ago, not having all the work done meanwhile in the main branch.
      - It contains a lot of datamodel changes apart from the main question, which are the same problematic.

      And again, I'm not saying the current code quality on the XML export is the best, but that it should be worked on as a separate proposal, not trying to impose all the changes together. I even offered to help him to extract that improvement to be proposed over current OCA code, but my offering seems to not serve for anything...

      I'm also surprised about the washing done on Alexis' attitude, while he clearly recognized it.

      Anyway, I continue with the merging of the current modules that is blocking me and a lot of other good contributors, and I have already spent a lot of time on this topic.

      Regards.

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

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

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



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

      by Stéphane Bidoul - 07:21 - 18 Apr 2025
    • Re: The future of oca/bank-payment
      Bravo, Enric, thanks for these words that I totally shared.

      Stéphane, Friday 18th was the deadline, the limit date, giving by Virginie to heard a decision on Alexis side if he wants to accept my offering of converging the good things of his proposal (like the XML export refactoring) into the current one, and put in pause (which is not the same as to reject) the switch to that fields till 19, while we get more information from Odoo what are their intentions with them, or directly see if Odoo expands their usage, but he was pretty clear that he doesn't want to converge in any case in 18 in this message, and proposing something impossible: once you split into 2, join both forks again is not going to happen. And less with a person that has proved now that has no will of wanting to converge. Or the rest follows whatever he wants to propose, or no more effort on his part. So, what I did is to follow our path. No need to wait more because nothing will change waiting till today.

      I reiterate again my will of putting more of my time extracting the improvements on the XML export code if you at least accept to resign on some things for 18.0 while we continue investigating, but if not, I think this is a definitive schism with a lot of consequences.

      Regards.
      by Pedro M. Baeza - 07:16 - 18 Apr 2025

  • dms in 18.0 is wow
    Dear Contributors, I couldn't wait until I share the video of dms module for version 18.0 that I am almost finished with.

    It will include wow features starting with new odoo design for 18.0 and also a handy security and privacy for managing files and sharing too as well.

    I am waiting for positive feedback and encouragement.

    happy contribution...

    https://youtu.be/5z7yPdCnZCo
    by Mohamed Alkobrosly - 04:45 - 26 Mar 2025
  • Planned disruption of OCA services on April 7th
    Hi everyone,

    We have been informed by our hosting company that a mainboard replacement needs to be performed on the main OCA server.

    This means that most OCA services (CI, runboat, weblate, GitHub bot, etc) will be disrupted on 7 April 2025, from 08:00 GMT+2 to 12:00 GMT+2.

    Please organize accordingly.

    I'll provide more information as it becomes available.

    Best regards,

    -Stéphane

    --
    Stéphane Bidoul
    http://acsone.eu/
    by Stéphane Bidoul - 10:31 - 25 Mar 2025

    1 replies 1 replies

    • Re: Planned disruption of OCA services on April 7th
      The server is back online.

      Thank you for your patience.

      Best regards,

      -Stéphane

      On Tue, Mar 25, 2025 at 10:27 AM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
      Hi everyone,

      We have been informed by our hosting company that a mainboard replacement needs to be performed on the main OCA server.

      This means that most OCA services (CI, runboat, weblate, GitHub bot, etc) will be disrupted on 7 April 2025, from 08:00 GMT+2 to 12:00 GMT+2.

      Please organize accordingly.

      I'll provide more information as it becomes available.

      Best regards,

      -Stéphane

      --
      Stéphane Bidoul
      http://acsone.eu/
      by Stéphane Bidoul - 03:31 - 7 Apr 2025
  • dms security issues solved
    Dear OCA community, recently we have been migrating DMS module from 17.0 to 18.0.

    While migration we encountered some security critical issues.
    We found that some people have raised them in:

    https://github.com/OCA/dms/issues/381
    https://github.com/OCA/dms/issues/386

    I was interested to assign each portal user access to only their related files and by default related directories only.

    Now we could solve the security issue in 18.0 but I guess if some members here are annoyed from these issues in older versions like 17.0 and 18.0 I left the commit of the solution in that PR:

    https://github.com/OCA/dms/pull/385

    here is the commit of the solution:

    8db593b4bcb94f772576f7fec33f6c1837bd610f

    In brief as portal users can access only their related sales order and invoices, they access only their related files.

    Only we have to assign any user as a follower to the file in its mixin in form view and those users whether they are internal or portal will access only the files they are following.

    I am waiting for your reviews on our migration, and I am pleased to have the fix merged in older versions too.

    Best Regards...
    by Mohamed Alkobrosly - 06:56 - 25 Mar 2025

    3 replies 3 replies

    • Re: dms security issues solved
      Don't worry. There's no problem, but the wording is important. To put "DMS security issues" raises an alarm on something that it's not true. If you want to organize the security in another way, it can be discussed.

      Let's talk about it on GitHub.

      Regards.
      by Pedro M. Baeza - 05:36 - 25 Mar 2025
    • Re: dms security issues solved
      Dear Pedro and community.

      I am so sorry for causing interruption, I was excited to introduce an extra layer of security for better organization of docs. and ultimate security too.

      Thanks for Pedro for guiding me on best behave.

      Best regards...

      On Tue, Mar 25, 2025 at 10:27 AM Pedro M. Baeza <notifications@odoo-community.org> wrote:
      Hi, Mohamed, what you (and some others) consider security issues, are conscious decisions about how the DMS work, and they should be discussed separately from the migration to a new version. Please keep the migration clean from these behavior changes and let's discuss any change in GitHub separately.

      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 Mohamed Alkobrosly - 05:30 - 25 Mar 2025
    • Re: dms security issues solved
      Hi, Mohamed, what you (and some others) consider security issues, are conscious decisions about how the DMS work, and they should be discussed separately from the migration to a new version. Please keep the migration clean from these behavior changes and let's discuss any change in GitHub separately.

      Regards.
      by Pedro M. Baeza - 08:26 - 25 Mar 2025