Message Threads | The Odoo Community Association

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

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

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

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

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

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:

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>

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

by Tom Blauwendraat - 03:46 - 22 Nov 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)