Tuesday, April 23, 2024
3 changes
Resolved issues and error corrections
This fix resolves an issue where financial reports would hang indefinitely when using cross-report expressions that reference data from other reports. The problem occurred because the system was only looking for required calculation references within the current report, not in other linked reports. This update ensures all necessary references are properly found, allowing reports to load correctly.
Original PR description
To reproduce: - Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance" - Create another report, containing a single…
To reproduce:
- Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance"
- Create another report, containing a single line with code line_2_1. Give it two expressions: - One aggregation, with formula="14.0" (hardcoded fixed value), and subformula "if_other_expr_above(line_2_1.dudu, EUR(0))"
- Another expression of any engine labelled 'dudu'
==> Try opening the first report; it loads forever.
This is because the bound expression is only searched in the expressions of the active report ; not in the expressions loaded from other reports. In our case, the aggregation needing the bound is from the second report, so the bound belongs to its report as well. The looping occurs because that value, since it's not present in the first report's evaluated data, is considered as not yet computed, and the computation is continuously delayed at the end of the treatment queue, causing it to never become empty.
Forward-Port-Of: odoo/enterprise#59175
Forward-Port-Of: odoo/enterprise#58339This update resolves a critical performance issue in the Spanish tax report (Model 347) that occurred when processing large numbers of partners with small transactions. Previously, the system would crash when trying to exclude too many partners from the report. The fix optimizes the database query to include relevant partners instead of excluding irrelevant ones, allowing the report to generate successfully even with thousands of partners.
Original PR description
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the very long UserError Cause ----- Too much partners must be excluded and the list of this partners are added to a domain which becomes very long and an error is raised when we use the function ast.literal_eval on it. Fix ----- The partners are not excluded in the domain but the other partners are included in the SQL query. opw-3770944
This update resolves a critical issue in the German localization module where balance sheet report updates were failing during system upgrades. The problem occurred because the migration script was attempting to rename accounting tags that already existed, causing duplicate name conflicts. The fix adds a safety check to skip the renaming process if the target tag already exists, preventing upgrade failures for German companies using Odoo's accounting features.
Original PR description
Forward port [commit](https://github.com/odoo/odoo/pull/132219) because the [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is…
Forward port [commit](https://github.com/odoo/odoo/pull/132219) because the [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is failing when we try to rename [ref](https://github.com/odoo/odoo/blob/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py#L24) the tag due to the duplicate name constraint.
The implementation of forward porting has become necessary as the script attempts execution with each version, encounter failure due to the presence of the existing tag 'tag_de_liabilities_bs_B_1'. To prevent duplication, we have introduced a pre-check. If the 'B1' tag already exists, script execution is skipped.
Note: The [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is failing for the 17.0 version. However, if we migrate to the version saas-16.3, it also fails. Therefore, we are creating a PR in the saas-16.3 version to forward port it for subsequent versions as well.
Upgrade request traceback group: 813
```
File "/home/odoo/src/odoo/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py", line 45, in migrate
rename_tag(cr, "tag_de_liabilities_bs_C_1", "tag_de_liabilities_bs_B_1")
File "/home/odoo/src/odoo/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py", line 5, in rename_tag
cr.execute(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "ir_model_data_module_name_uniq_index"
DETAIL: Key (module, name)=(l10n_de, tag_de_liabilities_bs_B_1) already exists.
```
In odoo#126249 the german balance sheet report was updated and
during the 15.2 FW port, some issues needed fixing. The
issues and their fixes are:
- Deleted tags: As the script didn't run, some tags (like F and all D tags) would be deleted and not renamed. As the tag might already be used as a FK in another table, we remove it from ir_model_data so it's not deleted by the ORM. Also, this means that the tags xml adds the B1 as a new tag which means renaming C1 to B1 will not work in the script due to the unique name constraint, this is handled by checking if B1 exists and if it does we do not run the script.
Enterprise PR: odoo/enterprise/pull/45899
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#161629