Wednesday, January 14, 2026
22 changes · saas-18.3
Enhancements to existing features
This update adds three new fields to invoices generated for Chorus Pro compliance – Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header, allowing for accurate documentation required by Chorus Pro and improving data tracking for financial reporting.
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 fixes a minor issue in the VoIP contact search test. Previously, the test could produce incorrect results due to data used in the demo environment. The fix now ensures the test only uses data created specifically for the test, leading to more reliable and accurate search results.
Original PR description
In the test, we suppose to find no phone number matched result when search term length is shorter than `_phone_search_min_length`. However, it can still match `name` or `email` if possible. In this fix, we change the test to only consider the data created in the test, to avoid the wrong result from demo data. backport odoo/enterprise#101200
This update fixes an issue where a distracting helper message remained visible in the bank reconciliation journal when there were no entries. The change hides this message, creating a cleaner and more professional experience, particularly on mobile devices. This improves usability and reduces visual clutter.
Original PR description
Before this PR, in the bank reconciliation journal, the no-content helper remained visible when the quick-create view was opened and there were 0 entries. This was unexpected behavior and caused overlapping issues, especially on mobile views. With this PR, the no-content helper is hidden whenever the quick-create view is open and there are 0 entries either isGrouped or not. task-5470591
This update resolves an issue where FrontDesk hosts with restricted user access couldn't complete the visitor checkout process via email. The fix allows the checkout action to run with elevated permissions, ensuring all hosts can now successfully check out visitors without errors. This improves the usability of the FrontDesk module for all staff.
Original PR description
Steps to reproduce: * Create a visitor record with a host who has only FrontDesk user access. * Ensure Notify with Email is enabled on the station. * Click Check Out Visitor from the received email → access error appears. Issue: * Hosts with only FrontDesk user access received an access error when clicking the “Check Out Visitor” button from the email notification. * They were unable to complete the visitor checkout process. Fix: * Run the checkout action with sudo() so the host can successfully check out the visitor from the email link. Impact: * Hosts can now check out visitors without encountering permission errors. task-5373026
This update fixes an issue where follower list avatars appeared distorted, particularly with non-square images. The change utilizes a standard Odoo class for avatars, ensuring consistent and correct image scaling and ratios. This improves the visual appearance of the follower list for all users.
Original PR description
Before this commit, follower list menu had avatar that do not preserve ratio of avatars. This is noticeable for avatars that have ratio quite different from 1:1, like 3:2 or 2:3 or even less squarish. This happens because of missing `.o_object_fit_cover`, that [1] erroneously removed from REF of follower template part into its own component. This commit uses an equivalent but more official solution: `.o_avatar`, which is a classname dedicated for avatars, which has `.o_object_fit_cover` property. Task-5412078 Before / After <img width="638" height="526" alt="Screenshot 2026-01-12 at 17 23 54" src="https://github.com/user-attachments/assets/b8d3a921-52a8-48b7-a0d0-5fbfdd33a92c" /> <img width="640" height="528" alt="Screenshot 2026-01-12 at 17 23 33" src="https://github.com/user-attachments/assets/8070420c-f341-4085-bcb2-2fba060765f0" /> [1]: https://github.com/odoo/odoo/pull/200382
This update fixes an issue where a specific error occurred when a leave request was linked to a refused allocation and the system's automated cleanup process ran. The fix addresses a problem with how data was being accessed, preventing a traceback and ensuring the system functions correctly under these circumstances. This improves the reliability of leave management.
Original PR description
When a leave is linked to a refused allocation and the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs. Steps to reproduce the error: - Install ``hr_holidays`` without demo data -…
When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.
Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
- Allocation Type: Accrual Allocation
- Set the Time Off Type and Accrual Plan created above
- Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``
Traceback:
``IndexError: list index out of range``
https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.
sentry-6874651972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243315
Forward-Port-Of: odoo/odoo#227201This update resolves an issue where superuser mode prevented users from correctly pinning or unpinning embedded actions within the Documents module. The change adds a check for superuser status, allowing superusers to perform these actions without errors, which is crucial for automated processes and installation scripts.
Original PR description
Prior to this commit, an AccessError would be raised when pinning or unpinning embedded actions if the current user did not belong to the 'documents.group_documents_user' group. This could cause issues during operations running in superuser mode (e.g., automated actions, installation scripts, or sudo() calls) because the check strictly validated the user's groups without considering the environment's superuser flag. This commit adds a check for `self.env.su` to ensure the AccessError is not raised when the environment is in superuser mode. Task-5380727 Forward-Port-Of: odoo/enterprise#104043 Forward-Port-Of: odoo/enterprise#101106
This update fixes an issue where matching a partner by bank account could be overwritten by a subsequent match using the partner's name. This ensures that the correct partner is always associated with bank statements, improving data accuracy and reliability. The change prevents redundant matching and avoids incorrect partner assignments.
Original PR description
Ensure the retrive partner from partner name doesn't override the retrieve partner from bank account. When retrieving a partner on an st_line, we first check for a match based on the bank account, and then on the partner name. However, we fail to check if a match was already found before searching by name. This means that if a partner is matched via bank account, and subsequently another match is found via name, the first match gets overridden by the second one. This commit adds a check for st_line.partner_id before attempting further matching, preventing the previous result from being overridden. no-task
This update fixes a technical issue that prevented Odoo from properly exporting code translations for the new odoo.orm package. By specifying the package name in the framework's export process, Odoo can now accurately capture and manage code translations, ensuring consistent localization across the platform. This improves the quality and availability of translated code for our users.
Original PR description
New package odoo.orm was added in PR https://github.com/odoo/odoo/pull/182727 The new package's name must be specified in ``TranslationModuleReader._export_translatable_resources`` to allow the framework to export its code translations. 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#243584
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 pragmatic workaround to avoid blocking legitimate emails.
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 portal triggered a false 'page view' event for customers. A simple adjustment was made to the request headers sent from the link preview, ensuring accurate tracking of customer portal activity. This improves the reliability of our data regarding customer engagement.
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 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, preventing confusion and ensuring invoices are processed properly. This improves the reliability of the HR EDI module.
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 a minor performance issue in a test related to loading menus within the Odoo web application. The change optimizes a database query, resulting in faster test execution times. This improves the overall stability and responsiveness of the web module.
Original PR description
Forward-Port-Of: odoo/odoo#243298
This update resolves a rare error in tax calculations that occurred due to the unpredictable order in which a set of allowed tokens is processed. The fix ensures that tax formulas are consistently evaluated, preventing calculation failures. This improves the reliability of tax processing within Odoo.
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 a technical issue in the Odoo recruitment demo data. The system was incorrectly using user records instead of partner records, which caused errors. This fix ensures the demo data functions correctly, providing a reliable demonstration of the recruitment module.
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 update fixes several issues within the o_spreadsheet component, ensuring it's running the latest version (18.3.32). These fixes improve the functionality and stability of the spreadsheet feature, particularly related to calculations and data selection within the application.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/8d1d32160 [REL] 18.3.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/8d1d32160 [REL] 18.3.32 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3d2d2e6da [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/de60a1cd2 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/61bbf4ce1 [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/42d525737 [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 website menu entries incorrectly pointed to the last created page when multiple pages with the same name were created. The change ensures menu entries are only updated with the correct page ID upon initial page creation, preventing confusion and ensuring accurate page linking across the website.
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 fixes a potential issue where applicants could re-sign previously completed job offers, leading to incorrect offer statuses. The change blocks access to these fully signed offers, ensuring data integrity and preventing users from unintentionally modifying offer details. This improves the reliability of the applicant workflow.
Original PR description
This commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456 Forward-Port-Of: odoo/enterprise#103527 Forward-Port-Of: odoo/enterprise#101834
This update resolves a technical issue preventing the correct saving of order details related to Swedish point-of-sale systems. The fix ensures that crucial data is properly recorded, improving the reliability of order information. 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#104218 Forward-Port-Of: odoo/enterprise#104180
This update aligns a small icon used in the SaaS dashboard with established design guidelines. The change ensures a more consistent and professional look and feel for our users. It's a minor visual improvement that contributes to overall brand quality.
Original PR description
This `network_light.svg` wasn't quite aligned with Milky picto's design guidelines. In this PR the pictogram has been tweaked in order for it to follow the guidelines. task-5126719
This pull request removes a redundant CSS class from the Point of Sale module. The class was previously used to limit button width but is no longer needed. This cleanup improves the codebase and reduces potential maintenance overhead.
Original PR description
The issue was to put the button css class at a max width of 200px. But it's not used anymore. So it can be deleted bug was created from this pr : https://github.com/odoo/odoo/pull/229478 task : 5493872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the process of generating UBL invoices for Colombia and Mexico by refactoring internal code and automating the customer/supplier swap for vendor bills. This change improves the flexibility and maintainability of the system, ensuring 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