Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

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