Daily updates from Odoo
Tuesday, December 9, 2025
27 changes · saas-18.4
New functionality added to Odoo
This update introduces a new test suite specifically for the Turkish e-invoice module's integration with the Nilvera API. Previously, there were no tests to ensure the API connection and data exchange were functioning correctly. These tests provide crucial verification and improve the reliability of the Turkish e-invoice functionality.
Original PR description
There are no tests for the Turkish e-invoice module. This commit adds that. Task ID: 4655864 Forward-Port-Of: odoo/odoo#229980 Forward-Port-Of: odoo/odoo#216179
Enhancements to existing features
This update allows other Odoo modules to customize the criteria used to define SLAs (Service Level Agreements) when creating helpdesk tickets. Previously, this customization was limited, but this change expands flexibility and improves the ability to tailor SLAs to specific business needs. It builds on existing functionality for related domains.
Original PR description
Allow other modules to modify the _sla_find domain when adding SLAs to helpdesk tickets. This is already the case for extra and false domains, while the main domain is hardcoded up to this commit. Forward-Port-Of: odoo/enterprise#97501
This update enables users to send multiple attachments when sending invoices through the Peppol network. The attachments are now embedded within the invoice XML file using a standard 'AdditionalDocumentReference' tag, improving the efficiency of electronic invoice exchange. This enhancement aligns with Peppol standards and simplifies document handling.
Original PR description
[IMP] account: multiple embed files peppol This commit allows user to send multiple attachments through peppol. The attachments will be embedded into the xml under the `AdditionalDocumentReference` tags task-5103539 Forward-Port-Of: odoo/odoo#238662 Forward-Port-Of: odoo/odoo#234339
Resolved issues and error corrections
This update fixes a discrepancy in how invoices are recorded for Vietnamese accounting. Previously, the system incorrectly treated 'Unearned Revenue' (account 3387) as a payable account, leading to inaccurate balance sheet reporting. This change ensures 'Unearned Revenue' is correctly classified as a current liability, improving financial accuracy.
Original PR description
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the…
When posting an invoice, the system creates: - Journal Entry: Dr 131 (Receivable) / Cr 511 Then the system creates a deferral entry: - Deferral entry: Dr 511 / Cr 3387 (Payable) Falsifying the Balance sheet report, in the accounts receivable and accounts payable indicators The issue was that account 3387 was configured as `Payable`, which caused the system to generate both Receivable (131) and Payable (3387) for the same partner. This is incorrect because account 3387 represents "Unearned Revenue", which is a current liability, not a payable account. By changing the account type from `Payable` to `Current Liabilities`, the deferral entry now correctly reflects that 3387 is a current liability account, preventing the incorrect reconciliation behavior where both receivable and payable entries were created for the same partner. After this fix: - Entry: Dr 131 (Receivable) / Cr 511 - Deferral: Dr 511 / Cr 3387 (Current Liabilities) 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#238807 Forward-Port-Of: odoo/odoo#237493
This update simplifies the handling of MPF payments within the Hong Kong accounting module. Previously, separate payments for wages and MPF were registered, creating complexity. Now, MPF accounts are set to be unreconcilable by default, requiring accountants to manually reconcile statements with the government account.
Original PR description
Currently, we register two separate payments for MPF at the same time as we do for the employee's wages. This is not what we want to do; as both are not paid at the same time. MPF is also handled separately, and paid outside of Odoo on the government platform, making the registration of separate payments more complex for not many benefits. Thus, we make these accounts un-reconcilable by default, and will expect accountants to reconcile the statement with the account directly. task-5349299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238074
This update fixes an issue where timesheet values were incorrectly displayed in project updates. A recent change in how the system handles time conversions led to an extra conversion step, resulting in inaccurate day counts. This fix ensures that timesheet hours are now correctly converted and displayed in project updates, providing accurate reporting.
Original PR description
Similar to: 0104cee Steps to reproduce: -------------------- 1. Install hr_timesheet 2. Create a new project and a task 3. On the task, add a timesheet line with some time (e.g., 16 hours) 4. Open…
Similar to: 0104cee Steps to reproduce: -------------------- 1. Install hr_timesheet 2. Create a new project and a task 3. On the task, add a timesheet line with some time (e.g., 16 hours) 4. Open the project dashboard > create a new project update > observe the timesheet time 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the project dashboard > create another project update > observe the timesheet time again Issue: ------ Incorrect value displayed in the Timesheets. (e.g., 16 Days instead of 2 Days) Cause: ------- After commit 28b69da, the UoM model was restructured, changing how conversions between hours and days are computed. https://github.com/odoo/odoo/blob/aeda822db05b218fd1271c7666307950b7a98512/addons/hr_timesheet/models/project_project.py#L137-L143 The `total_timesheet_time` value is now already stored in the final unit (e.g., days). Whenever a new project update is created, the division in `create()` performs an unnecessary second conversion on an already converted value, causing the incorrect display. https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/hr_timesheet/models/project_update.py#L36-L37 Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days. opw-5184077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237532
This update resolves an issue that previously blocked users from creating new Amazon accounts within a newly created company. The fix ensures the system correctly handles the absence of initial warehouses and stock locations, allowing for seamless account setup.
Original PR description
Currently, an error occurs when user tries to create a new amazon account on a new company. Steps to replicate: - Install `sale_amazon`. - Create a new company and switch to it. - Go to Settings >…
Currently, an error occurs when user tries to create a new amazon account on a new company.
Steps to replicate:
- Install `sale_amazon`.
- Create a new company and switch to it.
- Go to Settings > Amazon account > Try to Create a new account.
Error:
```
File /home/odoo/odoo18/enterprise/sale_amazon/models/amazon_account.py, line 214, in create
'location_id': parent_location_data[0]['view_location_id'][0],
IndexError: list index out of range
```
Cause:
- Whenever a new company is created, it doesnt have any warehouses [1] and amazon stock locations [2].
- This causes the `parent_location_data` to be an empty list and causes error at line [3].
Solution:
- Assigning the `location_id` if the `parent_location_data` exists.
[1]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L206-L210
[2]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L201-L204
[3]: https://github.com/odoo/enterprise/blob/23f085bdba333807a25a2d41214b25f474c7edf8/sale_amazon/models/amazon_account.py#L214
sentry-7086464738
Forward-Port-Of: odoo/enterprise#101465This update resolves an issue preventing the IoT Box upgrade script from correctly updating the Odoo configuration file. By using sudo and installing pip requirements as the Odoo user, the script now functions reliably, ensuring a smoother and more secure upgrade process. This improves the stability of the IoT Box deployment.
Original PR description
On 25.06 images, the IoT Box upgrade script can't update `odoo.conf` file (modules to load) as odoo user running sed doesn't have enough permissions. We now run this command with sudo then ensure the ownership of the file is still `odoo:odoo` We now also ensure that pip requirements are installed for user `odoo` instead of root. Task: 5383045 Forward-Port-Of: odoo/odoo#238553
This change prevents distracting audio notifications during Odoo tests. Previously, test runs were disrupted by unexpected sounds from the computer, leading to frustration. This update ensures a cleaner and more reliable testing environment.
Original PR description
When running tests locally, it's really annoying (and sometimes really jarring / surprising) to hear random beeps and boops from your machine, especially when it's an old timey ringtone from voip. Make it stop. Forward-Port-Of: odoo/odoo#238906 Forward-Port-Of: odoo/odoo#238882
This update resolves a bug where a button would disappear when animated and its label was edited. The fix utilizes `textContent` instead of `innerText` to accurately retrieve the button's label content, regardless of its visibility state. This ensures the button remains visible during editing operations.
Original PR description
Problem: When adding an animation to a button and then trying to edit its label, the button disappears. Cause: Because of the animation effect, while editing, the button is in its initial `invisible` animation state. In that state, `innerText` always returns an empty string because it checks only the visible content of the element. Solution: Use `textContent` instead, which does not depend on element visibility. Steps to reproduce: - Open Website. - Drop any text snippet. - Add a button. - Add an animation to the button. - Edit the button label. - The button disappears. opw-5391115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue related to how the Swedish SIE import process calculates SHA512 hashes. The fix ensures that SHA512 digests are generated correctly, improving the reliability of data import and preventing potential import errors. This primarily impacts the l10n_se_sie_import module.
Original PR description
Forward-Port-Of: odoo/enterprise#101511
This update optimizes the speed of dropzones within the Odoo interface, particularly when adding multiple snippets at once. Previously, the process could take several seconds. This change improves the user experience by significantly reducing the time it takes to drag and drop elements, making the interface more responsive.
Original PR description
We had a problem when the number of snippets was quite big (>50). For example, when we try to drop a snippet in that situation it takes around 2-3 seconds to activate dropzones and the dragging "card" to appear. Now we don't get getComputedStyle() and getBoundingClientRect() for every element and perform DOM insertions at once for every parent. This commit follows [the html_builder refactoring]. [the html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddb Related to task-4367641
This update resolves an issue preventing clients from exporting their bills. Previously, bills weren't being generated, leading to a missing export option. This change ensures that clients can now successfully download their bill documents.
Original PR description
After this PR: https://github.com/odoo/odoo/pull/235934, clients can't export bills because they were never sent. Allow clients to export bills. Related feedback on task-4946367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual issue where form fields were displaying placeholder text as 'null' instead of an empty field. When creating or editing website forms, the placeholder text is now correctly blank, providing a cleaner and more intuitive user experience. This ensures consistent form appearance and usability.
Original PR description
Steps to see the issue: - Open website and start editing - Drop a form - Add a new field, or click on an optional field, the type of which we can modify - Set the field type to 'Selection' or 'Radio Buttons' (or any other that does not have placeholders) - Set the field type back to 'Text' => Field's placeholder is `'null'`, but it should just be empty. task-5383835 Forward-Port-Of: odoo/odoo#238710
This update fixes an issue where new employee timesheets weren't correctly reflecting previously created time off requests. The change ensures that only global time offs are considered, preventing incorrect timesheet generation and improving accuracy for new hires. This resolves a technical glitch impacting employee time tracking.
Original PR description
**Steps to reproduce** 1. Have a future `resource.calendar.leaves` without a `calendar_id` but with a `resource_id`. To achieve this, you can for example install Payroll and Attendance, create a contract with the work entry source being attendances and with no working schedule. Then, create a time off in hours for that employee and validate it. In that case, the `hr.leave` has no `resource_calendar_id` as computed in `_compute_resource_calendar_id`. This leads to a `resource.calendar.leaves` record without a `calendar_id` once the time off is validated. 2. Create a new employee. A timesheet corresponding to the previously created time off is created. **Change** Make sure only global time offs are considered. opw-5248992 Forward-Port-Of: odoo/odoo#237773
This update resolves an issue where clicking a Field Service record in the kanban view opened it in the same tab instead of a new one. The fix corrects a technical error within the `industry_fsm` module that prevented the expected new-tab behavior when using the middle mouse button. This ensures a smoother user experience when accessing records.
Original PR description
Steps to reproduce: 1. Install `industry_fsm` 2. Open Field service module 3. In the kanban view, click a record with the middle mouse button Issue: - The record opens in the same tab instead of a new tab. Cause: - `FsmMyTaskKanbanRecord` overrides `onGlobalClick` without propagating the `newWindow` argument, preventing the expected new-tab behavior. Solution: - Forward the `newWindow` parameter to the parent implementation to restore the correct handling of the middle mouse click opw-5351842 Forward-Port-Of: odoo/enterprise#100926
This update resolves an issue where the correct group wasn't being assigned to the teleworking field in the payroll module for Switzerland (l10n_ch_hr_payroll). This ensures accurate reporting and compliance with Swiss tax regulations related to remote work arrangements. The change improves the accuracy of payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#101691
This update ensures that certain tests are automatically skipped when the 'accountant' module is not installed in Odoo. This prevents unnecessary test execution and improves the efficiency of the testing process. The change corrects a previous issue where tests were incorrectly run without the accountant module.
Original PR description
Some tests were meant to be skipped if accountant was not installed.
This update fixes a visual issue on the website where a product's variant section would incorrectly appear empty when no product attributes were selected. The fix ensures this section is only visible when actual product attributes are present, improving the user experience and preventing confusing empty sections.
Original PR description
### Issue: Variant section which only contains multi-value attributes is visible when none of the attributes are visible. #### To reproduce: 1- Create a product with a single value attribute. 2- Navigate to product page on the website. 3- As seen there is an empty extra section under price. <img width="626" height="296" alt="image" src="https://github.com/user-attachments/assets/cbf0e9e2-b17a-4b1b-94e0-f4b94780dab3" /> #### Cause: This section is to show custom or multi-value attributes. However, when product only contains attributes which have single and non-custom values, the attributes will not be visible. In this cases the section is visible but empty. This fix propose to hide variants when no visible line exists. opw-5241432
This update corrects a critical issue where Swiss account translations were missing, particularly for payroll documents. This ensured all official documents were consistently translated, preventing mixed language content and maintaining compliance standards. The fix was made in collaboration with multiple Odoo team members.
Original PR description
Some Swiss account translations were missing, mainly related to payroll. This resulted in payroll documents having mixed languages, which is not acceptable for official documents. opw-5343680 Forward-Port-Of: odoo/odoo#239122 Forward-Port-Of: odoo/odoo#239001
This update prevents a potential memory error that could occur when installing the HR Timesheet module on databases with many existing accounting records. The change ensures that new data fields are created efficiently, improving the installation process and preventing performance issues. This enhances the stability and speed of adding the HR Timesheet to existing Odoo databases.
Original PR description
Description ----------- On databases with a large count of existing `account.analytic.line` records, installing modules like `hr_timesheet`, which adds compute stored or related stored fields to this model can trigger a memory error due to the volume of records that need to be recomputed. This commit creates the columns manually with the correct default value that is inferred from the state and implementation of said fields. Reference --------- opw-5234833 opw-5255382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239024
This update fixes a limitation in how barcodes handle rental transactions within Odoo. A new hook mechanism has been added, allowing for overrides specifically for the 'sale_stock_renting' process. This ensures accurate barcode scanning and tracking during rental operations.
Original PR description
Add a hook method to be used in barcode that can be overriden for `sale_stock_renting`. As there is no common module for these two module, this was put in their common ancestor. opw-5265874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238753
This update fixes an issue where rental receipts weren't being validated correctly when scanned through the barcode app. The change ensures that rental receipts are handled as partial receipts, even when linked to deliveries, preventing validation errors. This improves the reliability of the rental process.
Original PR description
Steps to reproduce: - Enable Rental pickings - Create a rental for a product, for 4 quantity - Process the delivery - Open the barcode app and open the reception - Scan the product once and validate…
Steps to reproduce: - Enable Rental pickings - Create a rental for a product, for 4 quantity - Process the delivery - Open the barcode app and open the reception - Scan the product once and validate Issue: The receipt is validated without issues nor warning, despite being incomplete. This is due to a bad mix of two changes: - #60801, which always sets the rental receipt as return of the delivery - #48788, which removes the backorder check for returns in barcode For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time. However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt. To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking. opw-5265874 Forward-Port-Of: odoo/enterprise#101387
This update fixes a bug in the Mexican Point of Sale (POS) localization that caused incorrect invoices when refunds with global discounts were processed. The fix prevents refunds from exceeding the original order total, ensuring accurate invoice generation for Mexican businesses. This resolves a potential invoicing issue and improves data integrity.
Original PR description
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to…
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization. Steps to reproduce: ------------------- * Activate the global discount option in any PoS * Open PoS and make a sale with a global discount * Refund the sale without including the discount * Go to the backend * Go to the order list and select the 2 orders you made * Now try to create a global invoice > Observation: The global invoice is in error because the negative lines cannot be distributed correctly. Why the fix: ------------ To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense. opw-4899501 Forward-Port-Of: odoo/enterprise#100780 Forward-Port-Of: odoo/enterprise#93101
This update resolves an issue where outdated sub-channels were repeatedly unpinned during routine system maintenance, leading to unwanted notifications. Additionally, the change prevents unpinning sub-channels if members still have unread messages, preserving the functionality of the pin feature for accessing those threads. This ensures a cleaner and more efficient notification system.
Original PR description
Before this commit, outdated sub-channels were unpinned each time the vacuum ran. It occurs because a condition on sub-channel being pinned is missing. In practice, it's not a big deal funtionnaly but leads to useless notifications being sent. While at it, this PR prevents unpins when there are still unread messages in the sub-channel: the pin feature is used to see unread messages on otherwise hidden threads. Forward-Port-Of: odoo/odoo#239073 Forward-Port-Of: odoo/odoo#238493
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 system's calculations, ensuring that the payment term name accurately reflects the new reference. This improves invoice clarity and consistency.
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 fixes an issue where repair order moves weren't correctly linked in inventory reports. The change was necessary due to a previous update removing the 'name' field from stock moves. The fix ensures accurate referencing of repair order moves for reporting purposes.
Original PR description
### Steps to reproduce: - Create and confirm a repair order for a storable product - Go to Inventory > Reporting > Moves History #### > The related move line appears without reference ### Issue: The issue has been introduced with facf4eba6cd0504aae949c23454c6ffa9eaa9c3f which purpose is was to remove the `name` field of the `stock.move` model. However, prior to saas-18.4, the reference of the move relied on its name: https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 To not lose this reference an override of the `_compute_reference` compute method was introduced for repair orders. But it is currently ineffective since `moves_with_reference` is a set of records and not a set of ides which makes it the method call its super method on every records including the repair orders. opw-5385004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr