Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • 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: [SPAM] Re: Odoo OpenUpgrade Wizard status ? 
    hello,

thank you holger for mentioning your script, which i did not know about. i did not look into it yet to understand its internals, but its goal seem very similar to the one of odoo openupgrade wizard (oow for short). i would love to see an effort inside the oca to bring people together around one solution to avoid wasted efforts everywhere.

when we started the oow project with sylvain and rémy almost 3 years ago (already!), it was because of discussions between us about all the effort that is required to set up a correct environment to run openupgrade and how time-consuming mistakes can be in that process, as feedback is really slow, especially with huge databases.

at coop it easy we had a set of (bash) scripts to help run migrations and sylvain at grap had already created something more advanced in python. oow is the evolution of sylvain’s tool, with contributions mainly from rémy.

concerning its maturity, it has evolved quite a bit since its inception, and at coop it easy we’ve been using it for all of our client migrations since last year. that said, it’s not perfect: it’s quite opinionated and still a little rough around the edges (for example: debugging docker build errors requires to relaunch the command manually to see the output), but i’ve personally been using it to migrate multiple databases, most of them simultaneously using the same environment.

in summary: it’s ready for production use. feel free to use it and report issues or propose fixes and improvements.

in the long run, we think it should be part of oca’s tooling.

kind regards,

hugues
    by hugues - 11:41 - 15 Jan 2025
  • Re: archiving vendor 
    You are right. The PO doesn't get archived but I can't find it anymore 
in the PO list view when searching for the vendor name of an archived 
vendor. That's confusing but something we can deal with now that we know it.

Am 14.01.25 um 17:18 schrieb Daniel Reis:

> AFAIK this is not an Odoo behavior: archiving a contact does not archive 

> the related POs.

> In fact, out of the box you can't even archive POs.

> 

> /Daniel

> 

> 

> On 14/01/2025 13:39, Jan Suhr | Nitrokey wrote:

>> Hi!

>> This is more a functional question and hope this is the right channel

>> for such.

>>

>> We have vendors configured as "parent contact" and many of them have

>> several contacts (employee) which we configure as "child contacts". In

>> Purchase we address queries to an individual contact so that it is send

>> to his email address directly. Now we figured if a vendor contact leaves

>> the company we would like to archive the partner record in Odoo. But in

>> consequence all his POs are archived too, which is not what we want

>> because the history of POs is still relevant. Do you have

>> recommendations how to handle this better?

>>

>> Best regards

>> Jan

>>

>> _______________________________________________

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

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

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

>> <mailto:contributors@odoo-community.org>

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

>> odoo-community.org/groups?unsubscribe>

>>

> 

> -- 

> *DANIEL REIS*

> MANAGING PARTNER

> 

>  >> Schedule time on my calendar <https://meetings.hubspot.com/dreis1>.

> *M:* +351 919 991 307

> *E:* dreis@OpenSourceIntegrators.com 

> <mailto:dreis@OpenSourceIntegrators.com>

> *A:* Avenida da República 3000, Estoril Office Center, 2649-517 Cascais

> 

> [Logo OpenSourceIntegrators.com] <https://www.opensourceintegrators.com/>

> 

> _______________________________________________

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

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

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

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

> odoo-community.org/groups?unsubscribe>

>
    by Jan Suhr - 08:36 - 15 Jan 2025
  • Re: archiving vendor
    They probably just aren't searchable. I have had an open bug report with Odoo for years about not being able to import / export records with a user_id field where the user has been archived. Will be same thing.

    On Wed, Jan 15, 2025 at 5:17 AM Daniel Reis <notifications@odoo-community.org> wrote:
    AFAIK this is not an Odoo behavior: archiving a contact does not archive the related POs.
    In fact, out of the box you can't even archive POs.

    /Daniel


    On 14/01/2025 13:39, Jan Suhr | Nitrokey wrote:
    Hi!
This is more a functional question and hope this is the right channel 
for such.

