Message Threads | The Odoo Community Association

Javascript Debug

Hello you,

when debuggin js with chrome in v16 and v15 the js/css is located in a non named subfolder.
In v14, it is not the case. There it looks more right. (See attached images.)
I could believe, thats why I can not debug inside Intellij, because the path mapping does not work correctly.

Has anyone here an idea ?

Thank you all.

has got anyone an idea why the javascript/scss/... sources are not located under the running domain

Vielen Dank und viele Grüße

Stefan Wild
Geschäftsführer

sewisoft GmbH
Örtleinsweg 39
96148 Baunach

info@sewisoft.de
Tel. +49 (0) 160 / 99 11 25 69
www.sewisoft.de

Sitz der Gesellschaft: Baunach
Registergericht: Amtsgericht Bamberg, HRB 8508
Geschäftsführer: Günter Selbert, Stefan Wild

by Stefan Wild - 02:26 - 17 Dec 2022

4 attachments 4 attachments

2 replies 2 replies

Re: Javascript Debug

> when debuggin js with chrome in v16 and v15 the js/css is located in a non

> named subfolder. In v14, it is not the case. There it looks more right.

> (See attached images.) I could believe, thats why I can not debug inside

> Intellij, because the path mapping does not work correctly.

> 

> Has anyone here an idea ?

the files in the source map those versions generate have leading slashes. Given 
this is a non-standard by google, I'd figure whatever chrome does is correct 
and the fact that firefox handles this more gracefully is a fluke.

You might try to remove leading slashes in
https://github.com/odoo/odoo/blob/16.0/odoo/tools/sourcemap_generator.py#L95
and see if this fixes your problem.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com

by Holger Brunn - 09:16 - 18 Dec 2022

1 attachments 1 attachments

Re: Javascript Debug

> when debuggin js with chrome in v16 and v15 the js/css is located in a non

> named subfolder. In v14, it is not the case. There it looks more right.

> (See attached images.) I could believe, thats why I can not debug inside

> Intellij, because the path mapping does not work correctly.

> 

> Has anyone here an idea ?

the files in the source map those versions generate have leading slashes. Given 
this is a non-standard by google, I'd figure whatever chrome does is correct 
and the fact that firefox handles this more gracefully is a fluke.

You might try to remove leading slashes in
https://github.com/odoo/odoo/blob/16.0/odoo/tools/sourcemap_generator.py#L95
and see if this fixes your problem.


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com

by "Holger Brunn" <mail@hunki-enterprises.nl> - 09:16 - 18 Dec 2022

1 attachments 1 attachments

Weblate project is locked

Hi,

This project https://translation.odoo-community.org/projects/commission-15-0/commission-15-0-account_commission/ seems to have been locked since the module https://github.com/OCA/commission/tree/15.0/account_commission was added on 5 December, and we have not been able to work on the translation on it.

The lock seems to have been done due to the following alert:

> No file mask matches.
> This component set up is incomplete, as it lacks any translations.
> * Starting new translations directly in Weblate is possible, and creates files based on the file mask.
> * Check whether the file mask account_commission/i18n/*.po matches files in your version control system repository.

This is a brand new module, and therefore there is no *.po file yet.

https://github.com/OCA/commission/tree/fa60e0c6f13b58e2081d6376d0366564b32d6c0f/account_commission/i18n

Questions:

1. Is this (i.e. the project gets locked for new modules with no translation) how Weblate projects are supposed to behave?

2. How can we unlock such projects?

Thank you.

--

Yoshi Tashiro

by Yoshi Tashiro. - 03:01 - 16 Dec 2022

3 replies 3 replies

Re: Weblate project is locked

> I guess there is no concrete plans on this at this point.

Indeed :)

Please send the reports to transbot@odoo-community.org. I monitor that one and will handle the requests.
If there are enough of them I guess that will motivate me to dig deeper :)

-sbi

On Mon, Dec 19, 2022 at 2:52 PM Yoshi Tashiro <notifications@odoo-community.org> wrote:
Thank you very much, Stephane.

> We could broaden repository maintenance access but probably not to all translators.

I guess there is no concrete plans on this at this point. I may bring up this topic when the problem starts bugging me, but until then please allow us to report individual issues here if this is the proper channel.

Thanks again.
--
Yoshi Tashiro

On Mon, Dec 19, 2022 at 8:22 PM Stéphane Bidoul <notifications@odoo-community.org> wrote:
Hi Yoshi,

On Fri, Dec 16, 2022 at 3:02 PM Yoshi Tashiro <notifications@odoo-community.org> wrote:
1. Is this (i.e. the project gets locked for new modules with no translation) how Weblate projects are supposed to behave?

No. Unfortunately I don't know exactly why it happens yet.
It sometimes happen when there are git sync issues but it was not the case here.

2. How can we unlock such projects?

I unlocked it just now.

We could broaden repository maintenance access but probably not to all translators.

Best regards,

-sbi

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

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

by Stéphane Bidoul - 03:41 - 19 Dec 2022
Re: Weblate project is locked

Thank you very much, Stephane.

> We could broaden repository maintenance access but probably not to all translators.

I guess there is no concrete plans on this at this point. I may bring up this topic when the problem starts bugging me, but until then please allow us to report individual issues here if this is the proper channel.

Thanks again.
--
Yoshi Tashiro

On Mon, Dec 19, 2022 at 8:22 PM Stéphane Bidoul <notifications@odoo-community.org> wrote:
Hi Yoshi,

On Fri, Dec 16, 2022 at 3:02 PM Yoshi Tashiro <notifications@odoo-community.org> wrote:
1. Is this (i.e. the project gets locked for new modules with no translation) how Weblate projects are supposed to behave?

No. Unfortunately I don't know exactly why it happens yet.
It sometimes happen when there are git sync issues but it was not the case here.

2. How can we unlock such projects?

I unlocked it just now.

We could broaden repository maintenance access but probably not to all translators.

Best regards,

-sbi

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

by Yoshi Tashiro. - 02:51 - 19 Dec 2022
Re: Weblate project is locked

Hi Yoshi,

On Fri, Dec 16, 2022 at 3:02 PM Yoshi Tashiro <notifications@odoo-community.org> wrote:
1. Is this (i.e. the project gets locked for new modules with no translation) how Weblate projects are supposed to behave?

No. Unfortunately I don't know exactly why it happens yet.
It sometimes happen when there are git sync issues but it was not the case here.

2. How can we unlock such projects?

I unlocked it just now.

We could broaden repository maintenance access but probably not to all translators.

Best regards,

-sbi

by Stéphane Bidoul - 12:21 - 19 Dec 2022

M14 Accounting for French 'Collectivités locales'

Dear french OCA contributors,

I am actually working on a RFQ for accounting software of a French Polynesia City Hall. It works the same as in France due to the regulations.

We need M14 implementation (Budgets and Accounting) and PES (Protocole d'échanges standards)

https://www.collectivites-locales.gouv.fr/finances-locales/linstruction-m14-comptabilite-des-communes

https://www.collectivites-locales.gouv.fr/finances-locales/le-protocole-dechange-standard-pes

RFQ deadline is before january 4th 2023

Launching production is planned april 2023

If someone interested in answering with us for RFQ and developing modules, please contact me

Best regards

by Cyril VINH-TUNG - 07:01 - 15 Dec 2022

OCA - Github - Switch brach by default

Hello!

I would like to know as PSC if I can change the default branch of a repository and how 😊

For example, by default account-financial-reporting is v13, It should be v15. Isn’t it?

https://github.com/OCA/account-financial-reporting

More branches by default are v14, etc.

Thanks

Regards

Rafael

by "Rafael Blasco" <rblasco@rbnpro.com> - 03:26 - 14 Dec 2022

3 replies 3 replies

Translation for Odoo core<=12.0

Hi all,

as Odoo deletes translation ability for versions not supported, is it possible to create a project in weblate for these versions?

As an alternative, I'll do PRs for every term to translate, perhaps not the better way (an user without git knowledge will find it hard to do).

Thanks,

Sergio Corato

by Sergio Corato - 12:05 - 14 Dec 2022

4 replies 4 replies

Re: Translation for Odoo core<=12.0

Hi Martin,
so I'll go with direct PR on OCB wheen needed.
Thanks all
Sergio Corato

Il giorno mer 14 dic 2022 alle ore 16:17 Martin Trigaux (mat) <notifications@odoo-community.org> ha scritto:
Hi there,

Martin, managing the Transifex project at Odoo S.A. here.
Just to add that the 13.0 Transifex project is going away very soon too (probably end of year), it's no longer supported since the release of 16.0. We have a limited number of terms in our Transifex plan so we can't keep forever for all versions unfortunately.

As said Moises, we will not accept PR on deprecated branches (we can accept translation PR on a supported version if it's in a language/module that are not on Transifex). So OCA/OCB is your best bet but adding past projects on Weblate is not negligible in term of size.
To give you a rough idea to those managing the OCA Weblate project if you consider it : Odoo 13.0 is 236k source words and it's increasing of ~30k at each release.

Best,

Martin

On 14/12/2022 12:06, Sergio Corato wrote:

Hi all,

as Odoo deletes translation ability for versions not supported, is it possible to create a project in weblate for these versions?

As an alternative, I'll do PRs for every term to translate, perhaps not the better way (an user without git knowledge will find it hard to do).

Thanks,

Sergio Corato

_______________________________________________
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 Sergio Corato - 05:35 - 14 Dec 2022
Re: Translation for Odoo core<=12.0

Hi there,

Martin, managing the Transifex project at Odoo S.A. here.
Just to add that the 13.0 Transifex project is going away very soon too (probably end of year), it's no longer supported since the release of 16.0. We have a limited number of terms in our Transifex plan so we can't keep forever for all versions unfortunately.

As said Moises, we will not accept PR on deprecated branches (we can accept translation PR on a supported version if it's in a language/module that are not on Transifex). So OCA/OCB is your best bet but adding past projects on Weblate is not negligible in term of size.
To give you a rough idea to those managing the OCA Weblate project if you consider it : Odoo 13.0 is 236k source words and it's increasing of ~30k at each release.

Best,

Martin

On 14/12/2022 12:06, Sergio Corato wrote:

Hi all,

as Odoo deletes translation ability for versions not supported, is it possible to create a project in weblate for these versions?

As an alternative, I'll do PRs for every term to translate, perhaps not the better way (an user without git knowledge will find it hard to do).

Thanks,

Sergio Corato

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

by Martin Trigaux - 04:16 - 14 Dec 2022
Re: Translation for Odoo core<=12.0

Hi Moisés,
no, I mean https://github.com/OCA/OCB
Sergio Corato

Il giorno mer 14 dic 2022 alle ore 15:27 Moises Lopez <notifications@odoo-community.org> ha scritto:
Hi Sergio

Did you mean, create a new PR to
https://github.com/odoo/odoo?

If yes, It could breaks Odoo SA contributing guidelines

1) Odoo doesn't accept PR related to translations:
- https://github.com/odoo/odoo/wiki/Contributing#how-can-i-translate-odoo-in-my-language

2) Odoo doesn't accept PR for deprecated branches/versions:
- https://github.com/odoo/odoo/wiki/Contributing#against-which-version-should-i-submit-a-patch

A workaround, create in your custom module a translation file:
- "your_module/i18n_extra/{LANG}.po"

with the terms that you need to change for all installed modules and improve the translation from transifex for stable ones

On Wed 14 Dec 2022 at 5:06 a.m. Sergio Corato <notifications@odoo-community.org> wrote:
Hi all,

as Odoo deletes translation ability for versions not supported, is it possible to create a project in weblate for these versions?

As an alternative, I'll do PRs for every term to translate, perhaps not the better way (an user without git knowledge will find it hard to do).

Thanks,
Sergio Corato

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

--
Moisés López Calderón
Mobile: (+521) 477-752-22-30
Twitter: @moylop260
hangout: moylop260@vauxoo.com
http://www.vauxoo.com - Odoo Gold Partner
Twitter: @vauxoo

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

by Sergio Corato - 03:36 - 14 Dec 2022
Re: Translation for Odoo core<=12.0

Hi Sergio

Did you mean, create a new PR to
https://github.com/odoo/odoo?

If yes, It could breaks Odoo SA contributing guidelines

1) Odoo doesn't accept PR related to translations:
- https://github.com/odoo/odoo/wiki/Contributing#how-can-i-translate-odoo-in-my-language

2) Odoo doesn't accept PR for deprecated branches/versions:
- https://github.com/odoo/odoo/wiki/Contributing#against-which-version-should-i-submit-a-patch

A workaround, create in your custom module a translation file:
- "your_module/i18n_extra/{LANG}.po"

with the terms that you need to change for all installed modules and improve the translation from transifex for stable ones

On Wed 14 Dec 2022 at 5:06 a.m. Sergio Corato <notifications@odoo-community.org> wrote:
Hi all,

as Odoo deletes translation ability for versions not supported, is it possible to create a project in weblate for these versions?

As an alternative, I'll do PRs for every term to translate, perhaps not the better way (an user without git knowledge will find it hard to do).

Thanks,
Sergio Corato

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

--
Moisés López Calderón
Mobile: (+521) 477-752-22-30
Twitter: @moylop260
hangout: moylop260@vauxoo.com
http://www.vauxoo.com - Odoo Gold Partner
Twitter: @vauxoo

by Moisés López Calderón - 03:26 - 14 Dec 2022

Re: pre-commit changes

> The idea of the first pre-commit set is to store the automatic changes

Well, I was coming from a place where I'd separate aesthetic changes (automatic or not) vs. functional changes, but thanks for clarifing that.

I'll squash my intermediate commit into the Migration one.

Have a nice day.

by Marco Colombo - 02:10 - 6 Dec 2022

2 replies 2 replies

Re: pre-commit changes

Daniel, the question is not related to the pre-commit config, but the changes that pre-commit does on your code.

Regards.

by Pedro M. Baeza - 04:25 - 9 Dec 2022
Re: pre-commit changes

Actually, pre-commit config updates should be on their own commit, so that they don't contaminate the module history.

You may want to also create a separate PR cherry-picking that particular commit, that can be fat tracked by maintainers.
That will avoid the risk of someone else proposing a different commit to update pre-commit config, that will cause you merge conflicts.

Thanks
Daniel

On 06/12/22 13:11, Marco Colombo wrote:

> The idea of the first pre-commit set is to store the automatic changes

Well, I was coming from a place where I'd separate aesthetic changes (automatic or not) vs. functional changes, but thanks for clarifing that.

I'll squash my intermediate commit into the Migration one.

Have a nice day.

_______________________________________________
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 DIRECTOR
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34

by Daniel Reis - 10:35 - 9 Dec 2022

Migration 12.0 -> 13.0 and field collision

Hi,

I'm starting a migration process for a copy of our production database and it fails on the following error (detailed log attached):

ERROR mig_9008 odoo.sql_db: bad query:
UPDATE ir_model_fields
SET name = 'notified_partner_ids'
WHERE name = 'needaction_partner_ids'
AND model = 'mail.message'

ERROR: duplicate key value violates unique constraint "ir_model_fields_name_unique"
DETAIL: Key (model, name)=(mail.message, notified_partner_ids) already exists.

ERROR mig_9008 OpenUpgrade: mail: error in migration script mail/migrations/13.0.1.0/pre-migration.py: duplicate key value violates unique constraint "ir_model_fields_name_unique"

I tracked down the issue and I found out that the `notified_partner_ids` field was an existing field added in 7.0 but deleted in 9.0.

Maybe this field should have been dropped or renamed to `openupgrade_legacy_xxx`, I don't know if it should be the case or if I made a mistake in my original upgrade path, but this field still exists in our database even if not referenced in any files.

Whatever, if you are in my case, I made a PR to identify and remove orphaned fields (for the database_cleanup module):

https://github.com/OCA/server-tools/pull/2491

For the record, we have more than 1000 orphaned fields (list attached) in our production database (updated from 6.1 -> 7.0 -> 8.0 -> 9.0 -> 10.0 -> 11.0 in october 2020)

--

Yann PAPOUIN
Ingénieur R&D




		WWW.DECGROUPE.COM

	02 43 21 65 50 poste 51
	02 43 39 30 78
	ypa@decgroupe.com
	3 r Champ du Verger 72700 ALLONNES

by Yann Papouin - 11:46 - 6 Dec 2022

2 attachments 2 attachments

Re: Candidature pour un poste en Alternance – Bachelor Concepteur développeurd’applications

Bonjour,

l'OCA est une communauté de développeurs, analystes, gestionnaires de projets autour du logiciel Odoo.

Ce n'est pas une entreprise qui offre du service à des clients directs.

Je vous conseille de vous renseigner avant d'envoyer ce genre de mail à une mailing liste comptant des centaines de personnes, ce qui s'apparente à du spam.

De plus, la langue de communication n'est pas le français mais l'anglais.

Bonne continuation dans votre recherche.

Virginie Dewulf, membre du board de l'OCA.

-----Original Message-----

From: adnaneazzouz <notifications@odoo-community.org>

Reply-To: Odoo Community Association (OCA) Contributors <contributors@odoo-community.org>

To: Contributors <contributors@odoo-community.org>

Subject: Candidature pour un poste en Alternance – Bachelor Concepteur développeurd’applications

Date: Sun, 04 Dec 2022 14:02:29 -0000

Bonjour,

Afin de réaliser mon Bachelor Concepteur développeur d’applications en alternance, je vous adresse ma candidature pour un poste au sein de votre entreprise.

La formation que je m'apprête à suivre me permettra d'acquérir de nouvelles compétences opérationnelles, afin de mener à bien les missions que vous voudrez bien me confier.

Cette formation en alternance se déroule en ligne selon les modalités suivantes :

- Des rentrées toute l'année (pas de date fixe de rentrée)
- Un rythme d'alternance optimisé : 4 jours en entreprise / 1 jour en formation, adapté aux temps forts d'activité de votre entreprise
- Un programme de formation à la carte : vous déterminez l'ordre des modules à suivre en fonction des missions que vous serez amené à me confier.

De plus, pour toute embauche en alternance vous bénéficiez d’une prime de 8000€ grâce au plan "1 jeune, 1 solution", ce qui diminue considérablement le coût lié à mon embauche.

Vous trouverez ci-joint mon CV ainsi que la brochure de présentation de l'ISCOD.

Dans l'attente d'un entretien, je vous prie d'agréer, Madame, Monsieur, l'expression de mes salutations distinguées.

Adnane Azzouz
+33769283265

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

by Virginie Dewulf. - 10:31 - 5 Dec 2022

Candidature pour un poste en Alternance – Bachelor Concepteur développeur d’applications

Bonjour,

Afin de réaliser mon Bachelor Concepteur développeur d’applications en alternance, je vous adresse ma candidature pour un poste au sein de votre entreprise.

La formation que je m'apprête à suivre me permettra d'acquérir de nouvelles compétences opérationnelles, afin de mener à bien les missions que vous voudrez bien me confier.

Cette formation en alternance se déroule en ligne selon les modalités suivantes :

- Des rentrées toute l'année (pas de date fixe de rentrée)
- Un rythme d'alternance optimisé : 4 jours en entreprise / 1 jour en formation, adapté aux temps forts d'activité de votre entreprise
- Un programme de formation à la carte : vous déterminez l'ordre des modules à suivre en fonction des missions que vous serez amené à me confier.

De plus, pour toute embauche en alternance vous bénéficiez d’une prime de 8000€ grâce au plan "1 jeune, 1 solution", ce qui diminue considérablement le coût lié à mon embauche.

Vous trouverez ci-joint mon CV ainsi que la brochure de présentation de l'ISCOD.

Dans l'attente d'un entretien, je vous prie d'agréer, Madame, Monsieur, l'expression de mes salutations distinguées.

Adnane Azzouz
+33769283265

by adnaneazzouz@outlook.fr - 03:01 - 4 Dec 2022

2 attachments 2 attachments

Q: How to Configure GS1 barcodes on Odoo 14 community version

Greetings All,

I'm facing an issue with reading gs1 datamatrix codes, I have installed all related gs1 barcodes modules but the system is still not able to read the barcodes. I have tried to configure it but there was no success.

Also, after updating "Stock Barcodes" to the latest version, I could not figure out how to configure the barcode option settings.

It would be really appreciated if you guide me through the process on how to configure the gs1 as well as the new barcode option configurations for the latest version of "Stock Barcodes"

Below you'll find all the module that were installed Odoo 14 community version :

Stock Barcodes

Stock Barcodes GS1

Stock Barcodes GS1 Expiry

GS1 Barcode API

Product GS1 Barcode

by Hazem - 07:05 - 4 Dec 2022

pre-commit changes

Hi,

quick question about pre-commit changes during migration.

I'm migrating a module from 14.0 to 16.0. I've noticed that the first pre-commit related commit ("[IMP]: pre-commit stuff") takes care only of part of the changes needed to make pre-commit happy (it is possible due to the --no-verify). The missing part can be significant.
The following commit ("[MIG]: $MODULE: Migration to 16.0") must include those changes too, plus anything migration related.

So I was wondering if that defeats the purpose of having pre-commit changes separated in their own commit. Right now, my approach is to create a second commit, named "[IMP]: more pre-commit stuff", just to make pre-commit happy, and then add another commit with the migration stuff.

Alternatives I've considered: ignoring the issue and include both migration and the rest of pre-commit changes in one commit ("[MIG]: $MODULE: Migration to 16.0"), or do as I do now but squash the two pre-commit related commits before merge (or equivalently, get rid of the --no-verify in the first place, and manually add all changes to the first commit).

Thoughts / suggestions?

by Marco Colombo - 01:46 - 2 Dec 2022

1 replies 1 replies

XML errors when upgrading modules, because of fields in unrelated modules

Hello,

I've been finding this weird issue for a while, but decided to take some tome to write about it.

I've seen frequently the case where:

1. A custom module adds a field to a model and view. For example. to res.company.
2. Later, another (unrelated) custom module also adds a new field to that same model (model and view).

When installing or upgrading that second module, I see errors loading the XML with the form view.
The error says that the field added by module 1 is missing in the view.
But a) module 1 is installed an the field exists and b) the XML for the view in module 2 doesn't have any reference to that "missing" field!

I found this frequently in Odoo 14.
Honestly I'm not sure if it if also happens in other versions.

Has anyone else experienced this?

Thank you

--

DANIEL REIS
MANAGING DIRECTOR

M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34

by Daniel Reis - 02:30 - 25 Nov 2022

4 replies 4 replies

Re: XML errors when upgrading modules, because of fields in unrelated modules
Hi Daniel,

I encountered a similar issue lately when developing a module in OCA/sale-workflow, everything was working fine locally, but the XML error you described was raised on the CI:

- my module was adding a field in the embedded tree view of sale order line in the SO form, which by default is in editable mode (no form)

- another module from OCA/sale-workflow disabled this editable mode so the form view of the SO line was open, on which my field wasn't added, so during tests when opening the form, the "field not found" error was triggered. Adding the field also on the embedded SO line form view fixed the issue.

Could it be the same kind of issue you are facing?

Regards,

Le 25/11/2022 à 14:31, Daniel Reis a écrit :

Hello,

I've been finding this weird issue for a while, but decided to take some tome to write about it.

I've seen frequently the case where:

1. A custom module adds a field to a model and view. For example. to res.company.
2. Later, another (unrelated) custom module also adds a new field to that same model (model and view).

When installing or upgrading that second module, I see errors loading the XML with the form view.
The error says that the field added by module 1 is missing in the view.
But a) module 1 is installed an the field exists and b) the XML for the view in module 2 doesn't have any reference to that "missing" field!

I found this frequently in Odoo 14.
Honestly I'm not sure if it if also happens in other versions.

Has anyone else experienced this?

Thank you

--

DANIEL REIS
MANAGING DIRECTOR
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34

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

-- Sébastien Alix Business Solutions Odoo Developer Camptocamp France SA https://www.camptocamp.com/
by Sébastien Alix - 09:46 - 28 Nov 2022
Re: XML errors when upgrading modules, because of fields in unrelated modules

Hi Daniel

the error you describe usually comes when you remove a field from a model and view.

If you now update both modules at the same time, it depends on how your Postgres server returns the modules.
Because no explicit ordering is specified when loading the module.

If the module is updated first that the field is not removed, an error occurs because the other view is still in the database and not updated.

in this context, however, other errors can also occur.
such as. when loading data via XML.

I hope this helps.

Regards
Michael

Am 25.11.2022 15:42 schrieb Daniel Reis <notifications@odoo-community.org>:
Hi Moises,

I haven't found this to be easy reproductible.
The particular case I encountered today went away after I ran a "-u base" (that I really din't like to do).

On your questions:

1) Yes, In this case both inherited from "base.view_company_form".
2) No (see 1)
3) No groups set on model on view
4) Yes. View on Module 1 does not have a default priority (16 was assigned) and View in Module 2 has priority=100. This looked good to me.
5) Yes, tons of them, between core addons and other OCA modules :-)

I can give it a try at stripping the modules down and reproducing.

Thanks Moises
/Daniel

On 25/11/22 14:22, Moises Lopez wrote:

Hi Daniel

I have a few question related to reproduce the case

1) Do The third view is inherited from original one?

1. id=original

2. id=inh_a inherit=original

3. id=inh_b inherit=original

2) Do The third view is inherited from 2nd one?

1. id=original

2. id=inh_a inherit=original

3. id=inh_b inherit=inh_a

3) Do the original field has "groups"?

4) Do the inherited views has "priority"?

5) Are there other views inheriting the same view?

Could you share the both modules with minimal code and the odoo-bin command to reproduce it, please?

--

Moisés López Calderón

Mobile: (+521) 477-752-22-30

Twitter: @moylop260

hangout: moylop260@vauxoo.com
http://www.vauxoo.com - Odoo Gold Partner

Twitter: @vauxoo

_______________________________________________
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 DIRECTOR
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34

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

by Michael Tietz - 07:20 - 25 Nov 2022
Re: XML errors when upgrading modules, because of fields in unrelated modules

Hi Moises,

I haven't found this to be easy reproductible.
The particular case I encountered today went away after I ran a "-u base" (that I really din't like to do).

On your questions:

1) Yes, In this case both inherited from "base.view_company_form".
2) No (see 1)
3) No groups set on model on view
4) Yes. View on Module 1 does not have a default priority (16 was assigned) and View in Module 2 has priority=100. This looked good to me.
5) Yes, tons of them, between core addons and other OCA modules :-)

I can give it a try at stripping the modules down and reproducing.

Thanks Moises
/Daniel

On 25/11/22 14:22, Moises Lopez wrote:

Hi Daniel

I have a few question related to reproduce the case

1) Do The third view is inherited from original one?

1. id=original

2. id=inh_a inherit=original

3. id=inh_b inherit=original

2) Do The third view is inherited from 2nd one?

1. id=original

2. id=inh_a inherit=original

3. id=inh_b inherit=inh_a

3) Do the original field has "groups"?

4) Do the inherited views has "priority"?

5) Are there other views inheriting the same view?

Could you share the both modules with minimal code and the odoo-bin command to reproduce it, please?

--

Moisés López Calderón

Mobile: (+521) 477-752-22-30

Twitter: @moylop260

hangout: moylop260@vauxoo.com
http://www.vauxoo.com - Odoo Gold Partner

Twitter: @vauxoo

_______________________________________________
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 DIRECTOR
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, #34

by Daniel Reis - 03:41 - 25 Nov 2022
Re: XML errors when upgrading modules, because of fields in unrelated modules

Hi Daniel

I have a few question related to reproduce the case

1) Do The third view is inherited from original one?

1. id=original
2. id=inh_a inherit=original
3. id=inh_b inherit=original

2) Do The third view is inherited from 2nd one?

1. id=original
2. id=inh_a inherit=original
3. id=inh_b inherit=inh_a

3) Do the original field has "groups"?

4) Do the inherited views has "priority"?

5) Are there other views inheriting the same view?

Could you share the both modules with minimal code and the odoo-bin command to reproduce it, please?

--
Moisés López Calderón
Mobile: (+521) 477-752-22-30
Twitter: @moylop260
hangout: moylop260@vauxoo.com
http://www.vauxoo.com - Odoo Gold Partner
Twitter: @vauxoo

by Moisés López Calderón - 03:20 - 25 Nov 2022

OCA Financial Auditors Campaign Closes Today - 25th November

Hello OCA Contributors,

Just a reminder our Financial Auditors Campaign closes today. So far we have only had 1 applicant. Preferably we would like to be able to vote for 3.

To apply as a candidate you do not need to be a delegate or member. Perhaps someone on your team has the skills to help the OCA with the annual audit?

It isn't a huge task thankfully but does obviously require a certain skill set.

Please fill in the survey below or share the link with colleagues who might be interested:

OCA Financial Auditors Campaign

Warmest regards,
Rebecca

--

Rebecca Gellatly

General Secretary

Odoo Community Association

by Rebecca Gellatly - 10:30 - 25 Nov 2022

Financial Auditor Campaign closes November 25th

Hello OCA Contributors,

I hope the week is going well for you!

I just wanted to remind you our financial auditors campaign closes this coming Friday 25th of November.

To apply as a candidate you do not need to be a delegate or member. Perhaps someone on your team has the skills to help the OCA with the annual audit?

Please fill in the survey below or share the link with colleagues who might be interested:

OCA Financial Auditors Campaign

Warmest regards,
Rebecca

--

Rebecca Gellatly

General Secretary

Odoo Community Association

by Rebecca Gellatly - 04:51 - 23 Nov 2022

Module name, name collision

Hi all,

It seems there are miscellaneous practices to deal with name collision in OCA, mainly regarding Odoo SA module names

here mgmt is used

https://github.com/OCA/helpdesk/tree/14.0

here and in some other repos oca is used

https://github.com/OCA/edi

Is there any other practice ?

Should we converge on the same standard ? with a rename in future version with apriori openupgrade file ?

Personally I prefer oca, but it probably needs to be voted !?

What do you think?

Regards

Thanks

by David BEAL - 04:16 - 22 Nov 2022

3 replies 3 replies

Re: Module name, name collision

BTW:

https://www.odoo-code-search.com/

The feature already exists to tell you if the mod name exists.

This friends have it for free, it should be nice if OCA contacts them and let them serve something (may be paid).

Regards.

El mar, 22 nov 2022 a la(s) 09:17, David Beal (notifications@odoo-community.org) escribió:
Hi all,

It seems there are miscellaneous practices to deal with name collision in OCA, mainly regarding Odoo SA module names

here mgmt is used
https://github.com/OCA/helpdesk/tree/14.0

here and in some other repos oca is used
https://github.com/OCA/edi

Is there any other practice ?

Should we converge on the same standard ? with a rename in future version with apriori openupgrade file ?

Personally I prefer oca, but it probably needs to be voted !?

What do you think?

Regards

Thanks

_______________________________________________
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
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 10:51 - 15 Dec 2022
Re: Module name, name collision

IMHO.

Avoid prefixes or suffixes.

an script in the ci with a centralize DB with module names would be the practical solution.

1. A quick service with elastic.
2. An script that makes a push to such index.
3. Serve a quick rest search.
4. An script for the CI that makes:
curl url/search/modules_here -r
read_response.json -> found
5. Red if exists (with proper output).

Why not the prefix/suffix.

1. Nothing will avoid with such technique the duplication of functions and modules.
2. In dev time the developer will know where the problem is (now I do simply a search in google, but as I said it can be automated).

Regards.

El mar, 22 nov 2022 a la(s) 09:17, David Beal (notifications@odoo-community.org) escribió:
Hi all,

It seems there are miscellaneous practices to deal with name collision in OCA, mainly regarding Odoo SA module names

here mgmt is used
https://github.com/OCA/helpdesk/tree/14.0

here and in some other repos oca is used
https://github.com/OCA/edi

Is there any other practice ?

Should we converge on the same standard ? with a rename in future version with apriori openupgrade file ?

Personally I prefer oca, but it probably needs to be voted !?

What do you think?

Regards

Thanks

_______________________________________________
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
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
nhomar@vauxoo.com vauxoo.com/contactus

by Nhomar Hernández - 10:46 - 15 Dec 2022
Re: Module name, name collision

Hello,

It could be contextual, if we find that a better name would reflect what the module does.

However, I would go with an `_oca` suffix by default to avoid the name collision.

Cheers,
Yannick

On Tue, 22 Nov 2022 at 16:17, David Beal <notifications@odoo-community.org> wrote:
Hi all,

It seems there are miscellaneous practices to deal with name collision in OCA, mainly regarding Odoo SA module names

here mgmt is used
https://github.com/OCA/helpdesk/tree/14.0

here and in some other repos oca is used
https://github.com/OCA/edi

Is there any other practice ?

Should we converge on the same standard ? with a rename in future version with apriori openupgrade file ?

Personally I prefer oca, but it probably needs to be voted !?

What do you think?

Regards

Thanks

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

by Yannick Payot - 05:26 - 15 Dec 2022

OCA - RFQ - Improving the Documentation of Open Upgrade

Hello OCA Contributors.

Have you seen our latest RFQ for improving the Open Upgrade Documentation?

Please have a look here if you are interested in responding:

OpenUgrade Documentation RFQ

Send your proposals in by December 4th. We look forward to hearing from you.

Warmest regards,
Rebecca

--

Rebecca Gellatly

General Secretary

Odoo Community Association

by Rebecca Gellatly - 12:01 - 22 Nov 2022

Question about migration of account.tax and related entity (in my case on l10n_be)

Dear community,

I'm currently migrating a database from version 9.0 to version 14.0.
My problem is between 12.0 and 13.0 where accounting element has
changed.

The database is using Mis Builder to generate accounting reports. These
reports are based on account.account.tag that are linked to account.tax
(and also account.move.line in 13.0).

As I have seen, in 9.0 (and until 12.0), account.account.tag are linked
to an account.tax via a simple field tag_ids :
https://github.com/OCA/OCB/blob/12.0/addons/account/models/account.py#L937

Starting from 13.0, tags are no more linked to account.tax directly.
They are linked to an account.tax.repartition.line which is linked to an
account.account.tax.
https://github.com/OCA/OCB/blob/13.0/addons/account/models/account.py#L1340-L1341

In 13.0, the account.chart.template has been updated accordingly.

As is, the migration did not succeed. At some point, odoo try
to remove the old account.tag. But that's not possible because these
tags are linked to existing account.move.line.
https://github.com/OCA/OCB/blob/13.0/addons/account/models/account_move.py#L2792-L2796

To avoid such deletetion, I flagged existing account.account.tag as
noupdate=True.

When migrating the database the existing all account.account.tag linked
to the account.tax are moved to all the account.tax.repartition.line of
the account.tax. Meaning that if there is account.account.tag named
"03", "49", "54" that are all linked to an account.tax. After migration
each line of account.tax.repartition.line will have "03", "49" and "54"
as tags.

This does not reflect the new account.chart.template for belgium.

So my first intention was to update the account.tax, particulary their
account.tax.repartition.line to replace the old account.account.tag by
the new one created during the migration. Using the new
account.chart.template as an example. But that does not works, because
existing account.move.line always points to the old account.account.tag.

I have no idea how to update the tags on the account.move.line to
reflects the new account.chart.template and the new tags.

I tried to find the logic that computes tags on an account.move.line.
But it's really obscure for me. And simply applying the following
recompute method does not works (it causses issue about non balanced
account element):
https://github.com/OCA/OCB/blob/13.0/addons/account/models/account_move.py#L990-L1049

Anther option is to map the old tags to the new one. But here comes the
problem that there is more new tags than old ones. So that I'm not sure
how to perform the mapping. For example the following records:
https://github.com/OCA/OCB/blob/12.0/addons/l10n_be/data/account_tax_template_data.xml#L16-L19
https://github.com/OCA/OCB/blob/13.0/addons/l10n_be/data/account_tax_report_data.xml#L45-L52
In 13.0 the account.account.tag created have sign. There exist two
version for the tag 03:
SELECT name, applicability, tax_negate
FROM account_account_tag WHERE name ILIKE '%03';
name | applicability | tax_negate
---------------------------+---------------+------------
Belgium VAT Form: grid 03 | taxes | <- the old one
-03 | taxes | t <-|
+03 | taxes | f <-L the two new ones
(3 rows)

Should I replace the old "03" tag by the "+03" one, or should I
sometimes replace it by the "-03" and when ?

When this will be solved, I will still be wondering if such a line is
ok ?
SELECT account_move_line_id, name
FROM account_account_tag_account_move_line_rel AS aatamlr
JOIN account_account_tag AS aat
ON aatamlr.account_account_tag_id = aat.id
WHERE account_move_line_id = 9166;
account_move_line_id | name
----------------------+---------------------------
9166 | Belgium VAT Form: grid 03
9166 | Belgium VAT Form: grid 54
9166 | Belgium VAT Form: grid 49
9166 | Belgium VAT Form: grid 64

Where we see that an account.move.line is linked to 4 differents
account.account.tag.

I also take a look at this:
- https://github.com/OCA/OCB/blob/12.0/addons/account/models/chart_template.py#L14-L52
- https://github.com/OCA/OCB/blob/13.0/addons/account/models/chart_template.py#L14-L31
But it does not seams to solve the previous issue.

And finaly I looked at account_chart_update module, but it did not seams to solve the previous issues niether.
https://github.com/OCA/account-financial-tools/tree/14.0/account_chart_update

If you have any clue, it will be very helpfull. :)

Regards,

--
Rémy Taymans @ Coop IT Easy
+32 493 02 69 85 - <https://github.com/remytms>
<https://coopiteasy.be>

by Rémy Taymans - 04:06 - 21 Nov 2022

2 replies 2 replies

Re: Question about migration of account.tax and related entity (in my case on l10n_be)

Dear Tom,
Dear Danny,

Thank you very much for your help. I will look at the resources you mentioned. :)

Best regards,

--
Rémy Taymans @ Coop IT Easy
+32 493 02 69 85 - <https://github.com/remytms>
<https://coopiteasy.be>

Quoting Tom Blauwendraat (2022-11-22 15:46:48)
> Hi Remy,
>
> We had the same problem in the migration of a few of our Dutch customers. My colleague Danny who is not on this list (yet, but he will sign up) worked on that and says the following:
>
> -----------------------------------------
>
> Dear Remy,
>
> We have had a very similar thing happen in our migration from 10 to 14, between 12 and 13 yes. Although some of the things you mentioned we did not encounter, I had no problem with account.account.tag's being deleted for example.
>
> Part of the problem with the tags is this, in 13.0 a new model, called account.tax.report.line has been introduced. Now in 13, some tags are defined in xml files as account.tax.report.line instead of account.account.tag (as they were before). The report line model is responsible for creating new account.account.tag records in python, prefixed with a minus and plus sign.
>
> So you are dealing with new account.account.tag records, while all your account move lines and other stuff is still linked to the old account.account.tag records. There is no direct link to old and new tag records, so you kind of have to 'know' which old account.account.tag records are replaced with which new account.tax.report.line records, and then you could map them.
> I took the route of remapping the old tags to the new tags, and that work can be viewed here: https://github.com/OCA/OpenUpgrade/blob/13.0/addons/l10n_nl/migrations/13.0.3.0/post-migration.py
> I've moved some of the code into helper functions: https://github.com/OCA/openupgradelib/blob/master/openupgradelib/openupgrade_130.py
> So I hope it will be easy enough to use those helper functions in your own script. Or maybe the convert_old_tax_tags_into_new_report_line_tags function of l10n_nl could even be completely reused? This is the function that does the mapping.
>
> Best regards,
> Danny de Jong
>
> ------------------
>
> With the following PS: ---> I noticed that the "l10n_be" migration scripts are missing from OpenUpgrade so that was the same as we encountered for l10n_nl

by Rémy Taymans - 05:35 - 22 Nov 2022

Re: Question about migration of account.tax and related entity (in my case on l10n_be)

Hi Remy,

We had the same problem in the migration of a few of our Dutch customers. My colleague Danny who is not on this list (yet, but he will sign up) worked on that and says the following:

-----------------------------------------

Dear Remy,

We have had a very similar thing happen in our migration from 10 to 14, between 12 and 13 yes. Although some of the things you mentioned we did not encounter, I had no problem with account.account.tag's being deleted for example.

Part of the problem with the tags is this, in 13.0 a new model, called account.tax.report.line has been introduced. Now in 13, some tags are defined in xml files as account.tax.report.line instead of account.account.tag (as they were before). The report line model is responsible for creating new account.account.tag records in python, prefixed with a minus and plus sign.

So you are dealing with new account.account.tag records, while all your account move lines and other stuff is still linked to the old account.account.tag records. There is no direct link to old and new tag records, so you kind of have to 'know' which old account.account.tag records are replaced with which new account.tax.report.line records, and then you could map them.

I took the route of remapping the old tags to the new tags, and that work can be viewed here: https://github.com/OCA/OpenUpgrade/blob/13.0/addons/l10n_nl/migrations/13.0.3.0/post-migration.py
I've moved some of the code into helper functions: https://github.com/OCA/openupgradelib/blob/master/openupgradelib/openupgrade_130.py
So I hope it will be easy enough to use those helper functions in your own script. Or maybe the convert_old_tax_tags_into_new_report_line_tags function of l10n_nl could even be completely reused? This is the function that does the mapping.

Best regards,

Danny de Jong

------------------

With the following PS: ---> I noticed that the "l10n_be" migration scripts are missing from OpenUpgrade so that was the same as we encountered for l10n_nl

------------------------------------------

On 11/21/22 16:07, Rémy Taymans wrote: