Daily updates from Odoo
Monday, March 23, 2026
111 changes
3 changes
Resolved issues and error corrections
This update fixes an issue where the table editor lost focus after deleting rows or columns, disrupting the editing workflow and causing confusion. Now, the editor automatically refocuses, ensuring actions like Undo work correctly and improving the overall user experience when managing table data.
Original PR description
**Current behavior before PR:** When a user deletes a row or column from table menu, the editor loses focus. As a result, actions like Undo do not behave as expected and require multiple attempts to restore the original table state. This breaks the editing flow, causes confusion when performing table-related actions. **Desired behavior after PR:** This PR ensures that editable is focused after deleting row or column from table menu. This commit also makes sure that selection is set properly and hint is visible on empty cell after deleting the column. task-5725593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254684 Forward-Port-Of: odoo/odoo#245433
This update corrects a bug where project sharing settings were incorrectly changing after sharing with portal users. The change ensures that project visibility remains as intended, regardless of the sharing method used. This resolves an issue impacting how users access and collaborate on projects.
Original PR description
Steps to reproduce: - Create/open any project - Set visibility to `Invited internal users and portal users`. - Share project with a portal user - Visibility changes to `All internal users and invited portal users`. Cause: - Previously, this behavior was implemented specifically for sharing the project from the cog menu. However, the `Share Project` option has now been removed from the cog menu. - After introducing the new `invited_users` visibility option, the existing share logic was not updated to support this new value; as a result, the project's existing visibility is unintentionally overwritten. Solution: - Remove the hardcoded update of `privacy_visibility` in the `action_send_mail` method. task-5924243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255197 Forward-Port-Of: odoo/odoo#248235
This update ensures that all product attributes (like color and size) are accurately reflected when scanning barcodes in the Point of Sale system. Previously, the system only displayed variant-specific attributes, leading to inconsistent order lines. This fix guarantees a more reliable and complete product representation during scanning, improving the customer experience.
Original PR description
Currently, when a product has more attribute values then variant values (some attribue can have only one option), the pos behaves differently depending if you select the product or scan it. Steps to reproduce: ------------------- * Modify the acoustic bloc screen "Attributes & Variants" tab * Have one attribute line Color, only White as values * Have one attribute line Size, S and M as values * Go to the variants, select the one corresponding to the Size S > Observe it also has the attribute White * Set a barcode on this variant * Open shop * Select Acoustic Bloc Screens, select Size S, confirm * Now scan the barcode > Observation: 2 Different pos order lines on the order, the first shows S, White as attributes, the second one only shows S. Why the fix: ------------ We need to use all attribute values, not only the variant values. opw-5932560 Forward-Port-Of: odoo/odoo#255181 Forward-Port-Of: odoo/odoo#252233
4 changes
Resolved issues and error corrections
This update resolves an issue where invoices with recupel taxes applied to negative lines were failing XML validation, specifically when using the Peppol standard. The fix ensures negative fixed taxes are correctly identified as allowances, preventing validation errors and enabling proper invoice export for PEPPOL transactions.
Original PR description
**PROBLEM** If you set a recupel tax (fixed tax affecting base) and use it on a negative line, the generate xml will not pass validation. **STEP TO REPRODUCE** 1. Setup Peppol. 2. Create a recupel tax (fixed tax of 1€, affecting the base). 3. Create an invoice with a negative line, with a VAT and the recupel tax. 4. Send the invoice using peppol, and validate the xml. 5. Notice the xml doesn't pass validation. **CAUSES** 1. The negative fixed tax should be an allowance, but is marked as a charge in the xml. 2. Only fixed taxes that are charges influences the line_extension_amount, but it should also be the case with negative fixed taxes. 3. Negative fixed taxes should have a ChargeAllowanceReasonCode that is in the AllowanceReasonCode list. opw-5955289 Forward-Port-Of: odoo/odoo#253657 Forward-Port-Of: odoo/odoo#252716
This update resolves an issue where invoice cancellations were causing database blocks due to a mismatch in status between Odoo and the ticketBAI system. The fix checks for a security hash before sending invoices to ticketBAI, preventing the attempted reset to draft that triggered the error. This ensures invoices can be correctly processed and avoids disruptions.
Original PR description
Before this commit, if the user configured the sales journal to be locked by a hash, then a cancellation in ticketbai would 1/ send the cancel request to ticketBAI. This would be processed…
Before this commit, if the user configured the sales journal to be locked by a hash, then a cancellation in ticketbai would 1/ send the cancel request to ticketBAI. This would be processed successfully 2/ try to reset the invoice to draft inside of Odoo, then cancel it. This would fail with an error since account moves protected by a hash cannot be reset to draft. The result is a blocked database where the invoice cannot be altered in Odoo while its status doesn't match the status in ticketBAI. In this commit, we propose to check for the secure hash before sending the invoice over to ticketBAI. The invoice is not altered yet at that stage to account for potential ticketBAI errors in the normal flow. While this option is not great from a usability perspective (preventing secure hashes with ticketBAI is probably best), we believe the current solution offers the best compromise in the context of a bugfix. The issue does not seem to be reproducible outside of production as the core of the problem is a mismatch in state between ticketBAIand Odoo. opw-5912848
This update simplifies how packaging quantities are calculated on sale order lines. Previously, changing the packaging quantity triggered unintended calculations, leading to inconsistent results. Now, users can directly choose their packaging and quantity, ensuring accurate order fulfillment and reducing potential errors.
Original PR description
Setup: A product with a packaging of 1 unit and a box of 4 units Usecase1: - Add a line (by default it suggest the 1 unit packaging) - Increase the quantity to 4 (it remains on unit packaging) - Increase it to 5 It switch the packaging to Box of 4 and the quantity to 20. Usecase2: - Add a line of 1 unit - Swith the packaging to box (the packaging quantity switch to 0.25) - Set the packaging quantity to 4 (I want 4 boxes) It switch everything back to unit. We had to choose between: - The packaging is computed base on the quantity to delivery in order to suggest a packaging or - The user choose the packaging and the quantity of packaging to drive the quantity to deliver. This commit modify the behavior, in order to let the user choose its packaging and drive the quantity to deliver base on that. opw-6019088
This update fixes an issue where kit products were incorrectly reporting the full sales price of each component in delivery DDTs. Previously, the report didn't account for kits, leading to inflated values. Now, the report accurately reflects the value of each component within the kit.
Original PR description
Steps to reproduce: - Have an IT company setup - Create a product with a Sales Price and define a kit BOM with 2 components - Create SO with product - Confirm, go to delivery, validate - Print Issue: In the delivery DDT, there is a summary of the delivery where each item has its own entry (product, quantity, value). However, in case of kit BOM, each component is reported with the full value of the sale operation. Analysis: This occurs because in the report code we don't consider the possibility of kit products, where multiple components are associated to the same sale line. Ticket [link](https://www.odoo.com/odoo/project.task/5013606) opw-5013606 Forward-Port-Of: odoo/odoo#224103
4 changes
Resolved issues and error corrections
This update resolves a bug where changing the packaging quantity in a quotation unexpectedly altered the calculated product quantity and packaging amount. The fix removes a dependency causing incorrect calculations, ensuring packaging quantities update accurately when adjusting the main quantity.
Original PR description
**Behaviour:** When creating a sale order line for an item with multiple packagings, modifying the packaging quantity will trigger the computation of the product quantity which will trigger the…
**Behaviour:** When creating a sale order line for an item with multiple packagings, modifying the packaging quantity will trigger the computation of the product quantity which will trigger the computation for the packaging itself. This creates a dependency between the chosen package and the quantity selected which can end up triggering unexpected reactions when following specific flows. **Steps to reproduce:** - Enable packages for sales in configuration - Create a product, in the inventory tab, add two packages: Pack of one, and Pack of four and set corresponding unit. - Create a quotation and set the SO line to Quantity to one, this should set Packaging and Packaging Quantity to 1 aswell - Now change Packaging Quantity to 4, this should visually only change the Quantity to 4 - Now if you change Quantity to 5, you should see Packaging switch to packs of 4 and Quantity jump to 20. This is caused because when in` _compute_product_uom_qty` we try to get the `product_packaging_id` which in turn triggers `_compute_product_packaging_id `before completing the previous compute. https://github.com/odoo/odoo/blob/cf9805874722b6729b5301fdea4f107ae221a1d2/addons/sale/models/sale_order_line.py#L397-L411 When we change the packaging_qty to 4, the packaging_id doesnt change as the compute is triggered before assigning 4 to the uom_qty. But when we change packaging_qty to 5, the packaging_id changes to packs of 4 as the compute is triggered before the uom_qty should go to 5 which then results in the uom_qty switching to 20. The solution removes the dependency between package_id and qty.
This update resolves an issue preventing the export of self-billing invoices when using the Factur-X (CII) electronic invoicing format. The fix addresses a missing function within the invoicing process, allowing users to correctly generate self-billing invoices for Factur-X invoices. This ensures seamless integration with Peppol Self-Billing.
Original PR description
# How to reproduce - Install the Peppol Self-Billing module (account_peppol_selfbilling) - Go to any contact - In the accounting tab, set the Electroing Invoicing to "Factur-X (CII)" - Try to access…
# How to reproduce
- Install the Peppol Self-Billing module (account_peppol_selfbilling)
- Go to any contact
- In the accounting tab, set the Electroing Invoicing to "Factur-X (CII)"
- Try to access any Vendor Bill
# The problem
A traceback is shown
# Why
This commit (https://github.com/odoo/odoo/commit/c696a11ee735b0689ef6a00f1a189916724d4854) backported the peppol self-billing feature.
When the user try to access a Vendor Bill, this check is run :
```py
def _is_exportable_as_self_invoice(self):
return (
self.state == 'posted'
and self.is_purchase_document()
and self.commercial_partner_id.ubl_cii_format
and (edi_builder := self.commercial_partner_id._get_edi_builder()) is not None
and edi_builder._can_export_selfbilling()
and self.journal_id.is_self_billing
)
```
In the case of Factur-X invoicing (account.edi.xml.cii), ```_can_export_selfbilling()```is not defined.
opw-6022938
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where leave hours weren't accurately calculated when employees used calendars with multiple defined dates and times. Previously, the system didn't properly interpret complex calendar schedules, leading to incorrect leave start and end times. This change ensures that leave hours align precisely with the defined calendar events, providing accurate leave tracking.
Original PR description
Define the correct hours in the leaves if the calendar has defined dates (`date_from` and `date_to`) Use case example: - Create a calendar and define on Friday (Morning: from 08:00 to 13.00,…
Define the correct hours in the leaves if the calendar has defined dates (`date_from` and `date_to`) Use case example: - Create a calendar and define on Friday (Morning: from 08:00 to 13.00, Afternoon: from 19:00 to 21:00) with date_to=2025-01-01. - Define another specific Friday (Morning: from 09:00 to 14.00, Afternoon: from 17:00 to 20:00) in the same calendar with date_from=2025-01-01. - Create an employee and define the calendar created for him/her. - Create a leaves for the employee and select a Friday (2025-05-02). - The start hour of the leave must be 2025-05-02 09:00:00 - The end hour of the leave must be 2025-05-02 20:00:00   Please @pedrobaeza can you review it? @Tecnativa TT56218 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208378
This update ensures that attachment files are always linked to a financial transaction simultaneously. Previously, updating the transaction details and attaching a file could lead to inconsistencies. This change guarantees data integrity and prevents errors when sending RS EDI documents.
Original PR description
Was committing the move fields update, then updating the attachment. This might create an issue were the move update commits successfully, but setting the attachment fails and we end up with an inconsistency. Set attachment in the same transaction as the move update. task-6035727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr