Wednesday, December 31, 2025
9 changes · saas-18.3
Resolved issues and error corrections
This update ensures that product descriptions are correctly updated in UrbanPiper whenever the menu is synchronized. Previously, changes to product descriptions weren't reflected in UrbanPiper, leading to outdated information. This fix resolves that issue, maintaining accurate product details for our UrbanPiper integration.
Original PR description
Before this commit: --- When we sync the menu with the product description and later update the product description, re-syncing the menu does not update the product description in UrbanPiper. After this commit: --- This fix ensures that any change in the product description is properly sent to UrbanPiper during menu synchronization. task-5439271 Forward-Port-Of: odoo/enterprise#102846
This update resolves an installation problem that prevented users from correctly setting up the Mauritius localization within Odoo. The issue stemmed from a missing configuration setting, which has now been added to the module manifest to ensure proper installation and functionality. This ensures smooth setup for users utilizing the Mauritius fiscal localization.
Original PR description
Steps to reproduce: 1. Install 'accountant' 2. Create a new company without a country and switch to that company 3. Accounting > Configuration > Fiscal Localization 4. Select Mauritius and save Issue: It gives a traceback: KeyError: 'mu' Cause: 'auto_install' is not present in the manifest file. Solution: Add 'auto_install': ['account'] in the manifest as it is done in other localization modules. opw-5231064 Forward-Port-Of: odoo/odoo#239881 Forward-Port-Of: odoo/odoo#236207
This update resolves an issue that caused a technical error when users clicked on the 'Extra Hours' time off type in the dashboard. The problem stemmed from a missing piece of information in the system's data, which triggered an error. This fix ensures a smoother user experience when selecting this time off option.
Original PR description
Steps to reproduce: -------------------------- 1. Install hr_holidays_attendance. 2. Go to Time Off > Dashboard 3. Try to click on "Extra Hours" Issue: -------- A traceback occurs: ```python…
Steps to reproduce: -------------------------- 1. Install hr_holidays_attendance. 2. Go to Time Off > Dashboard 3. Try to click on "Extra Hours" Issue: -------- A traceback occurs: ```python InvalidDomainError: Invalid domain representation: holiday_status_id,=,5,company_id,=,,user_id,=,2 ``` Cause: --------- After 0aeaa2b (hr_holidays), clicking a time off type sends [employee_company](https://github.com/odoo/odoo/blob/84b137098ee46b1dab679fa8d99dbf368929413d/addons/hr_holidays/models/hr_leave_type.py#L539) in the domain. https://github.com/odoo/odoo/blob/84b137098ee46b1dab679fa8d99dbf368929413d/addons/hr_holidays/static/src/dashboard/time_off_card.js#L70-L74 However, the hour-based time off type created by `hr_holidays_attendance` does not define `employee_company`, so the domain contains **undefined,** triggering `InvalidDomainError.` Solution: ----------- Add the missing employee_company value in hr_holidays_attendance to resolve the issue. opw-5358682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239185
This update fixes an issue where combo line prices were incorrectly set to 'automatic' after order creation. The change ensures combo line price types remain as originally intended, preventing conflicts with price updates and maintaining accurate pricing for combo sales. This improves the reliability of point-of-sale transactions.
Original PR description
After commit https://github.com/odoo/odoo/commit/69057e41fb4cd800d23401ead8ae11bf7cba7c64, the price type of combo lines was changed to 'automatic' when creating the combo line. This caused the set pricelist logic to update the price of combo lines with automatic price type, which conflicts with the intended behavior. This commit ensures that the price type of combo lines is preserved as original in cases where we want to update the price, and only set to automatic in cases like loading a sale order or refunding an order. opw-5240429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239748 Forward-Port-Of: odoo/odoo#234575
This update resolves an issue where Odoo invoices with discounts generated through Nemhandel would fail validation. The change ensures that discounts are correctly accounted for in invoice calculations, allowing invoices with discounts to be successfully sent to customers via Nemhandel. This improves the functionality of the Nemhandel integration.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241614
This update resolves an issue where large .docx files weren't being correctly identified with their proper file type (like .docx) when using the `python-magic` library. Previously, the system incorrectly guessed 'application/zip' for these files. This change increases the data sent to the file type guesser, ensuring accurate identification and proper handling of large documents.
Original PR description
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open…
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed. If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly. But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files. The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment. I've tested it with double the amount of bytes and it seems to work correctly. Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details. ### Current behavior before PR: <img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" /> ### Desired behavior after PR is merged: The uploaded file's mimetype is correctly identified for big (>40mb) open office files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239045 Forward-Port-Of: odoo/odoo#233266
This update corrects a restriction imposed by Mexican tax authorities (SAT) on the ‘CuentaPredial’ field in our software. The change ensures Odoo correctly handles the required format for this field, aligning with current SAT regulations. This is necessary for accurate tax reporting and compliance in Mexico.
Original PR description
SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node
Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd
Forward-Port-Of: odoo/enterprise#102981This update resolves an issue where users couldn't answer incoming calls when opening modals like email or SMS wizards. The fix adjusts the software's layering to ensure the softphone is always visible and clickable when a call is active. This improves the user experience by allowing immediate call handling.
Original PR description
If you get a call when opening any modal/composer like email/sms wizard, you won't be able to pick up the call as the softphone is not clickable. This is because the z-index of the softphone is less than the modal. This commit fixes that issue by making the softphone above modals only if there is a pending call. [Task-4018118](https://www.odoo.com/odoo/project.task/4018118)
This update resolves an issue where delivery validation would fail after splitting a stock move line within a delivery order. Now, the system correctly recognizes that the new move line is associated with the original picked move, allowing validation to proceed smoothly. This ensures accurate order processing and prevents unnecessary backorder warnings.
Original PR description
Scenario: * create a delivery with quantity 3 and mark as TODO * mark the stock move as picked * open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new…
Scenario: * create a delivery with quantity 3 and mark as TODO * mark the stock move as picked * open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new package or a new lot * exit the popup and try to validate the delivery Behavior before this commit: * the stock move in the delivery form remains picked * validation shows a backorder popup, warning of missing quantity Reason: the newly created stock move line is not picked, but this information is not displayed anywhere, so users are not aware of the cause of this issue After this commit: * the stock move is no longer picked after a new move line is added * users can click the "Picked" checkbox in the delivery form manually, which marks all stock move lines as picked as well * after this action, delivery validation proceeds without backorders opw-5345579 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#239089