Thursday, February 27, 2025
21 changes · 17.0
Resolved issues and error corrections
This fixes an automated test in the website editor so it works reliably with Chrome 133 and earlier versions. It helps maintain confidence that editor banner behavior continues to be checked correctly without affecting everyday user features.
Original PR description
The sequence of events leads to slightly different results in Chrome 133 which results in the test failing. This commit changes the sequence of events so that the test passes in Chrome 133 as well as the prior versions.
Event registration forms now ignore unexpected extra form fields instead of failing when their values do not match the attendee field format. This helps visitors complete registrations reliably even when custom form details are present.
Original PR description
When registration form have extra form details where the field value doesn't match an attendee field format (2 or 3 values separated by a dash) we where crashing while trying to unpack the split value. This commit simply ignore the field if its value doesn't match the expected format of an attendee field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Receipts for account settlements and other non-editable orders will no longer show the prompt to start adding products when there are no order lines. This prevents confusing messaging for cashiers and customers when viewing finalized or receipt-only order information.
Original PR description
Issue: When settling user account, the order will not have any order lines, that will display a misleading empty state on the receipt, saying: "Start adding products". Fix: We do not display this empty state, when the order is not editable, which is the case of, but not only, settling an account. Note that we have another related PR https://github.com/odoo/enterprise/pull/76370 for the same ticket, which fixes only the case of settling an account. However, @adgu-odoo suggested to make the fix more general, to fix the case of not only settling an account, but also other possible cases where we show the OrderWidget in a receipt. If this PR is merged, the other one should be closed, and vice versa. opw-4430325
This fix prevents errors when website page templates are regenerated after some related snippets have been archived. It ensures archived template records are still recognized, avoiding duplicate creation failures during website setup or upgrades.
Original PR description
- While calling `_generate_primary_snippet_templates`, `create_missing_views` fetches the existing snippet views. However, archived snippet is ignored, causing `create_missing_views` to attempt to create the snippet again, mistakenly considering it as a missing view. This leads to a traceback:
```py
File "/data/build/odoo/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)=(website, new_page_template_services_0_s_website_form) already exists.
```
- To prevent such errors, it's better to fetch inactive views as well during creation.
opw-4510585
upg-2452055
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixes a display issue in the online shop cart where suggested rental accessories could appear with a broken layout when they had rental pricing periods. This helps customers view add-on rental products correctly during checkout, reducing confusion and improving the shopping experience.
Original PR description
Steps to reproduce:
1) Configure 2 rental products (product1 and product2)
2) Add at least 1 pricing period to product2
3) Set product2 as accessory product to product1
4) Go to /shop page and add product1
5) Go to the cart and observe the broken layout of suggested
accessories
opw-4463981Fixes an issue where payroll work hour calculations could fail when processing multiple employee contracts at once. This helps payroll operations run reliably for contract groups that share timezone settings.
Original PR description
This PR fixes the bug that I introduced in this PR: https://github.com/odoo/enterprise/pull/78880 The bug involves the timezone-getting code in `HrContract._get_work_hours()`. When I tried to fix the bug addressed in the linked PR, I failed to account for the fact that `_get_work_hours()` can be called on sets of contracts with size greater than 1. We're still guaranteed the uniqueness of timezones, but singleton errors were being raised by my original fix if the contract set this method was called on had more than one calendar. The `assert` statement added to this method is enough to ensure this bug won't appear again.
Odoo Studio now handles numeric values used for yes/no field options without crashing. This makes editing affected fields in debug mode more reliable for administrators and implementers.
Original PR description
Have a field in a view like this
```<field name="" options="{ some_boolean: 1 }" />```
And have the corresponding supportedOption (defined on the field widget):
```{
somme_boolean: {
type: "boolean"
}
}```
Open studio and click on that field, in debug mode.
Before this commit, there was a crash because 1 or 0 were directly passed to a component which expected a boolean value. After this commit, before displaying the options we convert 0 or 1 to the corresponding boolean.This update adds checks to ensure receipts for customer account settlements do not show the misleading “Start adding products” empty message. It helps keep the point-of-sale experience clearer for staff when processing due payments without a regular order.
Original PR description
When settling the user account from `pos_settle_due`, we show a receipt with no order (as expected), but with an empty state saying "Start adding products"! This bug has been reported while using the `pos_settle_due` module, however, the fix has been made generic and hence been implemented in the `point_of_sale` module. This PR just adds the test specific to `pos_settle_due`. opw-4430325
Miscellaneous changes
Set the correct accounts for expense & income currency exchange accounts Description of the issue/feature this PR addresses: task: https://www.odoo.com/odoo/my-tasks/4179478 swap Exchange Difference Gain & Exchange Difference Loss Current behavior before PR: - The exchange difference accounts were wrongly assigned Desired behavior after PR is merged: - Fix issue by swapping them --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
Set the correct accounts for expense & income currency exchange accounts Description of the issue/feature this PR addresses: task: https://www.odoo.com/odoo/my-tasks/4179478 swap Exchange Difference Gain & Exchange Difference Loss Current behavior before PR: - The exchange difference accounts were wrongly assigned Desired behavior after PR is merged: - Fix issue by swapping them --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190704
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores permitidos` Steps to reproduce: - Have l10n_es_edi_sii module installed and have a tax agency selected. - Make a Bill using '12% agri' tax Issue: When sending the bill for validation the error is raised. This occurs because the field "ClaveRegimenEspecialOTrascendencia" is set to "01", whe
Original PR description
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores…
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores permitidos` Steps to reproduce: - Have l10n_es_edi_sii module installed and have a tax agency selected. - Make a Bill using '12% agri' tax Issue: When sending the bill for validation the error is raised. This occurs because the field "ClaveRegimenEspecialOTrascendencia" is set to "01", when it should be "02" for exempt taxes. Also, in this case TipoImpositivo and CuotaSoportada should be replaced by PorcentCompensacionREAGYP and ImporteCompensacionREAGYP https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca/que-consiste-regimen-especial-agricultura-pesca.html https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/Validaciones_ErroresSII_v1.1.pdf opw-4486190 Forward-Port-Of: odoo/odoo#196017
This commit fixes an issue where the partner assigned to a booth could be incorrect based on the provided email. Indeed, we don't want to assign an existing partner when non-logged, as it could conflict when trying to checkout the order and providing another one. In addition, it just does not make much sense. Instead we now suggest to login before booking your booths. Task-4163951 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior a
Original PR description
This commit fixes an issue where the partner assigned to a booth could be incorrect based on the provided email. Indeed, we don't want to assign an existing partner when non-logged, as it could conflict when trying to checkout the order and providing another one. In addition, it just does not make much sense. Instead we now suggest to login before booking your booths. Task-4163951 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#179083
How to reproduce: - Create a dashboard with pivot grouped such that some group values are empty (E.g. CRM lead > group by 'lost reason') - Add a pivot.header formula where you point towards the positional field (e.g. `=ODOO.PIVOT.HEADER(1,"#lost_reason_id",1)` ) - Add a relational filter that points on the 'lost reason' model - Go back to the dashboard app to visualize it and click on the modified cell -> crash The pivot ui plugin did not properly account for that scenario as it was ex
Original PR description
How to reproduce: - Create a dashboard with pivot grouped such that some group values are empty (E.g. CRM lead > group by 'lost reason') - Add a pivot.header formula where you point towards the positional field (e.g. `=ODOO.PIVOT.HEADER(1,"#lost_reason_id",1)` ) - Add a relational filter that points on the 'lost reason' model - Go back to the dashboard app to visualize it and click on the modified cell -> crash The pivot ui plugin did not properly account for that scenario as it was expecting a string as an output of `getPivotHeaderValue`. However, the later had changed its return type since we handle both balues and stringified values as arguments in the formula. Task-4582602 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#198002
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This ambiguity arises within the _get_on_leave_ids method, affecting the execution of a SQL query designed to identify users on leave. How to reproduce the issue: Install both hr_holidays and auth_signup modules. Attempt to execute the _get_on_leave_ids method to identify users on leave. Behaviour befor
Original PR description
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This…
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This ambiguity arises within the _get_on_leave_ids method, affecting the execution of a SQL query designed to identify users on leave. How to reproduce the issue: Install both hr_holidays and auth_signup modules. Attempt to execute the _get_on_leave_ids method to identify users on leave. Behaviour before this commit: An "ambiguous column error" is raised due to the SQL query not specifying which state field to use, leading to confusion between the state fields in the hr_leave and res_users tables. Expected behaviour: The SQL query should clearly reference the state field from the hr_leave table, avoiding ambiguity and accurately identifying users on leave without errors. Solution: The SQL query within the _get_on_leave_ids method has been updated to use hr_leave.state = 'validate' for clear distinction, resolving the ambiguous column error. opw-3770758 Forward-Port-Of: odoo/odoo#156663
…value Currently, the display name of a record is not loaded in the Records selector when we invoke the 'search more' list view and is fetched from the server after the callback to the component `FilterValue` which means that the latter only receives a list of ids and undefined display names which ultimately means that we set "undefined" as a global filter value. Note that this was patched later with the introduction of the service `name`. Task-4564737 OPW-4482365 Description of the
Original PR description
…value Currently, the display name of a record is not loaded in the Records selector when we invoke the 'search more' list view and is fetched from the server after the callback to the component `FilterValue` which means that the latter only receives a list of ids and undefined display names which ultimately means that we set "undefined" as a global filter value. Note that this was patched later with the introduction of the service `name`. Task-4564737 OPW-4482365 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#197221
When your spouse has no income or low income, you can benefit from withholding taxes reduction. Before this commit, only the case where the spouse had no income was implemented. This PR includes the case where the spouse has low income to also benefit for the withholding taxe reduction. task-4582221 Forward-Port-Of: odoo/enterprise#80052
Original PR description
When your spouse has no income or low income, you can benefit from withholding taxes reduction. Before this commit, only the case where the spouse had no income was implemented. This PR includes the case where the spouse has low income to also benefit for the withholding taxe reduction. task-4582221 Forward-Port-Of: odoo/enterprise#80052
Before this commit mandate reports were printing incorrectly, depending on the language of mandate either signature was printed on separate page or the writing was cut off in the middle and thus uninteligable. The commit squishes text of the mandate a bit so that we can fit all the information in one page. ticket-3522796 Previous behavior:  Behavior after commit:  Behavior after commit:  Forward-Port-Of: odoo/enterprise#48693
The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock. Notes: We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution. Traceback: (VALUES where removed for readability, there were 100 of them) ``` 2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "accoun
Original PR description
The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock. Notes: We spotted a lot of deadlock in or lock due to that CRON. We saw that…
The aim of this commit is to prevent the CRON `account_account.auto_reconcile_bank_statement_line` to fail due a deadlock.
Notes:
We spotted a lot of deadlock in or lock due to that CRON. We saw that it could rollback the write on a lot of row at the same time and could prevent the cron to call itself for the next execution.
Traceback: (VALUES where removed for readability, there were 100 of them)
```
2025-01-27 12:00:39,276 3822296 ERROR openerp odoo.sql_db: bad query: b'UPDATE "account_bank_statement_line"
SET "cron_last_check" = "__tmp"."cron_last_check"::timestamp, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (...), (...), (...), (...), ) AS "__tmp"("id", "cron_last_check", "write_date", "write_uid")
WHERE "account_bank_statement_line"."id" = "__tmp"."id"'
ERROR: deadlock detected
DETAIL: Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT: See server log for query details.
CONTEXT: while updating tuple (10685,6) in relation "account_bank_statement_line"
2025-01-27 12:00:39,277 3822296 ERROR openerp odoo.addons.base.models.ir_cron: Job 'Try to reconcile automatically your statement lines' (297) server action #4952 failed
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_cron.py", line 572, in _callback
self.env.flush_all()
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 833, in flush_all
self[model_name].flush_model()
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6707, in flush_model
self._flush(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6784, in _flush
model.browse(some_ids)._write_multi(vals_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4881, in _write_multi
self.env.execute_query(SQL(
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 962, in execute_query
self.cr.execute(query)
File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 373, in execute
res = self._obj.execute(query, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.DeadlockDetected: deadlock detected
DETAIL: Process 934692 waits for ShareLock on transaction 2414965881; blocked by process 932819.
Process 932819 waits for ShareLock on transaction 2414966299; blocked by process 934692.
HINT: See server log for query details.
CONTEXT: while updating tuple (10685,6) in relation "account_bank_statement_line"
```
task-id: 4393854
Forward-Port-Of: odoo/enterprise#80059The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#52832
Original PR description
The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#52832
Add a default field for each analytic plans when exporting journal items from list view task-4378083 Forward-Port-Of: odoo/enterprise#78530
Original PR description
Add a default field for each analytic plans when exporting journal items from list view task-4378083 Forward-Port-Of: odoo/enterprise#78530
The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#52832
Original PR description
The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#52832
…ng filter value Currently, the display name of a record is not loaded in the Records selector when we invoke the 'search more' list view and is fetched from the server after the callback to the component `FilterValue` which means that the latter only receives a list of ids and undefined display names which ultimately means that we set "undefined" as a global filter value. Note that this was patched later with the introduction of the service `name`. Test adaptation of https://github.com
Original PR description
…ng filter value Currently, the display name of a record is not loaded in the Records selector when we invoke the 'search more' list view and is fetched from the server after the callback to the component `FilterValue` which means that the latter only receives a list of ids and undefined display names which ultimately means that we set "undefined" as a global filter value. Note that this was patched later with the introduction of the service `name`. Test adaptation of https://github.com/odoo/odoo/pull/197221 Task-4564737 OPW-4482365 Forward-Port-Of: odoo/enterprise#79012