Wednesday, December 10, 2025
28 changes · saas-18.3
Resolved issues and error corrections
This update corrects an issue where the payment term line name wasn't updated when changing the 'Customer Reference' on an invoice. The fix addresses a technical detail within the invoicing system, ensuring consistent and accurate naming of payment terms across invoices. This improves data clarity and reduces potential errors.
Original PR description
### Issue: When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated. ### Steps to reproduce: - Create an invoice with payment terms, confirm it - Modify…
### Issue:
When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated.
### Steps to reproduce:
- Create an invoice with payment terms, confirm it
- Modify its "Customer Reference" to 'test' for example
- In the page "Journal Items" the name of the terms line has been recomputed to "test - INV/2025/XXXXX"
- Modify again its "Customer Reference" to 'abcdef' for example
- In the page "Journal Items" the name of the terms line was not recomputed
### Cause:
In `_compute_name()` we only write the name if this condition is `True`:
```py
if n_terms > 1 or not line.name or line._origin.name == line._origin.move_id.payment_reference or (
line._origin.move_id.payment_reference and line._origin.move_id.ref
and line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'
):
line.name = name
```
The purpose of this line is to keep the name of the line if it was manually inputted. So the logic is: we only write the computed name if the previous name was computed. To check this, we check if `line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'`.
The issue comes from the use of `_origin` in a compute. `_origin` refers to the record before we make any change. But it is meant to be used for `onchange` methods, in these the values are not yet written so `_origin` refers to the record before saving.
Here, when saving, `line._origin` is the same as `line`, so
- `line._origin.move_id.ref` is the new ref.
- `line._origin.name` uses the old ref (it's currently being recomputed).
### Solution:
Unfortunately, in the compute, there are no trace left of what were the previous values as the write already occurred.
The initial complaint justifying to keep custom line names was that on bills, the line name is empty. So when inputting a custom line name, it was removed by the compute method. The previous fix wanted to be more general by always keeping custom line names.
Considering this, this commit removes part of the previous fix: Now we only keep the custom line name when the compute method wants to remove it. So we keep the previous fix for bills.
### Note
There was a test verifying exactly that when manually deleting the line name, in the end
the line does not have a name. This will no longer be the case but a decision must be made between:
1. updating the line name when changing the ref
2. not recomputing line name when it has been changed manually
3. removing the line name when it's manually deleted
We can have 2 and 3 but not with 1 afaik.
opw-5246917
Forward-Port-Of: odoo/odoo#237710This update addresses a requirement for Swiss payroll reporting (ELM transmission) by adding a specific group to the teleworking field in the HR contract and employee modules. This ensures accurate data is sent to the tax authorities, complying with Swiss regulations and avoiding potential reporting errors. The change was implemented as a fix to a previously identified issue.
Original PR description
Forward-Port-Of: odoo/enterprise#101691
This update resolves an issue where the system incorrectly processed invoice sequences without spaces, leading to errors. The change utilizes a regular expression to reliably extract the folio number regardless of the sequence format (space, slash, or hyphen), ensuring accurate invoice processing. This improves data integrity and prevents potential errors related to invoice generation.
Original PR description
Before this commit, the method `_get_last_sequence` assumed that the document sequence always contained a space separator (e.g., "INV 12345") It attempted to extract the folio number using `res.split(" ")[-1]`.
If the sequence format did not contain a space, such as the standard Odoo format `INV/2025/01234`, the split would return the entire string. This caused a `ValueError` when trying to cast the non-numeric string to an integer:
ValueError: invalid literal for int() with base 10: 'INV/2025/01234'
This commit fixes the issue by using a regular expression to extract the last group of digits from the sequence string. This ensures the folio number is correctly retrieved regardless of the separator used (slash, space, or hyphen).
opw-5401509
Forward-Port-Of: odoo/enterprise#101665This update corrects a technical issue that was preventing the generation of WPS payroll reports. The fix resolves traceback errors caused by an incorrect function usage, ensuring accurate report creation for Saudi Arabia. This improves the reliability of payroll reporting.
Original PR description
this commit addresses traceback errors occured due to incorrect usage of `_` function. task-5310946 Forward-Port-Of: odoo/enterprise#99789
This update corrects a display issue on the Odoo portal where users were seeing outdated document counts. Now, the portal only shows documents that are currently in the user's signing sequence, ensuring a more accurate and user-friendly experience. This improves clarity and prevents confusion for users managing sequential signatures.
Original PR description
Version: - 18.0 Steps to reproduce: - Install sign - Upload document. - Add multiple signers - Set a sequential signing order Issue: - When documents require sequential signing, portal users see a banner saying there’s a new document to sign, even if it’s not yet their turn. Solution: - Update the counter to show only the documents that the user can currently sign. Impact: - Portal users now only see documents when it’s their turn to sign. Task-5226240 Forward-Port-Of: odoo/enterprise#98671
A technical issue in the Accounting module prevented users from opening a Studio-created menu item linked to the account.code.mapping model, resulting in a confusing traceback. This fix replaces the error with a clear message, improving the user experience and preventing technical issues when accessing this feature.
Original PR description
**Steps to reproduce:** * Install **Accounting** and ensure Studio is available. * Using **Studio**, create a new menu item pointing to the model *account.code.mapping*. * Save the menu and click it to open the corresponding view. **Observed behavior:** * Opening the Studio-created menu triggers a full traceback. **Cause:** * The model *account.code.mapping* overrides `_search()` and raises `NotImplementedError` when no `account_ids` can be extracted from the domain, which is the case when opening the view without filters. * The missing `_search` logic for empty domains was never implemented, and the resulting exception propagates to the UI as a traceback. **Fix:** * Replace the `NotImplementedError` with a user-friendly `UserError` explaining that the view cannot be opened without specifying relevant filters, preventing the traceback and improving clarity. opw-5183909 Forward-Port-Of: odoo/odoo#239076 Forward-Port-Of: odoo/odoo#236665
This update clarifies the documentation for the HTML Editor's position plugin, ensuring developers understand how to use and configure it correctly. The change improves clarity and reduces potential confusion, leading to smoother development and integration of the HTML Editor feature. This is a minor documentation update.
Original PR description
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#239168
This update adds a new account for 'Salaries & Wages Payable' within the Odoo accounting system for Hong Kong (l10n_hk). This resolves a previous misconfiguration and ensures accurate tracking of payroll liabilities under Hong Kong's NET tax rules. It improves the reliability of payroll reporting and compliance.
Original PR description
Adds a new Salaries & Wages Payable account of type current liabilities in order to use it in payroll for the NET rules and solve a misconfiguration in the default data. task-5042786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237884
This update resolves a technical issue that caused a traceback when reloading the WorkEntries page in Studio. The fix ensures Studio correctly loads the page action, preventing errors and improving stability for users. This change enhances the overall Studio experience.
Original PR description
**Verison:** - saas-18.2 **Steps to reproduce:** - Go to an employee form view. - Click on the WorkEntries smart button. - Open Studio. - Reload page. **Issue:** - A traceback appears after reloading the page in Studio. **Cause:** - The smart button URL uses the model name hr.work.entry, but Studio’s service_action expects a path without dots. Because the action cannot be loaded correctly, the view breaks and triggers the traceback. **Solution:** - Return the proper path instead of the model name so that the action loads correctly. This prevents the error when reloading the page. task-5236317 Forward-Port-Of: odoo/odoo#235662
This update addresses a requirement from the Belgian Peppol Authority. Users can still register with 9925, but a warning has been added to guide them towards the preferred 0208 (BCE/KBO) registration method. This ensures compliance and provides clearer guidance for our Belgian users.
Original PR description
The Belgian Peppol Authority wants us to register belgian users with 0208 (BCE/KBO) and not 9925 (BE VAT). It should still be possible to register with 9925 for some edge case, but let's make it clear to our users that this is not the regular path. task-none (feedback from support + TSB) Forward-Port-Of: odoo/odoo#239208 Forward-Port-Of: odoo/odoo#238737
This update resolves an issue where internal URLs (like 'blob:') in tests previously required a mock 'fetch' to function correctly. This change ensures internal URLs work seamlessly without the need for mocking, improving the reliability and consistency of our test environment. It also addresses a previous issue where test mocks were being used outside of tests, now with stricter enforcement.
Original PR description
Before this commit, internal URLs (i.e. "blob:" and "data:") required 'fetch' to be mocked to work. This is wierd because these requests are handled directly by the browser and shouldn't require any…
Before this commit, internal URLs (i.e. "blob:" and "data:") required
'fetch' to be mocked to work. This is wierd because these requests are
handled directly by the browser and shouldn't require any particular
manipulation from the (mocked) server.
This commit ensures that internal URLs still work without fetch being
mocked.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
- Enterprise: https://github.com/odoo/enterprise/pull/101780
Forward-Port-Of: odoo/odoo#239011This update resolves a technical issue that was causing test failures. The change prevents the use of internal testing tools outside of the testing environment, ensuring the stability and reliability of our tests. This improves the overall quality and consistency of the Odoo Enterprise software.
Original PR description
This commit adapts tests failing due to a recent fix preventing the use of 'mock...' helpers outside of tests. - Community: https://github.com/odoo/odoo/pull/239237
This update fixes a problem where blog post publication times were inconsistent during performance tests. The change ensures that test results are always reliable by freezing time during key operations, preventing variations in how blog posts are processed. This improves the accuracy of our performance metrics.
Original PR description
Some blog post are published with a post_date matching the time the test is run meaning that they are not considered published. We have multiple possibilities when _get_url_hot_query is called: - all call to /blog are executed before the publication date: 9 - some call to /blog are executed after the publication date: 11 - only the last call is executed after the publication date: ~40-50 Using freezetime after the publication date ensures a consistent result This can be easily reproduced by freezing the time on the first calls in _get_url_hot_query and not on the last one. Runbot error [55754](https://runbot.odoo.com/odoo/error/55754) Forward-Port-Of: odoo/odoo#239236
This update fixes a potential issue where the system was incorrectly removing outdated sub-channels. The change adds a crucial check to ensure the cleanup process only affects actual sub-channels, preventing unnecessary actions and maintaining data integrity. This ensures a smoother and more reliable experience for users managing their channels.
Original PR description
In [1], the `_gc_unpin_outdated_sub_channels` method was updated to avoid unpinning sub-channels multiple times. However, a condition is missing on `parent_channel_id` to restrict this gc to actual sub- channels. [1]: https://github.com/odoo/odoo/pull/238493 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#239248
This update fixes a flaw in a stock test that could lead to inaccurate results. The test was failing due to slight timing differences in how moves were created, causing assertions to be incorrect. To ensure consistent and reliable test outcomes, the test now freezes time, guaranteeing the test always behaves as intended.
Original PR description
In a previous fix in #174442, we ensured that the order of moves when freeing reservation would remain deterministic, even if move dates were the same. In the test however, we didn't make sure that both moves were created at the exact same time, meaning that in some case, a millisecond could pass between the two moves creation, making the later assert checking if both dates are the same wrong, and making the test irrelevant. Now freeze the time at an irrelevant date just to make sure the test always does what it was intended to do. runbot-233470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239229
This update resolves an issue where users with access to multiple companies but only one employee were unable to schedule planning slots for those companies. The fix restores the previous behavior, allowing users to assign themselves to planning slots across all companies they have access to, regardless of the number of employees they have within those companies. This ensures consistent planning functionality.
Original PR description
Since #91616, if a user has access to multiple companies but only has an employee in one, they are unable to assign themselves to a planning slot from a company other than that of their employee. This was not the case in previous versions and is causing issues in our internal db. To restore the previous behavior, any user with access to a company but only 1 employee will be able to assign themselves to slots of said company. opw-5163200
This update fixes an issue where subscription details weren't being displayed correctly within the dashboard. Specifically, it addressed a problem with how subscription data was filtered and presented, ensuring subscription titles are now shown accurately and preventing related sale order items from appearing in the wrong section. This improves the user experience for managing subscriptions.
Original PR description
Before this commit, when subscriptions were linked to the analytic account of a project, the sale order items appears in an unwanted section when the section is unfolded. Meanwhile, when the subscription section is unfolded the title of the subscriptions items are not correctly displayed. The first issue is due to the fact that we did not correctly exclude the subscriptions items from the domain. The second issue is due to the fact that we fetch the field 'name' from the subscription search instead of the field 'display_name' task-5159781 Forward-Port-Of: odoo/enterprise#97238
This update fixes an issue where multiple quality checks were being created for the same picking when adding additional products. The change ensures that only one quality check is generated per operation, streamlining the picking process and preventing unnecessary quality control tasks. This improves efficiency and reduces potential errors.
Original PR description
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations…
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations field). 3. Create a Receipt containing one product. 4. Click the Mark as To Do button. 5. Add another product to the same Receipt and save it. Observation: -------------------------- Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation. Issue: -------------------------- No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation. Solution: -------------------------- Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created. opw-5249233 Forward-Port-Of: odoo/enterprise#100118
This update ensures that newly imported customer and supplier records are automatically recognized as ‘companies’ within Odoo. This improves data accuracy and streamlines processes related to invoicing and reporting. It addresses a previous issue where imported partners weren't correctly categorized.
Original PR description
Ensure imported partner records are marked as companies when creating new partners. Task-5353923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239116 Forward-Port-Of: odoo/odoo#238793
This update fixes an issue where the LWF report incorrectly included data from previous runs when a department was selected. The fix clears existing report data before generating a new report, ensuring accurate reporting with department selection. This improves the reliability of the LWF report for payroll calculations.
Original PR description
Step to reproduce: - Install l10n_in_hr_payroll. - Create 3-4 employee with labour welfare fund, all in different departments. - Open the LWF report wizard and do not select any department. -…
Step to reproduce: - Install l10n_in_hr_payroll. - Create 3-4 employee with labour welfare fund, all in different departments. - Open the LWF report wizard and do not select any department. - Download report , all employee will come in report. - Now select any department and download report again. - All employee(It is fetching previous data) + employee from selected department will come in report. Cause: - In '_compute_line_ids()' wizard computed field 'line_ids' doesn't properly reset previous lines as a result previous data remains in lines. - When the department is changed, the wizard id remain same, so previously lines added to wizard are coming with new lines. - Using `Command.link()` for new lines is invalid because it requires an existing database record ID, but wizard lines are creating inside a compute method so their IDs are only saved after the flush. Fix: - Since this is a stable version, clear the previously existing lines using 'Command.clear()' before creating new ones. Task - 5366498 Forward-Port-Of: odoo/enterprise#101190
This update resolves an issue where outdated records in the system's data management (ir.model.data) persisted after a model was removed. These lingering records could cause unexpected errors and performance problems. This fix ensures data is cleaned up properly, improving system stability and reliability.
Original PR description
When a model is unlinked, the `ir.model.data` related to that model wasn't cleaned up. This leaves dangling records that can generate issues. sentry-6938852090 Forward-Port-Of: odoo/odoo#236615
This update resolves an issue where the demo stock data installation incorrectly used US currency, causing problems when users have databases with different currencies (like EUR). The fix ensures the demo data installation works correctly regardless of the company's currency setting, improving data consistency.
Original PR description
Currently in the `_merge_move_itemgetter` the system call `self.company_id.currency_id.decimal_places`. However the demo data of stock create a database with US currency and some `stock.move` in it. If we have an existing database with EUR for example. The upper call will return a `currency_id.decimal_places` since we have multiple currency. The best solution, would be to split `_action_confirm` to do a loop by company. But it would need a small refactoring and we will do a minimal diff to fix this issue. Using the smallest currency among all the company is not always correct but it's a super edge case and we should probably remove this code since it went to far. Close #230965, #234078 Forward-Port-Of: odoo/odoo#239273
This update fixes an issue where job activity counts on the dashboard were not updating correctly after activities were marked as completed. The change ensures that only active activities are considered in the dashboard reporting, preventing inaccurate counts and improving the reliability of recruitment data. This resolves a previous bug related to activity persistence and archiving.
Original PR description
**Steps to reproduce:** - Create an activity type with `keep_done` enabled - Go to Recruitment - Open a job position - Select an application - Create an activity with the new activity type - Ensure its date is in the past - Go to the dashboard, you will see the overdue activity - Go to the record and mark the activity as done - Go back to the dashboard, the activity count is not updated **Issue:** Before https://github.com/odoo/odoo/commit/d290f3f3f23e activities were not kept by default in the database when marked as done. But it was still possible to enable this in the activity type using `keep_done`. The current behavior is to always keep the activity and archive it on done. In both cases the `_compute_activities` raw query should not take archived activities into account. **Fix:** Added the activity active check to the raw query. opw-5108204 Forward-Port-Of: odoo/odoo#238856 Forward-Port-Of: odoo/odoo#236591
This update fixes an issue where pressing Enter multiple times before a star rating created duplicate elements. It also resolves a problem with line breaks next to non-editable elements, ensuring line breaks now function correctly. This improves the user experience and stability of the HTML editor.
Original PR description
**Current behavior before PR:** - When pressing Enter twice before a star rating (3-star or 5-star), the previous paragraph incorrectly ended up containing a single star. - When performing a line break next to a contenteditable false element, `deepEditableSelection` returned a selection whose anchor was inside that non-editable element. Since the selection was inside a contenteditable false element, the `insertLineBreakElement` method returned early without doing anything. **Desired behavior after PR is merged:** - Pressing Enter before the star rating no longer duplicates a star in the previous paragraph. - When `deepEditableSelection` returns a selection whose anchor lies inside a contenteditable false element, we now use an editable selection instead. This prevents the anchor from ending up inside a non-editable element and allows the line break to work correctly. task-5079270 Forward-Port-Of: odoo/odoo#226433
This update resolves an issue where adding a second tax to a bank rec line would delete the first. It now correctly allows multiple taxes to be applied, addressing inconsistencies in how tax calculations were handled, particularly when dealing with refunds.
Original PR description
This commit will allow to add multiple taxes on a move line in the bank rec widget. For the moment, when having a line with a tax, and then add one more. The previous tax get deleted. task-5081786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where changes to parser rules couldn't be saved after the parser was initially set up. This change ensures that parser rules are consistently applied, improving data accuracy and stability. It's a routine maintenance update.
Original PR description
The parser rules cannot be modified once the parser has been instantiated. task-5091744 Forward-Port-Of: odoo/odoo#239046
This update fixes a technical issue that could display error messages to users during event ticket payments. The problem arose from unusual configurations with rentable tickets, leading to errors. The fix silently handles these situations to ensure a smoother payment experience for customers.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `website_event_sale` but not `stock` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- Having odd configurations like rentable tickets creates rental orders without rental dates, leading to unhandled errors. Solution -------- While rentable event tickets doesn't make enough sense to make it work, we can still improve the error handling to prevent showing tracebacks to the client. opw-5207045 Forward-Port-Of: odoo/enterprise#99703 Forward-Port-Of: odoo/enterprise#99000
This update resolves a problem where invoice PDFs generated for Arabic-speaking customers sometimes had incorrect formatting, like missing logos or repeated headers. The fix reduces the number of invoices processed at once, allowing the printing software to render them properly. This ensures all invoices are generated with accurate and professional formatting.
Original PR description
Repro steps: 1. Create a customer whose language is Arabic 2. Create 16 or more invoices for that customer 3. Send these invoices together all at once Issue: PDFs generated for the invoices are strange, some have missing logo in the header, while others have the header repeated multiple times on the page. Root cause: wkhtmltopdf does not have enough time to render all these PDFs at once, so it fails to render them properly leading to these half-rendered PDFs. Solution: This commit solves this issue by reducing the number of invoices that the cron processes at once from 20 to only 10 (the default of the function _cron_account_move_send). This would ensure that wkhtmltopdf has enough time to process and render a batch of invoices at once. opw-4997495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236810