Tuesday, December 2, 2025
19 changes · saas-18.4
Enhancements to existing features
This update adds demo tax data and sample invoices to the Odoo Arabic localization (l10n_ar) module. This allows internal teams and reviewers to quickly test and verify that tax calculations and reporting are accurate, without needing to manually set up complex tax configurations. It streamlines the testing process for legal compliance requirements.
Original PR description
**Purpose of the PR** This PR introduces demo data to facilitate testing of the legal requirement implemented in v16 and forward-ported to all supported versions. **What it does** - Provides demo taxes (e.g., national, other categories). - Adds demo invoices combining different taxes. **Why** The demo data allows users and reviewers to quickly verify that the correct legal legend is displayed without having to manually configure taxes and create invoices. References: Adhoc task 53768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr CLA PR: https://github.com/odoo/odoo/pull/226715 Forward-Port-Of: odoo/odoo#237932 Forward-Port-Of: odoo/odoo#226938
Resolved issues and error corrections
This update corrects a previous issue where the system incorrectly set the preferred invoice sending method based on the first 'Send & Print' action for a partner. This prevented users from easily switching to new sending methods like 'PEPPOL' without being repeatedly prompted to use email. This change ensures users have control over their sending preferences.
Original PR description
Before this commit, we were setting the preferred invoice sending method on the Contact depending on what was in the first Send & Print to this specific partner. It's a bad idea because user don't know about this setting and when they want to switch the default method (example email -> peppol) the wizard will keep propose them to send it by email only and they don't know why since they never knowingly set it to "email". task-none (feedback from AVW) Forward-Port-Of: odoo/odoo#238029 Forward-Port-Of: odoo/odoo#237956
This update corrects a bug where administrators without HR permissions could trigger an error when attempting to create a new employee. The fix hides the 'Create Employee' button for users lacking the necessary HR rights, ensuring a smoother user experience and preventing unexpected errors.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** - Make sure Marc Demo is an Administrator but has no Employees (HR) access rights. - Log in as Marc Demo. - Go to Settings → Users → Create a new user. - Enter a name and email, then Save. - You’ll see the "Create Employee" button it appears even though the user has no HR rights. - Click it → an Access Error occurs. **Isuue:** - The "Create Employee" button is visible for users who don’t have HR permissions, causing an access error when clicked. **Solution:** - Hide the "Create Employee" button for users without HR access by adding the correct group restriction. task-5212464 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#235258
This update fixes an issue where styles (color, size) applied to text within a list weren't always correctly reflected on the list markers. Now, when text is converted to a list, all applied styles are consistently applied to the markers, improving the visual consistency of lists.
Original PR description
**Current behavior before PR:** - When applying a color or size style to the entire text and then converting it into a list, the style was reflected on the list marker. - However, if multiple styles (e.g., both color and size, or color and bold) were applied, only one style or sometimes none was reflected on the marker. **Desired behavior after PR is merged:** - When text with color, size, or both styles is converted into a list, The list markers now consistently reflect those styles. task-5097649 Forward-Port-Of: odoo/odoo#234296 Forward-Port-Of: odoo/odoo#227813
This update fixes an issue where payslips generated from payruns were named 'new payslip' instead of including the employee's name and pay period. The change ensures that PDF payslips now correctly display 'Salary Slip - [employee name] - [time period]', improving clarity and professionalism for users. This was a simple fix to a missing function call.
Original PR description
_ ## Short functional explanation of the error When generating a payslip from a payrun for an employee, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - [name of…
_ ## Short functional explanation of the error When generating a payslip from a payrun for an employee, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - [name of employee] - [time period of the slip]" ## Reproduction Steps 1. Go to Payroll and click on the Payslips tab > payslips. 2. Click on Pay Run. Select Regular Pay and click Continue. 3. Select an employee for which you'd like to generate the payslip. 4. Click on the employee row in the list view. 5. Click Compute sheet > Print. ## Expected behavior A PDF with name "Salary Slip - [employee name] - [time period]" is generated. ## Unexpected Behavior A PDF with name "new Payslip" is generated. ## Origin of the issue When printing the slip with this flow, we don't call the method ```_compute_name()``` used to compute the name of the current slip. Therefore, it stays at 'New Slip', which is the default name. Henceforth, we have to call this method manually when printing the slip. _ opw-5216796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a minor timing problem that was causing automated tests for our Point of Sale (POS) system to occasionally fail. The fix ensures that key order acceptance times are correctly recorded, improving the reliability of our testing process. This resolves a specific runbot error and contributes to overall system stability.
Original PR description
in this commit: - Fixed the `_acceptOrder, _dispatchOrder, _completeOrder` test, which could fail due to minor timing delays. - Updated the assertion to only verify that `orderAcceptTime` is not empty. runbot-error-234594 Forward-Port-Of: odoo/enterprise#100942
This update resolves an issue where changes to employee records didn't trigger related updates in the system. The fix ensures that when you modify employee details through the user interface, the correct dependent fields are updated as expected. This improves data consistency and accuracy.
Original PR description
purpose: when changing fields of employee in the UI, the `_onchange` of the fields doesn't trigger because it's defined on `hr.version` -added `test_related_fields_on_version_onchange` to check if `_onchange` methods are implemented on `hr.employee` to call the corresponding methods on `hr.version` task-id: 5173389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where changes to employee details (like insurance or company car) weren't consistently reflected in related fields. The update ensures that changes are correctly propagated across the system, preventing incorrect default values in the employee configuration. Additionally, a performance optimization was implemented to speed up a calculation related to mobility budgets.
Original PR description
'*' = be, ch purpose: currently when you change the values of fields like insurance or company car the onchange doesn't reflect on the subfields which is the case for cars, insurances, etc. this makes the fields have wrong default values in the configurator - added `_onchange` methods for related fields of `hr_version` in `hr_employee` to call the corresponding `_onchange` in `hr_version` - optimized the method `_compute_l10n_be_mobility_budget_amount` to use binary search instead of linear loop task-id: 5173389
This update corrects a bug that caused the Odoo Knowledge article editor to scroll back to the top after closing the `/article` command, particularly when editing long articles. The fix ensures the editor's focus is properly maintained, preventing this disruptive scroll jump and improving the user experience.
Original PR description
Problem: When editing a long Knowledge article and executing the `/article` command, closing the dialog automatically scrolls the page to the top. Cause: This happens because `useActiveElement` inside the `Dialog` component runs its cleanup function when the dialog unmounts. While unmounting, `document.activeElement` is `body`, so the cleanup tries to focus back the `oldActiveElement`, which is the `editable`, and this resets the selection and causes the scroll jump. Solution: Set the selection when closing the dialog, ensuring the `editable` remains the `document.activeElement` during cleanup, preventing the focus reset. Steps to reproduce: - Edit a long article further down the page. - Use the `/article` command. - Dismiss the dialog. → The page scrolls back to the top. opw-4797567 Forward-Port-Of: odoo/enterprise#100634
This update corrects a minor issue in the PEPPOL data neutralization script. Previously, the script wouldn't process data if a required key was missing. Now, the script automatically inserts the key, ensuring all PEPPOL transactions are properly neutralized and compliant. This improves data processing reliability.
Original PR description
There can be some siutations where you can not have the key account_peppol.edi.mode while having a connection. But the neutralize only updates and so, if the key is not present, it does nothing. So change it to insert the key if no present --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238184
This update resolves an issue where test emails using 'view_online' would fail if the associated mailing contact was deleted. The fix ensures the system retrieves the first available mailing contact ID, preventing the 'record not found' error. This improves the reliability of test email campaigns.
Original PR description
In the email marketing, when you add "view_online" and dynamic placeholder "object.name", and try doing a test email, it creates a url token for the "view online" with the res_id as the user's id which grabs the record from the mailing_contact with that res_id. So, in case the mailing_contact with the res_id is deleted, the "view_online" gives you error saying record with id "res_id" cannot be find. Our fix is to search the mailing_contact and grab the id of the first record. This fix updates the code from this commit: [8a9981e](https://github.com/odoo/odoo/commit/8a9981e78a438ceb53a4fdc0445ebed2170c6624) opw-5049654 Forward-Port-Of: odoo/odoo#232440
This update fixes a technical issue that caused a traceback when removing colors from a mega menu within the website editor. The fix ensures that color styles are correctly copied, preventing errors and improving the stability of the editor functionality. This resolves a minor disruption for users managing website content.
Original PR description
Problem: When removing a color from a block, a traceback occurs. Cause: After https://github.com/odoo/odoo/commit/bda6835293b2b222a003b9696fa052f31539a4ef we copy only style attributes to the `newFont` but the color can be applied through a class that applies text color so we should also copy classes that changes text color. Steps to reproduce: - Open Website. - Add a mega menu. - Open the editor. - On the mega menu, enable the “eCommerce Categories” option. - Edit one of the navigation headers’ labels and save. - Observe traceback. opw-5357516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug where website favicons weren't correctly displayed in browser tabs after changing website settings or switching between websites with different favicons. The issue stemmed from browser caching, which prevented the new favicon from being loaded. Now, the correct website favicon is consistently shown in browser tabs.
Original PR description
When editing a website favicon in settings or switching between websites with different favicons, the browser tab always displayed the default Odoo favicon instead of the specific website's favicon.…
When editing a website favicon in settings or switching between websites with different favicons, the browser tab always displayed the default Odoo favicon instead of the specific website's favicon. the favicon were not immediately reflected due to browser caching. The browser is responsible for caching the favicon. When you load a page, the browser sees `<link rel="shortcut icon" href="...">`. If it has already downloaded the image at that URL, it will use the stored (cached) copy instead of asking the server for it again. This improves performance. but also it's responsible for the bug. Steps to reproduce: =================== 1. Set a custom favicon for your website in Settings. 2. Open the Website app. 3. Observe that the browser tab shows the default Odoo favicon instead of the custom one. Solution: ========= Retrieve the favicon URL directly from the iframe's document content (link[rel~='icon']) and update the main window's favicon opw-5126299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a change in how Odoo handles HTML formatting in stock order notes. Previously, searching for notes would generate an infinite loop. This fix ensures that search results are accurate and prevents unnecessary activity. The update also improves performance by limiting search results.
Original PR description
From saas-18.2 and later, html fields has been changed the old behaviour.
Ex.
```python
model.create({'note': 'test'}) -> <p>test</p>
```
Old behaviour:
```python
model.search_count([('note', '=', 'test')]) -> 1
```
New behaviour:
```python
model.search_count([('note', '=', 'test')]) -> 0
```
To follow the new behaviour and not generate infinite activities, we need to add html elements to the error message.
Additional, we improved the performance (better to count and limit vs see all the whole table).
OPW-5266061
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#237977This update resolves an issue where duplicating an approver within an approval request caused a system error. The fix prevents the same user from being linked to multiple approvers, eliminating the traceback and ensuring the approval process functions correctly. This improves stability and prevents disruptions to user workflows.
Original PR description
When User duplicates the approver for any approval request and tries to open that approval request, A traceback will appear. Steps to reproduce the error: - Activate the developer mode - Go to Approvals > Create a new approval request > add any approver > Save - Click on the ``View`` button in the approver line - Now, In the Form view > Actions > Duplicate - Go back to that approval request through breadcrumbs Traceback: ``` ValueError: Expected singleton: approval.approver(1, 3) ``` https://github.com/odoo/enterprise/blob/83b6c0e1c052b08bd23c5e009773b5a3148ddeec/approvals/models/approval_request.py#L270 When the customer duplicates the approver, ``user_id`` will be also duplicated. So, Now Same User is linked with multiple approver. So, It will lead to the above traceback. sentry-6642840799 Forward-Port-Of: odoo/enterprise#100979 Forward-Port-Of: odoo/enterprise#87164
This update fixes a bug that prevented the correct date of a new product template from being set. Previously, the system would fail if a product was created without first using an existing template, leading to inaccurate date information. This ensures all product templates are properly initialized with their launch date.
Original PR description
If _compute_write_date is launched when creating a product.product without starting from an existing product.template, the compute may be launched before the product.template is created, hence record.product_tmpl_id.write_date is False, and comparing datetime and bool leads to an error. This completes the fix proposed https://github.com/odoo/odoo/pull/138177 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237756 Forward-Port-Of: odoo/odoo#237523
This update fixes a rare issue where a test process could fail due to timing problems with locking resources. The fix ensures the test environment remains stable by maintaining a reference to the lock, preventing errors when the test thread finishes early. This improves the reliability of our automated testing.
Original PR description
In some rare cases the late_request_thread could execute so fast without releasing the GIL that assertCanOpenTestCursor was executed before the main_lock.acquire(), causing the lock to be None. In…
In some rare cases the late_request_thread could execute so fast without releasing the GIL that assertCanOpenTestCursor was executed before the main_lock.acquire(), causing the lock to be None. In this case, acquiring the lock is pointless since the late_request_thread has already finished, defeating the purpose of this quire, but we can workaround this keeping a reference to the main_lock before starting the thread. This way, even if the late_request_thread is already finished, we can still acquire the lock even if it is already released. Normal flow: - main_thread acquires main_lock - main_thread span request_thread - main_thread tries to acquire main_lock and again and blocks - request_thread runs and releases main_lock - main_thread acquires main_lock and continues When it fails - main_thread acquires main_lock - main_thread span request_thread - request_thread runs and releases main_lock - main_thread tries to acquire main_lock witch is None and fails Fixed - main_thread acquires main_lock - main_thread span request_thread - request_thread runs and releases main_lock - main_thread tries to acquire main_lock but it is already released - main_thread acquires main_lock and continues Runbot error [229827](https://runbot.odoo.com/odoo/runbot.build.error/229827) Forward-Port-Of: odoo/odoo#237886
This update fixes an issue where the ‘Late Activities’ and ‘Today’s Activities’ counters on the Recruitment dashboard didn't correctly reflect completed activities. The fix ensures that inactive activities are no longer counted, preventing inaccurate activity counts after an activity is marked as done. This improves the accuracy of the Jobs kanban view.
Original PR description
On the Recruitment dashboard (Jobs kanban), the counters for “Late Activities” and “Today’s Activities” may not decrease after an activity is marked as done, even though completed activities no longer appear in the applicant list. Root cause: `_compute_activities` aggregates counts from `mail_activity` using the deadline and job filters but does not exclude non-running (inactive/archived) activities. If an activity is not unlinked and becomes inactive (`active = FALSE`), it still matches `date_deadline <= today` and is counted. Steps to reproduce: 1. Open Recruitment 2. Pick any job and schedule an activity with Due date is Today (also try Yesterday for “Late”). 3. Mark the activity as Done. the number of activities today or late will not decrease opw-5123947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232722
This update resolves an issue where newly created documents in the l10n_uy_edi module didn't correctly populate certain computed fields. The fix adds a fallback mechanism to ensure these fields are assigned upon record creation, preventing data inconsistencies. This ensures accurate reporting and processing of EDI documents.
Original PR description
The PR https://github.com/odoo/odoo/pull/209587 adds a check for onchange calls on a newly created record. Since in that case `move_id` is not set on `l10n_uy.document`, the compute method fails to assign values. This commit adds a pre-assigned fallback for this specific case. Runbot error: https://runbot.odoo.com/odoo/error/234425