Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

  • Migrating sign_oca to 18.0
    I am delighted to share that I could finally migrate sign_oca module from version 17.0 to version 18.0.

    I exerted a lot of effort as:
    32 files changed
    +300 -262 lines changed

    I am not 100% sure about perfect functionality, I have never used it before.

    I would like some members to review and tell me if there is any bug.

    I also suggest if the description and usage be modified to guide very new users.

    https://github.com/OCA/sign/pull/74

    best wishes for all :)
    by Mohamed Alkobrosly - 12:21 - 28 Dec 2024
  • The OCA is looking for a Content Creator & Training Manager (Deadline 24th January)
    Hello everyone,

    With the OCA Board, we are organizing new projects for 2025. To do so, we will need more people to help out on a regular basis, hence the creation of this new position within the team (there are currently 2 people working for the OCA with a fee: Rebecca, General Secretary and Event Manager, and myself Virginie, Executive Director.

    We are looking for a Content Creator & Training Manager. The details are available here:

    The RFQ process is available here:

    Deadline to answer is on January, 23th, with the objective of getting started with this new role in the begin of February.

    Thanks a lot for sharing and applying if you are interested!

    A side note: I remind you that there is another Call for Participation ongoing: propose your content to share your knowledge and expertise with the other OCA members in 2025 through webinars.
    Deadline is on the 16th January.

    I wish you a happy end of 2024 and begin of 2025,
    Virginie Dewulf
    Executive Director
    +32 477 64 17 20
    by Virginie Dewulf (OCA) - 09:46 - 23 Dec 2024
  • UOM in Odoo 17

    Dear all,

    I hope this message finds you well.

    I am encountering some challenges with the use of Units of Measure (UOM) in the Sales and Point of Sale (POS) modules. These cases primarily involve a supermarket setup where products are sold both at retail and wholesale levels (e.g., by unit or box).

    Issue 1: UOM and Product Attributes
    We do not want to create separate products for each UOM. Instead, we aim to utilize product attributes for future use on the website.
    For example:

    • Mango Juice (Brand A): Attributes include size (250 ml, 1 liter) and uom type (piece, dozen).

    Issue 2: Items Sold by Dimensions
    Some products are sold based on width and height in meters. For instance:

    • Purchased as sheets (e.g., 2m x 9m, 6m x 6m).
    • These need to be sold in a way that reflects accurate inventory deductions.

    Could you please advise on how to address these scenarios? I am open to considering customization if necessary.

    Thank you,

    by salehmahdi96 - 10:06 - 18 Dec 2024
  • OCA rub-boat error
    Hello dear community, I have been fixing an issue with a module and this module showed me two errors and the cause is the same, I suspect I should have add my fix to version 16.0 instead of version 17.0 due to that error.


    Any guidance, please?



    Downloading graphql-server-3.0.0b7.tar.gz (48 kB)
    56 Preparing metadata (setup.py): started
    57 Preparing metadata (setup.py): finished with status 'done'
    58ERROR: Could not find a version that satisfies the requirement odoo-addon-auth_jwt<17.1dev,>=17.0dev (from versions: 16.0.1.0.0.3, 16.0.1.1.0, 16.0.1.1.0.2, 16.0.1.1.0.3, 16.0.1.1.0.6, 16.0.1.1.0.7)
    59ERROR: No matching distribution found for odoo-addon-auth_jwt<17.1dev,>=17.0dev
    60Error: Process completed with exit code 1.














    0s

    by Mohamed Alkobrosly - 10:16 - 17 Dec 2024

    3 replies 3 replies

  • Sync odoo's calendar smartphones without Google nor Outlook
    Dear all

    Does anybody manage to sync odoo's calendar without Google/outlook ?

    Actually I tried Myodoo that has bugs and I'm going to try the old z-push odoo's backend https://github.com/funbaker/odoozpush

    Thanks and have a great weekend

    --------------------------------
    Cyril VINH-TUNG
    INVITU
    Computer & Network Engineering
    BP 32 - 98713 Papeete - French Polynesia
    Tél: +689 40 46 11 99
    contact@invitu.com
    www.invitu.com
    by Cyril VINH-TUNG - 08:06 - 14 Dec 2024

    5 replies 5 replies

  • demo data and tests
    Hello Odoo community,

    More and more the OCA contributors avoid writing tests which depend on demo data and so does Odoo SA. This makes it easier to ensure tests are simple and will run no matter how demo data might be touched by other modules.

    But eventually this could bring other benefits such as the ability to run these standard tests in the CI with production database dumps (that is where the demo data cannot be loaded in general).

    In this case, I have a first question: probably some customization's might add required fields. What would be the best practice to be able to run these "native" or OCA tests that might fail to create records with such new constraints? We could imagine some monkey patches and standard hooks to help... We kind of face this already today by running tests with all repo modules installed, but with production dumps, much more modules would be installed together along with some non OCA customization which also need to be developed more cheaply...

    But more important is my second question: if we set it as a good practice that OCA tests shouldn't depend on demo data, why are we still running the OCA CI with demo data enabled (still the case with Odoo 18 CI) ? Or is it planned we stop doing this in Odoo 19? I mean we could also save a good deal of server resources/time by not loading the gazillions of catchy Odoo CE demo data in each test run...


    Thank you very much for your answers.


    --
    Raphaël Valyi
    Founder and consultant

    by "Raphaël Valyi" <rvalyi@akretion.com> - 04:51 - 12 Dec 2024

    4 replies 4 replies

    • Re: demo data and tests

      Hello,

      On my projects I try to use demo data for master data, for the following reasons:

      • It results in code that is more readable.
      • I disagree that creating object in the fixture makes it easier to ensure tests are simple. It's much simpler to include a «self.data_name = self.env.ref("")» statement in the fixture that to include a full create({}) call, which often requires the programmer to specify fields that have nothing to do with the features being tested (like the object's name, etc).
      • Simple code make it easier to avoid creating a common setUpClass() method for every testcase in a module, which WILL have unintended consequences when you need to test some novel codepath that depends on some flags.
      • Small setup differences that a testcase may need can be encoded in instructions following the «self.data_name = self.env.ref("")» statement, like this:
        • self.bank_journal_01 = self.env.ref("account_bugfixes.demo_bank_journal_01")
        • self.bank_journal_01.code = "MYCODE01"
      • Makes it easier to compare fixtures used in unrelated tests, seeing in what they defer, etc.
      • I disagree that not depending on demo data makes it easier to ensure tests will run no matter how demo data might be touched by other modules. Invariants about fixture, in my opinion, must be enforced by including additional tests that assert that the test data begins as expected. Also, it's a design principle that new modules must not break existing functionality, and so must happen for demo data (i.e. in general, one should avoid patching existing demo records in dependencies).
      • Tests that depend on demo data also run faster, because demo data is created only once.

      This is my opinion.

      João Jerónimo


      Às 15:52 de 12/12/2024, Raphaël Valyi escreveu:
      Hello Odoo community,

      More and more the OCA contributors avoid writing tests which depend on demo data and so does Odoo SA. This makes it easier to ensure tests are simple and will run no matter how demo data might be touched by other modules.

      But eventually this could bring other benefits such as the ability to run these standard tests in the CI with production database dumps (that is where the demo data cannot be loaded in general).

      In this case, I have a first question: probably some customization's might add required fields. What would be the best practice to be able to run these "native" or OCA tests that might fail to create records with such new constraints? We could imagine some monkey patches and standard hooks to help... We kind of face this already today by running tests with all repo modules installed, but with production dumps, much more modules would be installed together along with some non OCA customization which also need to be developed more cheaply...

      But more important is my second question: if we set it as a good practice that OCA tests shouldn't depend on demo data, why are we still running the OCA CI with demo data enabled (still the case with Odoo 18 CI) ? Or is it planned we stop doing this in Odoo 19? I mean we could also save a good deal of server resources/time by not loading the gazillions of catchy Odoo CE demo data in each test run...


      Thank you very much for your answers.


      --
      Raphaël Valyi
      Founder and consultant

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

      by j_j_b_o_devel - 03:16 - 18 Dec 2024
    • Re: demo data and tests
      Hi

      On my projects tests are run at 2 levels:
      • At development level: The developer tests the code he has written to ensure that it works as expected. For this, the developper writes unit tests that are run on an empty database with only this addon installed. This ensures that the code is correct and works properly in the context defined by the dependencies of the addon.
      • At integration level: The CI runs all the tests on a database with all the addons installed. This ensures that the code is correct and works properly in the context of the whole system.

      To achieve this, we apply the following guidelines:
      • Tests don't rely on demo data; This eases the maintenance of the tests and ensures that the tests are not impacted by changes in the demo data. Moreover, it helps the developer to understand the context in which the tests are run.
      • Code that modifies / constrains an existing behavior must be disabled by default and must be enabled by a configuration parameter. This ensures that if you run the tests from other addons on a database where this addon is installed, the tests will not be impacted by this addon. It also ensures that if the tests are run at insall and another addon modifies the same behavior, the tests will not be impacted by this addon if it has been installed previously in the installation process. (The disabled behaviour is activated at test setup). All the disabled features are enabled in a top level addon which is excluded from the installation by the CI and installed only into the client database.
      •  Some specific test addons are developed for specific integration tests. These addons are useful to ensure that addons installed side by side are compatible even if they don't depend on each other. At test setup, we first activate the features of the addons that are activable by configuration parameter.
      • To avoid the need to use the "post_install' annotation, the CI runs the tests with pytest-odoo. The main difference compared to the way odoo runs the tests is that the registry is populated with all the addons installed into the database. pytest-odoo is a test runner only while when you run the tests with odoo, the tests are run along the installation/upgrade of the addons at the same time the registry is populated. To run tests with pytest-odoo, the first requirement is to have the addons to test installed in the database. One advantage of this approach is that even if your addon creates a new record for which another addon has created a new required field with a default value the tests will run correctly even if you don't depend on this addon.
      • ...
      With all these guidelines in place, we improve the quality, reliability, maintainability, flexibility, compatibility and the speed of the tests in both development and integration levels. Last but not least, in our CI we are now able to run our tests in parallel by using the pytest-xdist plugin. This is a huge improvement in the speed of the tests.

      We are still not perfect and since all the code modifying an existing behaviour is activated in production, some tests will fail if they are run on the production database since they are not designed to run with the modified behaviour.. But we solved a lot of issues we encountered in the past when tests were run by odoo at install/upgrade time. 

      Regards,

      lmi


      Use post install test tags and remove at install. And refuse PRs with required fields that don't set defaults. This is the normal practice anyway as you would get errors with or without using demo data.

      Also, one other benefit, particularly in number based tests is we use a library called hypothesis to determine values and try to find failing combos.

      Le ven. 13 déc. 2024, 04:52, Raphaël Valyi <notifications@odoo-community.org> a écrit :
      Hello Odoo community,

      More and more the OCA contributors avoid writing tests which depend on demo data and so does Odoo SA. This makes it easier to ensure tests are simple and will run no matter how demo data might be touched by other modules.

      But eventually this could bring other benefits such as the ability to run these standard tests in the CI with production database dumps (that is where the demo data cannot be loaded in general).

      In this case, I have a first question: probably some customization's might add required fields. What would be the best practice to be able to run these "native" or OCA tests that might fail to create records with such new constraints? We could imagine some monkey patches and standard hooks to help... We kind of face this already today by running tests with all repo modules installed, but with production dumps, much more modules would be installed together along with some non OCA customization which also need to be developed more cheaply...

      But more important is my second question: if we set it as a good practice that OCA tests shouldn't depend on demo data, why are we still running the OCA CI with demo data enabled (still the case with Odoo 18 CI) ? Or is it planned we stop doing this in Odoo 19? I mean we could also save a good deal of server resources/time by not loading the gazillions of catchy Odoo CE demo data in each test run...


      Thank you very much for your answers.


      --
      Raphaël Valyi
      Founder and consultant

      _______________________________________________
      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



      --
      Laurent Mignon
      Technical lead / Management Team
      T: +32 2 8883148


      Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
      Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
      Zone industrielle 22 | L-8287 Kehlen | Luxembourg

      by Laurent Mignon - 09:06 - 13 Dec 2024
    • Re: demo data and tests
      Irt to loading demo data, afaik, post test it is a demo instance as well for manual testing

      Le ven. 13 déc. 2024, 06:28, Graeme Gellatly <graeme@moahub.nz> a écrit :
      Hi

      Use post install test tags and remove at install. And refuse PRs with required fields that don't set defaults. This is the normal practice anyway as you would get errors with or without using demo data.

      Also, one other benefit, particularly in number based tests is we use a library called hypothesis to determine values and try to find failing combos.

      Le ven. 13 déc. 2024, 04:52, Raphaël Valyi <notifications@odoo-community.org> a écrit :
      Hello Odoo community,

      More and more the OCA contributors avoid writing tests which depend on demo data and so does Odoo SA. This makes it easier to ensure tests are simple and will run no matter how demo data might be touched by other modules.

      But eventually this could bring other benefits such as the ability to run these standard tests in the CI with production database dumps (that is where the demo data cannot be loaded in general).

      In this case, I have a first question: probably some customization's might add required fields. What would be the best practice to be able to run these "native" or OCA tests that might fail to create records with such new constraints? We could imagine some monkey patches and standard hooks to help... We kind of face this already today by running tests with all repo modules installed, but with production dumps, much more modules would be installed together along with some non OCA customization which also need to be developed more cheaply...

      But more important is my second question: if we set it as a good practice that OCA tests shouldn't depend on demo data, why are we still running the OCA CI with demo data enabled (still the case with Odoo 18 CI) ? Or is it planned we stop doing this in Odoo 19? I mean we could also save a good deal of server resources/time by not loading the gazillions of catchy Odoo CE demo data in each test run...


      Thank you very much for your answers.


      --
      Raphaël Valyi
      Founder and consultant

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

      by Graeme Gellatly - 06:31 - 12 Dec 2024
    • Re: demo data and tests
      Hi

      Use post install test tags and remove at install. And refuse PRs with required fields that don't set defaults. This is the normal practice anyway as you would get errors with or without using demo data.

      Also, one other benefit, particularly in number based tests is we use a library called hypothesis to determine values and try to find failing combos.

      Le ven. 13 déc. 2024, 04:52, Raphaël Valyi <notifications@odoo-community.org> a écrit :
      Hello Odoo community,

      More and more the OCA contributors avoid writing tests which depend on demo data and so does Odoo SA. This makes it easier to ensure tests are simple and will run no matter how demo data might be touched by other modules.

      But eventually this could bring other benefits such as the ability to run these standard tests in the CI with production database dumps (that is where the demo data cannot be loaded in general).

      In this case, I have a first question: probably some customization's might add required fields. What would be the best practice to be able to run these "native" or OCA tests that might fail to create records with such new constraints? We could imagine some monkey patches and standard hooks to help... We kind of face this already today by running tests with all repo modules installed, but with production dumps, much more modules would be installed together along with some non OCA customization which also need to be developed more cheaply...

      But more important is my second question: if we set it as a good practice that OCA tests shouldn't depend on demo data, why are we still running the OCA CI with demo data enabled (still the case with Odoo 18 CI) ? Or is it planned we stop doing this in Odoo 19? I mean we could also save a good deal of server resources/time by not loading the gazillions of catchy Odoo CE demo data in each test run...


      Thank you very much for your answers.


      --
      Raphaël Valyi
      Founder and consultant

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

      by Graeme Gellatly - 06:31 - 12 Dec 2024
  • Awnings dimensions app
    Hello community,

    I'm looking for a module to calculate awnings dimensions. 

    Is there any app which covers this need please ?

    Thank you!

    --
     
    Ahmed Trigui
    Conseiller Analyste fonctionnel
    +1 514-317-7944
    LinkedIn Twitter Facebook YouTube
     
      Nouveau
    Savez-vous tout sur l'open source ?     		  Découvrir
    by Ahmed Trigui - 01:51 - 11 Dec 2024

    13 replies 13 replies

    • RE: Awnings dimensions app

      Thanks David ! I’ll have a look.

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: David Beal [mailto:notifications@odoo-community.org]
      Verzonden: vrijdag 13 december 2024 14:02
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

       

      Le ven. 13 déc. 2024 à 12:29, David Beal <david.beal@akretion.com> a écrit :

      Hi Ahmed,

       

      You might consider taking a look here

       

       

      Let me know if you have any questions

       

      Regards

       

      David BEAL

      Consultant ERP Odoo

       

       

      Le ven. 13 déc. 2024 à 09:16, Johan Van Hirtum <notifications@odoo-community.org> a écrit :

      Thanks a lot for your answers, Graeme -)

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: Graeme Gellatly [mailto:notifications@odoo-community.org]
      Verzonden: donderdag 12 december 2024 11:54
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

      For the awning issue in particular, we used to do something similar in another system. You just end up making arbitrary distinctions in your variants. e.g. 500-1000mm W add $10, 1000-1500m add $20 and same for depth. I did that for 20 years and still have 1 customer doing like that. In fact even for all the advancement with DSL's etc mentioned above, 90% of pricing still internally follows that pattern. The main reason being is that other peoples systems can't handle truly dynamic dimensions at the invoice level and needs the arbitrary partcodes and distinctions.

       

      On Thu, Dec 12, 2024 at 11:36 PM Graeme Gellatly <graeme@moahub.nz> wrote:

      Well primarily i work with dimensioned products. Timber is actually a bit more complex because it is bought in cubes but sold in usually sizes x length.  I did that with variants and so.e customisation.

       

      But for basic things, if you consider a sale of a widget is 1 unit, then a sale of a dimensioned producy is 1 x 1.8 of something it is just one extra field or of 3d then d x w x h = v. If you need to record a whole list of things then say 4@ 4.8 6@3.2 adds up to roughly 38lm of something and can be held in a o2m on order line. All you are really manipulating is order qty.

       

      Le jeu. 12 déc. 2024, 21:57, Johan Van Hirtum <notifications@odoo-community.org> a écrit :

      Hi Graeme,

       

      Do you have or know about a module that let define dimensions on products and on variants ? Because most things with awnings can be done with variants ( fabric color, alu color, operation mode ) but there is no possibility to have an attribute that let you specify a dimension as an integer value. The same for products. In for example wood products, you sell pieces but the price is in meter and the length is a parameter you must provide. Sometimes you also have a product with fixed dimensions ( a profile or a plate ), price in m of m², where you can sell as a hole or cut to dimensions ( with sometimes an extra fee as % for cutting ). A solution for these situations would be all is needed I think for a lot of use cases.

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: Graeme Gellatly [mailto:notifications@odoo-community.org]
      Verzonden: woensdag 11 december 2024 20:58
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

      Hi,

       

      It doesn't really explain very well your question.

       

      Is it off plans, is it for pricing, is it for BoMs, for manufacturing machine integration e.g. CNC, is it the paper cutting problem, etc etc etc. I've done a lot of work in this space within custom MTO for manufacturing and pricing of construction materials. The 2 most difficult modules I used to maintain are mrp_dynamic_line (public, but always too risky/aggressive to be OCA) which calculates Production Orders dynamically from template attributes. The second is a DSL for managing the specification for a particular industry to do pricing, send to BoM (using dynamic_line and materials list from DSL, and does calculate all the dimensions) and api to manufacturing equipment on the SO Line which is private. The actual part of that module that handles the dimensions calculation is quite simple. It is just a one2many on sale order line with a few basic fields (and every similar model)

       

      Those between them + Odoo + OCA cover maybe 30% of the problem space.

       

      If it is custom MTO, then you also have a LOT of product code/cost/attribute/tracking/valuation considerations because every item at least in this case can have a different cost based on those DSL attributes with no real relation to any UoM concept. You need to avoid this if you can.

       

      Modern QS stuff, uses google earth to approximate dimension in brownfields, can read pdf plans, has onsite site measure functionality, produces necessary legal docs, quotes, 3d models etc, calculates angles and rakes, material specific things like can waste be reused elsewhere, environmental specific things like wind loading and engineering and legal requirements for them. And it does it in a few minutes, just needing regularly updated component pricing via a csv or similar.

      Then production planning software manages complex scheduling like the 2d and 3d cutting problems.

      Then machine specific software handles the rest.

       

      But for simple cases, in newer versions of Odoo, and possibly just enterprise, they allow a configuration spreadsheet at the sale to populate the sale. And they have a new Engineering to Order approach. I have two other smaller manufacturing for construction clients who had been using external tools wanting this investigated, but not started yet.

       

       

       

      On Thu, Dec 12, 2024 at 1:52 AM Ahmed Trigui <notifications@odoo-community.org> wrote:

      Hello community,

       

      I'm looking for a module to calculate awnings dimensions. 

       

      Is there any app which covers this need please ?

       

      Thank you!

       

      --

       

       

      Ahmed Trigui

      Conseiller Analyste fonctionnel

      +1 514-317-7944

      LinkedIn

      Twitter

      Facebook

      YouTube

       

       

       

      Nouveau
      Savez-vous tout sur l'open source ?

       

      Découvrir

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

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

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

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

      _______________________________________________
      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 johan - 03:41 - 13 Dec 2024
    • Re: Awnings dimensions app

      Le ven. 13 déc. 2024 à 12:29, David Beal <david.beal@akretion.com> a écrit :
      Hi Ahmed,

      You might consider taking a look here


      Let me know if you have any questions

      Regards

      David BEAL
      Consultant ERP Odoo


      Le ven. 13 déc. 2024 à 09:16, Johan Van Hirtum <notifications@odoo-community.org> a écrit :

      Thanks a lot for your answers, Graeme -)

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: Graeme Gellatly [mailto:notifications@odoo-community.org]
      Verzonden: donderdag 12 december 2024 11:54
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

      For the awning issue in particular, we used to do something similar in another system. You just end up making arbitrary distinctions in your variants. e.g. 500-1000mm W add $10, 1000-1500m add $20 and same for depth. I did that for 20 years and still have 1 customer doing like that. In fact even for all the advancement with DSL's etc mentioned above, 90% of pricing still internally follows that pattern. The main reason being is that other peoples systems can't handle truly dynamic dimensions at the invoice level and needs the arbitrary partcodes and distinctions.

       

      On Thu, Dec 12, 2024 at 11:36 PM Graeme Gellatly <graeme@moahub.nz> wrote:

      Well primarily i work with dimensioned products. Timber is actually a bit more complex because it is bought in cubes but sold in usually sizes x length.  I did that with variants and so.e customisation.

       

      But for basic things, if you consider a sale of a widget is 1 unit, then a sale of a dimensioned producy is 1 x 1.8 of something it is just one extra field or of 3d then d x w x h = v. If you need to record a whole list of things then say 4@ 4.8 6@3.2 adds up to roughly 38lm of something and can be held in a o2m on order line. All you are really manipulating is order qty.

       

      Le jeu. 12 déc. 2024, 21:57, Johan Van Hirtum <notifications@odoo-community.org> a écrit :

      Hi Graeme,

       

      Do you have or know about a module that let define dimensions on products and on variants ? Because most things with awnings can be done with variants ( fabric color, alu color, operation mode ) but there is no possibility to have an attribute that let you specify a dimension as an integer value. The same for products. In for example wood products, you sell pieces but the price is in meter and the length is a parameter you must provide. Sometimes you also have a product with fixed dimensions ( a profile or a plate ), price in m of m², where you can sell as a hole or cut to dimensions ( with sometimes an extra fee as % for cutting ). A solution for these situations would be all is needed I think for a lot of use cases.

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: Graeme Gellatly [mailto:notifications@odoo-community.org]
      Verzonden: woensdag 11 december 2024 20:58
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

      Hi,

       

      It doesn't really explain very well your question.

       

      Is it off plans, is it for pricing, is it for BoMs, for manufacturing machine integration e.g. CNC, is it the paper cutting problem, etc etc etc. I've done a lot of work in this space within custom MTO for manufacturing and pricing of construction materials. The 2 most difficult modules I used to maintain are mrp_dynamic_line (public, but always too risky/aggressive to be OCA) which calculates Production Orders dynamically from template attributes. The second is a DSL for managing the specification for a particular industry to do pricing, send to BoM (using dynamic_line and materials list from DSL, and does calculate all the dimensions) and api to manufacturing equipment on the SO Line which is private. The actual part of that module that handles the dimensions calculation is quite simple. It is just a one2many on sale order line with a few basic fields (and every similar model)

       

      Those between them + Odoo + OCA cover maybe 30% of the problem space.

       

      If it is custom MTO, then you also have a LOT of product code/cost/attribute/tracking/valuation considerations because every item at least in this case can have a different cost based on those DSL attributes with no real relation to any UoM concept. You need to avoid this if you can.

       

      Modern QS stuff, uses google earth to approximate dimension in brownfields, can read pdf plans, has onsite site measure functionality, produces necessary legal docs, quotes, 3d models etc, calculates angles and rakes, material specific things like can waste be reused elsewhere, environmental specific things like wind loading and engineering and legal requirements for them. And it does it in a few minutes, just needing regularly updated component pricing via a csv or similar.

      Then production planning software manages complex scheduling like the 2d and 3d cutting problems.

      Then machine specific software handles the rest.

       

      But for simple cases, in newer versions of Odoo, and possibly just enterprise, they allow a configuration spreadsheet at the sale to populate the sale. And they have a new Engineering to Order approach. I have two other smaller manufacturing for construction clients who had been using external tools wanting this investigated, but not started yet.

       

       

       

      On Thu, Dec 12, 2024 at 1:52 AM Ahmed Trigui <notifications@odoo-community.org> wrote:

      Hello community,

       

      I'm looking for a module to calculate awnings dimensions. 

       

      Is there any app which covers this need please ?

       

      Thank you!

       

      --

       

       

      Ahmed Trigui

      Conseiller Analyste fonctionnel

      +1 514-317-7944

      LinkedIn

      Twitter

      Facebook

      YouTube

       

       

       

      Nouveau
      Savez-vous tout sur l'open source ?

       

      Découvrir

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

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

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

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

      _______________________________________________
      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 - 02:01 - 13 Dec 2024
    • Re: Awnings dimensions app
      Hi Ahmed,

      You might consider taking a look here


      Let me know if you have any questions

      Regards

      David BEAL
      Consultant ERP Odoo


      Le ven. 13 déc. 2024 à 09:16, Johan Van Hirtum <notifications@odoo-community.org> a écrit :

      Thanks a lot for your answers, Graeme -)

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: Graeme Gellatly [mailto:notifications@odoo-community.org]
      Verzonden: donderdag 12 december 2024 11:54
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

      For the awning issue in particular, we used to do something similar in another system. You just end up making arbitrary distinctions in your variants. e.g. 500-1000mm W add $10, 1000-1500m add $20 and same for depth. I did that for 20 years and still have 1 customer doing like that. In fact even for all the advancement with DSL's etc mentioned above, 90% of pricing still internally follows that pattern. The main reason being is that other peoples systems can't handle truly dynamic dimensions at the invoice level and needs the arbitrary partcodes and distinctions.

       

      On Thu, Dec 12, 2024 at 11:36 PM Graeme Gellatly <graeme@moahub.nz> wrote:

      Well primarily i work with dimensioned products. Timber is actually a bit more complex because it is bought in cubes but sold in usually sizes x length.  I did that with variants and so.e customisation.

       

      But for basic things, if you consider a sale of a widget is 1 unit, then a sale of a dimensioned producy is 1 x 1.8 of something it is just one extra field or of 3d then d x w x h = v. If you need to record a whole list of things then say 4@ 4.8 6@3.2 adds up to roughly 38lm of something and can be held in a o2m on order line. All you are really manipulating is order qty.

       

      Le jeu. 12 déc. 2024, 21:57, Johan Van Hirtum <notifications@odoo-community.org> a écrit :

      Hi Graeme,

       

      Do you have or know about a module that let define dimensions on products and on variants ? Because most things with awnings can be done with variants ( fabric color, alu color, operation mode ) but there is no possibility to have an attribute that let you specify a dimension as an integer value. The same for products. In for example wood products, you sell pieces but the price is in meter and the length is a parameter you must provide. Sometimes you also have a product with fixed dimensions ( a profile or a plate ), price in m of m², where you can sell as a hole or cut to dimensions ( with sometimes an extra fee as % for cutting ). A solution for these situations would be all is needed I think for a lot of use cases.

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: Graeme Gellatly [mailto:notifications@odoo-community.org]
      Verzonden: woensdag 11 december 2024 20:58
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

      Hi,

       

      It doesn't really explain very well your question.

       

      Is it off plans, is it for pricing, is it for BoMs, for manufacturing machine integration e.g. CNC, is it the paper cutting problem, etc etc etc. I've done a lot of work in this space within custom MTO for manufacturing and pricing of construction materials. The 2 most difficult modules I used to maintain are mrp_dynamic_line (public, but always too risky/aggressive to be OCA) which calculates Production Orders dynamically from template attributes. The second is a DSL for managing the specification for a particular industry to do pricing, send to BoM (using dynamic_line and materials list from DSL, and does calculate all the dimensions) and api to manufacturing equipment on the SO Line which is private. The actual part of that module that handles the dimensions calculation is quite simple. It is just a one2many on sale order line with a few basic fields (and every similar model)

       

      Those between them + Odoo + OCA cover maybe 30% of the problem space.

       

      If it is custom MTO, then you also have a LOT of product code/cost/attribute/tracking/valuation considerations because every item at least in this case can have a different cost based on those DSL attributes with no real relation to any UoM concept. You need to avoid this if you can.

       

      Modern QS stuff, uses google earth to approximate dimension in brownfields, can read pdf plans, has onsite site measure functionality, produces necessary legal docs, quotes, 3d models etc, calculates angles and rakes, material specific things like can waste be reused elsewhere, environmental specific things like wind loading and engineering and legal requirements for them. And it does it in a few minutes, just needing regularly updated component pricing via a csv or similar.

      Then production planning software manages complex scheduling like the 2d and 3d cutting problems.

      Then machine specific software handles the rest.

       

      But for simple cases, in newer versions of Odoo, and possibly just enterprise, they allow a configuration spreadsheet at the sale to populate the sale. And they have a new Engineering to Order approach. I have two other smaller manufacturing for construction clients who had been using external tools wanting this investigated, but not started yet.

       

       

       

      On Thu, Dec 12, 2024 at 1:52 AM Ahmed Trigui <notifications@odoo-community.org> wrote:

      Hello community,

       

      I'm looking for a module to calculate awnings dimensions. 

       

      Is there any app which covers this need please ?

       

      Thank you!

       

      --

       

       

      Ahmed Trigui

      Conseiller Analyste fonctionnel

      +1 514-317-7944

      LinkedIn

      Twitter

      Facebook

      YouTube

       

       

       

      Nouveau
      Savez-vous tout sur l'open source ?

       

      Découvrir

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

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

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

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

      _______________________________________________
      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 - 12:30 - 13 Dec 2024
    • RE: Awnings dimensions app

      Thanks a lot for your answers, Graeme -)

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: Graeme Gellatly [mailto:notifications@odoo-community.org]
      Verzonden: donderdag 12 december 2024 11:54
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

      For the awning issue in particular, we used to do something similar in another system. You just end up making arbitrary distinctions in your variants. e.g. 500-1000mm W add $10, 1000-1500m add $20 and same for depth. I did that for 20 years and still have 1 customer doing like that. In fact even for all the advancement with DSL's etc mentioned above, 90% of pricing still internally follows that pattern. The main reason being is that other peoples systems can't handle truly dynamic dimensions at the invoice level and needs the arbitrary partcodes and distinctions.

       

      On Thu, Dec 12, 2024 at 11:36 PM Graeme Gellatly <graeme@moahub.nz> wrote:

      Well primarily i work with dimensioned products. Timber is actually a bit more complex because it is bought in cubes but sold in usually sizes x length.  I did that with variants and so.e customisation.

       

      But for basic things, if you consider a sale of a widget is 1 unit, then a sale of a dimensioned producy is 1 x 1.8 of something it is just one extra field or of 3d then d x w x h = v. If you need to record a whole list of things then say 4@ 4.8 6@3.2 adds up to roughly 38lm of something and can be held in a o2m on order line. All you are really manipulating is order qty.

       

      Le jeu. 12 déc. 2024, 21:57, Johan Van Hirtum <notifications@odoo-community.org> a écrit :

      Hi Graeme,

       

      Do you have or know about a module that let define dimensions on products and on variants ? Because most things with awnings can be done with variants ( fabric color, alu color, operation mode ) but there is no possibility to have an attribute that let you specify a dimension as an integer value. The same for products. In for example wood products, you sell pieces but the price is in meter and the length is a parameter you must provide. Sometimes you also have a product with fixed dimensions ( a profile or a plate ), price in m of m², where you can sell as a hole or cut to dimensions ( with sometimes an extra fee as % for cutting ). A solution for these situations would be all is needed I think for a lot of use cases.

       

      With kind regards,

       

      Van Hirtum Johan

       

      Van: Graeme Gellatly [mailto:notifications@odoo-community.org]
      Verzonden: woensdag 11 december 2024 20:58
      Aan: Contributors
      Onderwerp: Re: Awnings dimensions app

       

      Hi,

       

      It doesn't really explain very well your question.

       

      Is it off plans, is it for pricing, is it for BoMs, for manufacturing machine integration e.g. CNC, is it the paper cutting problem, etc etc etc. I've done a lot of work in this space within custom MTO for manufacturing and pricing of construction materials. The 2 most difficult modules I used to maintain are mrp_dynamic_line (public, but always too risky/aggressive to be OCA) which calculates Production Orders dynamically from template attributes. The second is a DSL for managing the specification for a particular industry to do pricing, send to BoM (using dynamic_line and materials list from DSL, and does calculate all the dimensions) and api to manufacturing equipment on the SO Line which is private. The actual part of that module that handles the dimensions calculation is quite simple. It is just a one2many on sale order line with a few basic fields (and every similar model)

       

      Those between them + Odoo + OCA cover maybe 30% of the problem space.

       

      If it is custom MTO, then you also have a LOT of product code/cost/attribute/tracking/valuation considerations because every item at least in this case can have a different cost based on those DSL attributes with no real relation to any UoM concept. You need to avoid this if you can.

       

      Modern QS stuff, uses google earth to approximate dimension in brownfields, can read pdf plans, has onsite site measure functionality, produces necessary legal docs, quotes, 3d models etc, calculates angles and rakes, material specific things like can waste be reused elsewhere, environmental specific things like wind loading and engineering and legal requirements for them. And it does it in a few minutes, just needing regularly updated component pricing via a csv or similar.

      Then production planning software manages complex scheduling like the 2d and 3d cutting problems.

      Then machine specific software handles the rest.

       

      But for simple cases, in newer versions of Odoo, and possibly just enterprise, they allow a configuration spreadsheet at the sale to populate the sale. And they have a new Engineering to Order approach. I have two other smaller manufacturing for construction clients who had been using external tools wanting this investigated, but not started yet.

       

       

       

      On Thu, Dec 12, 2024 at 1:52 AM Ahmed Trigui <notifications@odoo-community.org> wrote:

      Hello community,

       

      I'm looking for a module to calculate awnings dimensions. 

       

      Is there any app which covers this need please ?

       

      Thank you!

       

      --

       

       

      Ahmed Trigui

      Conseiller Analyste fonctionnel

      +1 514-317-7944

      LinkedIn

      Twitter

      Facebook

      YouTube

       

       

       

      Nouveau
      Savez-vous tout sur l'open source ?

       

      Découvrir

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

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

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

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

      by johan - 09:15 - 13 Dec 2024
    • Re: Awnings dimensions app
      If they do not want to go live without it, you should workshop to make them construct the budget for multiple awning contracts using standard Odoo, and develop a price for the "Configurator".  Make sure you allow for multiple rewrites.It is really a good job for Excel with a structured handoff to Odoo.  You should have a good estimate of fabric and a degree of difficulty (simple, average, above average, very hard awning design) as a way of budgeting for the rest.  Put the logic in Excel that a company subject-matter expert owns and define the hand-offs in terms of the product defs and BOMs.  KEEP IT SIMPLE, SIMPLE, SIMPLE as possible. And if you can, do not do it because you will have many other things more important to a good project.

      I have seen companies spend millions trying to put a product configurator into the ERP (SAP) only to find that they lost all flexibility in their business processes. If you can get the job done with an Excel spreadsheet, I would want to call that "Phase 1 Complete" and come back to it a year from now.  You may find they never ask for it again.

      One important guideline is to avoid making anything that is more complicated than what your company does today, at least until they know Odoo and can help design it.

      On Thu, Dec 12, 2024 at 8:42 AM Adam Heinz <notifications@odoo-community.org> wrote:
      On Thu, Dec 12, 2024 at 5:53 AM Graeme Gellatly <notifications@odoo-community.org> wrote:
      For the awning issue in particular, we used to do something similar in another system. You just end up making arbitrary distinctions in your variants. e.g. 500-1000mm W add $10, 1000-1500m add $20 and same for depth. I did that for 20 years and still have 1 customer doing like that. In fact even for all the advancement with DSL's etc mentioned above, 90% of pricing still internally follows that pattern. The main reason being is that other peoples systems can't handle truly dynamic dimensions at the invoice level and needs the arbitrary partcodes and distinctions.

      Our manufacturers price their products in size buckets as you describe above, but we order bespoke products with precise measurements.
       
      Le jeu. 12 déc. 2024, 21:57, Johan Van Hirtum <notifications@odoo-community.org> a écrit :

      Do you have or know about a module that let define dimensions on products and on variants ? Because most things with awnings can be done with variants ( fabric color, alu color, operation mode ) but there is no possibility to have an attribute that let you specify a dimension as an integer value. The same for products. In for example wood products, you sell pieces but the price is in meter and the length is a parameter you must provide. Sometimes you also have a product with fixed dimensions ( a profile or a plate ), price in m of m², where you can sell as a hole or cut to dimensions ( with sometimes an extra fee as % for cutting ). A solution for these situations would be all is needed I think for a lot of use cases.

      Have you experimented with the sale_product_configurator module and the product.attribute.custom.value model?

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

      by joel.patrick - 03:36 - 12 Dec 2024

  • "The plan" to help non technical to contribute documentation on OCA modules
    Hello,

    This is a followup email for this email thread:

    During the 2024 OCA Days, the OCA Consultants working group presented the status of the Documentation project: how to document OCA modules right now (using the Github workflow) with Julie and Florencia (video here: https://youtu.be/Kw0V_PdBUPg?feature=shared).

    In parallel, a prototype of a new tool and process to easily document OCA modules has been proposed by Jairo Llopis, after discussion with Stéphane Bidoul to take into account the full picture of OCA infrastructure.

    The goal of this new way of managing the documentation is two-fold:
    1. Allow consultants to update the documentation in a user-friendly tool
    2. Have a beautiful website with a good search features to find and read the OCA modules documentation

    This will impact the way the documentation is managed in the OCA modules. In summary, the documentation of all the OCA modules will be visible on a dedicated website, that will in the end of the transition replace the current OCA App Store. The documentation itself will be stored in a dedicated Doc repository (https://github.com/OCA/docs) and be removed from the readmes of the modules (where a link to the dedicated website will be displayed). Finally, there will be only one documentation page for all the versions of one module.

    The next steps are gathered in an issue on Github, called "the plan". Here it is:

    To get more information about this, please check the link above. You can also read the latest meeting notes of the Consultants meeting held in November here: https://docs.google.com/document/d/1v23TwOwm9I7w3MNFZo-iCWQxVKedwoVzN9nEyflJVd8/edit?usp=sharing

    If you want to share your feedback on this topic, I propose to keep it in the related issue on Github:

    Thanks a lot to the consultants working group and especially to Jairo and Stéphane for their help! As you'll see in the plan, there are many "todo"s and help is always welcome.

    All the best,
    Virginie Dewulf
    Executive Director
    +32 477 64 17 20
    by Virginie Dewulf (OCA) - 02:26 - 10 Dec 2024

    15 replies 15 replies

    • Re: "The plan" to help non technical to contribute documentation on OCA modules
      In the Odoo eco-system are there Functionals (as opposed to Technicals)?  That seems to be the way ERP works. Non-technicals = functionals? 

      Is there an open source model where the doc could be a model? Hadoop, ERPNext, …? How important is the governance model for good docs? more or less important than Wikipedia, for example?

      Best,
      JP
      On Wed, Jan 15, 2025 at 10:12 AM Francesco Foresti <notifications@odoo-community.org> wrote:
      Hi all, 

      regarding Simone's proposal: 

      "In order to fix this, and only this, there was one proposal that I did like at that table: add a button in the README that pops up an editor and lets functional people edit the README and seamlessly create a PR."

      In your opinion, would that be an acceptable first step that could be implemented relatively quickly?

      Cheers

      Francesco

      Il giorno gio 2 gen 2025 alle ore 11:37 Simone Rubino <notifications@odoo-community.org> ha scritto:
      Thanks Jairo for this extensive explanation of pros and cons, and the examples.
      I was at that table during the OCA days: I was not entirely convinced then as I'm not entirely convinced right now.
      I also tried a prototype of this new workflow and I can say that you and others put a lot of effort into it for sure, thanks again for that.

      In my opinion the new workflow is trying to fix many problems all at once, but I think that we should keep the focus on the one problem at hand:
      Allow consultants to update the documentation in a user-friendly tool
      and then move to others because it's easier to agree on fewer things at a time.

      As you explained, there are multiple issues right now:
      • functionals are not able to easily update the README of a module
      • a module has a different README in each version
      • migrations do not update the README properly
      • translations in README can't be done
      I think that right now we should focus on letting functional people update a module documentation (README) easily, let's try to solve only this problem first, then move to others.

      In order to fix this, and only this, there was one proposal that I did like at that table: add a button in the README that pops up an editor and lets functional people edit the README and seamlessly create a PR.
      It was discarded then because it did not solve version misalignment but that should be another step towards the ultimate documentation solution.
      I think this would be much easier to implement and roll out because it does not need a new repo or a new docs database because everything would be on the fly.

      On a side note, what about moving to a discussion in https://github.com/orgs/OCA/discussions? I think it would be easier to edit/manage/reply-to than emails.

      On Thu, 2 Jan 2025 at 10:37, Jairo Llopis <notifications@odoo-community.org> wrote:
      Hi everyone!

      IMHO both controversial points, when applied together, reduce the pain that we currently have.

      Some current facts:
      • Current OCA docs (aka READMEs) are not always updated.
      • Functional contributors have a very hard time at contributing to those docs.
      • Maintaining version divergences is already very hard for technicians. Asking functionals to do that is a big part of the current problem.
      • When thinking of a new docs system, we have to think about who will write the docs and who will read them.
      • Data duplication is not good for SEO.
      • We want good, up-to-date docs.
      So, let's say that we keep the current status quo. We just teach functionals how to use git, write good commit messages, write markdown, use github, switch between branches, do a rebase every now and then, and we expect them to update the readmes. And let's imagine for a second that this happens.

      Now they have a task: update docs for 10 modules, across all the 3 versions maintained in their companies. Many OCA contributors just use even Odoo releases, so those versions might be 14.0, 16.0 and 18.0.

      Now just do the math: 10 modules x 3 versions = 30 READMEs. With the new system, 10 modules x 1 single doc = 10 REAMEs to update. Conclusion: 1 single doc is more maintainable. And still, versions 15.0 and 17.0 would be forgotten with the older system, while with the newer one they'd also get those changes.

      I was sitting down at the table with the functional people expressing how difficult it is for them to contribute to OCA. At the same table were some very experienced contributors, including OCA Board members. We're trying to improve a problematic situation we have right now. Of course, current controversies came to the table. Some of our thoughts:
      • Is it really that important that the screenshots you see are for the same version of the module that you're using?
        • No. Many times, modules are migrated and screenshots are not updated. As long as the module works  mostly the same, it's good enough.
        • Besides, you can have a custom theme. Or even you could use Odoo EE and all your UI will be different.
      • Is it really that common that modules behave significantly different between versions?
        • It happens, but it's the less common case.
      So, if we favor the most common case (the module does mostly the same across versions) and still have a way to handle the least common one (significant UX divergences), we still are winning.

      So, are we really crazy to tell you that we can maintain a single doc? Let's see how others do it.

      When I think of good docs, I think of Gitlab. Their docs are awesome. How do they handle the different versions? I'll showcase some examples below, so we can learn from them. FWIW I'm currently browsing the latest Gitlab docs, which officially target v17.8. Also FWIW, they have a version dropdown. I used Gitlab for about 10 years and I never had to click that dropdown.

      These install instructions will tell you which postgres version to use. They have several gitlab flavors, and they maintain 4 major releases. However, all the info is gathered in a single docs page:
      image.png

      Now, think about it. Is it easier for a writer (who is not a programmer) to maintain 4 different branches of docs with different installation instructions? Or just to maintain the latest one, which has a table indicating data for all versions? Of course, the latter.

      How do they handle feature changes? See:
      image.png

      Again, if you're using Gitlab 16.0, it's still better for you to read these docs than the docs for 16.0, because you don't only know how it works, but how it has evolved since the version you're using. This helps you prepare for that. As a docs reader, this structure is way better. For a writer it's also easier to maintain.

      Now, let's think about deprecations and removals. They have a page dedicated to that. Currently I'm browsing docs for v17.8, but I can see info for past and future versions (up to Gitlab 20.0!). Future versions! Of course! It's relevant for me to know if something will be deprecated, even if it still works. Brilliant.

      Apart from that, deprecated features still have a red warning about their status. One example:
      image.png

      The fact that docs are centralized isn't a big problem IMHO. If you need offline access, you can clone the repo and browse those docs offline. And the fact that the module docs are scattered across various places (oca/docs and the module code) would be "less worse" than having to maintain up-to-date per-version readmes.

      An extra point of having centralized docs is that you can exit the current constraints of "just a readme per module", and start having use-case-based docs. Imagine a webpage where you can explain how to use OCA for having better inventory management, for boosting sales, for better privacy, etc. An use-case-based page can just link to the individual modules needed to get that use case done. That's impossible with the current structure.

      So, summarizing:
      • Current workflow
      1. Is easy to "fire and forget". You push the module, it has the readme, it works, done. Never look back. Yes, we knew that taking technicals out of something comfortable for them would produce these kinds of reactions.
      2. When you migrate a module, most times docs are not updated accordingly.
      3. Has everything self-contained.
      4. Is per-version.
      5. Is hard to maintain. As a consequence, it's not properly maintained.
      6. It's impossible to use by functionals. Thus, writing docs is an extra burden almost exclusively on the shoulders of coders.
      7. Docs are written by whoever wrote the module. Sadly, this impacts negatively on the quality of the docs. They communicate with more technical words. Maintaining videos and pictures is burdensome for them.
      8. Translating is impossible.
      9. Merging changes involves irrelevant nitpickings (commit message, formatting, etc.)
      •  New workflow:
      1. Can be equally easy when adding a new module (due to a sync that could import that readme as the starting docs for the module). When adding a new feature, it can involve adding another PR to docs. That PR, however, doesn't have to be done by the programmer.
      2. When migrating a module, if it behaves the same, there'll be nothing to be done. Otherwise, see point 1.
      3. Docs centralized.
      4. Single page. Relevant per-version changes kept on the same page.
      5. Easier to maintain. As a consequence, they'll have more maintenance.
      6. Functionals can learn to contribute in a 5-minutes video. Less copywriting burden for coders.
      7. Docs are written by people that use the module. They communicate without technicisms. They value pictures and videos as that's their daily life. Docs quality will be better.
      8. Translating is possible (not yet in the MVP, before you ask).
      9. Functionals can merge without nitpicks. Reviews are done purely visually. The outcome is an SSG with very little attack surface. Git is just a DB.
      The new workflow is not perfect, and it might require an extra PR every now and then. However, IMHO it opens many doors for improvement that are currently closed.

      Many have predicted "catastrophes" with this idea. However, it's good to reflect on the pain points we currently have. Why not also try to predict how much better this would be? When I think about it, I see it's worth trying.

      _______________________________________________



      --

      Francesco Foresti
      Sicurpharma Srl
      +39 333 8123 790

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

      by joel.patrick - 04:35 - 16 Jan 2025
    • Re: "The plan" to help non technical to contribute documentation on OCA modules
      Hi all, 

      regarding Simone's proposal: 

      "In order to fix this, and only this, there was one proposal that I did like at that table: add a button in the README that pops up an editor and lets functional people edit the README and seamlessly create a PR."

      In your opinion, would that be an acceptable first step that could be implemented relatively quickly?

      Cheers

      Francesco

      Il giorno gio 2 gen 2025 alle ore 11:37 Simone Rubino <notifications@odoo-community.org> ha scritto:
      Thanks Jairo for this extensive explanation of pros and cons, and the examples.
      I was at that table during the OCA days: I was not entirely convinced then as I'm not entirely convinced right now.
      I also tried a prototype of this new workflow and I can say that you and others put a lot of effort into it for sure, thanks again for that.

      In my opinion the new workflow is trying to fix many problems all at once, but I think that we should keep the focus on the one problem at hand:
      Allow consultants to update the documentation in a user-friendly tool
      and then move to others because it's easier to agree on fewer things at a time.

      As you explained, there are multiple issues right now:
      • functionals are not able to easily update the README of a module
      • a module has a different README in each version
      • migrations do not update the README properly
      • translations in README can't be done
      I think that right now we should focus on letting functional people update a module documentation (README) easily, let's try to solve only this problem first, then move to others.

      In order to fix this, and only this, there was one proposal that I did like at that table: add a button in the README that pops up an editor and lets functional people edit the README and seamlessly create a PR.
      It was discarded then because it did not solve version misalignment but that should be another step towards the ultimate documentation solution.
      I think this would be much easier to implement and roll out because it does not need a new repo or a new docs database because everything would be on the fly.

      On a side note, what about moving to a discussion in https://github.com/orgs/OCA/discussions? I think it would be easier to edit/manage/reply-to than emails.

      On Thu, 2 Jan 2025 at 10:37, Jairo Llopis <notifications@odoo-community.org> wrote:
      Hi everyone!

      IMHO both controversial points, when applied together, reduce the pain that we currently have.

      Some current facts:
      • Current OCA docs (aka READMEs) are not always updated.
      • Functional contributors have a very hard time at contributing to those docs.
      • Maintaining version divergences is already very hard for technicians. Asking functionals to do that is a big part of the current problem.
      • When thinking of a new docs system, we have to think about who will write the docs and who will read them.
      • Data duplication is not good for SEO.
      • We want good, up-to-date docs.
      So, let's say that we keep the current status quo. We just teach functionals how to use git, write good commit messages, write markdown, use github, switch between branches, do a rebase every now and then, and we expect them to update the readmes. And let's imagine for a second that this happens.

      Now they have a task: update docs for 10 modules, across all the 3 versions maintained in their companies. Many OCA contributors just use even Odoo releases, so those versions might be 14.0, 16.0 and 18.0.

      Now just do the math: 10 modules x 3 versions = 30 READMEs. With the new system, 10 modules x 1 single doc = 10 REAMEs to update. Conclusion: 1 single doc is more maintainable. And still, versions 15.0 and 17.0 would be forgotten with the older system, while with the newer one they'd also get those changes.

      I was sitting down at the table with the functional people expressing how difficult it is for them to contribute to OCA. At the same table were some very experienced contributors, including OCA Board members. We're trying to improve a problematic situation we have right now. Of course, current controversies came to the table. Some of our thoughts:
      • Is it really that important that the screenshots you see are for the same version of the module that you're using?
        • No. Many times, modules are migrated and screenshots are not updated. As long as the module works  mostly the same, it's good enough.
        • Besides, you can have a custom theme. Or even you could use Odoo EE and all your UI will be different.
      • Is it really that common that modules behave significantly different between versions?
        • It happens, but it's the less common case.
      So, if we favor the most common case (the module does mostly the same across versions) and still have a way to handle the least common one (significant UX divergences), we still are winning.

      So, are we really crazy to tell you that we can maintain a single doc? Let's see how others do it.

      When I think of good docs, I think of Gitlab. Their docs are awesome. How do they handle the different versions? I'll showcase some examples below, so we can learn from them. FWIW I'm currently browsing the latest Gitlab docs, which officially target v17.8. Also FWIW, they have a version dropdown. I used Gitlab for about 10 years and I never had to click that dropdown.

      These install instructions will tell you which postgres version to use. They have several gitlab flavors, and they maintain 4 major releases. However, all the info is gathered in a single docs page:
      image.png

      Now, think about it. Is it easier for a writer (who is not a programmer) to maintain 4 different branches of docs with different installation instructions? Or just to maintain the latest one, which has a table indicating data for all versions? Of course, the latter.

      How do they handle feature changes? See:
      image.png

      Again, if you're using Gitlab 16.0, it's still better for you to read these docs than the docs for 16.0, because you don't only know how it works, but how it has evolved since the version you're using. This helps you prepare for that. As a docs reader, this structure is way better. For a writer it's also easier to maintain.

      Now, let's think about deprecations and removals. They have a page dedicated to that. Currently I'm browsing docs for v17.8, but I can see info for past and future versions (up to Gitlab 20.0!). Future versions! Of course! It's relevant for me to know if something will be deprecated, even if it still works. Brilliant.

      Apart from that, deprecated features still have a red warning about their status. One example:
      image.png

      The fact that docs are centralized isn't a big problem IMHO. If you need offline access, you can clone the repo and browse those docs offline. And the fact that the module docs are scattered across various places (oca/docs and the module code) would be "less worse" than having to maintain up-to-date per-version readmes.

      An extra point of having centralized docs is that you can exit the current constraints of "just a readme per module", and start having use-case-based docs. Imagine a webpage where you can explain how to use OCA for having better inventory management, for boosting sales, for better privacy, etc. An use-case-based page can just link to the individual modules needed to get that use case done. That's impossible with the current structure.

      So, summarizing:
      • Current workflow
      1. Is easy to "fire and forget". You push the module, it has the readme, it works, done. Never look back. Yes, we knew that taking technicals out of something comfortable for them would produce these kinds of reactions.
      2. When you migrate a module, most times docs are not updated accordingly.
      3. Has everything self-contained.
      4. Is per-version.
      5. Is hard to maintain. As a consequence, it's not properly maintained.
      6. It's impossible to use by functionals. Thus, writing docs is an extra burden almost exclusively on the shoulders of coders.
      7. Docs are written by whoever wrote the module. Sadly, this impacts negatively on the quality of the docs. They communicate with more technical words. Maintaining videos and pictures is burdensome for them.
      8. Translating is impossible.
      9. Merging changes involves irrelevant nitpickings (commit message, formatting, etc.)
      •  New workflow:
      1. Can be equally easy when adding a new module (due to a sync that could import that readme as the starting docs for the module). When adding a new feature, it can involve adding another PR to docs. That PR, however, doesn't have to be done by the programmer.
      2. When migrating a module, if it behaves the same, there'll be nothing to be done. Otherwise, see point 1.
      3. Docs centralized.
      4. Single page. Relevant per-version changes kept on the same page.
      5. Easier to maintain. As a consequence, they'll have more maintenance.
      6. Functionals can learn to contribute in a 5-minutes video. Less copywriting burden for coders.
      7. Docs are written by people that use the module. They communicate without technicisms. They value pictures and videos as that's their daily life. Docs quality will be better.
      8. Translating is possible (not yet in the MVP, before you ask).
      9. Functionals can merge without nitpicks. Reviews are done purely visually. The outcome is an SSG with very little attack surface. Git is just a DB.
      The new workflow is not perfect, and it might require an extra PR every now and then. However, IMHO it opens many doors for improvement that are currently closed.

      Many have predicted "catastrophes" with this idea. However, it's good to reflect on the pain points we currently have. Why not also try to predict how much better this would be? When I think about it, I see it's worth trying.

      _______________________________________________
      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



      --

      Francesco Foresti
      Sicurpharma Srl
      +39 333 8123 790
      by Francesco Foresti - 04:11 - 15 Jan 2025
    • Re: "The plan" to help non technical to contribute documentation on OCA modules
      Thanks Jairo for this extensive explanation of pros and cons, and the examples.
      I was at that table during the OCA days: I was not entirely convinced then as I'm not entirely convinced right now.
      I also tried a prototype of this new workflow and I can say that you and others put a lot of effort into it for sure, thanks again for that.

      In my opinion the new workflow is trying to fix many problems all at once, but I think that we should keep the focus on the one problem at hand:
      Allow consultants to update the documentation in a user-friendly tool
      and then move to others because it's easier to agree on fewer things at a time.

      As you explained, there are multiple issues right now:
      • functionals are not able to easily update the README of a module
      • a module has a different README in each version
      • migrations do not update the README properly
      • translations in README can't be done
      I think that right now we should focus on letting functional people update a module documentation (README) easily, let's try to solve only this problem first, then move to others.

      In order to fix this, and only this, there was one proposal that I did like at that table: add a button in the README that pops up an editor and lets functional people edit the README and seamlessly create a PR.
      It was discarded then because it did not solve version misalignment but that should be another step towards the ultimate documentation solution.
      I think this would be much easier to implement and roll out because it does not need a new repo or a new docs database because everything would be on the fly.

      On a side note, what about moving to a discussion in https://github.com/orgs/OCA/discussions? I think it would be easier to edit/manage/reply-to than emails.

      On Thu, 2 Jan 2025 at 10:37, Jairo Llopis <notifications@odoo-community.org> wrote:
      Hi everyone!

      IMHO both controversial points, when applied together, reduce the pain that we currently have.

      Some current facts:
      • Current OCA docs (aka READMEs) are not always updated.
      • Functional contributors have a very hard time at contributing to those docs.
      • Maintaining version divergences is already very hard for technicians. Asking functionals to do that is a big part of the current problem.
      • When thinking of a new docs system, we have to think about who will write the docs and who will read them.
      • Data duplication is not good for SEO.
      • We want good, up-to-date docs.
      So, let's say that we keep the current status quo. We just teach functionals how to use git, write good commit messages, write markdown, use github, switch between branches, do a rebase every now and then, and we expect them to update the readmes. And let's imagine for a second that this happens.

      Now they have a task: update docs for 10 modules, across all the 3 versions maintained in their companies. Many OCA contributors just use even Odoo releases, so those versions might be 14.0, 16.0 and 18.0.

      Now just do the math: 10 modules x 3 versions = 30 READMEs. With the new system, 10 modules x 1 single doc = 10 REAMEs to update. Conclusion: 1 single doc is more maintainable. And still, versions 15.0 and 17.0 would be forgotten with the older system, while with the newer one they'd also get those changes.

      I was sitting down at the table with the functional people expressing how difficult it is for them to contribute to OCA. At the same table were some very experienced contributors, including OCA Board members. We're trying to improve a problematic situation we have right now. Of course, current controversies came to the table. Some of our thoughts:
      • Is it really that important that the screenshots you see are for the same version of the module that you're using?
        • No. Many times, modules are migrated and screenshots are not updated. As long as the module works  mostly the same, it's good enough.
        • Besides, you can have a custom theme. Or even you could use Odoo EE and all your UI will be different.
      • Is it really that common that modules behave significantly different between versions?
        • It happens, but it's the less common case.
      So, if we favor the most common case (the module does mostly the same across versions) and still have a way to handle the least common one (significant UX divergences), we still are winning.

      So, are we really crazy to tell you that we can maintain a single doc? Let's see how others do it.

      When I think of good docs, I think of Gitlab. Their docs are awesome. How do they handle the different versions? I'll showcase some examples below, so we can learn from them. FWIW I'm currently browsing the latest Gitlab docs, which officially target v17.8. Also FWIW, they have a version dropdown. I used Gitlab for about 10 years and I never had to click that dropdown.

      These install instructions will tell you which postgres version to use. They have several gitlab flavors, and they maintain 4 major releases. However, all the info is gathered in a single docs page:
      image.png

      Now, think about it. Is it easier for a writer (who is not a programmer) to maintain 4 different branches of docs with different installation instructions? Or just to maintain the latest one, which has a table indicating data for all versions? Of course, the latter.

      How do they handle feature changes? See:
      image.png

      Again, if you're using Gitlab 16.0, it's still better for you to read these docs than the docs for 16.0, because you don't only know how it works, but how it has evolved since the version you're using. This helps you prepare for that. As a docs reader, this structure is way better. For a writer it's also easier to maintain.

      Now, let's think about deprecations and removals. They have a page dedicated to that. Currently I'm browsing docs for v17.8, but I can see info for past and future versions (up to Gitlab 20.0!). Future versions! Of course! It's relevant for me to know if something will be deprecated, even if it still works. Brilliant.

      Apart from that, deprecated features still have a red warning about their status. One example:
      image.png

      The fact that docs are centralized isn't a big problem IMHO. If you need offline access, you can clone the repo and browse those docs offline. And the fact that the module docs are scattered across various places (oca/docs and the module code) would be "less worse" than having to maintain up-to-date per-version readmes.

      An extra point of having centralized docs is that you can exit the current constraints of "just a readme per module", and start having use-case-based docs. Imagine a webpage where you can explain how to use OCA for having better inventory management, for boosting sales, for better privacy, etc. An use-case-based page can just link to the individual modules needed to get that use case done. That's impossible with the current structure.

      So, summarizing:
      • Current workflow
      1. Is easy to "fire and forget". You push the module, it has the readme, it works, done. Never look back. Yes, we knew that taking technicals out of something comfortable for them would produce these kinds of reactions.
      2. When you migrate a module, most times docs are not updated accordingly.
      3. Has everything self-contained.
      4. Is per-version.
      5. Is hard to maintain. As a consequence, it's not properly maintained.
      6. It's impossible to use by functionals. Thus, writing docs is an extra burden almost exclusively on the shoulders of coders.
      7. Docs are written by whoever wrote the module. Sadly, this impacts negatively on the quality of the docs. They communicate with more technical words. Maintaining videos and pictures is burdensome for them.
      8. Translating is impossible.
      9. Merging changes involves irrelevant nitpickings (commit message, formatting, etc.)
      •  New workflow:
      1. Can be equally easy when adding a new module (due to a sync that could import that readme as the starting docs for the module). When adding a new feature, it can involve adding another PR to docs. That PR, however, doesn't have to be done by the programmer.
      2. When migrating a module, if it behaves the same, there'll be nothing to be done. Otherwise, see point 1.
      3. Docs centralized.
      4. Single page. Relevant per-version changes kept on the same page.
      5. Easier to maintain. As a consequence, they'll have more maintenance.
      6. Functionals can learn to contribute in a 5-minutes video. Less copywriting burden for coders.
      7. Docs are written by people that use the module. They communicate without technicisms. They value pictures and videos as that's their daily life. Docs quality will be better.
      8. Translating is possible (not yet in the MVP, before you ask).
      9. Functionals can merge without nitpicks. Reviews are done purely visually. The outcome is an SSG with very little attack surface. Git is just a DB.
      The new workflow is not perfect, and it might require an extra PR every now and then. However, IMHO it opens many doors for improvement that are currently closed.

      Many have predicted "catastrophes" with this idea. However, it's good to reflect on the pain points we currently have. Why not also try to predict how much better this would be? When I think about it, I see it's worth trying.

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

      by Simone Rubino. - 11:36 - 2 Jan 2025
    • Re: "The plan" to help non technical to contribute documentation on OCA modules
      Hi everyone!

      IMHO both controversial points, when applied together, reduce the pain that we currently have.

      Some current facts:
      • Current OCA docs (aka READMEs) are not always updated.
      • Functional contributors have a very hard time at contributing to those docs.
      • Maintaining version divergences is already very hard for technicians. Asking functionals to do that is a big part of the current problem.
      • When thinking of a new docs system, we have to think about who will write the docs and who will read them.
      • Data duplication is not good for SEO.
      • We want good, up-to-date docs.
      So, let's say that we keep the current status quo. We just teach functionals how to use git, write good commit messages, write markdown, use github, switch between branches, do a rebase every now and then, and we expect them to update the readmes. And let's imagine for a second that this happens.

      Now they have a task: update docs for 10 modules, across all the 3 versions maintained in their companies. Many OCA contributors just use even Odoo releases, so those versions might be 14.0, 16.0 and 18.0.

      Now just do the math: 10 modules x 3 versions = 30 READMEs. With the new system, 10 modules x 1 single doc = 10 REAMEs to update. Conclusion: 1 single doc is more maintainable. And still, versions 15.0 and 17.0 would be forgotten with the older system, while with the newer one they'd also get those changes.

      I was sitting down at the table with the functional people expressing how difficult it is for them to contribute to OCA. At the same table were some very experienced contributors, including OCA Board members. We're trying to improve a problematic situation we have right now. Of course, current controversies came to the table. Some of our thoughts:
      • Is it really that important that the screenshots you see are for the same version of the module that you're using?
        • No. Many times, modules are migrated and screenshots are not updated. As long as the module works  mostly the same, it's good enough.
        • Besides, you can have a custom theme. Or even you could use Odoo EE and all your UI will be different.
      • Is it really that common that modules behave significantly different between versions?
        • It happens, but it's the less common case.
      So, if we favor the most common case (the module does mostly the same across versions) and still have a way to handle the least common one (significant UX divergences), we still are winning.

      So, are we really crazy to tell you that we can maintain a single doc? Let's see how others do it.

      When I think of good docs, I think of Gitlab. Their docs are awesome. How do they handle the different versions? I'll showcase some examples below, so we can learn from them. FWIW I'm currently browsing the latest Gitlab docs, which officially target v17.8. Also FWIW, they have a version dropdown. I used Gitlab for about 10 years and I never had to click that dropdown.

      These install instructions will tell you which postgres version to use. They have several gitlab flavors, and they maintain 4 major releases. However, all the info is gathered in a single docs page:
      image.png

      Now, think about it. Is it easier for a writer (who is not a programmer) to maintain 4 different branches of docs with different installation instructions? Or just to maintain the latest one, which has a table indicating data for all versions? Of course, the latter.

      How do they handle feature changes? See:
      image.png

      Again, if you're using Gitlab 16.0, it's still better for you to read these docs than the docs for 16.0, because you don't only know how it works, but how it has evolved since the version you're using. This helps you prepare for that. As a docs reader, this structure is way better. For a writer it's also easier to maintain.

      Now, let's think about deprecations and removals. They have a page dedicated to that. Currently I'm browsing docs for v17.8, but I can see info for past and future versions (up to Gitlab 20.0!). Future versions! Of course! It's relevant for me to know if something will be deprecated, even if it still works. Brilliant.

      Apart from that, deprecated features still have a red warning about their status. One example:
      image.png

      The fact that docs are centralized isn't a big problem IMHO. If you need offline access, you can clone the repo and browse those docs offline. And the fact that the module docs are scattered across various places (oca/docs and the module code) would be "less worse" than having to maintain up-to-date per-version readmes.

      An extra point of having centralized docs is that you can exit the current constraints of "just a readme per module", and start having use-case-based docs. Imagine a webpage where you can explain how to use OCA for having better inventory management, for boosting sales, for better privacy, etc. An use-case-based page can just link to the individual modules needed to get that use case done. That's impossible with the current structure.

      So, summarizing:
      • Current workflow
      1. Is easy to "fire and forget". You push the module, it has the readme, it works, done. Never look back. Yes, we knew that taking technicals out of something comfortable for them would produce these kinds of reactions.
      2. When you migrate a module, most times docs are not updated accordingly.
      3. Has everything self-contained.
      4. Is per-version.
      5. Is hard to maintain. As a consequence, it's not properly maintained.
      6. It's impossible to use by functionals. Thus, writing docs is an extra burden almost exclusively on the shoulders of coders.
      7. Docs are written by whoever wrote the module. Sadly, this impacts negatively on the quality of the docs. They communicate with more technical words. Maintaining videos and pictures is burdensome for them.
      8. Translating is impossible.
      9. Merging changes involves irrelevant nitpickings (commit message, formatting, etc.)
    •  New workflow:
      1. Can be equally easy when adding a new module (due to a sync that could import that readme as the starting docs for the module). When adding a new feature, it can involve adding another PR to docs. That PR, however, doesn't have to be done by the programmer.
      2. When migrating a module, if it behaves the same, there'll be nothing to be done. Otherwise, see point 1.
      3. Docs centralized.
      4. Single page. Relevant per-version changes kept on the same page.
      5. Easier to maintain. As a consequence, they'll have more maintenance.
      6. Functionals can learn to contribute in a 5-minutes video. Less copywriting burden for coders.
      7. Docs are written by people that use the module. They communicate without technicisms. They value pictures and videos as that's their daily life. Docs quality will be better.
      8. Translating is possible (not yet in the MVP, before you ask).
      9. Functionals can merge without nitpicks. Reviews are done purely visually. The outcome is an SSG with very little attack surface. Git is just a DB.
      The new workflow is not perfect, and it might require an extra PR every now and then. However, IMHO it opens many doors for improvement that are currently closed.

    Many have predicted "catastrophes" with this idea. However, it's good to reflect on the pain points we currently have. Why not also try to predict how much better this would be? When I think about it, I see it's worth trying.
    by Jairo Llopis - 10:36 - 2 Jan 2025

    3 attachments 3 attachments

    image.png
    image.png
    image.png
  • Re: "The plan" to help non technical to contribute documentation on OCA modules
    Internal communication: seeds ----- Original message ----- Date: Dec 18, 2024, 9:12:51 PM From: Notifications Subject: Re: "The plan" to help non technical to [...] ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​


    seeds

    Best regards,

    photograph
    Ivan Sokolov
     Cetmix Odoo Solutions
    cetmix.com
    Facebook Twitter LinkedIn Instagram 
    This message is sent using Mail Messages Easy app


    ----- Original message -----
    Date: Dec 18, 2024, 9:12:51 PM
    From: Notifications
    Subject: Re: "The plan" to help non technical to contribute documentation on OCA modules


    On Thu, Dec 19, 2024 at 2:16 AM Adam Heinz <notifications@odoo-community.org> wrote:

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

    Powered by Messages Easy Pro

    by "Ivan Sokolov via Cetmix OÜ" <team@cetmix.com> - 10:40 - 18 Dec 2024

  • [Odoo CE 17.0] Fields related to custom fields don't save any values
    Hello everyone,
     
    I am writing this message because I need help with making fields related to custom fields store values into the database.
     
    Some days ago, I made a custom model through Python called "product_measures", which is inside a model called "product_dimension". Said model not only has three Many2one fields, each one for the product's measures, but is also inside another model of "product_dimension" called "product_template", which has the same fields but with the related field section and different names. The problem is that whenever I write anything on the fields, it doesn't save anything. Also, I'm trying to make it so every value that is created and is a number is converted into a Float.
     
    I'm sending the module in a zip file because I have been stuck with this problem for quite some time, and I would like to solve this problem as soon as possible.
     
    Thanks in advance for anyone who answers.
     
    Best regards.
    by Alejandro Párraga Alcázar - 09:36 - 10 Dec 2024

    2 attachments 2 attachments

    modified_product_dimension.zip
    attachment

    9 replies 9 replies

  • [18.0] Project Task Git integration
    Hi, 

    we're looking for an Odoo 18 project task git integration. 

    Specifically we need the feature that allows linking PR and commits to the task by branch name/commit name containing the name of the task, basically like Atlassian/Jira git integration.

    If you have any open source resource to provide as example we we might try to migrate it to version 18.0. 

    Thanks

    --Francesco Ballerini
    by Francesco Ballerini - 06:46 - 6 Dec 2024

    9 replies 9 replies

    • Re: [18.0] Project Task Git integration
      Hi Quentin, thanks for your help! 
      Ideally I'd like to have task sync with commits, pull requests and branches, also we're mainly focusing on github rather than gitlab. I will keep using https://github.com/OCA/project/pull/1390 as base for the implementation but I might definitely take some from your project. I see that you already have a task-pullrequest module published at https://github.com/Numigi/odoo-git-addons/tree/14.0/github_pull_request_project  , will be interesting to see the other part. 

      Thank you!

      Il giorno ven 20 dic 2024 alle ore 14:42 Quentin Lavallee <notifications@odoo-community.org> ha scritto:
      Hi,

      We use the following modules to define a Pull Request object and update it via Github webhooks:
      https://github.com/Numigi/odoo-git-addons/tree/14.0

      It is in the process of being migrated to v16.

      We then have a simple module (not published) that links Pull Requests in Odoo to tasks, we could open it if interested. The matching is done by looking for a task ID in Pull Request titles.

      Cheers,

      Le dim. 15 déc. 2024 à 14:42, Francesco Ballerini <notifications@odoo-community.org> a écrit :
      Hi Janik, thank you so much for sharing! I took a look at the connector, and from what I can see, it allows to sync repositories in your local environment by providing terminal access directly within the Odoo interface, along with some useful shortcuts and pre-configured commands. It's an interesting approach, and I might draw some inspiration from it. 

      For this task in particular I was especially interested in automatizing commit and pull requests behaviour by using git webhooks, and today I succeded setting up an environment to debug and extend the PR posted by Alan. It took me a while since I had to find a way to test webhooks with a localhost (never did it before), I finally succeded with a pretty simple Ngrok tunneling configuration.

      I take the opportunity to keep you update, at the moment my "roadmap" is:

      with the module webhook_gitlab that Alan provided in https://github.com/OCA/project/pull/1390 

      1 - setting up a developement environment in order to be able to debug, test, analyze code, extend the module on the version it was designed for (17.0) -- Done

      2 - extend "webhook_gitlab" module to incorporate desired behaviour, which is at least a sync of the commit history (and maybe pull requests) linked to a task providing a list with links to the task related commits.

      I'll share some notes on this step: as a general idea a commit should automatically be linked to the project task (when "push event webhook" triggers) if the commit message contains the name of any "project.task" from the Odoo Project linked with the repo where the push event triggered.

      E.g. I have Odoo Project named "Project X" linked to https://github.com/MyOrganization/ProjectX GitHub repo. When I push a commit into ProjectX GitHub repository I will notify Odoo server by setting a webhook that calls webhook processing controller . We should add a structured push processing method (at the moment only merging is processed I think) that compare every "project.task" name related to ProjectX and check if "project.task" name is found in the commit message. In that case the commit ID should be stored in a git.commit (new) model related to the project task and will be used to build a clickable url which is probably stored in a computed field. There should probably also be a commit resync button. -- TODO, doesn't seem too hard, but will require some time to be done.

      3 - when the functionality will be working on 17.0 I will migrate it on the 18.0 version (which is the version I need to work with this feature). The migration should not be hard in this case since most of the code will be methods to process github webhook requests and simply store some data in models, there shouldn't be huge changes in the code -- TODO

      I plan to proceed with these steps over the next few weeks. If you have any recommendations, please feel free to share them. I believe the hardest part for me will be writing tests, as I'm not very familiar with it. Thankfully, I think I’ll find substantial help in  https://github.com/OCA/interface-github/tree/16.0/github_connector


      Il giorno gio 12 dic 2024 alle ore 10:18 Janik von Rotz <notifications@odoo-community.org> ha scritto:
      Hi Francesco,

I have developed a module to manage git repositories: 
https://github.com/Mint-System/Odoo-Apps-Connector/tree/16.0/git_base
And here are the docs: https://www.odoo-wiki.org/git-base.html

I will eventually develop a "project_git" module that connects projects 
with git repos and supports creating feature branches from tasks.

All Mint System modules live up to the OCA standards.

Cheers,

Janik

On 12/6/24 6:48 PM, Francesco Ballerini wrote:




> Hi,




>




> we're looking for an Odoo 18 project task git integration.




>




> Specifically we need the feature that allows linking PR and commits to 




> the task by branch name/commit name containing the name of the task, 




> basically like Atlassian/Jira git integration.




>




> If you have any open source resource to provide as example we we might 




> try to migrate it to version 18.0.




>




> Thanks




>




> --Francesco Ballerini




>




> _______________________________________________




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




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




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




>




-- 
We are hiring: https://www.mint-system.ch/jobs
Send application to: jobs@mint-system.ch

CTO Mint System GmbH
Tel: +41 44 244 7222

      _______________________________________________
      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



      --
       
      Quentin Lavallée-Bourdeau
      Chargé de projets
      +1 514-317-7944
      LinkedIn Twitter Facebook YouTube
       
        Nouveau
      Essayez l'IA OpenSource pendant 30 jours       		  Découvrir

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

      by Francesco Ballerini - 12:26 - 24 Dec 2024
    • Re: [18.0] Project Task Git integration
      Hi,

      We use the following modules to define a Pull Request object and update it via Github webhooks:
      https://github.com/Numigi/odoo-git-addons/tree/14.0

      It is in the process of being migrated to v16.

      We then have a simple module (not published) that links Pull Requests in Odoo to tasks, we could open it if interested. The matching is done by looking for a task ID in Pull Request titles.

      Cheers,

      Le dim. 15 déc. 2024 à 14:42, Francesco Ballerini <notifications@odoo-community.org> a écrit :
      Hi Janik, thank you so much for sharing! I took a look at the connector, and from what I can see, it allows to sync repositories in your local environment by providing terminal access directly within the Odoo interface, along with some useful shortcuts and pre-configured commands. It's an interesting approach, and I might draw some inspiration from it. 

      For this task in particular I was especially interested in automatizing commit and pull requests behaviour by using git webhooks, and today I succeded setting up an environment to debug and extend the PR posted by Alan. It took me a while since I had to find a way to test webhooks with a localhost (never did it before), I finally succeded with a pretty simple Ngrok tunneling configuration.

      I take the opportunity to keep you update, at the moment my "roadmap" is:

      with the module webhook_gitlab that Alan provided in https://github.com/OCA/project/pull/1390 

      1 - setting up a developement environment in order to be able to debug, test, analyze code, extend the module on the version it was designed for (17.0) -- Done

      2 - extend "webhook_gitlab" module to incorporate desired behaviour, which is at least a sync of the commit history (and maybe pull requests) linked to a task providing a list with links to the task related commits.

      I'll share some notes on this step: as a general idea a commit should automatically be linked to the project task (when "push event webhook" triggers) if the commit message contains the name of any "project.task" from the Odoo Project linked with the repo where the push event triggered.

      E.g. I have Odoo Project named "Project X" linked to https://github.com/MyOrganization/ProjectX GitHub repo. When I push a commit into ProjectX GitHub repository I will notify Odoo server by setting a webhook that calls webhook processing controller . We should add a structured push processing method (at the moment only merging is processed I think) that compare every "project.task" name related to ProjectX and check if "project.task" name is found in the commit message. In that case the commit ID should be stored in a git.commit (new) model related to the project task and will be used to build a clickable url which is probably stored in a computed field. There should probably also be a commit resync button. -- TODO, doesn't seem too hard, but will require some time to be done.

      3 - when the functionality will be working on 17.0 I will migrate it on the 18.0 version (which is the version I need to work with this feature). The migration should not be hard in this case since most of the code will be methods to process github webhook requests and simply store some data in models, there shouldn't be huge changes in the code -- TODO

      I plan to proceed with these steps over the next few weeks. If you have any recommendations, please feel free to share them. I believe the hardest part for me will be writing tests, as I'm not very familiar with it. Thankfully, I think I’ll find substantial help in  https://github.com/OCA/interface-github/tree/16.0/github_connector


      Il giorno gio 12 dic 2024 alle ore 10:18 Janik von Rotz <notifications@odoo-community.org> ha scritto:
      Hi Francesco,

I have developed a module to manage git repositories: 
https://github.com/Mint-System/Odoo-Apps-Connector/tree/16.0/git_base
And here are the docs: https://www.odoo-wiki.org/git-base.html

I will eventually develop a "project_git" module that connects projects 
with git repos and supports creating feature branches from tasks.

All Mint System modules live up to the OCA standards.

Cheers,

Janik

On 12/6/24 6:48 PM, Francesco Ballerini wrote:



> Hi,



>



> we're looking for an Odoo 18 project task git integration.



>



> Specifically we need the feature that allows linking PR and commits to 



> the task by branch name/commit name containing the name of the task, 



> basically like Atlassian/Jira git integration.



>



> If you have any open source resource to provide as example we we might 



> try to migrate it to version 18.0.



>



> Thanks



>



> --Francesco Ballerini



>



> _______________________________________________



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



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



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



>



-- 
We are hiring: https://www.mint-system.ch/jobs
Send application to: jobs@mint-system.ch

CTO Mint System GmbH
Tel: +41 44 244 7222

      _______________________________________________
      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



      --
       
      Quentin Lavallée-Bourdeau
      Chargé de projets
      +1 514-317-7944
      LinkedIn Twitter Facebook YouTube
       
        Nouveau
      Essayez l'IA OpenSource pendant 30 jours       		  Découvrir
      by Quentin Lavallée-Bourdeau - 02:41 - 20 Dec 2024
    • Re: [18.0] Project Task Git integration
      Hi Janik, thank you so much for sharing! I took a look at the connector, and from what I can see, it allows to sync repositories in your local environment by providing terminal access directly within the Odoo interface, along with some useful shortcuts and pre-configured commands. It's an interesting approach, and I might draw some inspiration from it. 

      For this task in particular I was especially interested in automatizing commit and pull requests behaviour by using git webhooks, and today I succeded setting up an environment to debug and extend the PR posted by Alan. It took me a while since I had to find a way to test webhooks with a localhost (never did it before), I finally succeded with a pretty simple Ngrok tunneling configuration.

      I take the opportunity to keep you update, at the moment my "roadmap" is:

      with the module webhook_gitlab that Alan provided in https://github.com/OCA/project/pull/1390 

      1 - setting up a developement environment in order to be able to debug, test, analyze code, extend the module on the version it was designed for (17.0) -- Done

      2 - extend "webhook_gitlab" module to incorporate desired behaviour, which is at least a sync of the commit history (and maybe pull requests) linked to a task providing a list with links to the task related commits.

      I'll share some notes on this step: as a general idea a commit should automatically be linked to the project task (when "push event webhook" triggers) if the commit message contains the name of any "project.task" from the Odoo Project linked with the repo where the push event triggered.

      E.g. I have Odoo Project named "Project X" linked to https://github.com/MyOrganization/ProjectX GitHub repo. When I push a commit into ProjectX GitHub repository I will notify Odoo server by setting a webhook that calls webhook processing controller . We should add a structured push processing method (at the moment only merging is processed I think) that compare every "project.task" name related to ProjectX and check if "project.task" name is found in the commit message. In that case the commit ID should be stored in a git.commit (new) model related to the project task and will be used to build a clickable url which is probably stored in a computed field. There should probably also be a commit resync button. -- TODO, doesn't seem too hard, but will require some time to be done.

      3 - when the functionality will be working on 17.0 I will migrate it on the 18.0 version (which is the version I need to work with this feature). The migration should not be hard in this case since most of the code will be methods to process github webhook requests and simply store some data in models, there shouldn't be huge changes in the code -- TODO

      I plan to proceed with these steps over the next few weeks. If you have any recommendations, please feel free to share them. I believe the hardest part for me will be writing tests, as I'm not very familiar with it. Thankfully, I think I’ll find substantial help in  https://github.com/OCA/interface-github/tree/16.0/github_connector


      Il giorno gio 12 dic 2024 alle ore 10:18 Janik von Rotz <notifications@odoo-community.org> ha scritto:
      Hi Francesco,

I have developed a module to manage git repositories: 
https://github.com/Mint-System/Odoo-Apps-Connector/tree/16.0/git_base
And here are the docs: https://www.odoo-wiki.org/git-base.html

I will eventually develop a "project_git" module that connects projects 
with git repos and supports creating feature branches from tasks.

All Mint System modules live up to the OCA standards.

Cheers,

Janik

On 12/6/24 6:48 PM, Francesco Ballerini wrote:


> Hi,


>


> we're looking for an Odoo 18 project task git integration.


>


> Specifically we need the feature that allows linking PR and commits to 


> the task by branch name/commit name containing the name of the task, 


> basically like Atlassian/Jira git integration.


>


> If you have any open source resource to provide as example we we might 


> try to migrate it to version 18.0.


>


> Thanks


>


> --Francesco Ballerini


>


> _______________________________________________


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


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


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


>


-- 
We are hiring: https://www.mint-system.ch/jobs
Send application to: jobs@mint-system.ch

CTO Mint System GmbH
Tel: +41 44 244 7222

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

      by Francesco Ballerini - 08:38 - 15 Dec 2024
    • Re: [18.0] Project Task Git integration 
      Hi Francesco,

I have developed a module to manage git repositories: 
https://github.com/Mint-System/Odoo-Apps-Connector/tree/16.0/git_base
And here are the docs: https://www.odoo-wiki.org/git-base.html

I will eventually develop a "project_git" module that connects projects 
with git repos and supports creating feature branches from tasks.

All Mint System modules live up to the OCA standards.

Cheers,

Janik

On 12/6/24 6:48 PM, Francesco Ballerini wrote:

> Hi,

>

> we're looking for an Odoo 18 project task git integration.

>

> Specifically we need the feature that allows linking PR and commits to 

> the task by branch name/commit name containing the name of the task, 

> basically like Atlassian/Jira git integration.

>

> If you have any open source resource to provide as example we we might 

> try to migrate it to version 18.0.

>

> Thanks

>

> --Francesco Ballerini

>

> _______________________________________________

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

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

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

>

-- 
We are hiring: https://www.mint-system.ch/jobs
Send application to: jobs@mint-system.ch

CTO Mint System GmbH
Tel: +41 44 244 7222
      by Janik von Rotz - 10:16 - 12 Dec 2024
    • Re: [18.0] Project Task Git integration
      Thank you Alan!
      You will see the PR, since this isn't a main task for us I can't ensure that the PR will be ready in a matter of days but I'll do my best to provide it within the new year. 

      Really appreciate your support.

      --Francesco



      Il giorno lun 9 dic 2024 alle ore 16:58 Jesús Alan Ramos Rodríguez <notifications@odoo-community.org> ha scritto:
      I have created the PR https://github.com/OCA/project/pull/1390

      Please propose this to OCA and respect the commit history, I'll be happy to review everything, my GitHub username is alan196

      Hope see your PR 

      Sent with Spark
      El 9 dic 2024, 3:17 AM -0600, Francesco Ballerini <notifications@odoo-community.org>, escribió:
      Hi Jesùs,

      I've mentioned this with my teammates and we agree that it would be great to have access to the 17.0 module that works with PR titles. We will spend some hours on it in order to make it work on 18.0 if we can. 
      I will keep an eye the "Project" pull request section these days looking for your PR. Many thanks.

      --Francesco

      Il giorno dom 8 dic 2024 alle ore 23:48 Jesús Alan Ramos Rodríguez <notifications@odoo-community.org> ha scritto:
      Hello,

      I have this feature for 17.0 using pull reques title, I have it in a private repository, but I can open source it without any issue.

      It works with github and gitlab and use webhooks to notify odoo server.

      Everything is in one repository, I'll like to split it but now is not my priority right now, if you are interested I can make a PR with the module and you can modify it to work with 18.0.

      El 6 dic 2024, 11:47 AM -0600, Francesco Ballerini <notifications@odoo-community.org>, escribió:
      Hi, 

      we're looking for an Odoo 18 project task git integration. 

      Specifically we need the feature that allows linking PR and commits to the task by branch name/commit name containing the name of the task, basically like Atlassian/Jira git integration.

      If you have any open source resource to provide as example we we might try to migrate it to version 18.0. 

      Thanks

      --Francesco Ballerini

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

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

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

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

      by Francesco Ballerini - 05:31 - 9 Dec 2024

  • EDI broker integrations 
    Hi everyone,

Looking for some advice here - we have a customer that's looking for 
integration with an EDI broker. On their shortlist are Transus and Babelway.

EDI broker --> Odoo:
- Let down / let up: Create (Return) Sale Orders in Odoo, filling in 
customer ref, warehouse, expected delivery date, serial number / package 
number information
- RECADV: confirmation of order (apparently orders are created first as 
quotation, and then a message comes when they should be confirmed)
- INVRPT: inventory report, a message that is apparently sent when EDI 
broker wants to know if there is stock available

Odoo --> EDI broker:

- Create purchase order at client
- DESADV: represents a picking, so what is the content of each package
- Invoice, relay invoice to client

A quick research finds that these terms are EDIFACT terms and that both 
Transus and Babelway seem to support that format, and that there are 
alpha modules in OCA that implement part of the above: base_edifact and 
sale_order_import_edifact.

Does anyone know how to best go about this, and if there are other 
modules or Odoo base functionality available that can help?

-Tom
    by Tom Blauwendraat - 12:01 - 5 Dec 2024

    11 replies 11 replies

    • Re: EDI broker integrations
      Hi Tom,

      regarding the base: go w/ edi framework. You can handle any kind of exchange as it's agnostic.

      Regarding the format: I'd stay away from EDIFACT if possible (we are using them on v16 but the format is really horrible and hard to inspect).
      If you can, use UBL. There's a lot of work there that you can reuse (including PO export, despatch advice, SO import + OrderResponse, etc).

      Feel free to ask more questions on the framework repo ;)

      Bests,
      S

      On Thu, Dec 5, 2024 at 12:02 PM Tom Blauwendraat <notifications@odoo-community.org> wrote:
      Hi everyone,

Looking for some advice here - we have a customer that's looking for 
integration with an EDI broker. On their shortlist are Transus and Babelway.

EDI broker --> Odoo:
- Let down / let up: Create (Return) Sale Orders in Odoo, filling in 
customer ref, warehouse, expected delivery date, serial number / package 
number information
- RECADV: confirmation of order (apparently orders are created first as 
quotation, and then a message comes when they should be confirmed)
- INVRPT: inventory report, a message that is apparently sent when EDI 
broker wants to know if there is stock available

Odoo --> EDI broker:

- Create purchase order at client
- DESADV: represents a picking, so what is the content of each package
- Invoice, relay invoice to client

A quick research finds that these terms are EDIFACT terms and that both 
Transus and Babelway seem to support that format, and that there are 
alpha modules in OCA that implement part of the above: base_edifact and 
sale_order_import_edifact.

Does anyone know how to best go about this, and if there are other 
modules or Odoo base functionality available that can help?

-Tom

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



      --
      Simone Orsi

      Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
      by Simone Orsi. - 03:56 - 5 Dec 2024
    • Re: EDI broker integrations 
      On 12/5/24 13:27, Enric Tobella Alomar wrote:

>

> There are several Videos of Simone talking about it (the original 

> project comes from Simone (most of it) and me)

>

> https://www.youtube.com/@OdooCommunity/search?query=edi
Thanks guys! It looks like this is the golden tip and the way to go :-) 
long live your hard work and OCA
      by Tom Blauwendraat - 01:52 - 5 Dec 2024
    • RE: EDI broker integrations
      We use atgp (french company) but the module edi-framework is agnostic of the broker. There are a lot of brokers with their own template in this domain. The templates is not part of the edi-framework module, you need to create your owns. See video of Simone Orsi for more explanation: https://www.youtube.com/@OdooCommunity/search?query=edi

      --

      Jonathan Van den Broeck

      De : Tom Blauwendraat <notifications@odoo-community.org>
      Envoyé : jeudi 5 décembre 2024 13:07
      À : Contributors <contributors@odoo-community.org>
      Objet : Re: EDI broker integrations
       

      Which broker is that? And do you have a PR already

      On 12/5/24 12:52, Jonathan Van den Broeck wrote:
      Hello,

      We have approximately the same needs but we have another broker. We are currently in the process to use the OCA/edi-framework modules wich seems to be a perfect fit for these needs.

      --

      Jonathan Van den Broeck


      De : Tom Blauwendraat <notifications@odoo-community.org>
      Envoyé : jeudi 5 décembre 2024 12:02
      À : Contributors <contributors@odoo-community.org>
      Objet : EDI broker integrations
       
      Hi everyone,