We have vendors configured as "parent contact" and many of them have 
several contacts (employee) which we configure as "child contacts". In 
Purchase we address queries to an individual contact so that it is send 
to his email address directly. Now we figured if a vendor contact leaves 
the company we would like to archive the partner record in Odoo. But in 
consequence all his POs are archived too, which is not what we want 
because the history of POs is still relevant. Do you have 
recommendations how to handle this better?

Best regards
Jan

    _______________________________________________
    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 Graeme Gellatly - 10:10 - 14 Jan 2025
  • Re: [NEWS] oca-port: a new version has been released!
    Hello everyone,

    I wanted to let you know that a blog post has been written in collaboration with Sébastien to explain more about the oca-port project.

    Link:

    Thanks again to Sébastien and the other contributors for this nice tool!
    Virginie Dewulf
    Executive Director
    +32 477 64 17 20


    Le jeu. 21 nov. 2024 à 00:08, Rolando Pérez Rebollo <notifications@odoo-community.org> a écrit :

    thank U sebastian, I'm already thinking in some use cases at hand. I'll checkout the talks.

    On 11/20/24 11:32, Sebastien Alix wrote:

    Yes exactly it is a helper, but it won't do everything automatically sadly :)

    When it comes to migrate a module, it'll play the usual "git format-patch" command and pre-commit for you, and will print the next steps (and the link of the OCA migration guide you just provided).

    But its main strength is to compare two different git history (e.g. 14.0 and 16.0) for a module already migrated but which evolved overtime in 14.0, and list missing commits from 14.0 in 16.0, and "help" you to port them, example here some ports for the module 'account_invoice_section_sale_order', one branch after another:

    Basically it's mostly a helper to forward-port and backport (switch the branches!) commits from one branch/repo to another.

    Here are talks that were made about this tool:

    Yes, I'm not good to promote things, will try to improve that!

    Le 20/11/2024 à 15:52, Rolando Pérez Rebollo a écrit :

    Wow, are there any OCA talks or similar about this? I've just discovered. From the readme looks like could assist in the migration of addons. Is It a helper that replace manual work when doing stuff like https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-16.0?

    On 11/20/24 06:13, Mignon, Laurent wrote:
    Thank you Sébastion for this useful and powerful tool!

    On Wed, Nov 20, 2024 at 11:47 AM David Vidal <notifications@odoo-community.org> wrote:
    Thanks for the great work!

    El mié, 20 nov 2024 a las 11:38, Sebastien Alix (<notifications@odoo-community.org>) escribió:

    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/

    _______________________________________________
    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

    -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.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 Virginie Dewulf - 05:26 - 14 Jan 2025
  • Re: archiving vendor
    AFAIK this is not an Odoo behavior: archiving a contact does not archive the related POs.
    In fact, out of the box you can't even archive POs.

    /Daniel


    On 14/01/2025 13:39, Jan Suhr | Nitrokey wrote:
    Hi!
This is more a functional question and hope this is the right channel 
for such.

We have vendors configured as "parent contact" and many of them have 
several contacts (employee) which we configure as "child contacts". In 
Purchase we address queries to an individual contact so that it is send 
to his email address directly. Now we figured if a vendor contact leaves 
the company we would like to archive the partner record in Odoo. But in 
consequence all his POs are archived too, which is not what we want 
because the history of POs is still relevant. Do you have 
recommendations how to handle this better?

Best regards
Jan

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

    by Daniel Reis - 05:16 - 14 Jan 2025
  • Re: archiving vendor
    Purchase orders are not archived when the vendor is archived.

    Regards.
    by Pedro M. Baeza - 05:01 - 14 Jan 2025
  • Re:archiving vendor

    ​Surely someone will come up with an OCA form that covers this case, but in the meantime what I would do is set a custom field like "resigned_date" on the contact and manage the information where relevant.​


    Da "Jan Suhr | Nitrokey" notifications@odoo-community.org
    A "Contributors" contributors@odoo-community.org
    Cc
    Data Tue, 14 Jan 2025 13:38:59 -0000
    Oggetto archiving vendor


    Hi!
This is more a functional question and hope this is the right channel 
for such.

