Contributors

Mass Import of Products with Dynamic Attributes in Odoo 17 for Sales Orders.

I have some doubts, I am participating in a project to implement the ODOO system in version 17, I need to create products with their variants using the dynamic method, and then upload the new articles created in bulk.
I have two specific questions:
1. How can new items (SKUs) be uploaded en masse to a sales order, when the attributes are dynamic?
2. Is there a template to do this?

Regards.
HF.

by Hugo Ferrer - 06:07 - 20 Jan 2025
Questions about ODOO v.17 - Mass creation of items in purchase orders.

Good afternoon, Community.
I have a question, I am participating in an implementation project of the ODOO system in version 17, I need to create products with their variants dynamically, and then upload the items in bulk, to a purchase order, my partner tells me that this is not possible, I must do it from the sales order, and then create the purchase order manually, I cannot create the items in bulk. That causes a problem for me because my purchase orders contain up to 1000 SKU´s This is a restriction that complicates my operations at the purchasing level. I want to ask you if there is a solution if there is something that we and our partner are not seeing in the process.

I appreciate your support.

Regards.
HF

by Hugo Ferrer - 06:07 - 20 Jan 2025
1 replies 1 replies
Re: Questions about ODOO v.17 - Mass creation of items in purchase orders.

If you have the website_sale module installed, you can call product.template create_product_variant [1] idempotently via XML-RPC to create product variants on demand. Under the hood, that simply calls product.template _create_product_variant [2] in the product module, but you can't call that directly via XML-RPC since the function is private (indicated by the leading underscore in the name).

[1] https://github.com/odoo/odoo/blob/dc1cbcfec29d2434a842cbd668c9d800665b2cbe/addons/website_sale/models/product_template.py#L572
[2] https://github.com/odoo/odoo/blob/dc1cbcfec29d2434a842cbd668c9d800665b2cbe/addons/product/models/product_template.py#L1125

On Tue, Jan 21, 2025 at 7:22 AM hugo.ferrer <notifications@odoo-community.org> wrote:
Good afternoon, Community.
I have a question, I am participating in an implementation project of the ODOO system in version 17, I need to create products with their variants dynamically, and then upload the items in bulk, to a purchase order, my partner tells me that this is not possible, I must do it from the sales order, and then create the purchase order manually, I cannot create the items in bulk. That causes a problem for me because my purchase orders contain up to 1000 SKU´s This is a restriction that complicates my operations at the purchasing level. I want to ask you if there is a solution if there is something that we and our partner are not seeing in the process.

I appreciate your support.

Regards.
HF

_______________________________________________
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 - 21 Jan 2025
Members update of PSC team Finland
Dear maintainer of the web page https://odoo-community.org/psc-teams/finland-63 Jarmo Kortetjärvi (jarmo.kortetjarvi@futural.fi, https://odoo-community.org/partners/oy-tawasta-os-technologies-ltd-jarmo-kortetjarvi-2267) has been nominated as the OCA representative of the PSC team Finland. I, Jussi Lehto (https://odoo-community.org/members/ab-cetmix-nordic-oy-jussi-lehto-30807), have been nominated as a member. Due to inactivity, Henri Alasentie and Miku Laitinen have resigned. Please update the PSC team Finland web page according to the updates. I appreciate any help you can provide. ystävällisin terveisin / kind regards, -- Jussi Lehto Country Managing Partner (Finland) Cetmix® https://www.cetmix.fi e-mail: jussi.lehto@cetmix.com tel. +358 40 192 8404
by Jussi Lehto - 03:31 - 19 Jan 2025
2 replies 2 replies
Re: Members update of PSC team Finland

There's a channel contribute@odoo-community.org for notifying these things. On the technical side, you can make a pull request in https://github.com/OCA/repo-maintainer-conf with the needed changes, but not all the members see that one.

Regards.

by Pedro M. Baeza - 05:01 - 24 Feb 2025

Re: Members update of PSC team Finland

Hi

The page haven't been updated. Can anyone please advice what is the process to update the PSC members?

with kind regards,

Jussi Lehto

From: jussi.lehto@cetmix.com <jussi.lehto@cetmix.com>
Sent: Sunday, January 19, 2025 4:27:31 am
To: contributors@odoo-community.org <contributors@odoo-community.org>
Subject: Members update of PSC team Finland

Dear maintainer of the web page https://odoo-community.org/psc-teams/finland-63

Jarmo Kortetjärvi (jarmo.kortetjarvi@futural.fi, https://odoo-community.org/partners/oy-tawasta-os-technologies-ltd-jarmo-kortetjarvi-2267) has been nominated as the OCA representative of the PSC team Finland. I, Jussi Lehto (https://odoo-community.org/members/ab-cetmix-nordic-oy-jussi-lehto-30807), have been nominated as a member. Due to inactivity, Henri Alasentie and Miku Laitinen have resigned.

Please update the PSC team Finland web page according to the updates. I appreciate any help you can provide.

ystävällisin terveisin / kind regards,

--
Jussi Lehto
Country Managing Partner (Finland)
Cetmix®
https://www.cetmix.fi

e-mail: jussi.lehto@cetmix.com
tel. +358 40 192 8404

by Jussi Lehto - 04:56 - 24 Feb 2025
OCA Code Sprint - Brussels - 30 + 31 January
Hello OCA Contributors,

I hope 2025 is treating you well so far.

I just wanted to remind you we have our code sprint in Brussels coming up on the 30th and 31st of January. Just a couple of weeks away. We thought, as people might be in town for FOSDEM we would harness the opportunity to encourage people to meet up.

You can attend for just one day or both, completely up to you.

You can register here: https://odoo-community.org/event/oca-codeprint-brussels-2025-01-30-2025-02-01-158/register
The small price is just to cover lunches and refreshments.

We will run remotely too.

To help prepare:
Working document for the sprint is here. It is great to fill in beforehand to help focus the work at the event.
Discord Channel is here. This way our remote companions can join in too!
We look forward to seeing those that can make it.
Rebecca

--
Rebecca Gellatly
General Secretary
Odoo Community Association
by Rebecca Gellatly - 05:35 - 17 Jan 2025
4 replies 4 replies
Re: OCA Code Sprint - Brussels - 30 + 31 January

That is wonderful Peter. There are a number of very experienced contributors attending too and I am sure they will give you great help onboarding.

Virginie Dewulf our Executive Director will be in attendance as well as 2 board members, so you will be in great hands with any help/guidance needed.

Enjoy your time.
Rebecca

On Thu, 30 Jan 2025 at 11:12, Peter Niederlag <notifications@odoo-community.org> wrote:
Hi, I'll arrive thursday and have no clue yet on where I could dive in. So if there is any "hop on" for newbies, I'd be quite interested as im not very much involved with the community up to now. hope to meet some of you over there, sincere greets, Peter On 21.01.25 13:49, Rebecca Gellatly wrote: > Hello OCA Contributors, > > I hope 2025 is treating you well so far. > > I just wanted to remind you we have our code sprint in Brussels coming > up on the 30th and 31st of January. Just a couple of weeks away. We > thought, as people might be in town for FOSDEM we would harness the > opportunity to encourage people to meet up. > > You can attend for just one day or both, completely up to you. > > You can register here: > https://odoo-community.org/event/oca-codeprint-brussels-2025-01-30-2025-02-01-158/register <https://odoo-community.org/event/oca-codeprint-brussels-2025-01-30-2025-02-01-158/register> > The small price is just to cover lunches and refreshments. > > /We will run remotely too./ > > *To help prepare:* > > * Working document for the sprint is here > <https://docs.google.com/document/d/1EIDkXd8QaeZ1bj63gJcS-EUW9cTZLCCS7vrmx_LB_kQ/edit?usp=sharing>. It is great to fill in beforehand to help focus the work at the event. > * Discord Channel is here <https://discord.gg/qXa7gW6G>. This way our > remote companions can join in too! > > We look forward to seeing those that can make it. > Rebecca > > -- > Rebecca Gellatly > General Secretary > *Odoo Community Association* > > _______________________________________________ > 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> > mit freundlichen Grüßen, Peter Niederlag -- Dipl. Ökonom Peter Niederlag Geschäftsführender Gesellschafter Lösungen für digitale Zeiten Agile DevOps, Cloud, TYPO3, Odoo und Linux Datenbetrieb Technologie UG(haftungsbeschränkt) Lipper Hellweg 146, 33605 Bielefeld Geschäftsführer: Peter Niederlag HRB 41826 Amtsgericht Bielefeld Fon 0521 / 446 958 60 Fax 0521 / 446 958 69

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

--
Rebecca Gellatly
General Secretary
Odoo Community Association

by Rebecca Gellatly - 06:06 - 30 Jan 2025

Re: OCA Code Sprint - Brussels - 30 + 31 January

Hi, I'll arrive thursday and have no clue yet on where I could dive in. So if there is any "hop on" for newbies, I'd be quite interested as im not very much involved with the community up to now. hope to meet some of you over there, sincere greets, Peter On 21.01.25 13:49, Rebecca Gellatly wrote: > Hello OCA Contributors, > > I hope 2025 is treating you well so far. > > I just wanted to remind you we have our code sprint in Brussels coming > up on the 30th and 31st of January. Just a couple of weeks away. We > thought, as people might be in town for FOSDEM we would harness the > opportunity to encourage people to meet up. > > You can attend for just one day or both, completely up to you. > > You can register here: > https://odoo-community.org/event/oca-codeprint-brussels-2025-01-30-2025-02-01-158/register <https://odoo-community.org/event/oca-codeprint-brussels-2025-01-30-2025-02-01-158/register> > The small price is just to cover lunches and refreshments. > > /We will run remotely too./ > > *To help prepare:* > > * Working document for the sprint is here > <https://docs.google.com/document/d/1EIDkXd8QaeZ1bj63gJcS-EUW9cTZLCCS7vrmx_LB_kQ/edit?usp=sharing>. It is great to fill in beforehand to help focus the work at the event. > * Discord Channel is here <https://discord.gg/qXa7gW6G>. This way our > remote companions can join in too! > > We look forward to seeing those that can make it. > Rebecca > > -- > Rebecca Gellatly > General Secretary > *Odoo Community Association* > > _______________________________________________ > 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> > mit freundlichen Grüßen, Peter Niederlag -- Dipl. Ökonom Peter Niederlag Geschäftsführender Gesellschafter Lösungen für digitale Zeiten Agile DevOps, Cloud, TYPO3, Odoo und Linux Datenbetrieb Technologie UG(haftungsbeschränkt) Lipper Hellweg 146, 33605 Bielefeld Geschäftsführer: Peter Niederlag HRB 41826 Amtsgericht Bielefeld Fon 0521 / 446 958 60 Fax 0521 / 446 958 69

by Peter Niederlag - 11:11 - 29 Jan 2025

Re: OCA Code Sprint - Brussels - 30 + 31 January

Hi OCA Contributors and Members,
If you'd like to join the Code Sprint ONLINE, please use the Discord app!
New to Discord?
First, download the app and create an account.
After registering, use the following invitation link to join the OCA Discord Channel:
https://discord.gg/dhwChRkV
Reminder: The above Discord invitation is only valid for a limited time!
The OCA - GENERAL chat channel will be used during the Code Sprint on Thursday, January 30, and Friday, January 31.
If you have any questions, feel free to ask using the Discord app.
Looking forward to seeing you in Brussels or online via Discord!

Warmest regards,

Michel Stroom
--
Office Everywhere
Business Partner Odoo
t: +31 6 53360677
e: mstroom@office-everywhere.com
w: Office-Everywhere.com
LinkedIn profile: https://linkedin.com/in/stroom

On 21 Jan 2025, at 13:49, Rebecca Gellatly <notifications@odoo-community.org> wrote:

Hello OCA Contributors,

I hope 2025 is treating you well so far.

I just wanted to remind you we have our code sprint in Brussels coming up on the 30th and 31st of January. Just a couple of weeks away. We thought, as people might be in town for FOSDEM we would harness the opportunity to encourage people to meet up.

You can attend for just one day or both, completely up to you.

You can register here: https://odoo-community.org/event/oca-codeprint-brussels-2025-01-30-2025-02-01-158/register
The small price is just to cover lunches and refreshments.

We will run remotely too.

To help prepare:
Working document for the sprint is here. It is great to fill in beforehand to help focus the work at the event.
Discord Channel is here. This way our remote companions can join in too!
We look forward to seeing those that can make it.
Rebecca

--
Rebecca Gellatly
General Secretary
Odoo Community Association

_______________________________________________
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 - 09:21 - 28 Jan 2025

Re: OCA Code Sprint - Brussels - 30 + 31 January

Unfortunately i wasn.t in Brussels in this dates , success for oca members
Regards

Le mar. 21 janv. 2025, 13:49, Rebecca Gellatly <notifications@odoo-community.org> a écrit :
Hello OCA Contributors,

I hope 2025 is treating you well so far.

I just wanted to remind you we have our code sprint in Brussels coming up on the 30th and 31st of January. Just a couple of weeks away. We thought, as people might be in town for FOSDEM we would harness the opportunity to encourage people to meet up.

You can attend for just one day or both, completely up to you.

You can register here: https://odoo-community.org/event/oca-codeprint-brussels-2025-01-30-2025-02-01-158/register
The small price is just to cover lunches and refreshments.

We will run remotely too.

To help prepare:
Working document for the sprint is here. It is great to fill in beforehand to help focus the work at the event.
Discord Channel is here. This way our remote companions can join in too!
We look forward to seeing those that can make it.
Rebecca

--
Rebecca Gellatly
General Secretary
Odoo Community Association

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

by Abdrahman Elkafil - 05:01 - 21 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

5 replies 5 replies

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

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

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!

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

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

6 replies 6 replies

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

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!

--

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

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

PSC responsabilities

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

www.dixmit.com

by Enric Tobella Alomar - 10:16 - 30 Dec 2025

9 replies 9 replies

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:
Fix for this issue: https://github.com/decgroupe/odoo-ocb/commit/5d07dba81e05d44fdbd593017e13de5c22a1c46e#diff-baa76f7652700a485fa470cc6c5f215d63af2e21831d32a89ea3612c00d8a88fR34
Since URLs are relative, images are visible from the web view: https://odoo-community.org/groups/contributors-15/contributors-1976962?mode=thread&date_begin=&date_end=

--
Yann PAPOUIN, Ingénieur R&D | DEC

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.
lois.rilo@forgeflow.com | https://www.forgeflow.com
Twitter: /LoisRForgeFlow

by Lois Rilo Antelo - 04:00 - 8 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

www.dixmit.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 Adam Heinz - 02:41 - 4 Jan 2025
Re: [SPAM] PSC responsabilities

Fix for this issue: https://github.com/decgroupe/odoo-ocb/commit/5d07dba81e05d44fdbd593017e13de5c22a1c46e#diff-baa76f7652700a485fa470cc6c5f215d63af2e21831d32a89ea3612c00d8a88fR34
Since URLs are relative, images are visible from the web view: https://odoo-community.org/groups/contributors-15/contributors-1976962?mode=thread&date_begin=&date_end=

--
Yann PAPOUIN, Ingénieur R&D | DEC

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
Re: PSC responsabilities

Hello, thank you for doing this analysis. In the same ideia, I think we should somewhat promote the module maintainers. And the same logic could apply: if module maintainers don't do their job during a reasonable amount of time (like no module review during 18 months? 12 months?) then IMHO they should lose their maintainers status and other maintainers should be promoted. Yes, at the moment people don't participate too much because this is mostly a burden. However it's expected the OCA keeps growing and eventually by highlighting better modules authors and maintainers we manage to make it a little bit more attractive without spoiling it (cause yes there are already people doing astroturfing in the OCA sadly).

by "Raphaël Valyi" <rvalyi@akretion.com> - 06:58 - 31 Dec 2025

Re: PSC responsabilities

Hi everyone,

I think the first step would be to create a system to automate or measure the contributions of PSC members. This would provide transparency and help ensure that everyone is contributing fairly. By tracking contributions, we can identify areas where PSCs or individual members may need more support or encouragement. This system could also serve as a foundation for rewarding contributors and giving them the visibility they deserve.

The goal should be to make contributors feel valued and motivated to keep up their involvement.

I think it's essential that we address this issue to ensure the strength and credibility of the community.

Kind regards,

On Mon, Dec 30, 2024 at 9:28 AM Pedro M. Baeza <notifications@odoo-community.org> wrote:

I agree that some PSCs are not exercising their obligations and are just there for their rights when there are selfish interests. Others are just because they are now on other things and have become obsolete.

In summary, I agree that a PSC lifecycle should be implemented somehow.

Regards.

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

Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406

Start for free: Try Odoo Community in the cloud

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

by Jorge Elena Poblet - 12:16 - 30 Dec 2025

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:
https://drive.google.com/file/d/1udMxoPM3lbSiOfy5LxbfasxtXAaJ3Q2N/view?usp=sharing

The RFQ process is available here:
https://odoo-community.org/about/rfq-process#scrollTop=0

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.
(https://drive.google.com/file/d/1lQg98LvHenysH7NhueHJ4DZhbtTPJLtx/view?usp=drive_link).
Deadline is on the 16th January.

I wish you a happy end of 2024 and begin of 2025,
Virginie Dewulf
Executive Director
Odoo Community Association (OCA)
+32 477 64 17 20

by Virginie Dewulf - 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.

https://github.com/OCA/rest-framework/actions/runs/12363208323/job/34504085607?pr=481

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
Re: OCA rub-boat error

I preferred to use a PR no need to be merged

On Tue, Dec 17, 2024, 14:24 mohamed alkobrosly <alkobroslymohamed@gmail.com> wrote:
it is there in version 17.0

On Tue, Dec 17, 2024, 14:17 Rolando Pérez Rebollo <notifications@odoo-community.org> wrote:

auth_jwt hasn't been migrated to v17, maybe you can PR to v16 and port it to v17 later.

https://odoo-community.org/shop/auth-jwt-6626

\rrebollo

On 12/17/24 04:17, mohamed alkobrosly wrote:

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.

https://github.com/OCA/rest-framework/actions/runs/12363208323/job/34504085607?pr=481

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

_______________________________________________
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 Mohamed Alkobrosly - 12:30 - 17 Dec 2024

Re: OCA rub-boat error

it is there in version 17.0

On Tue, Dec 17, 2024, 14:17 Rolando Pérez Rebollo <notifications@odoo-community.org> wrote:

auth_jwt hasn't been migrated to v17, maybe you can PR to v16 and port it to v17 later.

https://odoo-community.org/shop/auth-jwt-6626

\rrebollo

On 12/17/24 04:17, mohamed alkobrosly wrote:

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.

https://github.com/OCA/rest-framework/actions/runs/12363208323/job/34504085607?pr=481

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

_______________________________________________
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 Mohamed Alkobrosly - 12:25 - 17 Dec 2024

Re: OCA rub-boat error

auth_jwt hasn't been migrated to v17, maybe you can PR to v16 and port it to v17 later.

https://odoo-community.org/shop/auth-jwt-6626

\rrebollo

On 12/17/24 04:17, mohamed alkobrosly wrote:

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.

https://github.com/OCA/rest-framework/actions/runs/12363208323/job/34504085607?pr=481

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

_______________________________________________
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 - 12:15 - 17 Dec 2024
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
Re: [SPAM] Sync odoo's calendar smartphones without Google nor Outlook

Thanks Xavier

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

Le mar. 17 déc. 2024, 02:07, Xavier Brochard <notifications@odoo-community.org> a écrit :
Hello Cyril There is an easy solution with vdirsyncer and a caldav/carddav server (like Nextcloud Agenda for instance). It's a bit «hacky» but works very well for me and my few employees. See https://vdirsyncer.pimutils.org/ The sync is as follow Odoo <=> Google/Outlook <=> vdirsyncer <=> Caldav server <=> any client If you need more details, just ask (je parle français). Another solution is to use a fake or compatible free/libre Outlook server (at least one exist). Xavier Le mardi 17 décembre 2024, 10:32:50 CET hugues de keyzer a écrit : > Le 2024-12-14 à 20:39, Cyril VINH-TUNG > 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 [8]

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

by Cyril VINH-TUNG - 06:26 - 17 Dec 2024

Re: [SPAM] Sync odoo's calendar smartphones without Google nor Outlook

Thanks Hugues

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

Le lun. 16 déc. 2024, 23:32, hugues de keyzer <notifications@odoo-community.org> a écrit :

hello,

you might take a look at the base_dav and calendar_dav modules, which provide caldav access to odoo’s calendar. unfortunately, the last available version is for odoo 11, because the migration has been blocked by the discussion whether to update the radicale library (on which base_dav depends) or not.

some links:

12.0 mig base_dav #141

[12.0][MIG] base_dav: migration to 12.0 #226

base_dav dead? #254

[MIG] base_dav: Migration to 17.0 #269

[MIG] base_dav: Migration to 17.0 #276

feel free to help move this forward, that would be useful.

kind regards,

hugues

Le 2024-12-14 à 20:39, Cyril VINH-TUNG a écrit :

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

_______________________________________________
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 Cyril VINH-TUNG - 06:21 - 17 Dec 2024

Re: [SPAM] Sync odoo's calendar smartphones without Google nor Outlook

Hello Cyril There is an easy solution with vdirsyncer and a caldav/carddav server (like Nextcloud Agenda for instance). It's a bit «hacky» but works very well for me and my few employees. See https://vdirsyncer.pimutils.org/ The sync is as follow Odoo <=> Google/Outlook <=> vdirsyncer <=> Caldav server <=> any client If you need more details, just ask (je parle français). Another solution is to use a fake or compatible free/libre Outlook server (at least one exist). Xavier Le mardi 17 décembre 2024, 10:32:50 CET hugues de keyzer a écrit : > Le 2024-12-14 à 20:39, Cyril VINH-TUNG > 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 [8]

by "Xavier Brochard" <zaz@chezlesenfants.fr> - 01:06 - 17 Dec 2024

1 attachments 1 attachments

signature.asc

Re: Sync odoo's calendar smartphones without Google nor Outlook

> because > the migration has been blocked by the discussion whether to update > the radicale library (on which base_dav depends) or not. I don't see how this can be a discussion. Releasing new software that pretty much by necessity is internet accessible built on a deprecated library that hasn't received updates for 5 years simply is grossly negligent. Especially if there's a maintained version readily available and it would just take a bit of effort to adopt the existing code to that. -- Your partner for the hard Odoo problems https://hunki-enterprises.com

by Holger Brunn - 11:06 - 17 Dec 2024

1 attachments 1 attachments

signature.asc

Re: [SPAM] Sync odoo's calendar smartphones without Google nor Outlook

hello,

you might take a look at the base_dav and calendar_dav modules, which provide caldav access to odoo’s calendar. unfortunately, the last available version is for odoo 11, because the migration has been blocked by the discussion whether to update the radicale library (on which base_dav depends) or not.

some links:

12.0 mig base_dav #141

[12.0][MIG] base_dav: migration to 12.0 #226

base_dav dead? #254

[MIG] base_dav: Migration to 17.0 #269

[MIG] base_dav: Migration to 17.0 #276

feel free to help move this forward, that would be useful.

kind regards,

hugues

Le 2024-12-14 à 20:39, Cyril VINH-TUNG a écrit :

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

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

by hugues - 10:31 - 17 Dec 2024
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
http://twitter.com/rvalyi
www.akretion.com

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

http://twitter.com/rvalyi

www.akretion.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 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
http://twitter.com/rvalyi
www.akretion.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

--
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
http://twitter.com/rvalyi
www.akretion.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 - 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
http://twitter.com/rvalyi
www.akretion.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 - 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

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

Screenshots here

https://github.com/OCA/manufacture/pull/1079#issuecomment-2541254424

David BEAL

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

https://github.com/OCA/manufacture/pull/1079
https://github.com/OCA/sale-workflow/pull/2998

Let me know if you have any questions

Regards

David BEAL
Akretion
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

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

Screenshots here

https://github.com/OCA/manufacture/pull/1079#issuecomment-2541254424

David BEAL

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

https://github.com/OCA/manufacture/pull/1079
https://github.com/OCA/sale-workflow/pull/2998

Let me know if you have any questions

Regards

David BEAL
Akretion
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

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

https://github.com/OCA/manufacture/pull/1079
https://github.com/OCA/sale-workflow/pull/2998

Let me know if you have any questions

Regards

David BEAL
Akretion
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

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

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:
https://odoo-community.org/groups/contributors-15/contributors-1909311?mode=thread&date_begin=&date_end=

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:
https://github.com/OCA/docs/issues/5

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:
https://github.com/OCA/docs/issues/5

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
Odoo Community Association (OCA)
+32 477 64 17 20

by Virginie Dewulf - 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:

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:

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:

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
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.
When you migrate a module, most times docs are not updated accordingly.
Has everything self-contained.
Is per-version.
Is hard to maintain. As a consequence, it's not properly maintained.
It's impossible to use by functionals. Thus, writing docs is an extra burden almost exclusively on the shoulders of coders.
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.
Translating is impossible.
Merging changes involves irrelevant nitpickings (commit message, formatting, etc.)
New workflow:
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.
When migrating a module, if it behaves the same, there'll be nothing to be done. Otherwise, see point 1.
Docs centralized.
Single page. Relevant per-version changes kept on the same page.
Easier to maintain. As a consequence, they'll have more maintenance.
Functionals can learn to contribute in a 5-minutes video. Less copywriting burden for coders.
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.
Translating is possible (not yet in the MVP, before you ask).
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
francesco.foresti@ooops404.com
+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:

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:

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:

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
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.
When you migrate a module, most times docs are not updated accordingly.
Has everything self-contained.
Is per-version.
Is hard to maintain. As a consequence, it's not properly maintained.
It's impossible to use by functionals. Thus, writing docs is an extra burden almost exclusively on the shoulders of coders.
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.
Translating is impossible.
Merging changes involves irrelevant nitpickings (commit message, formatting, etc.)
New workflow:
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.
When migrating a module, if it behaves the same, there'll be nothing to be done. Otherwise, see point 1.
Docs centralized.
Single page. Relevant per-version changes kept on the same page.
Easier to maintain. As a consequence, they'll have more maintenance.
Functionals can learn to contribute in a 5-minutes video. Less copywriting burden for coders.
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.
Translating is possible (not yet in the MVP, before you ask).
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
francesco.foresti@ooops404.com
+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:

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:

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:

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
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.
When you migrate a module, most times docs are not updated accordingly.
Has everything self-contained.
Is per-version.
Is hard to maintain. As a consequence, it's not properly maintained.
It's impossible to use by functionals. Thus, writing docs is an extra burden almost exclusively on the shoulders of coders.
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.
Translating is impossible.
Merging changes involves irrelevant nitpickings (commit message, formatting, etc.)
New workflow:
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.
When migrating a module, if it behaves the same, there'll be nothing to be done. Otherwise, see point 1.
Docs centralized.
Single page. Relevant per-version changes kept on the same page.
Easier to maintain. As a consequence, they'll have more maintenance.
Functionals can learn to contribute in a 5-minutes video. Less copywriting burden for coders.
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.
Translating is possible (not yet in the MVP, before you ask).
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:

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:

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:

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
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.
When you migrate a module, most times docs are not updated accordingly.
Has everything self-contained.
Is per-version.
Is hard to maintain. As a consequence, it's not properly maintained.
It's impossible to use by functionals. Thus, writing docs is an extra burden almost exclusively on the shoulders of coders.
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.
Translating is impossible.
Merging changes involves irrelevant nitpickings (commit message, formatting, etc.)
New workflow:
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.
When migrating a module, if it behaves the same, there'll be nothing to be done. Otherwise, see point 1.
Docs centralized.
Single page. Relevant per-version changes kept on the same page.
Easier to maintain. As a consequence, they'll have more maintenance.
Functionals can learn to contribute in a 5-minutes video. Less copywriting burden for coders.
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.
Translating is possible (not yet in the MVP, before you ask).
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

seeds

Best regards,

Ivan Sokolov
Cetmix Odoo Solutions

cetmix.com

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

https://www.odoo.com/event/odoo-experience-2024-4662/track/test-odoo-ui-with-tours-6320 will be best 10 minutes of your odoo life

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

Cetmix OÜ

team@cetmix.com | https://cetmix.com

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

Archives

Contributors