Looking for some advice here - we have a customer that's looking for 
integration with an EDI broker. On their shortlist are Transus and Babelway.

EDI broker --> Odoo:
- Let down / let up: Create (Return) Sale Orders in Odoo, filling in 
customer ref, warehouse, expected delivery date, serial number / package 
number information
- RECADV: confirmation of order (apparently orders are created first as 
quotation, and then a message comes when they should be confirmed)
- INVRPT: inventory report, a message that is apparently sent when EDI 
broker wants to know if there is stock available

Odoo --> EDI broker:

- Create purchase order at client
- DESADV: represents a picking, so what is the content of each package
- Invoice, relay invoice to client

A quick research finds that these terms are EDIFACT terms and that both 
Transus and Babelway seem to support that format, and that there are 
alpha modules in OCA that implement part of the above: base_edifact and 
sale_order_import_edifact.

Does anyone know how to best go about this, and if there are other 
modules or Odoo base functionality available that can help?

-Tom

      _______________________________________________
      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 jonathan.vandenbroeck - 01:41 - 5 Dec 2024
    • Re: EDI broker integrations
      Tom you should check https://github.com/OCA/edi-framework

      It was developed on v13 (it is on OCA/edi) and moved to its own repo. It allows you to receive and process files and also create and send. There are examples in OCA like spanish electronic invoicing and we are trying to improve the documentation of it.

      There are several Videos of Simone talking about it (the original project comes from Simone (most of it) and me)


      Kind regards,

      El jue, 5 dic 2024 a las 13:07, Tom Blauwendraat (<notifications@odoo-community.org>) escribió:

      Which broker is that? And do you have a PR already

      On 12/5/24 12:52, Jonathan Van den Broeck wrote:
      Hello,

      We have approximately the same needs but we have another broker. We are currently in the process to use the OCA/edi-framework modules wich seems to be a perfect fit for these needs.

      --

      Jonathan Van den Broeck


      De : Tom Blauwendraat <notifications@odoo-community.org>
      Envoyé : jeudi 5 décembre 2024 12:02
      À : Contributors <contributors@odoo-community.org>
      Objet : EDI broker integrations
       
      Hi everyone,

Looking for some advice here - we have a customer that's looking for 
integration with an EDI broker. On their shortlist are Transus and Babelway.

EDI broker --> Odoo:
- Let down / let up: Create (Return) Sale Orders in Odoo, filling in 
customer ref, warehouse, expected delivery date, serial number / package 
number information
- RECADV: confirmation of order (apparently orders are created first as 
quotation, and then a message comes when they should be confirmed)
- INVRPT: inventory report, a message that is apparently sent when EDI 
broker wants to know if there is stock available

Odoo --> EDI broker:

- Create purchase order at client
- DESADV: represents a picking, so what is the content of each package
- Invoice, relay invoice to client

A quick research finds that these terms are EDIFACT terms and that both 
Transus and Babelway seem to support that format, and that there are 
alpha modules in OCA that implement part of the above: base_edifact and 
sale_order_import_edifact.

Does anyone know how to best go about this, and if there are other 
modules or Odoo base functionality available that can help?

-Tom

      _______________________________________________
      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

      by Enric Tobella Alomar - 01:26 - 5 Dec 2024
    • Re: EDI broker integrations

      Which broker is that? And do you have a PR already

      On 12/5/24 12:52, Jonathan Van den Broeck wrote:
      Hello,

      We have approximately the same needs but we have another broker. We are currently in the process to use the OCA/edi-framework modules wich seems to be a perfect fit for these needs.

      --

      Jonathan Van den Broeck


      De : Tom Blauwendraat <notifications@odoo-community.org>
      Envoyé : jeudi 5 décembre 2024 12:02
      À : Contributors <contributors@odoo-community.org>
      Objet : EDI broker integrations
       
      Hi everyone,

