Monday, January 26, 2026
53 changes · master
Resolved issues and error corrections
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding was mistakenly carried over from annual reports due to a previous split in the codebase. This ensures accurate VAT reporting for Italian businesses.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104679 Forward-Port-Of: odoo/enterprise#103852
This update resolves an issue where website tour tests would fail after changing the header template to 'Sidebar'. The fix ensures the website builder remounts correctly before the tour proceeds, preventing the builder from resetting to its initial state and maintaining test stability.
Original PR description
When changing the header template to 'Sidebar', the loading screen disappears but the WebsiteBuilder component remounts asynchronously. If the tour proceeds to the theme tab before the remount completes, the builder resets to the Edit tab (its initial state), breaking the test flow. We wait for the builder to remount, and add `.editor_enable` class to the body of the iframe, so then nothing disrupts the flow. runbot-234504 Forward-Port-Of: odoo/odoo#245271 Forward-Port-Of: odoo/odoo#243518
This update fixes an issue where fiscal data for Chinese credit notes wasn't appearing in the PDF reports. The fix involved ensuring the correct display of a conditional element within the report template, now correctly rendering the required financial information.
Original PR description
The fiscal data is not displayed in the credit note pdf. This is because we're relaying on a div that is conditionnally displayed in the inherited template. opw-5467583 Forward-Port-Of: odoo/enterprise#104924
This update resolves an issue where the invite input field automatically gained focus, disrupting other dialogs like the call permission dialog. Now, the input only focuses when it's active and the user's context is engaged. Additionally, a testing helper was moved to improve test reliability.
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 Forward-Port-Of: odoo/odoo#245334 Forward-Port-Of: odoo/odoo#236248
This update improves the product information displayed in the point-of-sale system. It now shows the product's internal 'default_code' alongside its name in the product info popup. This provides additional context and traceability for sales staff and inventory management.
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 Forward-Port-Of: odoo/odoo#244068
A recent test for our live chat feature was intermittently failing due to a timing issue. This update increases the test's waiting period, allowing it to reliably process notifications even under heavy load. This ensures the live chat test remains stable and provides consistent results.
Original PR description
The `Only two quick actions are shown` live chat test awaits the first posted message because to avoid conflict with the reaction being added afterwards. To do so, the test uses the `waitForSteps` helper. However, during high load, 200ms might be too short to receive the notification, leading to the test failing. This commit increases the timeout. runbot-237587 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#245421
This update resolves an intermittent error that occurred when printing multiple receipts quickly via USB. The fix prevents multiple threads from accessing the printer simultaneously, ensuring reliable ESC/POS printing and eliminating fallback to CUPS. This improves the overall stability of receipt generation.
Original PR description
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS…
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status ERROR ? root: Could not set configuration: [Errno 16] Resource busy ``` This would cause `python-escpos` to be disabled and fallback to just CUPS printing. The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways: - IoT thread with `python-escpos` and CUPS try to access the printer at the same time. - Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time). Both of these scenarios should now prevented: - Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it. - We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time. task-5490942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245122 Forward-Port-Of: odoo/odoo#244031
This update resolves an issue preventing grouping within the planning module's slot templates. The fix ensures that parameters are passed to the underlying method in the correct order, enabling proper data aggregation. This improves the functionality of the planning system.
Original PR description
Before this commit, it was impossible to group by on any field in `planning.slot.template` model, because the parameters given to the parent method of `formatted_read_group` method were not given into the right order. This commit makes sure the order is respected. Forward-Port-Of: odoo/enterprise#105211
A technical error prevented the creation of a key email template when rental orders were present. This fix moved a necessary method to the `sale_renting` module, ensuring template validation works correctly regardless of whether the rental module is installed. This resolves a potential issue with e-commerce order emails.
Original PR description
The mail template `mail_template_sale_cart_recovery` creation fails in some cases if there is a rental order in the database. Indeed, during a template creation, the first record of the corresponding model is used to validate the template validity. In this case, the template is only meant for e-commerce orders and there won't be any e-commerce rental order without `website_sale_renting` but the validation is not aware of functional specificities, leading to a traceback because the method `_get_rental_pricing_description` doesn't exist when only `sale_renting` and `website_sale` are installed. To avoid this error, we move the method to `sale_renting`, even though there is no real life flows where this was breaking (except templates validation ofc). Was fixed first with c3f5dafa23a8b1fd36eaedd83a575b717e5e9377 but moved back into `website_sale_renting` by mistake with fd1d7f91e7e60a20a5401201ff89a7e875faad82 Forward-Port-Of: odoo/enterprise#105318
This update removes the Sign menu item from Odoo's Discuss channels. Previously, this menu was incorrectly displayed, which was confusing for users. This change ensures Discuss channels function as intended, focusing on mail threads instead of sign requests.
Original PR description
Currently, the Sign menu item is displayed in discuss channels, which is not making sense. This was due to an incomplete check in the isDisplayed method of the SignRequestCogMenu component. To fix this, we enhance the condition to ensure that the menu item is not displayed when the current model is 'discuss.channel'. Discuss channels inherently support mail threads, but should not have the Sign menu item. task-5494751 Forward-Port-Of: odoo/enterprise#105201
This update resolves an issue where the l10n_cl_edi module was incorrectly creating duplicate vendor bills when receiving identical XML invoices via the incoming mail server. The fix prevents duplicate bill creation, ensuring accurate record-keeping and avoiding potential accounting discrepancies. This addresses previous support tickets opw-5362664 and opw-5409700.
Original PR description
Steps to reproduce: - With a CL Company setup - Configure an incoming mail server with DTE server option enabled - In Vendor Bills journal, enable 'Use Documents?' - Receive the same XML twice via the incoming mail server - Check created vendor bills Issue: There will be duplicated bills. Each duplicate will show the message 'E-invoice already exist: nnnnn' However, the system should avoid duplicates from being created. opw-5362664 opw-5409700 Forward-Port-Of: odoo/enterprise#103211
This update resolves an issue where Odoo could encounter errors due to invalid IDs used when browsing data. The fix adds a filter to ensure all IDs are valid before processing, preventing a potential crash. This improves stability and reliability of Odoo trials.
Original PR description
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields:…
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal
This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields: `(menus|views|reports)_by_module` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.
One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)
This fix will avoid any additional traceback like this one.
opw-5865316
Forward-Port-Of: odoo/odoo#245469This update resolves a problem where a test tour for tax reports failed when specific localization modules weren't installed. The fix involved adjusting how the tour handles date calculations and ensuring it correctly identifies the appropriate tax report type based on the company's configuration. This ensures the test tour runs reliably across different Odoo environments.
Original PR description
- The tour shouldn't run if a localization with 'Tax Report' for the country is not installed (i.e. l10n_us_account) - Dynamic Javascript dates calculation don't mix well with Python's freeze_time running in the "No future" 2026 preparation build, so I froze the time in the Python test but resorted to hardcode the Javascript dates. - No need to check the position of the column "Column 1". In debug mode for the tour, there will be the "Debug" column where the info about the computations are shown, so it won't be the last. We just need to see that it shows, after all. Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624 Forward-Port-Of: odoo/enterprise#101689
This update corrects a display issue in the Barcode application where the inventory count badge incorrectly showed requests from one company even when no count existed for another. The fix ensures the badge accurately reflects the current inventory count for the company currently being viewed, improving data accuracy and reporting.
Original PR description
Steps to reproduce: - Create two companies (A and B) - Create a storable product "P1" - Log in with company A - Update the on-hand quantity of P1 in company A only - From Physical Inventory, request an inventory count for P1 - Switch to company B - Open the Barcode application Problem: The inventory count badge in the Barcode main menu displays a request count created for company A, even though no inventory count exists for company B. The badge incorrectly shows "1" instead of "0". opw-[5472031](https://www.odoo.com/web#id=5472031&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#104065
This update resolves an issue where currency rounding errors were causing the system to incorrectly remove small cash differences from reports. The fix ensures that even minor discrepancies, resulting from rounding, are accurately reflected, preventing unintended cash adjustments. This improves the reliability of our sales reporting.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update fixes an issue where the 'Pending' button in the manufacturing order system incorrectly stopped productivity records for all employees involved, instead of just the current one. The change ensures that only the employee actively working on the operation is impacted, improving workflow efficiency and preventing unnecessary resource allocation.
Original PR description
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Create a new operation OP1
- Create a manufacturing order to produce one unit of P1
- Confirm the manufacturing order
- Log in as Mitchel (admin) and start OP1
- Log in as Marc (demo) and also start OP1
- Click on Pending
Problem:
Both “mrp.workcenter.productivity” records are stopped, instead of stopping only the one linked to
The `button_pending` method was stopping productivity records for all employees linked to the work order.
opw-5453752
Forward-Port-Of: odoo/enterprise#105238
Forward-Port-Of: odoo/enterprise#103553This update allows users to modify fields within the 'stock.quant' view through Odoo's Studio interface, even if those fields don't have a unique identifier. Previously, this was restricted, but this change ensures Studio customizations are correctly applied to stock quantities.
Original PR description
In versions prior to 18.3, the “stock.quant” view did not have an “xml_id”, which prevented it from being modified through Studio. However, starting from version 18.3 and specifically since this commit: https://github.com/odoo/enterprise/commit/f4a4d54d45392c2ba46a123d4951f8b4468c5cba it is now possible to modify views through Studio even if they don't have an xml_id. But in the 'stock.quant' view, we perform a check at creation time to ensure that the field is among the allowed fields. Fields coming from Studio or from a customized view should, however, be ignored by this check and allowed. opw-5107591 Forward-Port-Of: odoo/odoo#230126
This update fixes a potential issue in the Swiss payroll reporting process. It now only creates a snapshot of the required data if one doesn't already exist, preventing unnecessary data duplication and improving the efficiency of the reporting system. This ensures more accurate and timely payroll reports for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#105258 Forward-Port-Of: odoo/enterprise#105135
This update resolves a potential issue where tracking numbers in the POS Self Order module could collide. Due to limitations in adding new fields to the main Odoo version, a simple method was implemented to randomly add a letter prefix (K) to tracking numbers, preventing duplicates and ensuring accurate order tracking.
Original PR description
Since we cannot add fields in stable we use a little trick to avoid collisions in tracking numbers for POS Self Order module. We do a modulo operation on the ID of the PoS config to select a random letter from A-Z and prepend it to the tracking number. Forward-Port-Of: odoo/odoo#245476
This change removes a previous restriction that limited the ability to use certain journal accounts for reconciliation. Previously, accounts used as default debit or credit accounts within journals were automatically prevented from being reconciled. This update provides greater flexibility for users to reconcile accounts as needed, improving the system's usability.
Original PR description
Previously, a constraint prevented accounts from being non-reconcilable if they were used as default debit/credit accounts involved in journals. This behavior is too restrictive. This commit removes the constraint. task-5254202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245608 Forward-Port-Of: odoo/odoo#244398
This update resolves a bug that occurred when generating German reports. Specifically, a division-by-zero error was triggered when currency exchange differences (where the amount_currency was zero) were processed. The fix ensures that these lines are correctly handled, preventing the error and improving report accuracy.
Original PR description
On move lines with zero `amount_currency` ( ex. currency exchange difference ), `_get_product_base_line_currency_rate` returns 0 currency rate which causes a division by zero error. Ignore the rate for lines with zero `amount_currency` opt-5358954 Forward-Port-Of: odoo/enterprise#105432 Forward-Port-Of: odoo/enterprise#105360
This update resolves a technical issue where creating two Sri Lanka companies resulted in an error due to duplicate tax IDs with periods. The fix removes the periods from the tax IDs in the system's configuration, ensuring proper company identification and preventing the error. This improves data accuracy for Sri Lankan businesses using Odoo.
Original PR description
**STEP TO REPRODUCE** 1. create a company, and set country to Sri Lanka. 2. create a 2nd company, and do the same. 3. There is a company inconsistencies error. **CAUSE** There is 2 taxes defined in `account.tax-lk.csv` with `.` in their id. This messes up with the function `company_xmlid()`: we end up loading the `account.tax` record of the 1st company when saving the 2nd company. opw-5473952 Forward-Port-Of: odoo/odoo#245244
A test failure in the payroll system's 13th month calculation was identified and fixed. The issue stemmed from incorrect date calculations within the test environment, specifically related to standard work hour calendars. This change ensures accurate 13th month pay calculations for employees.
Original PR description
[FIX] test_l10n_be_hr_payroll_account: fix the test of 13th month full leave Bug production: It is a runbot error occurred in test_13th_month_full_leave (version: master); 1 - Install and update…
[FIX] test_l10n_be_hr_payroll_account: fix the test of 13th month full leave
Bug production: It is a runbot error occurred in test_13th_month_full_leave (version: master);
1 - Install and update l10n_be_hr_payroll,l10n_be_hr_payroll_account,test_l10n_be_hr_payroll_account,hr_holidays,resource modules in localhost
2 - Execute the test test_13th_month_full_leave and it will fail, also in the same class (Test13thMonth) many other tests were failing.
Bug cause:
1 - In test test_13th_month_full_leave, for all year the sick day timeoff is allocated. (year: 2025), generate work entries for 2025 and expecting payslip amount must be 0 but it is not.
2 - When I looked to _get_paid_amount -> _get_paid_amount_13th_month -> _compute_presence_prorated_fixed_wage: Some days in the year was not counted as sick day and since few days are not counted, the payslip amount is > 0.
3 - By diving deeper: in function _get_calendar_days: date_to = min(date_max, leave.date_to.date()), from this line, I observed that leave.date_to is calculated 1 days before sometimes.
4 - In hr.leave model -> _compute_date_from_to -> hour_from, hour_to = holiday._get_hour_from_to(holiday.request_date_from, holiday.request_date_to) -> In here hour_from and hour_to is (0,0) when the calendar (id = 1) standard 40h/week is used.
5 - Since it returns (0,0) and converted to UTC in the next line, the date_to becomes 1 day before the expected date_to.
6 - After finding that, the standard 40h/week calendar returns (0,0) for work start hour and work end hour, I looked to 'resource.calendar' model.
7 - In function _get_default_attendance_ids, hour_from and hour_to returns 0,0 for typical 40 hours/week calendar which is not true.
8 - This standard calendar with id = 1 is used in other 4 tests in class Test13thMonth and they were failing as well, now all of them are fixed.
Bug solution:
1 - Fixing the hour_from and hour_to of standard 40h/week calendar from (0,0) -> (8, 16).
task - 5853076
Runbot Error
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-prThis update resolves an issue where applying text colors to lists in the HTML editor didn't correctly color the list markers. The fix corrects a logic error that was removing the text color class from the list item itself. Now, text color selections will consistently apply to both the text and the list marker.
Original PR description
### Steps to reproduce: - Create a list and type some text. - Press Ctrl + A and apply a text color from the toolbar. - Observe that the list marker is not colored. ### Description of the issue/feature this PR addresses: - `getFonts` looked for the closest element with a text color class, and this also matched `<li>` elements. When a `<li>` was selected, its text color class was removed and moved to a new <font> element created inside the `<li>`. - As a result, the color class was removed from the list item itself, which broke list marker coloring. ### Desired behavior after PR is merged: - Text color classes remain on list item, so list markers are colored correctly. task-5454639 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243005
Code cleanup and technical improvements
This update refactors the ECPay invoice widget conversion process within the Odoo website sale module. The changes improve the underlying code structure and make it easier to maintain and update the integration with ECPay. This ensures smoother and more reliable invoice generation for Odoo users.