Tuesday, December 2, 2025
31 changes · saas-18.4
Enhancements to existing features
This update ensures Odoo correctly handles German B2G invoices in the XRechnung format. A mandatory ‘Leitweg-ID’ routing identifier has been added to the invoice XML, directing invoices to the appropriate government entity. This ensures compliance with German regulations and accurate invoice processing.
Original PR description
*= l10n_account_edi_ubl_cii_tests For B2G transactions in Germany, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. Adding this Leitweg-ID for the UBL syntax. task-5194484 Description of the issue/feature this PR addresses: For electronic invoicing in Germany, for B2G transactions, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. We want to add this identifier for the XRechnung format. Current behavior before PR: The Leitweg-ID is not present in the UBL xml format. Desired behavior after PR is merged: The Leitweg-ID is added in the header of the invoice in the cbc:BuyerReference tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236333
This update enhances Odoo's tax calculations to accurately handle taxes based on volume, such as VAT on product quantities. This change was requested during Odoo Exp 2025 to ensure more precise tax calculations for businesses dealing with volume-based pricing. It impacts the account tax python module.
Original PR description
The use case to cover is when you have a volume based tax. Requested during Odoo Exp 2025. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237852 Forward-Port-Of: odoo/odoo#232146
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 pull request updates the core spreadsheet component within Odoo. It addresses several bug fixes and improvements related to chart rendering, cell interactions, and overall stability, ensuring a smoother user experience when working with spreadsheets. These changes enhance the functionality and reliability of the spreadsheet feature.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/95b1252fa [REL] 18.4.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/95b1252fa [REL] 18.4.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ecb26f8df [FIX] chart: don't crash treemap without visible data [Task: 5365419](https://www.odoo.com/odoo/2328/tasks/5365419) https://github.com/odoo/o-spreadsheet/commit/645e850b7 [FIX] clickable cells: prevent overlap with grid icons [Task: 4930803](https://www.odoo.com/odoo/2328/tasks/4930803) https://github.com/odoo/o-spreadsheet/commit/b5734b6b7 [FIX] pivot: Ensure computed measure range adaptation [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/627510033 [FIX] commands: remove duplicate in invalidateEvaluationCommands [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/15b6c6bf8 [FIX] Charts: Ensure Chart js extension are loaded on chart creation [Task: 5214007](https://www.odoo.com/odoo/2328/tasks/5214007) https://github.com/odoo/o-spreadsheet/commit/f814b303a [FIX] Demo: Fix wrapper style [Task: 5212448](https://www.odoo.com/odoo/2328/tasks/5212448) https://github.com/odoo/o-spreadsheet/commit/411165cea [FIX] composer: keep edition mode inactive on cursor selection change [Task: 5354541](https://www.odoo.com/odoo/2328/tasks/5354541) https://github.com/odoo/o-spreadsheet/commit/e81dd1632 [FIX] BottomBarSheet: sheet name should update on foreign changes [Task: 5016252](https://www.odoo.com/odoo/2328/tasks/5016252) https://github.com/odoo/o-spreadsheet/commit/de2393215 [FIX] Composer: Fix assistant position [Task: 5155838](https://www.odoo.com/odoo/2328/tasks/5155838) 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 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 enhances the reliability of payment processing for German POS systems by automatically retrying failed transactions (5xx errors) and notifying users if the payment system is unavailable. This prevents payment processing interruptions and ensures tills remain operational, improving the overall user experience. The changes simplify the underlying code for better maintainability.
Original PR description
In this task: --------------- - Moved the status code handling logic at proper place for all transactions API responses. - Removed the mixed usage of async/await and .then() by async/await totally in all transaction calls to simplify flow and improve readability. - For 5xx errors (e.g., 503), retry once as they occur when the server is unreachable. Print "TSS not reachable" if even after retries followed by exponential backoff logic. - Guarantee tills remain operational and not blocked even if the TSS is unreachable. task:5051693 Forward-Port-Of: odoo/enterprise#100911 Forward-Port-Of: odoo/enterprise#93694
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 an issue where error messages weren't being properly handled in the auto-retry system, leading to build failures. The change ensures that traceback errors are also caught and addressed, along with a related OSError issue during websocket handling, improving overall system stability.
Original PR description
The auto-retry is supposed to catch error logs as well as tracebacks. In some cases a traceback is logged as a message, and not as a logger arg, bypassing the replace already in place. This pr simply replaces the traceback string in the message as well. Build error [234619](https://runbot.odoo.com/odoo/runbot.build.error/234619) Also fixes OSError while handling request paused Build error [229906](https://runbot.odoo.com/odoo/runbot.build.error/229906) Forward-Port-Of: odoo/odoo#238133
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 fixes a visual quality issue in the product image thumbnails generated within the website editor. Previously, using WebP format directly in the browser resulted in blurry thumbnails. The fix implements Lanczos resampling for WebP processing, ensuring high-quality thumbnails across browsers.
Original PR description
**Steps to reproduce:** - Install eCommerce app - Go to the shop of the website - Activate the editor - Click on 'New' in the top right - Create new product with image - Image is automatically…
**Steps to reproduce:** - Install eCommerce app - Go to the shop of the website - Activate the editor - Click on 'New' in the top right - Create new product with image - Image is automatically converted to 1920x1920 in webp format - Thumbnails have low quality when computed in JS (visible artifacts such as dotted diagonal lines and aliasing), especially on Firefox **Issue:** For other image formats, the resizing is done in the backend and use a specific downsampling algorithm (Lanczos) with PIL to improve the output quality. But as we are moving to use .webp format as the default, which is processed directly in JS for security reasons (and browser dependent), this algorithm is not applied anymore (which leads to some visual degradation in the thumbnails). WebP format is not supported on the python side due to `Pillow` dependency to `libwebp` which is considered unsafe at the moment. Using higher resolution images and downsizing them using css sometimes fix the issue, but it mainly works on Firefox, which seems to apply a different downsampling with css and with canvas drawing. **Fix:** Implemented Lanczos resampling for the webp format when processed in the browser. related : https://github.com/odoo/odoo/commit/d1292a96a62b18a88a852c69ed7732d16ae0344e Not sure about the licensing needed, as I used this old implementation as a reference: https://github.com/mudcube/Lanczos.js opw-4561958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
This update resolves an issue where changes to spreadsheet sale inputs were unexpectedly lost due to system updates or user actions. The fix ensures that input values are correctly saved and reflected, providing a more reliable user experience. This improves data accuracy and reduces potential data loss.
Original PR description
Currently, the FieldSync record input suffers from two issues: 1) The input value can be reset by parasitic renders While the user is inputting a value, if they did not confirm it and a global render occurs (other user joining the session, dragging the mouse on the grid), the input value will be reset to the one stored in the plugin, therefore erasing the last change of the user 2) In Chrome-based navigators, users can change the value of the input by using their mouse scrolling wheel. Such action *does not* trigger an `onChange` event; which means that the new value is never directly saved. Both issues are addressed in this commit by keeping an internal state inside the component `FieldSyncSidePanel` and ensure this state is properly reflected in the plugin once we stop editing the input. Task-5123069 Forward-Port-Of: odoo/enterprise#96431