Looking for some advice here - we have a customer that's looking for 
integration with an EDI broker. On their shortlist are Transus and Babelway.

EDI broker --> Odoo:
- Let down / let up: Create (Return) Sale Orders in Odoo, filling in 
customer ref, warehouse, expected delivery date, serial number / package 
number information
- RECADV: confirmation of order (apparently orders are created first as 
quotation, and then a message comes when they should be confirmed)
- INVRPT: inventory report, a message that is apparently sent when EDI 
broker wants to know if there is stock available

Odoo --> EDI broker:

- Create purchase order at client
- DESADV: represents a picking, so what is the content of each package
- Invoice, relay invoice to client

A quick research finds that these terms are EDIFACT terms and that both 
Transus and Babelway seem to support that format, and that there are 
alpha modules in OCA that implement part of the above: base_edifact and 
sale_order_import_edifact.

Does anyone know how to best go about this, and if there are other 
modules or Odoo base functionality available that can help?

-Tom

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

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

      by Tom Blauwendraat - 01:06 - 5 Dec 2024

  • Clarification on merge/squash the commits generated by bots or weblate

    When reviewing this guide, it states:

    "In order to squash these administrative commits, use git rebase -i origin/x, where x is the Odoo version (14.0, 15.0, 16.0,...). Don't forget first to do git fetch origin x to get the latest remote information."

    In the context of migrating a module, this step is recommended after applying the patches and running pre-commit.

    My question is: regarding the x branch mentioned above—does it refer to the source version or the target version for the migration?

    by Ing. Rolando Pérez Rebollo - 12:11 - 29 Nov 2024

    2 replies 2 replies

    • Re: Clarification on merge/squash the commits generated by bots or weblate

      Thank U, Christopher.

      \Rebollo

      On 11/29/24 03:28, Christopher Rogos wrote:

      When you migrate a module from 16 to 17, you create a new branch “17.0-mig-my_module” based on the 17.0 branch.

      Then you transfer all commits from my_module to the new branch.

      When you are working on branch “17.0-mig-my_module” you can use “git rebase -i origin/17.0” to rebase the transferred commits on your branch, and clean them up by squashing some.

       

       

      From: Rolando Pérez Rebollo <notifications@odoo-community.org>
      Sent: Freitag, 29. November 2024 00:13
      To: Contributors <contributors@odoo-community.org>
      Subject: Clarification on merge/squash the commits generated by bots or weblate

       

      When reviewing this guide, it states:

      "In order to squash these administrative commits, use git rebase -i origin/x, where x is the Odoo version (14.0, 15.0, 16.0,...). Don't forget first to do git fetch origin x to get the latest remote information."

      In the context of migrating a module, this step is recommended after applying the patches and running pre-commit.

      My question is: regarding the x branch mentioned above—does it refer to the source version or the target version for the migration?

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

      by Ing. Rolando Pérez Rebollo - 10:26 - 29 Nov 2024
    • RE: Clarification on merge/squash the commits generated by bots or weblate

      When you migrate a module from 16 to 17, you create a new branch “17.0-mig-my_module” based on the 17.0 branch.

      Then you transfer all commits from my_module to the new branch.

      When you are working on branch “17.0-mig-my_module” you can use “git rebase -i origin/17.0” to rebase the transferred commits on your branch, and clean them up by squashing some.

       

       

      From: Rolando Pérez Rebollo <notifications@odoo-community.org>
      Sent: Freitag, 29. November 2024 00:13
      To: Contributors <contributors@odoo-community.org>
      Subject: Clarification on merge/squash the commits generated by bots or weblate

       

      When reviewing this guide, it states:

      "In order to squash these administrative commits, use git rebase -i origin/x, where x is the Odoo version (14.0, 15.0, 16.0,...). Don't forget first to do git fetch origin x to get the latest remote information."

      In the context of migrating a module, this step is recommended after applying the patches and running pre-commit.

      My question is: regarding the x branch mentioned above—does it refer to the source version or the target version for the migration?

      by Christopher Rogos - 09:26 - 29 Nov 2024
  • Vertical support
    Hello,

    I am interested in exploring the support of the Vertical Agriculture project.
    I also like to understand if it would be possible to initiate and lead a project for Commercial Horticulture.  There is already a version 1 available to initiate this project.

    Joel Patrick
    Partner

    by Joël PATRICK - 01:11 - 27 Nov 2024

    1 replies 1 replies

    • Re: Vertical support
      Hey Joel,
      I am interested in getting the agriculture vertical forward as well. 
      I already did a lot of work with a total different approach then the modules available there. More focused on the different disciplines of agriculture and especially the  reporting part. Stil a lot of work. But I have good connections to the food agriculture section, which gives great input on how it should work. 

      So if there is something coming up... 
      please let me know... 

      Cheers Nils
      Von: Joel Patrick <notifications@odoo-community.org>
      Gesendet: Wednesday, November 27, 2024 1:13:08 PM
      An: Contributors <contributors@odoo-community.org>
      Betreff: Vertical support
       

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

      Hello,

      I am interested in exploring the support of the Vertical Agriculture project.
      I also like to understand if it would be possible to initiate and lead a project for Commercial Horticulture.  There is already a version 1 available to initiate this project.

      Joel Patrick
      Partner

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

      by Nils Coenen - 02:06 - 27 Nov 2024
  • OCA Codesprint - around FOSDEM - are you keen?
    Hello OCA Contributors,

    You may have seen on our social media that we are weighing up if there is enough interest to organise an OCA Codesprint around the FOSDEM event next year.

    If this is something that is of interest to you, please let us know on our survey here. Depending on interest we will make a decision about what to do.

    The FOSDEM event is on the 1st and 2nd of February in Brussels. We are considering a sprint a day or two on either side.

    Have a great week.
    Rebecca

    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly - 01:26 - 26 Nov 2024

    9 replies 9 replies

  • Store large Size videos
    Hi everyone,

    Does anyone have experience with storing very large video files (e.g., 1-hour-long, few GB) in the Odoo file system or an external drive?

    Our use case involves an Odoo website with Videos, and we're trying to avoid embedding videos from external platforms like YouTube.

    Thanks

    by Hed Shefer - 02:41 - 20 Nov 2024

    11 replies 11 replies

  • FOSDEM Call for Participation: would OCA contributors join? + OCA Code Sprint in Brussels
    Hello Contributors,

    Hope this email finds you well.

    As open source fan, you might know that the FOSDEM DevsRooms have been launched and there are Call for Participation with deadline by the 1st December.

    If you don't know what the FOSDEM is, here is their own presentation: "FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event in Brussels. You don't need to register. Just turn up and join in!"

    The event will take place on Saturday 1st and Sunday 2nd February (unfortunately this is winter time in Brussels, so it's even worse than the OCA Days/Odoo XP event in October, weather-wise. But seeing thousands of open source developers gathering for a full weekend of conferences is hearth-warming, you'll see!).

    Wouldn't it be awesome to have OCA contributors pitching their knowledge during this big event? There are many DevRooms, one is Python and here is what they are looking for: 
      * Best practices for Python developers
  * New developments in Python land
  * How to get started with a specific library/framework
  * Launching and growing Python communities
  * How Python is being used for education
  * Python for Hardware / Infrastructure
  * Security tools in Python and securing Python
  * Data science, AI and Machine Learning
  * Data engineering and management
  * Video Games (or game-related tooling) written in Python
  * MicroPython, CircuitPython, embedded software
  * Scaling Python applications
    Another one is related to "Funding the FOSS Ecosystem" and another to Community  On both those topics, if someone of you would like to co-host a topic with me, we can make it work! I am still shy to propose a talk at such an event all by myself, not being a developer and all that.

    On the side of FOSDEM, we might organize an OCA Code Sprint (either on 30/31st January or 3th/4th February) if several of you want to travel to Brussels and take this opportunity to code sprint together. Let me know if this might interest you by answering this 1 minute survey:

    Many thanks,
    Virginie Dewulf
    Executive Director
    +32 477 64 17 20
    by Virginie Dewulf (OCA) - 12:35 - 20 Nov 2024

    2 replies 2 replies

    • Re: FOSDEM Call for Participation: would OCA contributors join? + OCA Code Sprint in Brussels
      Hello,

      We have no stand this year, maybe the next one!

      Virginie Dewulf
      Executive Director
      +32 477 64 17 20


      Le mer. 20 nov. 2024 à 19:47, Michel Stroom <notifications@odoo-community.org> a écrit :
      Hi Virginie,

      Do we, the OCA, have stand at the FOSDEM?

      Maybe I missed it in the long list that is published.
      Click the link below, accepted stands:

      If we do have a stand, I like to volunteer to get new OCA contributors and members.


      Warmest regards,

      Michel Stroom
      -- 

      Office Everywhere
      Business Partner Odoo

      t: +31 6 53360677
      e: mstroom@office-everywhere.com
      w: Office-Everywhere.com



      On 20 Nov 2024, at 12:37, Virginie Dewulf <virginie@odoo-community.org> wrote:

      Hello Contributors,

      Hope this email finds you well.

      As open source fan, you might know that the FOSDEM DevsRooms have been launched and there are Call for Participation with deadline by the 1st December.

      If you don't know what the FOSDEM is, here is their own presentation: "FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event in Brussels. You don't need to register. Just turn up and join in!"

      The event will take place on Saturday 1st and Sunday 2nd February (unfortunately this is winter time in Brussels, so it's even worse than the OCA Days/Odoo XP event in October, weather-wise. But seeing thousands of open source developers gathering for a full weekend of conferences is hearth-warming, you'll see!).

      Wouldn't it be awesome to have OCA contributors pitching their knowledge during this big event? There are many DevRooms, one is Python and here is what they are looking for: 
        * Best practices for Python developers
  * New developments in Python land
  * How to get started with a specific library/framework
  * Launching and growing Python communities
  * How Python is being used for education
  * Python for Hardware / Infrastructure
  * Security tools in Python and securing Python
  * Data science, AI and Machine Learning
  * Data engineering and management
  * Video Games (or game-related tooling) written in Python
  * MicroPython, CircuitPython, embedded software
  * Scaling Python applications
      Another one is related to "Funding the FOSS Ecosystem" and another to Community  On both those topics, if someone of you would like to co-host a topic with me, we can make it work! I am still shy to propose a talk at such an event all by myself, not being a developer and all that.

      On the side of FOSDEM, we might organize an OCA Code Sprint (either on 30/31st January or 3th/4th February) if several of you want to travel to Brussels and take this opportunity to code sprint together. Let me know if this might interest you by answering this 1 minute survey:

      Many thanks,
      Virginie Dewulf
      Executive Director
      +32 477 64 17 20

      _______________________________________________
      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 Virginie Dewulf (OCA) - 08:01 - 20 Nov 2024
    • Re: FOSDEM Call for Participation: would OCA contributors join? + OCA Code Sprint in Brussels
      Hi Virginie,

      Do we, the OCA, have stand at the FOSDEM?

      Maybe I missed it in the long list that is published.
      Click the link below, accepted stands:

      If we do have a stand, I like to volunteer to get new OCA contributors and members.


      Warmest regards,

      Michel Stroom
      -- 

      Office Everywhere
      Business Partner Odoo

      t: +31 6 53360677
      e: mstroom@office-everywhere.com
      w: Office-Everywhere.com



      On 20 Nov 2024, at 12:37, Virginie Dewulf <virginie@odoo-community.org> wrote:

      Hello Contributors,

      Hope this email finds you well.

      As open source fan, you might know that the FOSDEM DevsRooms have been launched and there are Call for Participation with deadline by the 1st December.

      If you don't know what the FOSDEM is, here is their own presentation: "FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event in Brussels. You don't need to register. Just turn up and join in!"

      The event will take place on Saturday 1st and Sunday 2nd February (unfortunately this is winter time in Brussels, so it's even worse than the OCA Days/Odoo XP event in October, weather-wise. But seeing thousands of open source developers gathering for a full weekend of conferences is hearth-warming, you'll see!).

      Wouldn't it be awesome to have OCA contributors pitching their knowledge during this big event? There are many DevRooms, one is Python and here is what they are looking for: 
        * Best practices for Python developers
  * New developments in Python land
  * How to get started with a specific library/framework
  * Launching and growing Python communities
  * How Python is being used for education
  * Python for Hardware / Infrastructure
  * Security tools in Python and securing Python
  * Data science, AI and Machine Learning
  * Data engineering and management
  * Video Games (or game-related tooling) written in Python
  * MicroPython, CircuitPython, embedded software
  * Scaling Python applications
      Another one is related to "Funding the FOSS Ecosystem" and another to Community  On both those topics, if someone of you would like to co-host a topic with me, we can make it work! I am still shy to propose a talk at such an event all by myself, not being a developer and all that.

      On the side of FOSDEM, we might organize an OCA Code Sprint (either on 30/31st January or 3th/4th February) if several of you want to travel to Brussels and take this opportunity to code sprint together. Let me know if this might interest you by answering this 1 minute survey:

      Many thanks,
      Virginie Dewulf
      Executive Director
      +32 477 64 17 20

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



      by Michel Stroom - 07:45 - 20 Nov 2024
  • [NEWS] oca-port: a new version has been released!

    Hello there!

    A new version of oca-port has been released:

    This new version changed the CLI parameters, and now allows to migrate modules or port commits from one repository to another thanks to the new syntax.

    Let's say that origin remote is for OCA/social, and mail remote for the newly created OCA/mail repository, to check if mail_tracking is migrated or have commits to port from 16.0 to 18.0:

      $ cd ~/OCA/social
  $ git remote add mail git@github.com:OCA/mail.git
  $ oca-port origin/16.0 mail/18.0 mail_tracking --verbose --fetch --dry-run

    Output:

    Source: origin/16.0, remote origin git@github.com:OCA/social.git
