Tuesday, January 6, 2026
26 changes · saas-18.4
Resolved issues and error corrections
This update resolves a technical error that prevented timesheets from correctly linking to sale orders when multiple identical sale orders were used. The fix ensures that timesheets consistently link to the first applicable sale order line, maintaining accurate tracking of service hours. This improves the reliability of timesheet data.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `industry_fsm_sale` module. 2. Open the settings of the field-service project and open the invoicing page 3. Add one employee on the…
Steps to reproduce:
------------------------------
1. Install `industry_fsm_sale` module.
2. Open the settings of the field-service project and open the invoicing page
3. Add one employee on the Invoicing page and create a new product with a Unit Price
4. On the product form, set the same value in the Sales Price field
5. Create a Sale Order with two sale order lines that use the same product and the same quantity
6. In Field Service create a Task for the same customer and set one of the sale order lines in the Sales Order Item field.
7. Create one timesheet for the task using the same employee added in the Invoicing page. Save the timesheet and click Mark as done
Observation:
------------------------------
A singleton traceback occurs when marking the task done:
```
raise ValueError('Expected singleton: %s' % record)
ValueError: Expected singleton: sale.order.line(62, 63)
```
Issue:
------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L507-L511
According to our scenario, we will get two SOL for the same product `id` and `price_unit` Which on further used to link the SOL to timesheet. Following code assumes the single SOL and gives singleton error https://github.com/odoo/enterprise/blob/31663b503c75dc2a83cc9585280df02f4d704e89/industry_fsm_sale/models/project_task.py#L553-L554
Solution:
------------------------------
When building the `sols_by_product_and_price_dict` using the key
(product_id, price_unit), When multiple sale order lines exist for the same key,
only keep the one that comes first in the sequence to maintain the consistency.
as in following code:
https://github.com/odoo/enterprise/blob/a7b79f79d90a37fb2458f05bcf439c109f1d756f/industry_fsm_sale/models/account_analytic_line.py#L15-L20
This ensures the timesheet always links to the first applicable sale
order line, matching existing behavior.
opw-5373018
Forward-Port-Of: odoo/enterprise#101774This update fixes an issue where the system was creating multiple Dimona activities for employees, leading to potential data inconsistencies. The change ensures that only one Dimona activity is created per employee, streamlining payroll processing and improving data accuracy. It was triggered by a manual update of the 'HR Employee: Update Current Version' automation.
Original PR description
create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium employee > new > payroll > contract > start_date: any date (this should create a first dimona activity) settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually `_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one. We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it. tasks-5134380 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
This update clarifies the purpose of the 'force_create' function within the Odoo account module. Previously, it was unclear that this function didn't actually create new records but instead updated existing ones. This change ensures better understanding and consistent use of the feature.
Original PR description
I have adding a docs for force_create that I have added in a previous task as it was not clear for some colleagues that it do not create but still updates the available records 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#241995
This update fixes a visual issue on the user profile page where course tags were being cut off at the bottom. The change adjusts the layout to ensure all tags are fully visible, maintaining a consistent and professional appearance. This improves the user experience by preventing truncated information.
Original PR description
In the website profile page, the course tags are slightly cut on the bottom. This commit adapts the block size to fit the entire tag. Note that the combo of fixed height / hidden overflow is actually intended to only show a single line of tags and not all of them, to avoid having a variable course card total height. Task-5457464 Forward-Port-Of: odoo/odoo#241897
This update fixes an issue where links to headings within locked articles didn't scroll to the correct location after loading. The fix ensures consistent navigation behavior for all articles, regardless of whether they're locked, improving the user experience for accessing content within the Knowledge base.
Original PR description
Problem: When navigating to a link that points to a heading in a locked article, the page does not scroll to the target heading after load. Cause: When an article is locked, `HtmlViewer` is used instead of the editor. In this mode, `HeadingLinkPlugin` is not loaded, even though it is the component responsible for scrolling to elements with `data-heading-link-id`. Solution: Add the same heading link scrolling logic to `HtmlViewer` so that links to headings work consistently, even when the article is locked. Steps to reproduce: - Go to Knowledge. - Copy a heading link. - Lock the article. - Paste the URL in the browser. - When the page loads, it does not scroll to the heading. opw-5418474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where links to headings within locked Knowledge articles didn't scroll to the correct section after loading. By adding scrolling logic to the `HtmlViewer` component, the system now consistently supports heading link navigation, regardless of article locking status. This improves the user experience for accessing information within Knowledge articles.
Original PR description
Problem: When navigating to a link that points to a heading in a locked article, the page does not scroll to the target heading after load. Cause: When an article is locked, `HtmlViewer` is used instead of the editor. In this mode, `HeadingLinkPlugin` is not loaded, even though it is the component responsible for scrolling to elements with `data-heading-link-id`. Solution: Add the same heading link scrolling logic to `HtmlViewer` so that links to headings work consistently, even when the article is locked. Steps to reproduce: - Go to Knowledge. - Copy a heading link. - Lock the article. - Paste the URL in the browser. - When the page loads, it does not scroll to the heading. opw-5418474
This update resolves an issue where tax grouping keys in the account_edi_ubl module could sometimes be unexpectedly empty. This fix ensures accurate tax reporting when generating invoices and other financial documents, particularly when using customizations. It also includes a minor correction related to excise taxes.
Original PR description
Some overrides assign a value to the tax's grouping_key after the super call. However, the returned value could be None. Also fix a little mistake regarding excise taxes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239954
This update fixes a reporting error in the French P&L statements. The 'owner remuneration' account (644) was incorrectly categorized as 'tax and duties'. It has now been moved to the correct 'wages and salaries' category, ensuring accurate financial reporting for French businesses.
Original PR description
Account '644 owner remuneration' was in the 'tax and duties' category in the french P&L but it belongs to the 'wages and salaries' category task-5446018 Forward-Port-Of: odoo/enterprise#103214 Forward-Port-Of: odoo/enterprise#103061
This update resolves an issue where color fields within editable list views weren't consistently saving changes when using the 'bottom' editing mode. Previously, users would need to refresh the page to see updates. This fix ensures color field edits are reliably saved, improving the user experience and data accuracy within Odoo's list views.
Original PR description
This commit fixes the issue where editing a field with widget="color" does not save it when the list is in editable="bottom" mode. project.task~5262582 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#238644
This update clarifies delivery slip reports by explicitly labeling the delivery address as 'Delivery Address' and simplifying customer information labels. These changes reduce potential errors and improve operational efficiency when processing deliveries.
Original PR description
To resolve ambiguities and improve operational efficiency: 1. The delivery address is explicitly labeled 'Delivery Address'. Ensuring no doubt about the final destination. 2. The label for the customer's primary information has been updated from 'Customer Address' to simply Customer, which prevents operators from mistaking it for the delivery point. Backport of https://github.com/odoo/odoo/pull/220019 Task: 3379926 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#241988
This update fixes a technical issue where Odoo incorrectly processed partner names with only one word. Previously, a single-word name would result in an empty first name field. Now, single-word names are correctly assigned to the first name, ensuring accurate data entry and reporting.
Original PR description
Description of the issue/feature this PR addresses: The name splitting logic fails when the partner name contains only one word, resulting in an empty first name. Current behavior before PR: Splitting a single-word name returns an empty first name and assigns the word to the last name. Desired behavior after PR is merged: A single-word name is correctly assigned to the first name field, leaving the last name empty. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241926
This update fixes an issue where delivery slips were printed with move lines in the wrong order. The fix ensures that move lines are printed in the correct sequence based on their original move IDs, resulting in accurate delivery slip generation. This improves the reliability of the delivery slip printing process.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213400
This update resolves a bug that prevented users from exporting data from the MRP MPS view. The issue stemmed from a recent change that incorrectly pulled fields from a related model. Now, the export function correctly displays the expected fields from the 'mrp.product.forecast' model, ensuring data can be exported without errors.
Original PR description
Steps to reproduce: - Go to MPS - Select one or more records - Click on Action > Export - Search and expand "Forecasted quantity at date" - Select "Forecasted quantity at date/Minimum to Replenish" - Export Before: A traceback is raised with the following error: "ValueError: Invalid field 'min_to_replenish_qty' on 'mrp.product.forecast'" This is caused by the model being overwritten by "mrp.production.schedule". The regression was introduced by commit ac52882, which added a default model "mrp.production.schedule". After: The export works correctly with sub fields. https://github.com/odoo/enterprise/commit/ac52882891a9ede6a5b008ac39fc62b82b7bf813 opw-5406704 Forward-Port-Of: odoo/enterprise#103097
This update fixes an issue with how Odoo identifies the latest HR employee version, ensuring accurate versioning across the system. The change simplifies the version lookup process and provides a reliable fallback mechanism if a specific version isn't available, enhancing stability and data consistency.
Original PR description
- Replaced search() with filtered_domain() to simplify version lookup. - Added self.ensure_one() to ensure single record context. - Used max() to get the latest version based on date_version. - Falls back to the first version in version_ids if no valid version is found. task-5215836
This update addresses a critical issue by implementing a standard neutralization process for the l10n_gt_edi module. This ensures that support teams can safely investigate database duplicates without risking unintended impacts on the live production system or customer data. It's a preventative measure to maintain system stability and data integrity.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gt_edi module The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. Forward-Port-Of: odoo/enterprise#102695
This update adds a crucial neutralization step for the l10n_tw_edi_ecpay module, allowing our support team to safely examine database copies without impacting the live production system. This process prevents unintended interactions and ensures data integrity during support investigations, improving overall stability.
Original PR description
This commit adds the missing neutralization necessary for the l10n_tw_edi_ecpay module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/223132 Forward-Port-Of: odoo/odoo#240975
This update fixes an issue where large .docx files weren't being correctly identified with their proper file type (like 'application/zip') when the `python-magic` library was installed. Previously, the system was defaulting to the wrong type. This ensures accurate file handling for all document uploads, especially large ones.
Original PR description
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open…
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed. If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly. But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files. The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment. I've tested it with double the amount of bytes and it seems to work correctly. Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details. ### Current behavior before PR: <img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" /> ### Desired behavior after PR is merged: The uploaded file's mimetype is correctly identified for big (>40mb) open office files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241565 Forward-Port-Of: odoo/odoo#233266
This update fixes an issue where job offer emails didn't include the employee's name in the subject line. Now, the email subject will automatically include the employee's name, improving clarity and personalization for candidates. This ensures a more professional and informative communication.
Original PR description
**Steps to reproduce:** - Go to Employees app and select any employee - Press "Offers" smart button - Create a new job offer and send it by email **Issue:** The employee name is not populated in the email subject. Task: 5407028
A technical issue causing a traceback when using the AI button in the applicant refusal process has been resolved. The fix involved modifying the application's code to correctly handle required fields, preventing errors and ensuring the AI functionality works reliably. This improves the applicant experience and reduces potential disruptions.
Original PR description
Step to reproduce: - Install hr_recruitment. - Open any applicant in any job position. - Click the Refuse button to open the refusal wizard. - Enable the send email toggle key. - Click on AI button Issue: traceback occurs Reason: - required field for using this widget is not defined. - so it tries to slice the res_ids field which is still not defined Solution: - In stable versions, we cannot add the missing required fields because this would cause upgrade issues. - Instead, we extend the widget and override its behavior to use active_model and active_id. task-5058510
This update fixes a minor issue where the appraisal plan start date wasn't being correctly set. A previous change removed some duplicate code, but this PR restores the necessary logic to ensure employees have the correct appraisal start date. This ensures accurate performance reviews and HR reporting.
Original PR description
**Issuee:** A recent change (https://github.com/odoo/enterprise/pull/100599/changes) was made to remove duplicate mehtod, but we need to maintain the main logic of setting the `appraisal_plan_start_date` field. This PR reintroduces this logic. Task:5408846
This update ensures that products designated for point-of-sale use (like those with discounts or tips) cannot be deleted or archived. This prevents potential errors and data inconsistencies within the point-of-sale system, ensuring accurate sales tracking.
Original PR description
Before this commit, it was possible to delete or archive some products even if they were special for the pos (discount, tips, settle, etc.). This commit adds a mechanism to prevent this and reduce the risk of errors linked to missing products in the pos. Enterprise PR: https://github.com/odoo/enterprise/pull/95789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229074
This update ensures that essential products like 'settle due' and 'deposit' are automatically configured for all Point of Sale (POS) settings when the pos_settle_due module is installed. Previously, these products were only available in POS sessions without open sessions, causing potential issues. This change guarantees consistent product availability across all POS configurations.
Original PR description
Before this commit, when the module pos_settle_due was installed, the special products (settle due, deposit, settle invoice) were only set on the POS configurations that did not have any open session. This could lead to issues when trying to use these products in a POS session of a configuration that did not have them set. Now, the special products are set on all POS configurations when installing the module. Community PR: https://github.com/odoo/odoo/pull/229074 Forward-Port-Of: odoo/enterprise#95789
This update resolves an issue where empty popups remained open and displayed incorrect options after content was removed. The fix ensures popups close correctly and prevents errors related to outdated options, improving the user experience. This change was made to enhance stability and usability.
Original PR description
**Descripion of the problems** When the content of a popup is deleted, two problems happen: 1. The popup stays open displaying an empty white rectangle. 2. Options relative to the last removed…
**Descripion of the problems** When the content of a popup is deleted, two problems happen: 1. The popup stays open displaying an empty white rectangle. 2. Options relative to the last removed element are still displayed and produce an error if the user interacts with them. **How to reproduce** Drop the snippet `s_popup`, and remove the "Block" element. Problems: 1. the popup is still open but empty, 2. the "Block" options are still displayed. **Origin of the problems** Problem 1 happens simply because nothing takes care of removing empty popups. Problem 2 happens because `RemovePlugin.removeCurrentTarget` set the `nextTargetEl` without first checking if the element is activable or not. Thus, when removing the last block in a popup, the next target is set to the `.o_we_no_overlay` close button, despite it being not activable. As a result, when `BuilderOptionsPlugin.updateContainers` is called, it does not update containers because the target is not activable. Thus, the "Block" options are still displayed despite the element being removed. **Fix** Both problems are fixed by changing `RemovePlugin.isEmptyAndRemovable` such that empty popups are marked as removable. task-5401692
This update adjusts the timing for maintaining video call connections, preventing disruptions when the Odoo server experiences temporary slowdowns. By extending the ping interval, the system can now handle brief connection hiccups without dropping calls, ensuring smoother video communication for users. This enhances the overall reliability of Odoo's video conferencing features.
Original PR description
Before this commit, the ping to keep rtc sessions alive was done every 30 seconds and had a 1 minute timeframe to successfully ping, which meant that missing a single ping would drop the rtc session. This commit increases the timeframe to 1 minutes and 15 seconds so that one ping can be missed. This can help preventing disconnections when the Odoo server is slow, as calls can work fine without a stable connection to the odoo server (since P2P and SFU connections are independent from Odoo once the connections are initialized). task-5177246 Forward-Port-Of: odoo/odoo#234553
This update fixes a visual inconsistency in the Point of Sale system. Previously, when searching for partners with wildcard characters, the system would show a 'found' count but not display the results in the partner list. This change ensures that the system accurately reflects the number of partners found during a search, resolving user confusion.
Original PR description
When the client typed `a%t%` into the search bar and pressed 'Enter', we load the partners from the backend using `getNewPartners` and showed a dialog "x partners found", however, we never show those results in the partner list since the search bar didn't support the wildcard ilike pattern. This commit adds support for searching wildcard patterns, to match the SQL behavior more or less. Clients now won't be confused by seeing "x partners loaded" and at the same time seeing an empty list. opw-5395340 Forward-Port-Of: odoo/odoo#242140 Forward-Port-Of: odoo/odoo#240541
Features or functions removed from Odoo
This update removes a duplicate function from the Point of Sale module. The `pushExternalOrderToBlackbox` function was essentially a copy of another existing function, streamlining the codebase and improving efficiency. This change ensures consistent functionality and reduces potential for errors.
Original PR description
Remove useless function `pushExternalOrderToBlackbox` that was doing the same as `pushOrderToBlackbox(order, true)`. This function was introduced in the following PR: https://github.com/odoo/enterprise/pull/102280 Forward-Port-Of: odoo/enterprise#102425