Wednesday, January 14, 2026
16 changes · saas-18.2
Enhancements to existing features
This update adds three new fields to Odoo invoice PDFs – Buyer Reference, Contract Reference, and Purchase Order Reference – to ensure compliance with Chorus Pro requirements. These fields allow users to accurately document key purchase information directly on the invoice, simplifying the invoicing process for Chorus Pro clients.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836 Forward-Port-Of: odoo/odoo#240494
Resolved issues and error corrections
This update resolves an issue where printing reports using custom handlers (like IoT) didn't automatically close the associated wizard. Previously, the wizard remained open, leading to unexpected behavior. Now, the system correctly closes the wizard after a report download, regardless of the handler used.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#238247
This update ensures that rating cards are only shown in portal chatter when a module specifically requests them. Previously, rating cards were displayed even when a module didn't explicitly enable the feature, leading to a cluttered user experience. This change improves the portal's clarity and focus.
Original PR description
*: test_mail_full Modules using portal rating can set an `data-display_rating` attribute when calling the portal chatter template to indicate whether they want the rating feature displayed. Currently, only two modules have this attribute set to true: ecommerce and elearning. For other modules that don't set this attribute, even if there is a rating, such as when rating a ticket in the helpdesk module, we don't want the rating card feature to be shown in portal chatter. This change ensures that the feature is only available if the module requests it. task-5347848 Forward-Port-Of: odoo/odoo#243255
This update resolves an issue where Odoo encountered errors when processing emails with attachment content types incorrectly identified as '*/*'. To ensure emails are processed smoothly, the system now defaults to 'application/octet-stream' for these cases, minimizing disruption. The change is a temporary workaround until email senders consistently adhere to standard MIME types.
Original PR description
In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type. While trying to parse such content in Odoo, it causes issues with the…
In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type. While trying to parse such content in Odoo, it causes issues with the standard CPython email library, as no standard handler exists for '*/*' content-types: Example error: ``` File "/usr/lib/python3.13/email/contentmanager.py", line 25, in get_content raise KeyError(content_type) KeyError: '*/*' ``` This is not compliant with valid MIME types defined in RFC2046/section-3, but in real life scenarios, blocking the processing of an incoming email in Odoo because of this might be excessive. While not a perfect solution, we will assume that attachments falsly reported as `*/*` are to be processed as 'application/octet-stream' content types. This should cover most use-cases, and if it still fails, we will consider that it's up to the original email sender to be RFC compliant. OPW-5425093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242193
This update resolves an issue where clicking a link in the Odoo portal triggered a false 'page view' event for customers. A simple change was made to the request headers to accurately track link clicks. This ensures that customer page views are recorded correctly, improving reporting and analytics.
Original PR description
When a link to the portal is sent from the chatter via message or log note, the preview of the link triggers that the page was viewed by customer. As a solution a variable was added to the request headers coming from the previewer. opw-5237785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243061
This update corrects a potential issue where admin users could inadvertently modify course ratings by editing or deleting other users' messages. The change ensures that default rating options remain consistent for admin users, maintaining the integrity of course evaluations. This prevents unintended alterations to course data.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273 Forward-Port-Of: odoo/odoo#236475
This update resolves an issue where enabling integer rounding on Aged Receivable reports would cause a crash. The fix prevents the system from attempting calculations with 'None' values, which were triggering an error. This ensures reports function correctly regardless of rounding settings.
Original PR description
Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None. Steps to…
Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None. Steps to reproduce: 1) Install 'account_reports' module with demo data and enable developer mode. 2) Navigate to Accounting > Reporting> Partner Reports > Aged Receivable. 3) Click on 'gear icon' to navigate advance options. 4) Click on the Options tab and set Integer Rounding to 'Nearest', click save and close adv options. 5) Expand a partner line. Error: `TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'` Root Cause: When integer rounding is enabled, the system iterates over formula results to round them using `float_round`(see[1]). However, specific report columns (such as totals for empty periods) may return None. The `float_round` function attempts to perform arithmetic on this value, failing because it cannot divide NoneType. FIX: Skip the rounding if the value received at [1] is None. [1]- https://github.com/odoo/enterprise/blob/9b517564d95424836da1e8368f6b5dc52ae45d1a/account_reports/models/account_report.py#L3329 opw-5392883 Forward-Port-Of: odoo/enterprise#102417
This update resolves a technical problem preventing the correct saving of order details (blackbox data) for the Swedish point-of-sale system. The fix ensures that this critical data is properly recorded in the database, improving data accuracy and reporting. It also includes updates for compatibility with new IoT box images.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585 Forward-Port-Of: odoo/enterprise#104180
This update fixes a problem where incorrect credentials caused misleading error messages when sending invoices. The change adds a test to ensure the correct error is displayed, improving the user experience and preventing confusion. This ensures invoices are processed correctly and reduces potential delays.
Original PR description
Fixing incorrect error display that occurred while trying to send an invoice to MER with incorrect credentials set up. (no task/error ID) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243489
This update resolves an issue where creating payroll rule parameters with future dates could trigger an error. The fix initializes computed fields to a default value, ensuring correct calculations regardless of the date used. This prevents unexpected compute errors and improves the stability of payroll processing.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500This update resolves a sporadic error in tax calculations that stemmed from how Odoo processes formulas. The issue was caused by the random order in which a set of allowed tokens is iterated, leading to inconsistent formula evaluation. This fix ensures more reliable tax calculations.
Original PR description
…me tokens greedily. Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033 This is a hard to reproduce bug because it depends in what order the…
…me tokens greedily. Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033 This is a hard to reproduce bug because it depends in what order the FORMULA_ALLOWED_TOKENS set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this: There might be taxes that do a different calculation depending on the base. So for example, we might need to do a formula like this: (base >= 100) and (base * 0.05) or (base * 0.07) <img width="1302" height="651" alt="Captura de pantalla 2025-12-26 a la(s) 11 17 02" src="https://github.com/user-attachments/assets/7ce16272-56a4-452b-8eba-e797442f68c2" /> This formula multiplies the base by a certain value depending on whether the base is greater or equal than 100. This formula will work sometimes, but sometimes, it will fail with this error. <img width="1302" height="615" alt="Captura de pantalla 2025-12-26 a la(s) 11 18 48" src="https://github.com/user-attachments/assets/5527ff5d-6747-4221-b54f-085e0603aa5a" /> The position of the error is the '=', because the '=' is not a valid token in this list: https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L10. The formula is not using just the '=' token in this formula. The formula is using the '>=' token and '>=' is an allowed token. So why this error appears sometimes? So here is the important thing and why this bug appears only sometimes: FORMULA_ALLOWED_TOKENS is not a tuple. It is a set. And sets iterate randomly (it is an unordered list). So the loop in this line: https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L127 sometimes sees the token '>=' first, and sometimes sees the token '>' first in its cycle. When the '>=' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>=' first so it advances 2 positions. In this scenario, the validation does not fail. But when the '>' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>' first so it advances 1 position. It has consumed only the '>' of '>='. Now, it will try to match the lone '=' to any of it tokens in the set of allowed tokens, but this '=' will not match any of the allowed tokens, so it will fail. You can reproduce this bug using the above formula, and restarting Odoo if the error does not appear. Eventually, after restarting, the FORMULA_ALLOWED_TOKENS will have the '>' first and trigger the error. The important part to understand here is that FORMULA_ALLOWED_TOKENS is unordered, so, the order of the loop is not guaranteed and sometimes this error is triggered and sometimes it is not, depending on the order the loop is done. 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#242661
This update resolves an issue where group channels (DMs with fewer than 3 members) were displaying incorrect information, such as a 'back on' banner and an IM status. The fix prevents the system from incorrectly identifying these channels, resulting in a more accurate and consistent user experience.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395 Forward-Port-Of: odoo/odoo#242058
This update resolves a technical issue where demo data for the recruitment module was incorrectly referencing user records instead of partner records. This fix ensures the demo data accurately reflects the expected data structure, improving the usability and reliability of the recruitment demo.
Original PR description
author_id expects a res.partner record. In this commit: Replace the user record with the corresponding partner record to avoid passing an incorrect recordset in demo data. Forward-Port-Of: odoo/odoo#241260
This pull request updates the core spreadsheet component within Odoo. It addresses several minor bugs and improves performance related to calculations and sheet selection, ensuring a smoother user experience. This update was made by a team of developers to maintain the stability and functionality of the spreadsheet feature.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/755a787c4 [REL] 18.2.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/755a787c4 [REL] 18.2.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/2322bd78f [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782) https://github.com/odoo/o-spreadsheet/commit/2783ff635 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/673dd2ee7 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885) https://github.com/odoo/o-spreadsheet/commit/ef7b40f5c [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an issue where menu entries were incorrectly updating across multiple pages with the same name. Now, menu entries are only updated when a new page is created, preventing confusion and ensuring accurate page linking. This improves the consistency of the website navigation.
Original PR description
With commit 19302cd40347065fcd937bd54e6dce27fe4940cc, when a page is created, menu entries with a url corresponding to the created page are updated to set their `page_id` to the new page. The update may also be triggered when creating several pages with the same name in a row. This commit updates a menu entry on page creation only if no page were already associated to the menu. Steps to reproduce: - Create a new page, call it "test" (will be available on `/test`) - Create a new page, call it "test" (will be available on `/test-1`) - Go to editor menu - Bug: both entries point to `/test-1` - Create a new page, call it "test" (will be available on `/test-2`) - Go to editor menu - Bug: the first one (and the new one) is pointing now to `/test-2` task-5186653 Forward-Port-Of: odoo/odoo#243312
This update simplifies the process of generating UBL invoices for Colombia and Mexico by streamlining internal code. Specifically, the order of customer and supplier information in vendor bills has been automatically corrected, and the underlying code has been refactored for easier future modifications. This ensures consistent and accurate UBL invoice generation.
Original PR description
For the Self-billing backport, we made two modifications which entail a small change in the l10n_co_dian and l10n_mx_edi code: - `_check_move_constrains` has been refactored to call a new `_get_move_constraints` method, which is more easily extensible. We perform the same modification in l10n_mx_edi. Note `_check_move_constrains` is still there, so any overrides will still work. - The customer and supplier are now swapped by default when exporting a vendor bill UBL, so it's no longer needed to do this specifically for the DIAN UBL. Community PR: https://github.com/odoo/odoo/pull/232548 Backport of https://github.com/odoo/enterprise/pull/92205 task-5153851 Forward-Port-Of: odoo/enterprise#97803