Wednesday, December 31, 2025
8 changes · saas-18.4
Resolved issues and error corrections
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 experience for users accessing time off requests.
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 resolves an issue where Employee Officers were experiencing access errors when editing employee records. By restricting access to salary offer information to HR Managers, the system now functions smoothly for all roles, ensuring data integrity and preventing unauthorized access.
Original PR description
Before: - Editing an employee form as an Employee Officer triggered an AccessError due to mail tracking attempting to read salary_offer_ids on hr.version. After: - salary_offer_ids is now restricted to HR Managers, preventing unauthorized reads during tracking when saving the employee form. Impact: - Employee Officers can edit employee records without encountering access errors. - Access to salary offers remains limited to appropriate managerial roles. Task: 5404676
This update resolves an issue where copying and pasting content from the Knowledge editor resulted in a loss of plain text formatting. The fix restores the ability to correctly paste text into other applications, ensuring users can accurately copy and paste content from the editor. This improves the usability of the Knowledge feature.
Original PR description
Since [1] when `vnd.odoo.odoo-editor` was added to the `HtmlViewer` clipboard, the `text/plain` mimetype was lost. This commit restores the plain text version of the clipboard. Steps to reproduce: - In knowledge, lock a page - Select some content - Copy - Paste into a plain text editor => No content was pasted [1]: https://github.com/odoo/odoo/commit/62a7c50b434e3f47ad58e20e96970cbd90b979b6 task-5449435 Forward-Port-Of: odoo/odoo#241642
This update automatically marks UrbanPiper orders as paid in Odoo when they are marked as 'dispatched'. This prevents order cancellations due to cashier oversight and ensures accurate order status tracking, improving the POS process.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 X-original-commit: 808cf7b3f8c185053dac5cbf75307efa67fd6e90 Forward-Port Of:odoo/enterprise#99513
This update fixes an issue where users could inadvertently change product taxes while items were already in their shopping cart. Now, users can still modify product details but tax updates are restricted when a product is in the cart, ensuring order accuracy and consistency.
Original PR description
- When a product is already in the cart, prevent updating its taxes from the frontend product edit popup. This avoids inconsistencies between the product taxes and the taxes applied to the order line. - Now we can still edit other fields of the product. task-id: 4943650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures invoices exported with distance selling correctly use the foreign VAT number defined for the customer's fiscal position. Previously, the company's VAT was incorrectly used, leading to inaccurate VAT reporting. This fix improves invoice accuracy and compliance with EU regulations.
Original PR description
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1.…
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1. Install a European localization (ex: l10n_at) 2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT. 3. Create a valid foreign customer. (within the EU) 4. Create and send an invoice for this customer. 5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position. This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML. This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it. opw-5182837 Forward-Port-Of: odoo/odoo#237666 Forward-Port-Of: odoo/odoo#236692
This update resolves a technical issue related to the Mexican tax reporting system (l10n_mx_edi) to comply with a recent regulation from the SAT (Mexican tax authority). The previous regex for 'CuentaPredial' accounts was too restrictive, and this change ensures accurate data input according to the latest SAT specifications. This ensures proper tax reporting compliance.
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 Odoo invoices with discounts generated for Nemhandel failed validation. The fix ensures that discounts are correctly accounted for in the invoice data, allowing these invoices to be successfully transmitted to customers. This improves the reliability of our 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