Thursday, January 22, 2026
23 changes · 19.0
Resolved issues and error corrections
This update fixes a typo in an automated test for the Mail app's search highlighting. It helps keep quality checks accurate and reduces the chance of false test failures, with no direct impact on everyday users.
Original PR description
Intoduced by https://github.com/odoo/odoo/pull/118794 Forward-Port-Of: odoo/odoo#244832 Forward-Port-Of: odoo/odoo#244720
This fix ensures payroll-related localization test modules are included when accounting localizations are tested. It helps catch payroll and localization issues earlier, reducing the chance of regressions reaching users.
Original PR description
Some payroll test module named test_l10n_xx are not being installed when l10n are tested. This causes the tests to never run, causing mistakes to regularly go through and break things. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoices sent through Peppol could fail when a product used the "Pack of 6" unit because its unit code was valid internationally but not accepted by Peppol. This fix removes that unsupported code so affected Belgian e-invoices can pass Peppol validation correctly.
Original PR description
**Steps to reproduce:** - Use a Belgian company - Create a Belgian contact with "EU Standard (Peppol Bis 3.0)" as eInvoice format - Create an invoice for that customer with a product using "Pack of 6" as unit of measure - Confirm the invoice - Send it to Peppol **Issue:** The validation of the invoice fails with the following error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension" **Cause:** The UNECE code used for "Pack of 6" UoM is "HD". "HD" is a correct UNECE code for "Half Dozen". However, it is not part of the subset of codes accepted by Peppol. opw-5463212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244668
A new automated test checks that custom website buttons are not incorrectly placed inside paragraph formatting. This helps prevent visual or editing issues for website builders and keeps button layouts consistent.
Original PR description
Add a hoot test covering the case where the custom button snippet gets incorrectly wrapped inside a `<p>` tag. Original changes introduced in commit 3a8f2cc418510c3b91f8b9086bb4a89a1745e40d. X-original-commit: 2753a4d23e90b3fea32abc2d19c8668579dbcefe
Editing a message in Discuss now keeps any role mentions that were included in the original message. This prevents important audience references from disappearing when users update sent messages.
Original PR description
**Current behavior before PR:** Editing a message with a role mention would cause the mention to be lost. **Desired behavior after PR is merged:** Role mentions are now preserved when editing a message. task-4702960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218992
This fix restores the database obfuscation command, which had stopped launching after a configuration value changed format. It also updates the command options to avoid a deprecation warning, helping keep maintenance workflows reliable.
Original PR description
Description of the issue/feature this PR addresses: - Can't launch `odoo-bin ofbuscate` because `config['db_name']` is now a list and `Registry(...)` does not support it ! Current behavior before PR: - Obfuscate command not working anymore Desired behavior after PR is merged: - Obfuscate command working again - Also migrating to `my_default` in options to avoid deprecation warning. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes the product expiry test use its own dedicated data instead of depending on optional demo data. This helps keep automated checks stable and reduces false failures during development and release validation.
Original PR description
Use test specific data instead of relying on demo data. Runbot Error : [232852](https://runbot.odoo.com/odoo/runbot.build.error/232852?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update restores the intended layout of the invoicing dashboard after enlarged help icons created too much empty space. The larger icons are now used only where needed in the bills list help view, keeping the dashboard clean and easier to scan.
Original PR description
As a part of task-5258726 the icons of no-content help in bills list view were enlarged. The icons used there were also used in the module dashboard, so enlarging them messed the dashboard styling. This commit fixes this issue by using a prop `largeIcons` on the `BillGuide` componenet to make it with large icons when needed only (in the bills list view no content help). task-5801970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale product information popup now includes each product's internal reference in its display name. This helps staff distinguish similar products more easily and reduces the chance of selecting the wrong item.
Original PR description
This commit adds the default_code (internal reference) to the display name of the product in the product info popup. opw-5493827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spanish e-invoicing fields now avoid applying default values to companies that do not use the Spanish localization. This reduces unnecessary database clutter in multi-company setups while still safely handling empty user selections for Spanish invoices.
Original PR description
On multi-company databases, having the defaults value on `account.move` selection fields unnecessary bloat the database for other companies with different fiscal package (localization). Moreover those two selection fields (`l10n_es_payment_means` and `l10n_es_edi_facturae_reason_code`) are not required, meaning the user can still set the value to `False` and we must be sure to handle that case anyway. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale reports now calculate tax base totals by rounding each line before adding them together. This prevents small discrepancies between line totals and report totals, improving confidence in sales and tax reporting.
Original PR description
Before this commit, the total base amounts of taxes might be different from summing the base amounts of each line, due to rounding issues. opw-5408201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Simple links in emails and editor content now better follow the font size set on their surrounding text. This keeps link styling consistent with the intended design and avoids unexpected sizing from mailing design settings.
Original PR description
Ensure that a simple link can inherit from an ancestor `font-size` defined using the Editor toolbar, overriding the `mass_mailing` Design Tab `--link-font-size` special variable. That variable will be removed in the future, because it is more natural that a link font-size is aligned with its container. task-5868086
The mail invite field now only takes focus when it is actually available and the related screen is active. This prevents it from stealing attention from important dialogs, such as call permission prompts, making the messaging experience smoother.
Original PR description
**Current behavior before PR:** - The invite input always tried to autofocus, in turn stealing focus from dialogs like the call-permission dialog. **Desired behavior after PR is merged:** - Autofocus only when the input exists and the context is active. - Moved `mockPermissionsPrompt` to `mail_test_helpers`. **Part of task-**[5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a data issue related to Brazilian VAT (tax) records in the enterprise accounting system. A previous change removed a necessary step to ensure VAT data was properly formatted, particularly in the POS module. This fix reintroduces the required formatting to maintain accurate tax reporting.
Original PR description
In [^1], we removed the compacting code that existed in l10n_br modules as all vats are now stored as compact forms since [^2]. *However*, we did not consider that databases updated to 18.4+ would not automatically apply the compacting code to all records. As such, we have reintroduced a small block of compacting code in `l10n_br_edi_pos` as that one does special operations with the VAT that needs to be stripped of special characters. opw-5491321 [^1]: odoo/enterprise#87562 [^2]: odoo/odoo#179078 Forward-Port-Of: odoo/enterprise#104960
This update resolves an error that occurred when generating PDF reports for accounting, specifically when a contact record lacked a name. The fix ensures that the report can now be successfully exported even if a contact doesn't have a defined name, improving report generation reliability.
Original PR description
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts`…
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts` modules. - Go to Contacts and open any contact (e.g., Azure Interior). - Click `Add` > `Save & Close`, then `save` the contact. - Navigate to Accounting > Reporting > Aged Receivable. - Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`). - Click `PDF` to export the report. **Error:** `TypeError: sequence item 0: expected str instance, bool found` **Root Cause:** At [1], `options['selected_partner_ids']` is built using `partner.name`, which may be `False` for unnamed contacts. At [2], the `partner_value` list may therefore contain `False` entries coming from `options['selected_partner_ids']`. When calling `', '.join(partner_value)`, an error is raised because the list contains `non-string` (`bool`) values. **Fix:** This commit prevents errors when exporting reports to PDF and ensures that partner names are displayed in the report the same way as in the partner selection widget. [1]: https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745 [2]: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93 opw-5467321 Forward-Port-Of: odoo/enterprise#105025 Forward-Port-Of: odoo/enterprise#103828
This update resolves an issue where FedEx labels incorrectly displayed addresses containing special characters (like accented letters). The code has been updated to ensure all address fields are converted to ASCII characters before being sent to FedEx, resulting in accurate address formatting on labels. This improves the presentation of customer addresses when using FedEx shipping.
Original PR description
Issue ----- Fedex does not handle special characters in addresses, so passing an address such as "Rue de Libération 15" will show as "Rue de Lib...ration 15" on labels. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#104979 Forward-Port-Of: odoo/enterprise#104265
This update fixes an issue where appraisals weren't automatically selecting the correct company-based template. The change ensures that appraisals, regardless of whether the employee or appraisal has a department assigned, correctly utilize the intended template. This prevents errors and ensures appraisals are set up accurately.
Original PR description
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one…
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one template, with the company of the employee but no department - Run the cron "Appraisal: Run employee appraisal" - Open the Appraisals app - Click on the newly created appraisal - It doesn't have the template ### Cause: - In `_compute_appraisal_template()`, only the department of the appraisal is used to compute the template. But `_create_new_appraisal()` doesn't include the department in `appraisal_values` to create the appraisal. So `appraisal.department_id` is `False` and the template from the department is ignored. - Another issue is if the employee has no department, then the appraisal also has no department. Then no template is selected by the search domain. ### Solution: - Include `department_id` in `appraisal_values` - Modify the search domain to include the case where the appraisal has no department opw-5477450
This update corrects a bug that prevented users from adding inputs to payslips. The fix ensures that the system correctly identifies and displays salary inputs for each employee, resolving an issue where inputs were not appearing. This improves the accuracy of payslip creation.
Original PR description
When trying to add Inputs for a payslips none appear as the domain was incorrect and only showed salary inputs for use in the employee. This is fixed in this commit by adding to the domain en each specific model. task-5486091
This update resolves an issue where work orders weren't correctly assigning employees due to an incorrect data structure. The fix ensures that employee IDs are handled properly, preventing duplicate key errors and ensuring accurate work order assignments. This improves the reliability of the work order management process.
Original PR description
The previous loop used `employee.id` as the key, which is undefined in this context because values come from resIds and represent record IDs directly. Steps to reproduce: - Enable work orders - Create a BOM with a work order - Configure 2 Assigned employees - Open the work order in Shop Floor An error is raised because, since `employee` is an integer (the ID), `employee.id` is undefined so odoo founds duplicate keys (all undefined). opw-5417887
This update resolves a technical issue preventing payroll tests from running correctly in both Hong Kong and Belgium. Specifically, it ensures the correct company settings are used during test execution, aligning data with payroll configurations and improving test reliability. This change is a fix for a known problem.
Original PR description
As we are enabling tests on runbot, a few issues need to be fixed. When tested in the l10n build, the BE tests are failing due to company setting issue on the admin user. Also aligns the readonly attribute of two computed field on the version to match the employee in HK payroll.
This update resolves a crash within the automated test suite for the Belgian payroll and HR module. The issue stemmed from missing instructions during a test involving job changes, causing unexpected page transitions. This fix ensures the test suite runs smoothly and reliably.
Original PR description
In the test tour related to the correct change of the salary configurator when the job changes on the employee, some missing expectUnloadPage options were causing the test to crash because the page was changing unexpectedly. With this PR we fix this error. Runbot Error: 231605 Forward-Port-Of: odoo/enterprise#105067
This update fixes an issue where Swiss payslips generated from payruns were named 'new payslip' instead of including the employee's name and pay period. The change ensures that PDF payslips now accurately display the employee's name and the relevant time period, improving clarity and compliance for Swiss payroll reporting.
Original PR description
_ ## Short functional explanation of the error When generating a payslip from a payrun for an employee on the swiss localization, the name of the PDF payslip is simply "new payslip" instead of…
_ ## Short functional explanation of the error When generating a payslip from a payrun for an employee on the swiss localization, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - <name of employee> - <time period of the slip>" ## Reproduction Steps 1. Install the app l10n_ch_hr_payroll. 2. Make sure you use a Swiss company. 3. Go to Payroll and click on the Payslips tab > payslips. 4. Click on Pay Run. Select Switzerland: ELM salaries and click Continue. 5. Select an employee for which you'd like to generate the payslip. 6. Click on the employee row in the list view. 7. Click Compute sheet > Print. ## Expected behavior A PDF with name "Salary Slip - <employee name> - <time period>" is generated. ## Unexpected Behavior A PDF with name "new Payslip" is generated. ## Origin of the issue When printing the slip with this flow, we don't call the method ```_compute_name()``` used to compute the name of the current slip. Therefore, it stays at 'New Slip', which is the default name. Henceforth, we have to call this method manually when printing the slip. _ opw-5253811
This update fixes an issue where test bank statement imports would create records in the database even after failing. The change ensures that test imports don't trigger reconciliation processes, preventing unintended data creation. This improves the reliability of test data and simplifies troubleshooting.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard 1) - On "Bank" journal card, select "Import File" option in dropdown menu - Upload a file containing a lot of statements…
**Steps to reproduce:**
- Install Accounting
- Go to Accounting dashboard
1) - On "Bank" journal card, select "Import File" option in dropdown menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
2) - Open "Bank" journal
- Select "Import records" in the cog menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
3) - Open "Bank" journal
- Click on "Upload" button
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
**Issue:**
The issue happens when the test import fails.
Even if it was a test, all the records are created in the database.
**Cause:**
During a test import the records should not be reconciled after creation.
However, by default, "auto_statement_processing" property is True and trigger the reconciliation.
When an error is raised during the test import, a rollback is made on a previous savepoint.
But a commit can be done in "_cron_try_auto_reconcile_statement_lines" method, which results in the records being created for real.
**Solution:**
Set "auto_statement_processing" property to False for Test import.
For use case 1) and 2), we make sure that we follow the same flow than use case 3).
opw-5436937