Daily updates from Odoo
Wednesday, December 31, 2025
10 changes · 18.0
New functionality added to Odoo
This update incorporates new master data for Brazil, aligning with recent changes to the country's fiscal regulations. These adjustments ensure Odoo continues to accurately handle Brazilian tax reporting and compliance, supporting our business operations in the Brazilian market. The changes affect tax reporting data.
Original PR description
task-4939796 Forward-Port-Of: odoo/odoo#240988
Enhancements to existing features
This update prepares Odoo for Brazil's upcoming shift to a new consumption tax system starting in 2026. Users can enable this new system based on their business location and transaction types. The changes adapt our existing modules to comply with the new requirements, primarily impacting tax calculations and EDI processes.
Original PR description
2026 marks the start of Brazil's 8-year plan to migrate to a completely new consumption tax system [1]. The new system is meant to be simpler than the old one, but we defer to Avalara for tax…
2026 marks the start of Brazil's 8-year plan to migrate to a completely new consumption tax system [1]. The new system is meant to be simpler than the old one, but we defer to Avalara for tax calculation so we don't really notice it technically. The old and new system have to coexist for the foreseeable future because the rollout happens gradually over many years. Whether the new system has to be enabled depends on the federal state the business is in, the type of transactions they do, and other factors. The user has the option to enable it through the l10n_br_is_icbs Boolean flag on the company, which gates all the new functionality. These changes impact both tax calculation and EDI. This set of modules adapts our existing l10n_br* modules to the new requirements set out by Avalara. We are required to send extra values to their API, and in some cases adapt existing ones. task-4939796 [1] https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm Forward-Port-Of: odoo/enterprise#102706
Resolved issues and error corrections
A bug in the TPAR report test was resolved by updating the test to use dynamic dates based on the current user's date. This prevents failures caused by hardcoded dates, ensuring the test runs correctly regardless of the current year and future deployments. This improves test reliability.
Original PR description
Behavior before:
The TPAR report test used hardcoded dates ('2025-01-01' to '2025-12-31'). When running tests with Faketime or on future deployments, this caused failures because the test did not adapt to the current date.
Behavior after:
The test now uses dynamic dates based on `fields.Date.context_today(self.env.user)`. This ensures the test runs correctly regardless of the current year and avoids issues with hardcoded dates.
Root Cause:
Hardcoded dates in the test conflicted with Faketime, causing the test environment to simulate a future year and fail.
Runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/237547
Forward-Port-Of: odoo/enterprise#102960This update resolves an issue where images in image galleries with links were left-aligned instead of centered. The fix ensures images remain correctly centered within gallery links, particularly with smaller images. A CSS adjustment was implemented to address this alignment problem, providing a reliable solution.
Original PR description
Problem: When adding a link to an image in an image gallery, the image becomes left-aligned instead of centered. This issue is most noticeable with images that have a small width. Cause: The image is…
Problem: When adding a link to an image in an image gallery, the image becomes left-aligned instead of centered. This issue is most noticeable with images that have a small width. Cause: The image is centered using the `mx-auto` class. However, when the image is wrapped in an anchor (`<a>`), the anchor does not take up the full width of the container. As a result, the image is no longer centered and shifts to the left. Before: <img width="836" height="586" alt="image" src="https://github.com/user-attachments/assets/f51fed85-727d-4391-a186-8a966f71657a" /> After: <img width="747" height="583" alt="image" src="https://github.com/user-attachments/assets/6a3bd724-5b9c-4160-b0a4-73e8d7fdd1ec" /> Steps to reproduce: - Add an image gallery block. - Replace an image with one that has a small width. - Add a link to the image. - The image is no longer centered and aligns to the left. The issue occurs because the direct parent of the link-image uses `display: flex`. In this commit, a CSS rule was added so that links wrapping an image with Bootstrap margin classes (`mx-auto`, etc.) applied by the image alignment option also get the same margins. This is only done when the direct parent of the link uses `display: flex` which is the case for elements like `carousel-item`. We also targeted parents with the `d-flex` class to fix a similar issue in the `Blockquote` snippet, where the "avatar" image has a `d-flex` parent and becomes misaligned when wrapped in a link. A JavaScript fix was initially considered, by detecting in the image alignment or link application options whether the link’s parent used `display: flex`. That approach would have been more precise to detect a `display: flex` parent, but it wouldn’t cover manually added/moved images. The CSS solution covers all known cases, can still be improved, and has the advantage of working reliably in all situations. opw-4985504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where refund alerts were triggered incorrectly due to rounding differences between order totals and line item sums. The change ensures accurate comparisons, preventing false alerts and improving the reliability of the Point of Sale (POS) system. This update focuses on a technical fix related to financial reporting accuracy.
Original PR description
Before this commit, if the total amount of the order had rounding differences compared to the sum of its lines, the system could incorrectly trigger an alert stating that the refund amount exceeds the original order amount. This was due to a direct comparison between the two amounts without considering potential rounding issues. opw-5402240
This update prevents a payment error that occurred when invoices with missing due dates were processed. The fix ensures correct invoice calculations and payment processing by prioritizing invoice lines with due dates, resolving a potential disruption to financial operations.
Original PR description
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting`…
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting` module. - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`. - Go to `Invoices` and `create a new Invoice`. - Add one invoice line and set the `Payment Term` to the `newly created payment term`. - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden). - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`. - Now `Confirm the invoice` and `Click on Pay`. **Error:** `TypeError: '<' not supported between instances of 'datetime.date' and 'bool'` **Cause:** This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised. Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error. **Fix:** This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above. [1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703 [2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635 [3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305 [4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522 sentry-713241246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how Odoo handles web socket connections, particularly under heavy load. By delaying cursor acquisition attempts, the system reduces connection failures and improves overall responsiveness, especially when dealing with a large number of simultaneous users.
Original PR description
Benchmarking with 4k connected clients, 1 message per second. | | Message dispatching | Cursor analysis | |-- |-- | -- | | Before|<img width="600" alt="image" src="https://github.com/user-attachments/assets/f02e7efc-4611-4356-8bef-386ff2b0a7da" />|<img width="600" alt="2_current_implementation__cursor_analysis" src="https://github.com/user-attachments/assets/04dce96e-74a6-4f1b-9918-a6c61913e7c4" />| |After|<img width="600" alt="image" src="https://github.com/user-attachments/assets/a9463484-7f69-4fcb-a248-5692893a8893" />|<img width="600" height="997" alt="8_tweak_delay_both_sleep__cursor_analysis" src="https://github.com/user-attachments/assets/34a2c233-5c36-4597-a55b-cfb89a41efcf" />| Forward-Port-Of: odoo/odoo#241330
This update optimizes how product category information is loaded in the product screen, resolving a performance bottleneck. Previously, the loading process was slow and inefficient, particularly when dealing with many product categories. This change significantly improves the speed and responsiveness of the product screen, enhancing the user experience.
Original PR description
Before this commit, the product category info loading was done in O(n^2) time complexity due to nested loops. It caused performance issues when loading a large number of product categories. opw-5442894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where warnings from the IoT were incorrectly treated as errors. Now, warnings are displayed as notifications, providing clearer feedback to users about the status of transactions. This improves the user experience and ensures accurate reporting.
Original PR description
Before this commit, all errors returned by the iot after a call to the blackbox were considered as errors. Actually, the errors are only the ones that do not start with 0 (no error) or 1 (warning). This commit changes the behaviour when handling warning. We now show a notification. task-id: 5062178 Forward-Port-Of: odoo/enterprise#93896
This update resolves an error that prevented users from opening the employee form within the Point of Sale (POS) frontend. The fix disables the employee selection field on the frontend only, allowing the form to function correctly in the backend where all necessary data is available. This ensures a smoother user experience for POS operations.
Original PR description
Opening employee form in the frontend was throwing an error, since not all thre required assets were available on the PoS frontend. So in this commit 57aba149b6e6927f9055124e58bed03f842329d5, we disabled openening the employee form by making the employee_id field unclikcable, both in forntend and backend!! It was enough however to only macking it unclikcable on the frontend, since it was working fine on the backend where all the required assets were loaded anyway. This commit restores the functionality on the backend, but overriding the `Many2OneField` used by the `employee_id`, and making it unclickable only on the frontned. opw-5252486