Daily updates from Odoo
Wednesday, January 7, 2026
19 changes · 17.0
Enhancements to existing features
Replaced the product's static list price with a dynamic computation of the value excluding taxes, multiplied by the product quantity. A new helper method `_l10n_ro_edi_compute_amount` was added to handle this logic, improving accuracy for eTransport documents. ## Description of the issue/feature this PR addresses: This PR fixes a calculation issue in the valuation of transported goods in the eTransport system. In the current implementation, the value of transported goods is incorrectly calcu
Original PR description
Replaced the product's static list price with a dynamic computation of the value excluding taxes, multiplied by the product quantity. A new helper method `_l10n_ro_edi_compute_amount` was added to…
Replaced the product's static list price with a dynamic computation of the value excluding taxes, multiplied by the product quantity. A new helper method `_l10n_ro_edi_compute_amount` was added to handle this logic, improving accuracy for eTransport documents. ## Description of the issue/feature this PR addresses: This PR fixes a calculation issue in the valuation of transported goods in the eTransport system. In the current implementation, the value of transported goods is incorrectly calculated because it doesn't account for the quantity in the final value calculation. ## Current behavior before PR: Currently, in eTransport documents, the value of transported goods (`valoareLeiFaraTva`) is not correctly calculated because the value is not multiplied by the quantity, which results in reporting a lower value than the actual one to the eTransport system. This can lead to fiscal and legal compliance issues. ## Desired behavior after PR is merged: After implementing this PR: - The total value of transported goods (`valoareLeiFaraTva`) will be correctly calculated by ensuring the unit price is properly multiplied by the quantity - Values will be rounded to 2 decimal places for accurate reporting - eTransport documents will correctly report the total monetary value of transported goods, ensuring compliance with Romanian fiscal requirements This fix ensures that the generated fiscal documents are correct and compliant with Romanian legal requirements for the eTransport system. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds crucial data attributes needed for accurate tax calculations and NFS-e submission when the Brazilian fiscal reform is active. Specifically, the system now transmits 'name', 'businessName', 'federalTaxId', and 'type' information. This ensures compliance with updated regulations and improves the reliability of tax reporting for Brazilian businesses.
Original PR description
Purpose: Additional attributes are required to be sent in the rendered node for tax calculation and NFS-e submission when the fiscal reform is enabled. The additional required attributes are: - name - businessName - federalTaxId - type task-5450129
Resolved issues and error corrections
This update resolves an issue where duplicating an invoice from a sales order would incorrectly link both the original and duplicate invoices with the same source document. The change prevents the automatic copying of the source document during invoice duplication, ensuring invoices are correctly linked to their originating sales orders.
Original PR description
### Issue: When opening an invoice from a Sale Order and duplicating it, the Source Document (invoice_origin) was also copied As a result, both the original and duplicated invoice showed the same Sale Order in the Source Document field ### Cause: The `action_view_invoice` method adds `default_invoice_origin` in the context, causing the `copy` function to set `invoice_origin` The field invoice_origin was already set with copy=False in this PR: https://github.com/odoo/odoo/pull/236656 The default context was introduced in PR: https://github.com/odoo/odoo/pull/34561 ### Steps to reproduce: - Create a sales order (SO) - Create and confirm an invoice from the SO - Click on the `Invoices` smart button to access the invoice (SO is visible at the top) - Duplicate and confirm the invoice (The SO is not linked) - Go to the invoices list view and make the `Source Document` visible - Observe that both invoices show the same SO as their `Source Document` opw-5360172
This pull request addresses visual issues in the website editor, specifically preventing blurry countdown displays and text overlap with icons. The changes ensure a sharper, more professional appearance and improved usability for website content creation.
Original PR description
## [FIX] website: prevent blurry countdown canvas and text on zoom [Commit 1] Steps to reproduce: - Go to Website -> Edit Mode - Add a Countdown snippet (size: "Small") - Save and zoom in/out, the countdown canvas and text appears blurry The countdown was rendered at a low resolution, which caused it to blur when zooming. This fix updates the canvas to draw at the proper resolution so the countdown remains sharp at any zoom level. ## [FIX] web_editor: prevent text overlap with icon [Commit 2] Steps to reproduce: - Go to Website -> Edit Mode - Add a Image snippet - Enter a long text in search bar: Issue: 1. Text overlaps with search icon. 2. Selecting the "Photos (via Unsplash)" option causes the text to overlap the dropdown icon. The fix adjusts the end padding to provide sufficient spacing between the text and the icons. task-[4771268](https://www.odoo.com/odoo/project/974/tasks/4771268)
This change fixes an issue where the company tolerance time wasn't being calculated accurately when an employee had multiple attendance entries for the same day. The update ensures that overtime is only added when it exceeds the defined tolerance, preventing incorrect overtime calculations. This improves the accuracy of employee time tracking.
Original PR description
_ ## Short functional explanation of the error When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly. ## Reproduction Steps 1. Go to…
_ ## Short functional explanation of the error When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly. ## Reproduction Steps 1. Go to attendances. 2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes. 3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12. ### Expected behavior As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed. ### Unexpected behavior 12 minutes of overtime are computed. ## Origin of the issue Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time. Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code. __ opw-5136861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the wrong manager was sometimes assigned to approval requests. The change ensures the correct manager, based on the request, is always selected, preventing errors and ensuring approvals are processed accurately. This improves the reliability of the approval workflow.
Original PR description
The previous code added the manager by searching for the first employee that matches the request_owner_id. If there are multiple such employees, it's possible that an employee from a different company than the approval can be selected. Ticket: [5185449](https://www.odoo.com/odoo/project.task/5185449)
A bug was preventing large SEPA batch payments from processing correctly due to a strict comparison of payment amounts. This update corrects the system to accurately handle payment amounts exceeding the maximum SEPA limit, ensuring proper batch payment validation.
Original PR description
**Steps to reproduce:** - Create a vendor payment with the amount 88888888.88 in euros - Set the payment method to SEPA Credit Transfer - Create a vendor batch paymentand set its payment method to SEPA Credit Transfer - Add the created payment to the batch payment - Validate the batch payment **Issue:** An error message pops up, indicating that the payment amount exceeds the maximum amount 99999999.99 for payments in Euros. This not the case since 88888888.88 < 99999999.99 **Solution:** Make sure the number of digits in the payment amount is strictly greater than the max digits instead of greater than or equal opw-5428415
This update fixes a problem where the descriptions for 'Payslip Other Input Types' in the Payroll app were not being translated correctly. The fix ensures that all available language translations are displayed, improving the user experience for international users. This change was made to ensure consistent and accurate information across different languages.
Original PR description
## Issue In the Payroll app, the *"Payslip Other Input Types"*'s descriptions were never translated. The `translate=True` parameter was missing from the field declaration. ## Steps to reproduce 1. Install Payroll (`hr_payroll`) 2. In Settings > Language, add and switch to a new language (e.g., French) 3. In Payroll > Configuration > Other Input Types, the *Description* column is not translated. ## Solution After applying this fix, re-exporting the `hr_payroll.pot` will correctly apply the available translations. This is not done in this PR as, from my understanding, the `.pot` files are automatically exported weekly and shouldn't be updated manually anymore. opw-5366741
This update resolves a bug where users were unexpectedly logged out when accessing images through security proxies like Cisco Secure Email. The fix disables session saving for image requests, preventing Odoo from creating a new session and triggering the logout. This change aligns with recent HTTP standards updates.
Original PR description
## Problem A logout occurs when an image in the chatter is requested through a third-party security proxy (like Cisco Secure Email or Microsoft SafeLinks) via a boomerang redirect following this…
## Problem
A logout occurs when an image in the chatter is requested through a third-party security proxy (like Cisco Secure Email or Microsoft SafeLinks) via a boomerang redirect following this flow:
- A user (Person A) opens an Odoo record. The chatter contains an image previously sent by a correspondent (Person B) whose email client or mail server rewrote the image URL to point to a security proxy.
- Firefox tries to load the image. The URL points to `cisco.com/...`. (for example)
- The proxy scans the link and redirects the browser back to the original Odoo URL: `odoo.com/web/image/...`.
- Firefox follows the strict (now deprecated) `rfc6265bis` rule: it looks at the whole redirect chain.
Since it sees a cross-site hop (cisco.com), it flags the final request as cross-site.
-> Because Odoo's session_id is `SameSite=Lax`, Firefox refuses to send
the cookie on this "false" redirect
- Odoo receives the request at `/web/image` without a session_id.
- Odoo creates a new, empty session to process the request.
- At the end of the request, because save_session is True by default, Odoo sends a `Set-Cookie: session_id=NEW_EMPTY_ID` header in the response.
- The browser receives this `Set-Cookie` header, and this time *applies a different policy*: it considers the header as same-origin, allowing it to overwrite the previously valid session cookie with this new one that corresponds to a fresh, unauthenticated session.
- The user is instantly logged out of their current Odoo tab.
## Context on Web Compatibility
This "redirect chain consideration" was a controversial part of the `RFC6265bis` draft.
Chrome and Safari never fully implemented it because telemetry showed it broke ~1% of the web. In March 2024, the HTTP Working Group (HTTPWG) officially decided to remove this requirement from the spec (reverting to a more permissive model) because it was deemed not web-compatible. Firefox, however, still enforces this strict behavior in many versions.
## How to we fix this
We set `routing={'save_session': False}` on the `/web/image controller`.
- This prevents Odoo from sending the `Set-Cookie` header if the session is dirty or new.
- Even if Firefox sends the request without a cookie, Odoo won't "reply" with a new session ID.
- The user's legitimate session cookie remains untouched in the browser.
## Sources
- HTTPWG Decision (March 2024): https://github.com/httpwg/http-extensions/issues/2104
- Reverting RFC6265bis: https://github.com/httpwg/http-extensions/pull/2750
opw-5184217
opw-4698750
opw-5166151This update fixes a potential issue where duplicate keys were generated for report views, leading to inconsistencies and potential errors. By ensuring unique keys regardless of template status (active or inactive), this change improves the reliability and accuracy of report generation, preventing customizations from overwriting each other.
Original PR description
Before this commit: ------------------------- The sequence used in the template key was computed based only on the last active template. If the next sequence number corresponded to an inactive…
Before this commit: ------------------------- The sequence used in the template key was computed based only on the last active template. If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template. After this commit: ----------------------- The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive. This ensures that template keys remain unique across all report templates. Why this commit: ----------------------- if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys. This fix prevents such conflicts by ensuring unique template key generation.
This update fixes a potential error in the Odoo system related to how third-party check payments are configured within journals. Previously, assigning the same payment method multiple times could cause errors during check transfers. Now, the system will prevent this duplication, ensuring data consistency and preventing unexpected transfer failures.
Original PR description
**Description of the issue/feature this PR addresses:** The same third-party check payment method (e.g., in_third_party_checks) can currently be assigned multiple times to the same journal, either as…
**Description of the issue/feature this PR addresses:** The same third-party check payment method (e.g., in_third_party_checks) can currently be assigned multiple times to the same journal, either as inbound or outbound. This misconfiguration leads to unexpected behavior and runtime errors when using the payment transfer wizard. **Current behavior before PR:** It is possible to assign a third-party check payment method more than once to a journal. When transferring a third-party check via the wizard (l10n_latam_payment_mass_transfer), the system may raise: pgsql Copy Edit ValueError: Expected singleton because more than one payment method line is returned. Functionally, allowing duplicate third-party check payment methods in the same journal does not make sense, as each method should be clearly associated with a unique payment context. **Desired behavior after PR is merged:** The system raises a ValidationError if a restricted third-party check payment method is added more than once to a journal. This ensures data consistency and prevents runtime errors when using the check transfer wizard. If a different handling is needed for a third-party check method, a new journal should be created and configured accordingly. **Video:** https://drive.google.com/file/d/1arbsjfA3NPG4aO2_BKxVStSTw5y4cgnM/view **Steps to reproduce the issue:** 1.Go to Accounting > Configuration > Journals. 2.Open a cash journal that will be used as the destination journal for third-party check transfers. 3.Add the same third-party check payment method multiple times in inbound_payment_method_line_ids. 4. Create the Third-Party Check. 5.Go to Accounting > Customer > Third-Party Checks and select a check to transfer. 6.Open the mass transfer wizard and select the journal from step 2 as the destination. 7.Click to confirm the transfer → the system will raise a ValueError: Expected singleton. Note: This issue has been observed from Odoo v15 onwards --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an issue where bank statements were incorrectly flagged as invalid, even when they were accurate. The fix adjusts how statement validity is calculated, ensuring that all valid statements are properly recognized. This improves the reliability of bank reconciliation within the accounting module.
Original PR description
Some bank account statements are computed as not valid, although they are valid. Statement 1 and 3 appear, and statement 3 is shown as invalid, while both statements should be shown as valid. Statement validity is computed depending on previous statement end balance and current statement start balance. The SQL query uses a window function to retrieve the previous statement. However, the function is applied after the WHERE clause. Therefore, it uses the end_balance of the previously selected statement instead of the previous statement. #### Step to reproduce: - In the bank dashboard of the accounting app - Create journal entry 1 - Create statement 1 - Create journal entry 2 - Create statement 2 - Validate the journal entry 2 - Create journal entry 3 - Create statement 3 - filter statement per "Not Matched" Ticket [link](https://www.odoo.com/odoo/project.task/5341433) opw-5341433
This update automatically calculates and transmits the 2050 pension contribution amount for employees in Switzerland. This ensures accurate and timely reporting to the Swiss tax authorities, addressing a previous manual process and improving compliance. The change impacts the HR payroll module.
Original PR description
task-5166226
This update corrects a bug in the l10n_lu reports that prevented the `TaxBase` element from being included in FAIA XML reports when invoices had multiple taxes. This ensures accurate reporting to Luxembourg authorities, resolving a potential compliance issue and improving data integrity.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519
This update resolves an issue where user avatars in the Chat UI were appearing distorted due to incorrect image scaling. The fix applies the 'object-fit: cover' style, ensuring avatars are displayed correctly and consistently. This improves the user experience by presenting accurate and properly sized profile pictures.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent issue in the Odoo Enterprise system's tour testing process was causing tests to incorrectly finish before manufacturing orders were fully processed. This update adds a step to ensure notifications are cleared, preventing the tour from prematurely concluding and ensuring accurate test results.
Original PR description
The tour test `test_barcode_production_create_bom` could fail when Odoo executes the second manufacturing order too quickly. If the validation notification from the first manufacturing order is still visible, the tour incorrectly considers the test finished while the MO is not fully processed. This change adds a step to explicitly close the notification before starting the new manufacturing order. Issue observed in Runbot build 248089 (v17).
This update ensures the mail plugin correctly identifies the version of Odoo being used. Previously, a recent update caused compatibility issues with older Odoo versions. Now, the plugin will display a message if it doesn't support the current Odoo version, preventing unexpected errors.
Original PR description
Purpose ======= Backport of https://github.com/odoo/odoo/commit/f1bc56523875f1f9c55dd33b575063f67ac192ee The new addin has been refactored and doesn't work with older Odoo version, and so we add an endpoint to be able to show a message if we don't support that Odoo version. Task-4727609 Forward-Port-Of: odoo/odoo#238811
This update addresses several minor issues within the spreadsheet component of Odoo. It includes fixes for data validation and improvements to the user interface, specifically related to popover behavior. These changes enhance the overall spreadsheet functionality and stability.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bd315c8d5d [REL] 17.0.83 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bd315c8d5d [REL] 17.0.83 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/6e91764cda [REV] grid: close popovers on external clicks [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/df7c781aa3 [REL] 17.0.82 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/45a24fdf1e [FIX] grid: close popovers on external clicks [Task: 5418367](https://www.odoo.com/odoo/2328/tasks/5418367) https://github.com/odoo/o-spreadsheet/commit/05e6ca5026 [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580) 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 fixes an issue in the 17.0 version of Odoo where tax names for cashback taxes were inaccurate. The changes rename relevant fields and add Portuguese translations to ensure accurate reporting and compliance with Brazilian tax regulations. This improves the clarity and reliability of financial data.
Original PR description
In 17.0, some taxes have had their incorrect name for the cashback taxes. This renames the invoice_label and name fields of such taxes to better represent what they are as well as add portuguese translations where necessary. task-5470453