Monday, February 9, 2026
20 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 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 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 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 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 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 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 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 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