Daily updates from Odoo
Friday, May 1, 2026
4 changes · saas-18.3
Resolved issues and error corrections
This update corrects a display issue where the Tax ID (DIČ) was appearing twice on Czech customer invoices. The fix removes a duplicate entry from the invoice template, ensuring accurate reporting and compliance with Czech regulations. This improves the user experience for customers in the Czech Republic.
Original PR description
**Steps to reproduce:** * Install the **l10n_cz** module. * Create a customer invoice for a Czech company. * Print the invoice. **Observed behavior:** * The **Tax ID (DIČ)** is displayed **twice** in…
**Steps to reproduce:** * Install the **l10n_cz** module. * Create a customer invoice for a Czech company. * Print the invoice. **Observed behavior:** * The **Tax ID (DIČ)** is displayed **twice** in the invoice header in default layout. * **VAT** is displayed **twice** in the invoice headed in folder layout. **Cause:** * The `registry_vat_external_layout` template adds `company.vat` to `company_address_list`. * Base external layouts already include `company.vat` in the same list. * This results in duplicated DIČ rendering. **Fix:** * Remove the redundant VAT `<li>` from `registry_vat_external_layout`. * Keep only the Czech-specific **Company ID** (`company_registry`) entry, which is not provided by base layouts. Before: <img width="900" height="261" alt="image" src="https://github.com/user-attachments/assets/9b5b81aa-a79d-4c93-8109-3c97d79356f4" /> After: <img width="804" height="221" alt="image" src="https://github.com/user-attachments/assets/4b62eddc-6117-4f52-a8fb-2b03812aad8b" /> opw-6125766 Forward-Port-Of: odoo/odoo#260966
This update fixes a series of issues preventing consistent color and font size application to list markers within the HTML editor. Specifically, it addresses problems with trailing empty lines, inline styles, and empty text nodes, ensuring accurate styling across various list item scenarios. This improves the user experience and consistency of the HTML editor.
Original PR description
### Steps to reproduce: **Issue 1:** - Create a list with multiple items and leave the last item empty. - Press Ctrl + A to select all content. - Apply a text color from the toolbar. - The list…
### Steps to reproduce: **Issue 1:** - Create a list with multiple items and leave the last item empty. - Press Ctrl + A to select all content. - Apply a text color from the toolbar. - The list marker of the last item does not receive the color. **Issue 2:** - Create a list and type some text. - Press Ctrl+A to select all. - Apply a font size via the font-size input (inline style=`font-size: ...`). - Then apply a font size via the font-size dropdown (class-based). - Font size from the dropdown is not applied. **Issue 3:** - Create a list item and type some text. - Convert the text into a link. - Copy the link. - Press Enter and paste the link. - Select the entire list using the mouse. - Apply font size & observe that font size is not applied to some list items. **Issue 4:** - Go to Todo and create a list. - Select all items (Ctrl + A). - Apply a background color class from the toolbar. - Apply a font color using inline styling. - Observe that the font color is not visible. ### Description of the issue/feature this PR addresses: - Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled. - Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect. - Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied. - Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden. ### Desired behavior after PR is merged: - List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder. - Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly. - Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application. - When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li. task - 5454639 Forward-Port-Of: odoo/odoo#241827
This update resolves a technical issue where long descriptions in related images on Sales Orders could cause website errors. The fix truncates excessively long filenames for binary streams to prevent exceeding Nginx's buffer size, ensuring images load correctly. This improves the user experience for Sales Order editing.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952 Forward-Port-Of: odoo/odoo#258498
This update resolves a bug where the system didn't properly validate overtime allocations when changing time off types. Previously, changes to time off types didn't trigger necessary checks, leading to incorrect calculations. This fix ensures accurate overtime adjustments are created and prevents potential errors in employee time tracking.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_holidays_attendance` module 2. Time off > configurations > Time off types 3. Create new time off type as follows: * Set…
Steps to reproduce: ------------------------------------- 1. Install `hr_holidays_attendance` module 2. Time off > configurations > Time off types 3. Create new time off type as follows: * Set Approval to Approved by time off officer * Change Take time off In to Hours 4. Save the record and enable Deduct Extra Hours 5. Go to Management > Allocations 6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee 7. Try to save record > Validation Error > Discard changes 8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record 9. Now change Time Off type to Created Time Off type > Save Observation: ------------------------------------- No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation. Issue: ------------------------------------- In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`holiday_status_id`) to overtime-deductible leave type. Check was only present in the `create` method: https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49 Solution: ------------------------------------- 1. Create new function for validate overtime and to create adjustment 2. Added that function to `create` as well as in `write` method 3. Prevents creating a duplicate overtime adjustment for an allocation that already has one opw-5937185 Forward-Port-Of: odoo/odoo#261529 Forward-Port-Of: odoo/odoo#249793