Daily updates from Odoo
Monday, February 9, 2026
30 changes · 18.0
Resolved issues and error corrections
This update fixes an issue where the general note message was being printed multiple times for each Point of Sale order. This resulted in unnecessary printer usage and potential delays. Now, the note message is printed only once, streamlining the POS process and improving efficiency.
Original PR description
Before this commit: =================== The general note message was printed multiple times for a single order, resulting in duplicate prints on the printer. After this commit: ==================== Ensure the general note message is printed only once, preventing duplicate prints. Task-5502902
This update resolves an issue where emails couldn't be sent to applicants who had been archived in the recruitment process. The fix ensures that archived applicants are correctly included when sending emails, preventing a disruption in communication. This improves the reliability of the applicant notification system.
Original PR description
Version: - 17.0 Steps to reproduce: - Create an applicant. - Archive the applicant. - Select the archived applicant. - Click the Send Email action. Issue: - Unable to Send Emails to Refused Applicants Cause: - The applicant_ids many2many field does not include archived applicants. Because of this, when an applicant is archived, the field becomes empty. Solution: - Add active_test to the field context. Task - 5786195 Forward-Port-Of: odoo/odoo#244691
This update resolves an issue where the 0% EU S tax code was incorrectly applied in Italy. The change ensures the correct code (N2.1) is used based on whether the transaction is for goods or services, aligning with Italian tax regulations. This correction improves tax reporting accuracy for Italian businesses.
Original PR description
In Italy, the code depends strictly on whether the transaction is for Goods or Services. N3.2 is for Intra-community supply of GOODS (Cessioni Intracomunitarie di beni) N2.1 is for Intra-community supply of SERVICES (Prestazioni di Servizi) This commit fixes the exoneration code on the 0% EU S tax from N3.2 to N2.1. task-5870894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245675
This update resolves an issue with the calculation of Spanish taxes (Mod 390) by accurately incorporating balances from specific accounts into the relevant tax reporting sections. This ensures compliance with Spanish tax regulations and improves the accuracy of financial reporting within the Odoo system. The change was part of a larger effort to improve the Spanish localization.
Original PR description
In this commit: Fixing 390 computation: - Add balance from 27, 29, 649 and 31 to casilla 33. - Add balance from 28, 30, 650 and 32 to casilla 34. Related PR : https://github.com/odoo/enterprise/pull/105597 task-5732679 Forward-Port-Of: odoo/odoo#245828
This update resolves an issue where switching between invoice and credit note types on existing, posted transactions caused errors. Now, users can switch these types even if the transaction's internal/external move sequence has been manually cleared, streamlining the process and eliminating the need for manual data re-import.
Original PR description
Previously, switching an Invoice to a Credit Note (or vice versa) on a posted in_()/out_() move raised a blocking error. This forced users to export, delete, and re-import the document with the correct move type. This **PR** relaxes the restriction for posted moves whose sequence has been manually cleared, allowing the `Switch Invoice/Credit Note` action to proceed in that specific case. **task**-5905206 Forward-Port-Of: odoo/odoo#247349
This update corrects a calculation error in the Point of Sale system when applying taxes. Specifically, it ensures that the total price displayed accurately reflects the base product price plus the correct tax amount, regardless of how taxes are configured. This fix resolves an issue where tax calculations were inconsistent, leading to incorrect totals.
Original PR description
When a fiscal position maps a tax-included tax to a tax-excluded tax (or vice versa), the price unit must be adjusted to keep the base amount consistent. This adjustment was missing in the POS…
When a fiscal position maps a tax-included tax to a tax-excluded tax (or vice versa), the price unit must be adjusted to keep the base amount consistent. This adjustment was missing in the POS frontend after the tax computation refactoring in v18+. Background: In v17, the computePriceAfterFp method handled this price adaptation: https://github.com/odoo/odoo/blob/36688ce4dad4b3d508b4fd3d778a06a5a7036408/addons/point_of_sale/static/src/app/store/pos_store.js#L1102-L1133 This method was removed in: https://github.com/odoo/odoo/commit/ab0bdf019212 The refactoring introduced: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/account/static/src/helpers/account_tax.js#L472-L481 However, the POS module was not updated to call this helper when preparing base lines for tax computation. Steps to reproduce: 1. Create a tax configured as "Included in Price" (21) 2. Create a tax configured as "Excluded from Price" (21) 4. Create a fiscal position that maps the included to the excluded tax 4. Add the fiscal position to a contact 5. Create a product with the included tax, priced at 100 6. In POS, add the contact as the client and add the product 7. Total incorrectly shows 121 (or 100 + tax) instead of 100 Ticket [link](https://www.odoo.com/odoo/project.task/5877918) opw-5877918 ------------------------------------------------------------------------ I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows employees to actively use the chatter feature while creating or viewing their own expense reports. Previously, they could only add attachments and messages when the expense was in draft mode. This change improves communication and allows employees to provide additional information or respond to inquiries related to their expenses.
Original PR description
An employee that created his expense was only able to add attachments and post message in the chatter when the expense was in draft. After this, it will still be able to attach attachment and post message without having the right to edit the expense. This is better as the employee will be able to answer questions that have been asked or add more proof if required. task-4966942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows for seamless payment matching between parent and child companies within Odoo. Previously, matching was limited to purchase orders; now, it extends to bills, streamlining financial reconciliation across company structures. This enhancement improves accuracy and efficiency in managing intercompany transactions.
Original PR description
On bills, the `purchase_vendor_bill_id` field already allows matching with cross-company purchase orders. This commit extends this behavior to payment matching. Steps to reproduce: - Create a child company from a parent company. - Create a purchase order in the child company. - Create a bill in the parent company. - In the bill’s payment matching, the child company’s purchase order should be available. opw-5416947
This update resolves an issue where the quantity displayed in the shopping cart wasn't accurately reflecting changes made by the user. The fix ensures that the cart correctly displays the updated quantity after a product is added or its quantity is modified, improving the shopping experience. This was a minor bug impacting order accuracy.
Original PR description
**Steps to produce:** - Install `website_sale` with demo data. - Go to the shop page. - Select product `Customizable Desk` > click `Add to cart`. - In the wizard, change the quantity to 100 and…
**Steps to produce:** - Install `website_sale` with demo data. - Go to the shop page. - Select product `Customizable Desk` > click `Add to cart`. - In the wizard, change the quantity to 100 and directly click `Checkout`. **Issue:** - The cart shows the product with quantity = 1 instead of the edited value. Root cause: - When the user clicks Checkout, both `setQuantity` and `onConfirm` are triggered almost simultaneously. - At [1], the `_setQuantity` method is called, but due to the await before the quantity update is completed, the update may not finish in time. As a result, the previous quantity is sometimes used during checkout instead of the newly selected one. Solution: - we can update the quantity immediately before awaiting `_updateCombination`, ensuring that the correct quantity is already set when onConfirm runs. [1]: https://github.com/odoo/odoo/blob/f4eabe47a602301013afa63da6bdf87809903d29/addons/sale/static/src/js/product_configurator_dialog/product_configurator_dialog.js#L225 opw-5435672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the generation of UBL files for BIS3 invoices. Previously, files lacking an EndpointID were automatically flagged as invalid due to PEPPOL compliance rules. This change adds necessary constraints within Odoo itself, ensuring UBL files are correctly formatted and compliant without immediate rejection.
Original PR description
If EndpointID is not set, the generated file is invalid due to the 2 following rules: [PEPPOL-EN16931-R010] Buyer electronic address MUST be provided. [PEPPOL-EN16931-R020] Seller electronic address MUST be provided. Since this is a configuration issue, there is no point of sending such files to be rejected right away. Instead, let's add those 2 contraints ODOO-side. task-5890887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the copy button within Odoo forms wasn't working correctly. By explicitly setting the button type to 'button', the fix prevents the button from submitting the form, ensuring it functions as intended. This improves the user experience when copying data.
Original PR description
Previously, the type of the button in the template of the CopyButton utility component was left unspecified. Because the default type for buttons is "submit", the copy button will not work if it is placed within a `<form>` element, and will instead submit the form (see [1]). This commit just forces the type of the button to "button" which has no default behavior, meaning it can be used even inside of `<form>` elements without issues. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#type
This update fixes a problem where the BoM report wasn't correctly displaying the selected variant. The issue stemmed from how the system ordered variant information, leading to a mismatch between the backend and frontend. This change ensures the report consistently reflects the variant the user intended to view.
Original PR description
Steps to reproduce on runbot ------------------ Select a product with several variants and a Bill of Materials (e.g. Stool). Change the variants order so that their ids are not ordered, this can be…
Steps to reproduce on runbot ------------------ Select a product with several variants and a Bill of Materials (e.g. Stool). Change the variants order so that their ids are not ordered, this can be done by modifying the default_code for example (e.g. Internal Reference for variant "Color: Green" set to "A"). When accessing the BoM report, you won’t be able to switch to one of the possible variants (in the example the Dark Blue variant). Why it is happening ------------------ The default variant to be displayed when opening the report is selected in the backend using the product_variant_id field. This field is computed as the first element in product_variant_ids as they are ordered in the model. We then send this variant’s information to the frontend and a dictionary containing every variant (key= id and value = display_name). In the serialization process, the object is reordered based on the keys. Thus, if the variants were not ordered based on their ids in python, the order will change. The displayed variant is correct as it has been passed directly but the frontend also computes the currentVariant attribute. This is computed as the first element in the dictionary but in this case, it is not the one that has been selected in the backend, as the order changed. As a result, you see the report for a variant A but the frontend considers you are on the report for variant B so you cannot switch to variant B as you are supposed to be already on it. The fix ------------------ I propose to use the explicitly passed id as the currentVariantId. opw-5409493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241603
This update resolves an issue preventing users with restricted company access from reloading translations. The fix bypasses a privilege check within the translation process, allowing users to continue updating language terms. This improves usability for users who don't have access to all company data.
Original PR description
When a user doesn't have access to all companies, he couldn't reload the translation terms. However, the exception occurs in the call to _get_chart_template_data, which doesn't especially require privileges, because it is static data. With this commit, we bypass the lack of company access to retrieve this data, and let the user continue the language reloading process. Task-id: [5916490](https://www.odoo.com/odoo/project.task/5916490) Forward-Port-Of: odoo/odoo#247540
This update fixes a previous issue where mention suggestions prioritized recent chat conversations over relevant followers. Now, suggestions will prioritize users who are followers of the record, ensuring more targeted and effective communication within Odoo's chat features. This change enhances the user experience by surfacing the most important contacts.
Original PR description
Before this commit, mention suggestions prioritized partners from recent chats over the record's followers. This commit fixes the behavior by reordering the sequence numbers to have the following priority order: Thread followers > Internal users > Recent chat partners. <img width="1051" height="316" alt="image" src="https://github.com/user-attachments/assets/6de527d1-b55d-4c00-b81f-15052147f9d6" /> task-5313114 Forward-Port-Of: odoo/odoo#237145
This update ensures a consistent visual style for mentions across both the small and full composer views. The changes improve readability and prevent overflow issues, particularly on smaller devices, leading to a better user experience when composing messages.
Original PR description
Use the same style in full composer than in small composer. Tweak style to account for small device, better handle overflows task-5916878 Before / After (small composer) <img width="342" height="466" alt="image" src="https://github.com/user-attachments/assets/234ff152-3c5a-4c82-b257-2800a752dd3a" /> <img width="496" height="476" alt="image" src="https://github.com/user-attachments/assets/60b3d12d-38ea-429a-9dec-441886ac022e" /> Before / After (full) <img width="413" height="394" alt="image" src="https://github.com/user-attachments/assets/c51e053f-7eb2-4ee0-8a9a-bd068ee9ded0" /> <img width="487" height="555" alt="image" src="https://github.com/user-attachments/assets/d0a3514d-aa1f-4d89-8fe4-7964ec20a288" /> Forward-Port-Of: odoo/odoo#247562
This update resolves an issue that occurred when the 'l10n_sa_edi' module was used with 'SA Company' configurations where the company street address was missing. The fix ensures the system correctly handles this situation, preventing a technical error during OTP request processing. This ensures smooth operation for users utilizing the SA-specific tax reporting features.
Original PR description
This error occurs when attempting to set the "OTP" received from "ZATCA". Steps to reproduce: - Install `l10n_sa_edi` module > Switch to `SA Company` - Go to `SA Company` and remove `Street` - Journals > Open journal with type 'Sale' > ZATCA > Onboard Journal > Enter any OTP > Request Traceback: `TypeError- value argument must be a str` At [1], the error occurs because the company has an empty street field, causing the value argument to be a `boolean` instead of the expected `string`. [1]- https://github.com/odoo/odoo/blob/40a0b44231fd9a725ccf3667c4992e691e24cde7/addons/l10n_sa_edi/models/certificate.py#L71 sentry-7185302332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug where syncing an order with point changes could incorrectly trigger processing for all orders, including draft ones. This change ensures that draft orders are not unnecessarily processed, improving order stability and preventing potential errors. It addresses a technical issue impacting order processing reliability.
Original PR description
Before this commit, when a draft order with point changes existed, syncing an order would trigger the post processing of all orders, including draft ones. This could lead to issues. opw-5370267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where serial numbers disappeared when creating repair orders with products initially tracked by quantity. The fix ensures that serial numbers are correctly associated with stock movements, preventing the UI from hiding newly created lines. This improves the accuracy of repair order tracking and reporting.
Original PR description
Steps to reproduce: 1. Create a storable product with tracking set to 'By Quantity'. 2. Update the Quantity on Hand (e.g., 100 units). 3. Change the product tracking to 'By Serial Number'. 4. Create…
Steps to reproduce: 1. Create a storable product with tracking set to 'By Quantity'. 2. Update the Quantity on Hand (e.g., 100 units). 3. Change the product tracking to 'By Serial Number'. 4. Create a Repair Order for this product. 5. Add a line, select a specific Serial Number, and click Save. 6. Observe that the serial number disappears. Cause: When reserving stock that was originally created as 'Generic' (no serial), the `_prepare_move_line_vals` method returns `lot_id=False`. The repair view uses `_compute_lot_ids` to display selected lots, which filters out any move lines where `lot_id` is False. This causes the new line to be effectively invisible to the UI immediately after creation. Solution: In the `_set_lot_ids` inverse method, explicitly force the `lot_id` into the create values dictionary (`move_line_vals`). This ensures that even if Odoo reserves generic stock, the resulting move line is born with the correct Serial Number identity, keeping it visible and valid. opw-5156267
This update fixes a problem where browser translation plugins were incorrectly replacing editable content with translated versions, disrupting the auto-save feature. Adding the `translate="no"` attribute to editable fields now prevents this interference, ensuring content is saved correctly.
Original PR description
Browser translation plugins were altering editable content by replacing the original content with translated versions, which caused issues when paired with auto-save. To prevent this behavior, the attribute `translate="no"` has been added to editable fields. task-5485078
This update fixes an issue where suggested mentions in the full composer weren't correctly sorted, preventing users from easily seeing followers. The fix ensures that mentions are now properly sorted, prioritizing followers for a more efficient and user-friendly experience. This improves collaboration within the system.
Original PR description
Fetch/sort suggestion in the full composer don't receive the thread param which leads to follower not being sorted at the top. task-5917226 Forward-Port-Of: odoo/odoo#247581
This update optimizes how Odoo retrieves messages, leading to faster loading times and a smoother user experience, particularly when accessing email activity records. The changes address a previous issue where message access was slow, especially when browsing records multiple times. This enhancement improves overall system responsiveness and efficiency.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245744
This update corrects a bug where VAT reports generated in Odoo were missing email addresses for certain customers. The fix ensures that email addresses are correctly populated in the XML export, addressing a mandatory field requirement and improving reporting accuracy. This ensures compliance and reliable data export.
Original PR description
**Steps to reproduce:** - Install l10n_be_reports and contacts - Switch to a Belgian company (e.g. BE Company CoA) - Go to Contacts - Open the company contact (i.e. BE Company CoA) - Add an invoice address withtout email - Create an invoice: * Customer: [a Belgian customer with a VAT number] * Invoice Lines: [a line with a tax] - Confirm the invoice - Go to "Accounting / Reporting / Belgium / Partner VAT Listing" - Export the XML **Issue:** In the XML, "<EmailAddress>" is empty althouth it is mandatory. **Cause:** The email is retrieved from the invoice address, but there is no fallback on the parent contact if it is empty. **Solution:** Fallback on the email of the parent contact as it is the case for the phone. opw-5870750 Forward-Port-Of: odoo/enterprise#105654
This update resolves an issue with Spanish tax reporting (l10n_es_reports) related to withholding taxes. Specifically, the system now correctly handles the 'type for 347' field in invoices, ensuring accurate tax calculations and compliance. This change improves the reliability of financial reporting for Spanish businesses using Odoo Enterprise.
Original PR description
- Moves that use withholding taxes should have the `type for 347` unselected and left blank. Related PR : https://github.com/odoo/odoo/pull/245828 task-5732679 Forward-Port-Of: odoo/enterprise#105597
This update fixes a bug where appointment slots remained available to customers even when a user was marked as being on time off. The fix ensures that unavailable dates are correctly blocked, preventing appointments from being scheduled during a user's scheduled time off. This improves scheduling accuracy and prevents double-booking.
Original PR description
__ ## Short functional explanation of the error When setting a time off for a user, it doesn't prevent customers from selecting an appointment slot during this time off with said user. ##…
__ ## Short functional explanation of the error When setting a time off for a user, it doesn't prevent customers from selecting an appointment slot during this time off with said user. ## Reproduction Steps 1. Go to Users. Create a user U and a corresponding employee E. 2. Click on the smart button Employee, and in Work Information tab, under Schedule, set the Working Hours as a working schedule you'll remember. Let's call it WS. 3. In debug mode, go to Employees > configuration > Working Schedules. Select the working schedule WS and click on Time Off. 4. Click on new. Give the time off a name, and in the field Working Hours, enter the working schedule WS. As resource, select the employee E. 5. Go to Appointments and click on New. Let the Availability based on Users, and add user U to users. Hit save and preview. ### Expected behavior The date on which the user has a time off shouldn't be selectable. ### Unexpected behavior The date is selectable, and the slots a user can select appear as usual. ## Origin of the issue In the method https://github.com/odoo/enterprise/blob/99231105268a74b24a396903cecc3699b16121b0/appointment/models/appointment_type.py#L1088 we only check if the user has a meeting for a time slot, but no holiday. This issue doesn't appear if the availability is based on resources: we do check leaves on resource for a given time slot with https://github.com/odoo/enterprise/blob/99231105268a74b24a396903cecc3699b16121b0/appointment/models/appointment_type.py#L1481 __ opw-5419376
This update automatically generates unique employee identification numbers and sets the initial marital status to the employee's birthday if they are single. This simplifies the process of creating new employee records in the payroll system, reducing manual data entry and improving data accuracy.
Original PR description
For quality of life improvement, the unique employee identification is now automatically generated and initial marital status date is set to the birthday by default if the person is single Forward-Port-Of: odoo/enterprise#106752
This update resolves an issue where accents were unintentionally removed from legal names used in Mexican electronic invoicing (EDI). This ensures accurate recognition of these names by the SAT (Servicio de Administración Tributaria), preventing potential processing errors and compliance issues. The change specifically addresses the 'ë' character, a common requirement for Mexican tax documents.
Original PR description
Previus commit (odoo#95207) removed accents for names including character ë which indeed its recognized for SAT opw-5897333
This update resolves an issue where reports would display outdated data while waiting for new variants to load. By preventing the initial display of the first variant, we ensure a smoother and more responsive user experience when switching between report options. This improves report loading times and data accuracy.
Original PR description
Previously, when a report was loading if a variant was selected, it would display the first one when it loaded and display the second one when it loaded. With this, we wont show the first one as we are waiting for the new one. To reproduce: - load the Demo data on the demo company - Add time.sleep(5) in _get_lines - load the Generic Tax report and wait for it to load - click on the Group by: Account > Tax and wait for 3s - click on the Group by: Tax > Account - Watch the Account > Tax load and still being displayed for 3s while the Tax > Account variant is loading.
This update resolves a minor issue in how the document search functionality retrieves its context information. By switching to a reliable public API, the system now consistently provides the necessary data, preventing potential errors and improving search stability. This ensures smoother operation for users.
Original PR description
**Before this commit** We were accessing the context on the `DocumentsSearchModel` object by using `_context`. This is incorrect because this property is private, and we can't guarantee its structure. In some cases, `_context` can be `null`, causing later issues when we try to access properties from the context. This was likely just a programming error, rather than intentional. **After this commit** We'll use the public API to get the context by accessing `context` on the `DocumentsSearchModel` object. The internals of that getter method can speak for themselves, but they are useful because they will give us a non-`null` context to work with. opw-5903535
This update standardizes the way time off and absences are recorded and transmitted for payroll reporting in Switzerland (CH). It backports a fix from a previous Odoo release, ensuring accurate and compliant reporting related to employee leave and absence data. This improves the reliability of the ELM (Einmalige Leistungen) transmission.
Original PR description
Backport of https://github.com/odoo/enterprise/commit/f238e04f3f6c39b61d0449a0766809df06eb6980 task-5384297 Forward-Port-Of: odoo/enterprise#101449
This update resolves an issue where the system was unnecessarily creating duplicate snapshots when transmitting ELM data for payroll in Switzerland. The change ensures that a snapshot is only created if one doesn't already exist, streamlining the process and improving efficiency. This prevents potential data inconsistencies and reduces unnecessary system load.
Original PR description
Forward-Port-Of: odoo/enterprise#105135