Wednesday, June 10, 2026
11 changes · saas-18.4
Resolved issues and error corrections
When products are added from a delivery linked to a sales order, the resulting sales order line now includes the proper sales description instead of only the product name. This helps keep customer-facing order details complete and consistent, reducing manual corrections after delivery validation.
Original PR description
When a line is added to a delivery related to a sale order, the corresponding line created in the sale order uses only the display_name as a description. This commit makes sure that if a previous SO line exists for the product, the new line uses the same description. Otherwise we call `get_product_multiline_description_sale()` Steps to reproduce: - Create a product with a description in the Sales tab - Create a quotation with any product (can be said product) and confirm it - Go to the delivery action, and add a new line with the product in the view, set delivered quantity to 1 - After Validating, you'll notice that the new line in the Quotation doesn't have a description opw-6175891 Forward-Port-Of: odoo/odoo#267425 Forward-Port-Of: odoo/odoo#262276
The website builder now shows the previously saved Google Maps API key when reopening the configuration dialog. This prevents users from thinking their key was lost and makes it easier to review or update map settings.
Original PR description
Opening the Google Maps API key dialog from the builder did not show the previously saved key, although it was still stored in the database. Steps to reproduce: 1. Open Edit mode > Theme > Advanced > Google Map (Custom Key) 2. Enter a key and save 3. Refresh and reopen the dialog The input is empty instead of showing the saved key. This regression was introduced during the OWL migration of builder: `ConfigureApiKeyAction` was always passing an empty string to `configureGMapsAPI()`. Fix by fetching the stored key from the `google_maps` service before opening the dialog and passing it to `configureGMapsAPI()`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
SEPA payment QR codes now show amounts with the proper currency decimal precision. This prevents rare cases where scanned vendor bill payments displayed extra decimal digits, reducing confusion and avoiding payment entry issues.
Original PR description
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of…
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of respecting the currency's expected precision. This occurs because the `amount` variable in `_get_qr_vals` was being converted directly using `str(amount)`. Due to Python's floating-point arithmetic, the float value in memory can contain decimal drift. Directly casting it to a string exposes this drift in the payload. This commit resolves the issue by replacing `str(amount)` with `float_repr(amount, currency.decimal_places)`. This safely bypasses the float representation issue, ensuring the string strictly respects the currency's configured decimal precision before being injected into the QR code. opw-5504258 **Steps to reproduce:** - Select company “My Belgian Company” - Create a 23% purchase tax - Create vendor bill - Select Vendor “BE Company CoA” - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73 - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show **Current behavior before PR:** - When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift. **Desired behavior after PR is merged:** - The SEPA QR code is generated with the correct number of decimal places. Forward-Port-Of: odoo/odoo#267293
Time Off allocation titles now show rounded hour values instead of long decimal numbers in specific work schedule setups. This makes allocation information easier for HR users to read and avoids confusion when reviewing employee time off balances.
Original PR description
Steps to reproduce: ------------------- 1. Install Time Off 2. Create an employee with a 38-hour working schedule (7.6h/day) 3. Create a time off type with request unit set to "Hours" 4. Create an…
Steps to reproduce: ------------------- 1. Install Time Off 2. Create an employee with a 38-hour working schedule (7.6h/day) 3. Create a time off type with request unit set to "Hours" 4. Create an allocation for this employee with a duration of 8 hours 5. Observe the allocation title displaying a long decimal value. (e.g., 7.999999999999999) Issue: ------ The `number_of_days` is calculated in `_compute_number_of_days` using: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L261-L262 For an 8-hour request on a 7.6h/day schedule, this results in ~1.052631579 days. In `_get_title`, this value is multiplied back to show hours: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L151 This multiplication leads to the long decimal values being displayed in the title. Solution: --------- Round the computed duration to two decimal places using `float_round`. **NOTE:** This issue is already fixed in saas-19.1 (commit 01d86a7). However, **no change** is required in the multi-allocation wizard, as the duration there directly uses user input and is not computed from working hours. opw-6091424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260140
This update fixes an issue where adding a recurring product to a confirmed sales order without a linked subscription plan would cause an error. The change adds a validation step to prevent this, ensuring that recurring products are only added when a valid subscription is present, improving data integrity.
Original PR description
Steps to reproduce: - Go to Sales → Products. - Create a Service product and enable the Recurring option. - Open an already confirmed Sales Order that does not contain any recurring products. - Add the newly created recurring product to the confirmed order. - Click Save. - Observe that a traceback occurs. Cause: - When adding a recurring product without a subscription plan to a confirmed Sale Order, _timesheet_create_task() attempts to compute a start date using order.next_invoice_date, which is not set. - This leads to a TypeError when `order.next_invoice_date` receives `False`. Solution: - Add a validation to prevent adding recurring products without a subscription plan and raise a proper `UserError` instead of allowing the code to reach task generation logic. task-5932700 Forward-Port-Of: odoo/enterprise#119847 Forward-Port-Of: odoo/enterprise#107691
This update resolves an error that occurred when confirming DHL deliveries. The system now automatically sets a future delivery date (one hour ahead) to avoid the 'date must be in the future' error, which previously prevented successful order confirmations. This ensures DHL delivery confirmations function correctly.
Original PR description
When confirming the delivery of an order using DHL shipping method we get an error that the date must be in the future. This happens when the scheduled date was not set, or set for a time in the past. This commit automatically sets the time to 1 hour in the future and bypasses the user error. opw-6148927 Forward-Port-Of: odoo/enterprise#116211
This update fixes a misleading error message displayed when a shift template's start time was set after its end time. The message has been corrected to accurately state that the start time must be before the end time, improving clarity for users creating shift templates. This ensures accurate shift scheduling.
Original PR description
Before this commit, when the user set a start hour after end hour, the error message raised said: "The start hour cannot be before the end hour for a one-day shift template.". Which does not make sense since the start hour has to be before the end hour to be valid. This commit fixes the error message to say the start hour cannot be after the end hour. Forward-Port-Of: odoo/enterprise#119637
This update prevents users from directly creating employee, cost, or mandatory benefits records through the Benefits form. This change ensures data integrity by requiring these records to be created through the standard HR contract workflow, improving data accuracy and reducing potential errors.
Original PR description
This commit prevents creating new employee, cost or mandatory benefits records directly from the Benefits form by setting these fields' `'no_create'` to `True`. task-5156844 Forward-Port-Of: odoo/enterprise#96770
This update resolves an issue where a specific combination of input data (short street address and a 'false' setting for a second street) was causing errors in the generation of French VAT reports. The fix ensures accurate report formatting and prevents potential processing failures, improving the reliability of this important financial reporting process.
Original PR description
When the street field is shorter than 30 char and street 2 is false, we end up with " False" in the xml, which will return an error in aspone. no task id Forward-Port-Of: odoo/enterprise#119718
A recent issue preventing users from adding cover images to Knowledge articles has been resolved. The fix corrects a technical error within the Knowledge module related to how cover uploads were handled, ensuring a smoother user experience. This resolves a crash that occurred during the upload process.
Original PR description
Steps to reproduce: 1. Install Knowledge. 2. Create an article. 3. Open the more actions menu. 4. Click "Add Cover". 5. Upload a cover image. Issue: - The upload crashes with the following traceback: `Uncaught Promise > this.props.setAbortUploadsCallback is not a function` Cause: - `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop. Solution: - Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded. Alternative approach: - Make ImageSelector tolerate callers that do not provide setAbortUploadsCallback by calling it with optional chaining. opw-6176716
This update fixes an issue where placeholder images were unnecessarily included in menu synchronization, leading to slower loading times. Now, only actual product images are sent, resulting in a more efficient and responsive menu display for users. This change improves the overall user experience.
Original PR description
This commit prevents placeholder images from being included in the menu sync payload and only sends `img_url` when an actual image is configured on the product or category. Task-6251430 Forward-Port-Of: odoo/enterprise#119883 Forward-Port-Of: odoo/enterprise#119482