Target: mail/18.0, remote mail git@github.com:OCA/mail.git
Fetch origin/16.0 from git@github.com:OCA/social.git
Fetch mail/18.0 from git@github.com:OCA/mail.git
⚠️	Migration of mail_tracking seems handled in this PR:
		https://github.com/OCA/mail/pull/1 (by trisdoan)
	We invite you to review this PR instead of opening a new one. Thank you!
ℹ️  mail_tracking can be migrated from 16.0 to 18.0.

    Seems there is already a PR open on OCA/mail to migrate this module, better to review this one before opening a new one!

    Otherwise, by removing the --dry-run flag (with an optional --destination) we could handle the migration, following OCA migration guide.

    If a module is already migrated, the list of missing commits (if any) grouped by PR will be listed, up to the user to port or to blacklist them if they are not relevant.

    This new version also allows you to migrate modules located in a subfolder instead of the root directory, useful for private project repositories for instance.

    ROADMAP:

    • integrate odoo-module-migrator to automatically upgrade code when migrating a module (WIP)
    • register/handle renamed modules

    Ideas, bugfixes and improvements are welcome.

    Have a good day,

    -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/
    by Sébastien Alix - 11:37 - 20 Nov 2024

    8 replies 8 replies

  • [14.0 CE] product_list_pricelist_price
    Hi, 

    did some one migrate https://github.com/OCA/product-attribute/tree/13.0/product_list_pricelist_price to version 14.0 and have the chance to share it ? 

    I remember that I've tried to use it on v14.0 and spotted some incompatibilities, if I remember well the GUI was crashing when adding a new pricelist column unless odoo was restarted. I remember that I spent some time on it but didn't find a solution to it.

    Thanks

    --Francesco B
    by Francesco Ballerini - 11:11 - 20 Nov 2024
  • [Odoo CE 17.0] Help needed with client search on budgets
    Hello everyone,
     
    I am writing this message because I need assistance with modifying how searching a client while doing a budget works.
     
    What I am trying to do is, instead of searching just by the name, I want it to work like the following: I made a custom field called "x_cliente_interno", which is a number to identify the client, and I would like to make the search work like how product search works: If you write either the product's ID or the product's name, it will show you both fields merged from the data you wrote. Something like this:
     
     
    And when you select it, it shows the data like this:
     
     
    To sum up, what I am trying to do is that when you search a client, the search shows you the field "x_cliente_interno" behind the client name, like this: "[x_cliente_interno] client name" and it should also stay like in the second image when selected.
     
    Thanks in advance for the help.
    by Alejandro Párraga Alcázar - 10:21 - 19 Nov 2024

    3 attachments 3 attachments

    imagen.png
    imagen.png
    attachment

    12 replies 12 replies

    • Re: [Odoo CE 17.0] Help needed with client search on budgets
      Hi @Redes Sociales JLBBERP  

      I didn't noticed at first but indeed you're right, thank you for pointing that out. 

      The fact that you see those info about VAT and address is basically due to the field context (defined in XML field definition) which contains key values like 'show_vat': 1. That context is propagated to the python context which will be evaluated in odoo 17 _compute_display_name method. 

      The code I gave you was totally overriding that context evaluation but this issue can be easily avoided by extending the _get_complete_name() hook instead, which is called in the first lines of _compute_display_name and can be extended to add values without overriding the context evaluation part. So I suggest to remove the _compute_display_name() override and replace it with the following 


      x_cliente_interno = fields.Integer() # use a standard field for consistency

      def _get_complete_name(self):
      """@override: add `x_cliente_interno` field to the complete name"""
      complete_name = super()._get_complete_name()
      cliente_interno = f"[{self.x_cliente_interno}] " if self.x_cliente_interno else ""
      complete_name_add_cliente_interno = cliente_interno + complete_name
      return complete_name_add_cliente_interno


      I made a quick test locally and this should be able to fix the issue

      Kindly regards

      --Francesco


      Il giorno mar 26 nov 2024 alle ore 09:47 Redes Sociales JLBBERP <notifications@odoo-community.org> ha scritto:
      Hello everyone,
       
      after making a custom module with Francescos' code and fixing the search function, I came across a problem related to how the partner is displayed at the sales order form:
       
      When searching for a customer, they are displayed with the following format: "[x_cliente_interno] + customer name", which is the exact format I needed. But the problem is that when I select any customer, it doesn't show it's address and neither it's VAT below the customer anymore.
       
      Here I send my version of the code from Francesco:
       
      from odoo import models, fields, api

      class ResPartner(models.Model):
       
      _inherit = “res.partner”

      x_cliente_interno = fields.Integer() # use a standard field for consistency

      @api.depends(“name”, “x_cliente_interno”)
      def _compute_display_name(self):
      “""Show reference code before partner name""”
      super()._compute_display_name()
      for partner in self:
      name = partner.name or “unknown”
      cliente_interno = f"[{partner.x_cliente_interno}] " if partner.x_cliente_interno else ""
      # !! Disclaimer !!
      # If you copy this code and change it DO NOT ASSIGN the value of partner.name,
      # that would compromise your datas. Only re-assign partner.display_name
      partner.display_name = cliente_interno + name # It's replacing the whole field

      @api.model
      def _name_search(self, name, domain=None, operator='ilike', limit=None, order=None):
      “""Add custom field `cliente_interno` to the search domain""”
      domain = domain or []
      if name:
      domain += ['|', '|', ('name', operator, name),                     
      ('email', operator, name),                     
      ('x_cliente_interno', '=', name)]
      return self._search(domain, limit=limit, order=order)
       
      I tried fixing it by myself, and even if I wasn't able to, I discovered the field "partner.display_name" is the one causing this problem.
       
      Thanks in advance for the help.
      El 20/11/2024 9:21 CET Redes Sociales JLBBERP <redes_sociales@jlbberp.com> escribió:
       
       
      Hello Francesco,

      I have seen your message right now, and I would like to thank you so much for not only your answer, but also for you writing the code I should do. I do not know how could I pay you back this favor that you have done for me.
       
      I rely on the community because I am in my beginnings and because of everything that my company JLBB ERP has given me through good collaboration, I am now checking it out. Do not doubt that everything I can contribute, you will find me here.
       
      Thank you Francesco for the help.
       
      Salutations to the community.
      El 20/11/2024 0:02 CET Francesco Ballerini <notifications@odoo-community.org> escribió:
       
       
      I apologize, it is now clear to me also that you need both the search from a custom field and the way the name is displayed, but the search is indeed prioritized. 
       
      As Daniel and Xavier pointed out, in Odoo 17.0 you can already submit the "ref" field (field label on GUI is "Reference") and get the right record. E.g. if you have a contact named John Doe with Reference set on "ab-001" and you search for "ab-001" in the contacts search or dropdown you will fetch John Doe. 
       
      You could migrate your "x_cliente_interno" data into the "ref" field, and this would automatically unlock the search feature. However if you need to keep this data in a specific custom field you will need to override _name_search() method. 
      In every case you will also need to override _compute_display_name if you want to also show the code before the field. I provided a couple of snippet below (just as an example, especially the _name_search override needs to be refined).
       
      Let me point out another thing: from the field name I assume you are using a field defined from GUI, unfortunately it's not recommended to use those kind of fields in python methods as it will easily lead to inconsistencies and bugs (e.g. if you delete field from db and not remove it from python methods..). This means that if you want to use a custom field in _name_search() override you should migrate data to a standard field aniway.

      This is an example of what you might do on a custom module. As you can see the _name_search() implementation has to be refined while the_compute_display_name method will work as is. 
      If you decide to migrate data into the "ref" field you can only implement _compute_display_name by replacing "cliente_interno" with "ref" and you do not need to implement _name_search() in this case.
       
      from odoo import models, fields, api
      from odoo.osv import expression

      class ResPartner(models.Model):
      _inherit = "res.partner"

      cliente_interno = fields.Char() # use a standard field for consistency

      @api.depends("name", "cliente_interno")
      def _compute_display_name(self):
      """Show reference code before partner name"""
      super()._compute_display_name()
      for partner in self:
      name = partner.name or "unknown"
      cliente_interno = f"[{partner.cliente_interno}] " if partner.cliente_interno else ""
      # !! Disclaimer !!
      #I f you copy this code and change it DO NOT ASSIGN the value of partner.name,
      # that would compromise your datas. Only re-assign partner.display_name
      partner.display_name = cliente_interno + name

      @api.model
      def _name_search(self, name, domain=None, operator='ilike', limit=None, order=None):
      """Add custom field `cliente_interno` to the search domain"""
      domain = expression.OR([domain or [], [("cliente_interno", operator, name)]])
      # this doesn't work properly, it seems like the domain we pass gets overridden,
      # might take this as example and adjust by debugging/find more examples on source code
      return super()._name_search(name, domain=domain, operator=operator, limit=limit, order=order)
       
       
      Regards
       
      --Francesco
       
      Il giorno mar 19 nov 2024 alle ore 14:13 Daniel Reis <notifications@odoo-community.org> ha scritto:
      From your description, it feels like this is already available in standard Odoo:
      The "ref" field is to be used for Client codes

      The code is no longer presented in front of the name.
      I think an OCA module is needed to bring that feature back.

      /Daniel

      On 19/11/2024 09:22, Redes Sociales JLBBERP wrote:
      Hello everyone,
       
      I am writing this message because I need assistance with modifying how searching a client while doing a budget works.
       
      What I am trying to do is, instead of searching just by the name, I want it to work like the following: I made a custom field called "x_cliente_interno", which is a number to identify the client, and I would like to make the search work like how product search works: If you write either the product's ID or the product's name, it will show you both fields merged from the data you wrote. Something like this:
       
       
      And when you select it, it shows the data like this:
       
       
      To sum up, what I am trying to do is that when you search a client, the search shows you the field "x_cliente_interno" behind the client name, like this: "[x_cliente_interno] client name" and it should also stay like in the second image when selected.
       
      Thanks in advance for the help.

      --
      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]

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

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

       
       

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

      by Francesco Ballerini - 02:01 - 27 Nov 2024
    • Re: [Odoo CE 17.0] Help needed with client search on budgets
      Hello everyone,
       
      after making a custom module with Francescos' code and fixing the search function, I came across a problem related to how the partner is displayed at the sales order form:
       
      When searching for a customer, they are displayed with the following format: "[x_cliente_interno] + customer name", which is the exact format I needed. But the problem is that when I select any customer, it doesn't show it's address and neither it's VAT below the customer anymore.
       
      Here I send my version of the code from Francesco:
       
      from odoo import models, fields, api

      class ResPartner(models.Model):
       
      _inherit = “res.partner”

      x_cliente_interno = fields.Integer() # use a standard field for consistency

      @api.depends(“name”, “x_cliente_interno”)
      def _compute_display_name(self):
      “""Show reference code before partner name""”
      super()._compute_display_name()
      for partner in self:
      name = partner.name or “unknown”
      cliente_interno = f"[{partner.x_cliente_interno}] " if partner.x_cliente_interno else ""
      # !! Disclaimer !!
      # If you copy this code and change it DO NOT ASSIGN the value of partner.name,
      # that would compromise your datas. Only re-assign partner.display_name
      partner.display_name = cliente_interno + name # It's replacing the whole field

      @api.model
      def _name_search(self, name, domain=None, operator='ilike', limit=None, order=None):
      “""Add custom field `cliente_interno` to the search domain""”
      domain = domain or []
      if name:
      domain += ['|', '|', ('name', operator, name),                     
      ('email', operator, name),                     
      ('x_cliente_interno', '=', name)]
      return self._search(domain, limit=limit, order=order)
       
      I tried fixing it by myself, and even if I wasn't able to, I discovered the field "partner.display_name" is the one causing this problem.
       
      Thanks in advance for the help.
      El 20/11/2024 9:21 CET Redes Sociales JLBBERP <redes_sociales@jlbberp.com> escribió:
       
       
      Hello Francesco,

      I have seen your message right now, and I would like to thank you so much for not only your answer, but also for you writing the code I should do. I do not know how could I pay you back this favor that you have done for me.
       
      I rely on the community because I am in my beginnings and because of everything that my company JLBB ERP has given me through good collaboration, I am now checking it out. Do not doubt that everything I can contribute, you will find me here.
       
      Thank you Francesco for the help.
       
      Salutations to the community.
      El 20/11/2024 0:02 CET Francesco Ballerini <notifications@odoo-community.org> escribió:
       
       
      I apologize, it is now clear to me also that you need both the search from a custom field and the way the name is displayed, but the search is indeed prioritized. 
       
      As Daniel and Xavier pointed out, in Odoo 17.0 you can already submit the "ref" field (field label on GUI is "Reference") and get the right record. E.g. if you have a contact named John Doe with Reference set on "ab-001" and you search for "ab-001" in the contacts search or dropdown you will fetch John Doe. 
       
      You could migrate your "x_cliente_interno" data into the "ref" field, and this would automatically unlock the search feature. However if you need to keep this data in a specific custom field you will need to override _name_search() method. 
      In every case you will also need to override _compute_display_name if you want to also show the code before the field. I provided a couple of snippet below (just as an example, especially the _name_search override needs to be refined).
       
      Let me point out another thing: from the field name I assume you are using a field defined from GUI, unfortunately it's not recommended to use those kind of fields in python methods as it will easily lead to inconsistencies and bugs (e.g. if you delete field from db and not remove it from python methods..). This means that if you want to use a custom field in _name_search() override you should migrate data to a standard field aniway.

      This is an example of what you might do on a custom module. As you can see the _name_search() implementation has to be refined while the_compute_display_name method will work as is. 
      If you decide to migrate data into the "ref" field you can only implement _compute_display_name by replacing "cliente_interno" with "ref" and you do not need to implement _name_search() in this case.
       
      from odoo import models, fields, api
      from odoo.osv import expression

      class ResPartner(models.Model):
      _inherit = "res.partner"

      cliente_interno = fields.Char() # use a standard field for consistency

      @api.depends("name", "cliente_interno")
      def _compute_display_name(self):
      """Show reference code before partner name"""
      super()._compute_display_name()
      for partner in self:
      name = partner.name or "unknown"
      cliente_interno = f"[{partner.cliente_interno}] " if partner.cliente_interno else ""
      # !! Disclaimer !!
      #I f you copy this code and change it DO NOT ASSIGN the value of partner.name,
      # that would compromise your datas. Only re-assign partner.display_name
      partner.display_name = cliente_interno + name

      @api.model
      def _name_search(self, name, domain=None, operator='ilike', limit=None, order=None):
      """Add custom field `cliente_interno` to the search domain"""
      domain = expression.OR([domain or [], [("cliente_interno", operator, name)]])
      # this doesn't work properly, it seems like the domain we pass gets overridden,
      # might take this as example and adjust by debugging/find more examples on source code
      return super()._name_search(name, domain=domain, operator=operator, limit=limit, order=order)
       
       
      Regards
       
      --Francesco
       
      Il giorno mar 19 nov 2024 alle ore 14:13 Daniel Reis <notifications@odoo-community.org> ha scritto:
      From your description, it feels like this is already available in standard Odoo:
      The "ref" field is to be used for Client codes

      The code is no longer presented in front of the name.
      I think an OCA module is needed to bring that feature back.

      /Daniel

      On 19/11/2024 09:22, Redes Sociales JLBBERP wrote:
      Hello everyone,
       
      I am writing this message because I need assistance with modifying how searching a client while doing a budget works.
       
      What I am trying to do is, instead of searching just by the name, I want it to work like the following: I made a custom field called "x_cliente_interno", which is a number to identify the client, and I would like to make the search work like how product search works: If you write either the product's ID or the product's name, it will show you both fields merged from the data you wrote. Something like this:
       
       
      And when you select it, it shows the data like this:
       
       
      To sum up, what I am trying to do is that when you search a client, the search shows you the field "x_cliente_interno" behind the client name, like this: "[x_cliente_interno] client name" and it should also stay like in the second image when selected.
       
      Thanks in advance for the help.

      --
      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]

      _______________________________________________
      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 Alejandro Párraga Alcázar - 09:46 - 26 Nov 2024

      2 attachments 2 attachments

      Part_1.png
      attachment
    • Re: [Odoo CE 17.0] Help needed with client search on budgets
      Hello Francesco,

      I have seen your message right now, and I would like to thank you so much for not only your answer, but also for you writing the code I should do. I do not know how could I pay you back this favor that you have done for me.
       
      I rely on the community because I am in my beginnings and because of everything that my company JLBB ERP has given me through good collaboration, I am now checking it out. Do not doubt that everything I can contribute, you will find me here.
       
      Thank you Francesco for the help.
       
      Salutations to the community.
      El 20/11/2024 0:02 CET Francesco Ballerini <notifications@odoo-community.org> escribió:
       
       
      I apologize, it is now clear to me also that you need both the search from a custom field and the way the name is displayed, but the search is indeed prioritized. 
       
      As Daniel and Xavier pointed out, in Odoo 17.0 you can already submit the "ref" field (field label on GUI is "Reference") and get the right record. E.g. if you have a contact named John Doe with Reference set on "ab-001" and you search for "ab-001" in the contacts search or dropdown you will fetch John Doe. 
       
      You could migrate your "x_cliente_interno" data into the "ref" field, and this would automatically unlock the search feature. However if you need to keep this data in a specific custom field you will need to override _name_search() method. 
      In every case you will also need to override _compute_display_name if you want to also show the code before the field. I provided a couple of snippet below (just as an example, especially the _name_search override needs to be refined).
       
      Let me point out another thing: from the field name I assume you are using a field defined from GUI, unfortunately it's not recommended to use those kind of fields in python methods as it will easily lead to inconsistencies and bugs (e.g. if you delete field from db and not remove it from python methods..). This means that if you want to use a custom field in _name_search() override you should migrate data to a standard field aniway.

      This is an example of what you might do on a custom module. As you can see the _name_search() implementation has to be refined while the_compute_display_name method will work as is. 
      If you decide to migrate data into the "ref" field you can only implement _compute_display_name by replacing "cliente_interno" with "ref" and you do not need to implement _name_search() in this case.
       
      from odoo import models, fields, api
      from odoo.osv import expression

      class ResPartner(models.Model):
      _inherit = "res.partner"

      cliente_interno = fields.Char() # use a standard field for consistency

      @api.depends("name", "cliente_interno")
      def _compute_display_name(self):
      """Show reference code before partner name"""
      super()._compute_display_name()
      for partner in self:
      name = partner.name or "unknown"
      cliente_interno = f"[{partner.cliente_interno}] " if partner.cliente_interno else ""
      # !! Disclaimer !!
      #I f you copy this code and change it DO NOT ASSIGN the value of partner.name,
      # that would compromise your datas. Only re-assign partner.display_name
      partner.display_name = cliente_interno + name

      @api.model
      def _name_search(self, name, domain=None, operator='ilike', limit=None, order=None):
      """Add custom field `cliente_interno` to the search domain"""
      domain = expression.OR([domain or [], [("cliente_interno", operator, name)]])
      # this doesn't work properly, it seems like the domain we pass gets overridden,
      # might take this as example and adjust by debugging/find more examples on source code
      return super()._name_search(name, domain=domain, operator=operator, limit=limit, order=order)
       
       
      Regards
       
      --Francesco
       
      Il giorno mar 19 nov 2024 alle ore 14:13 Daniel Reis <notifications@odoo-community.org> ha scritto:
      From your description, it feels like this is already available in standard Odoo:
      The "ref" field is to be used for Client codes

      The code is no longer presented in front of the name.
      I think an OCA module is needed to bring that feature back.

      /Daniel

      On 19/11/2024 09:22, Redes Sociales JLBBERP wrote:
      Hello everyone,
       
      I am writing this message because I need assistance with modifying how searching a client while doing a budget works.
       
      What I am trying to do is, instead of searching just by the name, I want it to work like the following: I made a custom field called "x_cliente_interno", which is a number to identify the client, and I would like to make the search work like how product search works: If you write either the product's ID or the product's name, it will show you both fields merged from the data you wrote. Something like this:
       
       
      And when you select it, it shows the data like this:
       
       
      To sum up, what I am trying to do is that when you search a client, the search shows you the field "x_cliente_interno" behind the client name, like this: "[x_cliente_interno] client name" and it should also stay like in the second image when selected.
       
      Thanks in advance for the help.

      --
      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]

      _______________________________________________
      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 Alejandro Párraga Alcázar - 09:26 - 20 Nov 2024

      1 attachments 1 attachments

      attachment
    • Re: [Odoo CE 17.0] Help needed with client search on budgets 
      > I apologize, it is now clear to me also that you need both the search from a

> custom field and the way the name is displayed, but the search is indeed

> prioritized.

anybody interested in only the searching part can use
https://apps.odoo.com/apps/modules/16.0/base_name_search_improved
without typing any code. The migration to v17 happened in
https://github.com/OCA/server-tools/pull/2831

Could be worthwhile to add a companion to this module allowing to configure the 
display name via UI too.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
      by Holger Brunn - 02:55 - 20 Nov 2024

      1 attachments 1 attachments

      signature.asc
    • Re: [Odoo CE 17.0] Help needed with client search on budgets
      I apologize, it is now clear to me also that you need both the search from a custom field and the way the name is displayed, but the search is indeed prioritized. 

      As Daniel and Xavier pointed out, in Odoo 17.0 you can already submit the "ref" field (field label on GUI is "Reference") and get the right record. E.g. if you have a contact named John Doe with Reference set on "ab-001" and you search for "ab-001" in the contacts search or dropdown you will fetch John Doe. 

      You could migrate your "x_cliente_interno" data into the "ref" field, and this would automatically unlock the search feature. However if you need to keep this data in a specific custom field you will need to override _name_search() method. 
      In every case you will also need to override _compute_display_name if you want to also show the code before the field. I provided a couple of snippet below (just as an example, especially the _name_search override needs to be refined).

      Let me point out another thing: from the field name I assume you are using a field defined from GUI, unfortunately it's not recommended to use those kind of fields in python methods as it will easily lead to inconsistencies and bugs (e.g. if you delete field from db and not remove it from python methods..). This means that if you want to use a custom field in _name_search() override you should migrate data to a standard field aniway.

      This is an example of what you might do on a custom module. As you can see the _name_search() implementation has to be refined while the_compute_display_name method will work as is. 
      If you decide to migrate data into the "ref" field you can only implement _compute_display_name by replacing "cliente_interno" with "ref" and you do not need to implement _name_search() in this case.

      from odoo import models, fields, api
      from odoo.osv import expression

      class ResPartner(models.Model):
      _inherit = "res.partner"

      cliente_interno = fields.Char() # use a standard field for consistency

      @api.depends("name", "cliente_interno")
      def _compute_display_name(self):
      """Show reference code before partner name"""
      super()._compute_display_name()
      for partner in self:
      name = partner.name or "unknown"
      cliente_interno = f"[{partner.cliente_interno}] " if partner.cliente_interno else ""
      # !! Disclaimer !!
      #I f you copy this code and change it DO NOT ASSIGN the value of partner.name,
      # that would compromise your datas. Only re-assign partner.display_name
      partner.display_name = cliente_interno + name

      @api.model
      def _name_search(self, name, domain=None, operator='ilike', limit=None, order=None):
      """Add custom field `cliente_interno` to the search domain"""
      domain = expression.OR([domain or [], [("cliente_interno", operator, name)]])
      # this doesn't work properly, it seems like the domain we pass gets overridden,
      # might take this as example and adjust by debugging/find more examples on source code
      return super()._name_search(name, domain=domain, operator=operator, limit=limit, order=order)



      Regards

      --Francesco

      Il giorno mar 19 nov 2024 alle ore 14:13 Daniel Reis <notifications@odoo-community.org> ha scritto:
      From your description, it feels like this is already available in standard Odoo:
      The "ref" field is to be used for Client codes

      The code is no longer presented in front of the name.
      I think an OCA module is needed to bring that feature back.

      /Daniel

      On 19/11/2024 09:22, Redes Sociales JLBBERP wrote:
      Hello everyone,
       
      I am writing this message because I need assistance with modifying how searching a client while doing a budget works.
       
      What I am trying to do is, instead of searching just by the name, I want it to work like the following: I made a custom field called "x_cliente_interno", which is a number to identify the client, and I would like to make the search work like how product search works: If you write either the product's ID or the product's name, it will show you both fields merged from the data you wrote. Something like this:
       
       
      And when you select it, it shows the data like this:
       
       
      To sum up, what I am trying to do is that when you search a client, the search shows you the field "x_cliente_interno" behind the client name, like this: "[x_cliente_interno] client name" and it should also stay like in the second image when selected.
       
      Thanks in advance for the help.

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


      --
      DANIEL REIS
      MANAGING PARTNER

      >> Schedule time on my calendar.
      M: +351 919 991 307
      E: dreis@OpenSourceIntegrators.com
      A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

      [Logo OpenSourceIntegrators.com]

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

      by Francesco Ballerini - 12:00 - 20 Nov 2024

  • [odoo16 ce] deploy doodba instance on portainer
    Hi, 

    few days ago I managed to set up a basic doodba instance. We're running this as "prod env" but we're actually just testing it at the moment. The instance is running well, but I've been asked to run this configuration from Portainer if possible.

    I'm trying to make some adaptations in order to make it work on portainer, I merged the `common.yaml` and `prod.yaml` in a single compose, added the result in the stack web editor, with some additional adjustments. However I am not sure how to solve this. 

    ```
    build:
          context: ./odoo
          args:
            DB_VERSION: "15"
            ODOO_VERSION: "16.0"
            UID: "${UID:-1000}"
            GID: "${GID:-1000}"
    ```

    when I try to deploy it says that "build" is an unsupported option. Is there any way to adapt this? 
    I would also like to ask if someone has to link an example on github or any other platform, I havent find any yet.

    Thank you
    --Francesco


    by Francesco Ballerini - 10:01 - 17 Nov 2024

    4 replies 4 replies

    • Re: [odoo16 ce] deploy doodba instance on portainer
      Thank you Enric, I didn't customize the image yet as I'm still exploring the Doodba environment in my spare time and thus progressing gradually with this task :-) 
      I’ll definitely keep your suggestion in mind. Once again, thank you all for the support.

      Cheers

      --Francesco

      Il giorno lun 18 nov 2024 alle ore 00:02 Enric Tobella Alomar <notifications@odoo-community.org> ha scritto:
      On the creation of the doodba, you were able to set where to store the image.

      Just use copier update to reset the values and set it to a registry of your own choice.

      Kind regards,

      El dom, 17 nov 2024 a las 23:22, Francesco Ballerini (<notifications@odoo-community.org>) escribió:
      Oh.. right, after I read your answer I feel like I made a dumb question, well, it is neither the first nor the last time ; ) 

      As a developer who is starting to explore the world of deployment, I find your advice very helpful, thanks Graeme. 

      --Francesco

      Il giorno dom 17 nov 2024 alle ore 22:27 Graeme Gellatly <notifications@odoo-community.org> ha scritto:
      It makes no sense to build in a production compose file (note, this is not to say Doodba is wrong, as it needs instructions to make a production build, but that in a real prod environment you wouldn't). You are just pulling an image. Provided you link to your already built image you don't need any of that. Your CI will have the build instructions, tag the image etc, and then you are just pulling it.

      On Mon, Nov 18, 2024 at 10:02 AM Francesco Ballerini <notifications@odoo-community.org> wrote:
      Hi, 

      few days ago I managed to set up a basic doodba instance. We're running this as "prod env" but we're actually just testing it at the moment. The instance is running well, but I've been asked to run this configuration from Portainer if possible.

      I'm trying to make some adaptations in order to make it work on portainer, I merged the `common.yaml` and `prod.yaml` in a single compose, added the result in the stack web editor, with some additional adjustments. However I am not sure how to solve this. 

      ```
      build:
            context: ./odoo
            args:
              DB_VERSION: "15"
              ODOO_VERSION: "16.0"
              UID: "${UID:-1000}"
              GID: "${GID:-1000}"
      ```

      when I try to deploy it says that "build" is an unsupported option. Is there any way to adapt this? 
      I would also like to ask if someone has to link an example on github or any other platform, I havent find any yet.

      Thank you
      --Francesco


      _______________________________________________
      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 Francesco Ballerini - 09:46 - 21 Nov 2024
    • Re: [odoo16 ce] deploy doodba instance on portainer
      On the creation of the doodba, you were able to set where to store the image.

      Just use copier update to reset the values and set it to a registry of your own choice.

      Kind regards,

      El dom, 17 nov 2024 a las 23:22, Francesco Ballerini (<notifications@odoo-community.org>) escribió:
      Oh.. right, after I read your answer I feel like I made a dumb question, well, it is neither the first nor the last time ; ) 

      As a developer who is starting to explore the world of deployment, I find your advice very helpful, thanks Graeme. 

      --Francesco

      Il giorno dom 17 nov 2024 alle ore 22:27 Graeme Gellatly <notifications@odoo-community.org> ha scritto:
      It makes no sense to build in a production compose file (note, this is not to say Doodba is wrong, as it needs instructions to make a production build, but that in a real prod environment you wouldn't). You are just pulling an image. Provided you link to your already built image you don't need any of that. Your CI will have the build instructions, tag the image etc, and then you are just pulling it.

      On Mon, Nov 18, 2024 at 10:02 AM Francesco Ballerini <notifications@odoo-community.org> wrote:
      Hi, 

      few days ago I managed to set up a basic doodba instance. We're running this as "prod env" but we're actually just testing it at the moment. The instance is running well, but I've been asked to run this configuration from Portainer if possible.

      I'm trying to make some adaptations in order to make it work on portainer, I merged the `common.yaml` and `prod.yaml` in a single compose, added the result in the stack web editor, with some additional adjustments. However I am not sure how to solve this. 

      ```
      build:
            context: ./odoo
            args:
              DB_VERSION: "15"
              ODOO_VERSION: "16.0"
              UID: "${UID:-1000}"
              GID: "${GID:-1000}"
      ```

      when I try to deploy it says that "build" is an unsupported option. Is there any way to adapt this? 
      I would also like to ask if someone has to link an example on github or any other platform, I havent find any yet.

      Thank you
      --Francesco


      _______________________________________________
      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

      by Enric Tobella Alomar - 12:01 - 18 Nov 2024
    • Re: [odoo16 ce] deploy doodba instance on portainer
      Oh.. right, after I read your answer I feel like I made a dumb question, well, it is neither the first nor the last time ; ) 

      As a developer who is starting to explore the world of deployment, I find your advice very helpful, thanks Graeme. 

      --Francesco

      Il giorno dom 17 nov 2024 alle ore 22:27 Graeme Gellatly <notifications@odoo-community.org> ha scritto:
      It makes no sense to build in a production compose file (note, this is not to say Doodba is wrong, as it needs instructions to make a production build, but that in a real prod environment you wouldn't). You are just pulling an image. Provided you link to your already built image you don't need any of that. Your CI will have the build instructions, tag the image etc, and then you are just pulling it.

      On Mon, Nov 18, 2024 at 10:02 AM Francesco Ballerini <notifications@odoo-community.org> wrote:
      Hi, 

      few days ago I managed to set up a basic doodba instance. We're running this as "prod env" but we're actually just testing it at the moment. The instance is running well, but I've been asked to run this configuration from Portainer if possible.

      I'm trying to make some adaptations in order to make it work on portainer, I merged the `common.yaml` and `prod.yaml` in a single compose, added the result in the stack web editor, with some additional adjustments. However I am not sure how to solve this. 

      ```
      build:
            context: ./odoo
            args:
              DB_VERSION: "15"
              ODOO_VERSION: "16.0"
              UID: "${UID:-1000}"
              GID: "${GID:-1000}"
      ```

      when I try to deploy it says that "build" is an unsupported option. Is there any way to adapt this? 
      I would also like to ask if someone has to link an example on github or any other platform, I havent find any yet.

      Thank you
      --Francesco


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

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

      by Francesco Ballerini - 11:21 - 17 Nov 2024
    • Re: [odoo16 ce] deploy doodba instance on portainer
      It makes no sense to build in a production compose file (note, this is not to say Doodba is wrong, as it needs instructions to make a production build, but that in a real prod environment you wouldn't). You are just pulling an image. Provided you link to your already built image you don't need any of that. Your CI will have the build instructions, tag the image etc, and then you are just pulling it.

      On Mon, Nov 18, 2024 at 10:02 AM Francesco Ballerini <notifications@odoo-community.org> wrote:
      Hi, 

      few days ago I managed to set up a basic doodba instance. We're running this as "prod env" but we're actually just testing it at the moment. The instance is running well, but I've been asked to run this configuration from Portainer if possible.

      I'm trying to make some adaptations in order to make it work on portainer, I merged the `common.yaml` and `prod.yaml` in a single compose, added the result in the stack web editor, with some additional adjustments. However I am not sure how to solve this. 

      ```
      build:
            context: ./odoo
            args:
              DB_VERSION: "15"
              ODOO_VERSION: "16.0"
              UID: "${UID:-1000}"
              GID: "${GID:-1000}"
      ```

      when I try to deploy it says that "build" is an unsupported option. Is there any way to adapt this? 
      I would also like to ask if someone has to link an example on github or any other platform, I havent find any yet.

      Thank you
      --Francesco


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

      by Graeme Gellatly - 10:26 - 17 Nov 2024