We have vendors configured as "parent contact" and many of them have 
several contacts (employee) which we configure as "child contacts". In 
Purchase we address queries to an individual contact so that it is send 
to his email address directly. Now we figured if a vendor contact leaves 
the company we would like to archive the partner record in Odoo. But in 
consequence all his POs are archived too, which is not what we want 
because the history of POs is still relevant. Do you have 
recommendations how to handle this better?

Best regards
Jan

    _______________________________________________


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


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


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




    Stefano Consolaro


    www.mymage.it
    by Stefano Consolaro - 04:55 - 14 Jan 2025
  • archiving vendor 
    Hi!
This is more a functional question and hope this is the right channel 
for such.

We have vendors configured as "parent contact" and many of them have 
several contacts (employee) which we configure as "child contacts". In 
Purchase we address queries to an individual contact so that it is send 
to his email address directly. Now we figured if a vendor contact leaves 
the company we would like to archive the partner record in Odoo. But in 
consequence all his POs are archived too, which is not what we want 
because the history of POs is still relevant. Do you have 
recommendations how to handle this better?

Best regards
Jan
    by Jan Suhr - 02:37 - 14 Jan 2025
  • Re: Odoo OpenUpgrade Wizard status ?


    El mié, 8 ene 2025 a la(s) 9:17 a.m., Росен Владимиров (notifications@odoo-community.org) escribió:
    My experience: The logic of OpenUpgrade tools from OCA is not relevant in all cases. The tool is based on logic: Convert sql database with new version of modules and move version step by step and change all modules to have all versions.
    Better way is to prepare new versions with correct modules and to import from old records using the OdooRPC tool. I migrate from 11.0 to 16.0 and to 17.0 using my script The logic there is to import data from old databases to convert in script and to import results in new databases. The trick is to save an external indication link to the old database record id, after which it is possible to move data from the live old database importing again if something is changed. The problem of the script is to have experience in all versions to find differences in data.

    This option in huge DB's or, in most cases is incorrect. The ID of the record failed to keep it in track and business logic do not comply with odoo way of working, this way of migrate is valid only to reestart DB's


     

    Thanks,
    Rosen Vladimirov
    +359886100204


    На вт, 7.01.2025 г. в 15:52 Holger Brunn <notifications@odoo-community.org> написа:
    I can't comment on the maturity of this tool, but wrote one myself mainly with 
the idea to make the project more accessible for new contributors:
https://github.com/hbrunn/OpenUpgrade/tree/run-migration
(you'll have to replace oca with hbrunn in the code snippet)

As for the matureness of this: Works pretty well, but as anything relying on 
OpenUpgrade it's not very robust against malformed data or other unexpected 
conditions. So while things *can* work great without any user intervention, 
there's always a chance you'll need to adapt your data to the upgrade scripts' 
expectations (or change those), and that will usually require deep technical 
knowledge about the Odoo versions involved.




-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.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



    --
    Nhomar G. Hernández M.
    about.me/nhomar
    by Nhomar Hernández - 06:51 - 8 Jan 2025
  • Re: Odoo OpenUpgrade Wizard status ?
    My experience: The logic of OpenUpgrade tools from OCA is not relevant in all cases. The tool is based on logic: Convert sql database with new version of modules and move version step by step and change all modules to have all versions.
    Better way is to prepare new versions with correct modules and to import from old records using the OdooRPC tool. I migrate from 11.0 to 16.0 and to 17.0 using my script The logic there is to import data from old databases to convert in script and to import results in new databases. The trick is to save an external indication link to the old database record id, after which it is possible to move data from the live old database importing again if something is changed. The problem of the script is to have experience in all versions to find differences in data.

    Thanks,
    Rosen Vladimirov
    +359886100204


    На вт, 7.01.2025 г. в 15:52 Holger Brunn <notifications@odoo-community.org> написа:
    I can't comment on the maturity of this tool, but wrote one myself mainly with 
the idea to make the project more accessible for new contributors:
https://github.com/hbrunn/OpenUpgrade/tree/run-migration
(you'll have to replace oca with hbrunn in the code snippet)

As for the matureness of this: Works pretty well, but as anything relying on 
OpenUpgrade it's not very robust against malformed data or other unexpected 
conditions. So while things *can* work great without any user intervention, 
there's always a chance you'll need to adapt your data to the upgrade scripts' 
expectations (or change those), and that will usually require deep technical 
knowledge about the Odoo versions involved.



-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.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 Rosen Vladimirov - 04:15 - 8 Jan 2025
  • Re: [SPAM] PSC responsabilities
    Sorry for continuing the side topic:

    Yann,

    That fix is great, this issue has been annoying me for a long time... have you considered proposing the patch to Odoo itself?

    Thanks!

    On Thu, Jan 2, 2025 at 8:57 AM Yann Papouin <notifications@odoo-community.org> wrote:

    Le lun. 30 déc. 2024 à 11:33, Pedro M. Baeza <notifications@odoo-community.org> a écrit :
    I'm afraid images are not shown when attached in Odoo mailing groups.

    Regards.

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

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



    --
    Lois Rilo Antelo
    ERP Consultant Manager at ForgeFlow S.L.
    by Lois Rilo Antelo - 04:00 - 8 Jan 2025
  • Re: Odoo OpenUpgrade Wizard status ? 
    I can't comment on the maturity of this tool, but wrote one myself mainly with 
the idea to make the project more accessible for new contributors:
https://github.com/hbrunn/OpenUpgrade/tree/run-migration
(you'll have to replace oca with hbrunn in the code snippet)

As for the matureness of this: Works pretty well, but as anything relying on 
OpenUpgrade it's not very robust against malformed data or other unexpected 
conditions. So while things *can* work great without any user intervention, 
there's always a chance you'll need to adapt your data to the upgrade scripts' 
expectations (or change those), and that will usually require deep technical 
knowledge about the Odoo versions involved.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
    by Holger Brunn - 02:51 - 7 Jan 2025

    1 attachments 1 attachments

    signature.asc
  • Re: Odoo OpenUpgrade Wizard status ?

    Interesting and -as per the idea- very valuable effort but it is not part of the "official" OCA tools / code as it resides in a repo outside GH. Maybe https://gitlab.com/legalsylvain and Rémy Taymans as the inventors of this can comment on its state of maturity and even better potential future ideas of injecting it to the official OCA repos

    Best Frederik

    Am 07.01.25 um 11:43 schrieb Rolando Pérez Rebollo:

    Hello dear friends,

    I'm exploring the idea of using Odoo OpenUpgrade Wizard for some customer upgrade projects. From the OCA presentation, it seems like a promising tool.

    The GitLab repository appears active, with the latest release in November. However, I’m wondering if it’s mature enough for production use or if it’s still in its early stages. Is the potential of being an early adopter worth it?

    Is anyone here actively using it in their projects? I’d love to hear your thoughts or experiences!

    --
    Binhex Logo
    Rolando Pérez Rebollo
    Python and Javascript Senior Developer
    Binhex
    r.perez@binhex.cloud
    Office (Spain) : +34 822 17 92 67
    Office (USA): +1 305 686 8151
    Offices:
    Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
    Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
    Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
    Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
    LinkedIn Twitter Facebook YouTube
    Start for free: Try Odoo Community in the cloud

    This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
    Privacy Policy

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

    -- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247
    by Frederik Kramer - 11:56 - 7 Jan 2025
  • Re: Odoo OpenUpgrade Wizard status ?

    Interesting and -as per the idea- very valuable effort but it is not part of the "official" OCA tools / code as it resides in a repo outside GH. Maybe https://gitlab.com/legalsylvain and Rémy Taymans as the inventors of this can comment on its state of maturity and even better potential future ideas of injecting it to the official OCA repos

    Best Frederik

    Am 07.01.25 um 11:43 schrieb Rolando Pérez Rebollo:

    Hello dear friends,

    I'm exploring the idea of using Odoo OpenUpgrade Wizard for some customer upgrade projects. From the OCA presentation, it seems like a promising tool.

    The GitLab repository appears active, with the latest release in November. However, I’m wondering if it’s mature enough for production use or if it’s still in its early stages. Is the potential of being an early adopter worth it?

    Is anyone here actively using it in their projects? I’d love to hear your thoughts or experiences!

    --
    Binhex Logo
    Rolando Pérez Rebollo
    Python and Javascript Senior Developer
    Binhex
    r.perez@binhex.cloud
    Office (Spain) : +34 822 17 92 67
    Office (USA): +1 305 686 8151
    Offices:
    Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
    Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
    Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
    Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
    LinkedIn Twitter Facebook YouTube
    Start for free: Try Odoo Community in the cloud

    This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
    Privacy Policy

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

    -- 
Dr.-Ing. Frederik Kramer
Geschäftsführer

initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.

Tel:   +49 (0) 4181 13503 12
Fax:   +49 (0) 4181 13503 10
Mobil: +49 (0) 179 3901819

Email: frederik.kramer@initos.com
Internet: www.initos.com

Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
USt-IdNr.: DE815580155
Steuer-Nr: 15/200/53247
    by Frederik Kramer - 11:56 - 7 Jan 2025
  • Odoo OpenUpgrade Wizard status ?

    Hello dear friends,

    I'm exploring the idea of using Odoo OpenUpgrade Wizard for some customer upgrade projects. From the OCA presentation, it seems like a promising tool.

    The GitLab repository appears active, with the latest release in November. However, I’m wondering if it’s mature enough for production use or if it’s still in its early stages. Is the potential of being an early adopter worth it?

    Is anyone here actively using it in their projects? I’d love to hear your thoughts or experiences!

    --
    Binhex Logo
    Rolando Pérez Rebollo
    Python and Javascript Senior Developer
    Binhex
    r.perez@binhex.cloud
    Office (Spain) : +34 822 17 92 67
    Office (USA): +1 305 686 8151
    Offices:
    Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
    Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
    Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
    Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
    LinkedIn Twitter Facebook YouTube
    Start for free: Try Odoo Community in the cloud

    This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
    Privacy Policy
    by Rolando Perez Rebollo - 11:42 - 7 Jan 2025
  • Re: PSC responsabilities
    These same KPI could be a good indicator for contributors to invite to become PSC. Certainly a better heuristic than intermittent self-nominations?

    On Mon, Dec 30, 2024 at 4:17 AM Enric Tobella Alomar <notifications@odoo-community.org> wrote:
    Hi everyone,

    I was preparing this year Ranking of contributors and I am concerned on some information I found when crossing this data with PSCs.

    I found several PSCs that are not involved into their respective repositories. For example, I found a PSC team that has 5 members, 3 of them participated in 1% of the PR, on of them on the 15% and the last one on 98%. The repository was big (more than 400 PR on one year). In other examples, the PSC only participated in their team PRs.

    Even in my case, I think I need to improve my collaboration as a PSC.

    I think we need to improve this situation as a Community, otherwise, people will loose faith in the PSCs and how OCA works. Some ideas I can think about:

    - Control PSCs on big repositories (it is hard to set a proper KPI on small repos)
    - Demote PSCs that are not contributing properly according to this KPIs
    - Review this KPIs yearly
    - Split bigger PSCs in order to avoid too much work
    - Avoid people to be PSC of more than 3 big PSC Teams
    - Give PSCs some extra benefits (lower fees on OCA days, special t-shirts...)
    - Give PSCs recognition of their work (easy to say, hard to think about it)

    Maybe I am dramatic here, but I think it is important. WDYT? Shall we do something about it?

    Kind regards,

    --
    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 Adam Heinz - 02:41 - 4 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: [SPAM] PSC responsabilities

    Le lun. 30 déc. 2024 à 11:33, Pedro M. Baeza <notifications@odoo-community.org> a écrit :
    I'm afraid images are not shown when attached in Odoo mailing groups.

    Regards.

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

    by Yann Papouin - 08:56 - 2 Jan 2025