Tuesday, March 3, 2026
5 changes · 17.0
Resolved issues and error corrections
This update fixes a limitation in Italian invoicing that prevented multiple tax lines (like 0% taxes) from being added to the same invoice. Previously, only the DOI tax could be included. This change now allows for the inclusion of other taxes such as Enasarco and RIT, aligning with Italian tax regulations and enabling more accurate invoice processing.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699
This update corrects a problem where QR codes generated in self-ordering mode (for pickup zones) contained incorrect URLs. The fix ensures QR codes accurately reflect the order without including table identifiers, improving the reliability of order downloads. This resolves an issue reported in opw-5095607.
Original PR description
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where product catalogs weren't correctly converting currency when displaying products or adding them to purchase orders. Now, the catalog accurately reflects the vendor's currency, ensuring consistent pricing across all sales channels. This improves accuracy and avoids discrepancies in purchase order calculations.
Original PR description
When a product is sold by a vendor in a different currency from the PO currency, the product catalog did not correctly convert the currency when displaying the product or when adding it to the PO. This was inconsistent with the backend form view, which does convert the currency when the product is added. This fix is a backport of: https://github.com/odoo/odoo/commit/aadb877f971c638bc39e91136bfe7f8dc2fce500 opw-5266131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where changes made to email HTML within the code view weren't automatically saved. Now, when switching back to the editor view after editing HTML, the field is correctly marked as dirty, ensuring all changes are saved seamlessly. This improves the Email Marketing workflow for users.
Original PR description
Problem: In Email Marketing, switching to code view, editing the HTML, and then switching back to the editor view does not mark the field as dirty. As a result, changes cannot be saved unless an additional modification is made directly in the editor. Solution: Explicitly mark the field as dirty when switching from code view back to editor view, ensuring HTML changes are properly detected. Steps to reproduce: - Create a new Email Marketing record. - Drop any snippet. - Switch to code view. - Modify the HTML. - Switch back to editor view. - Observe that the field is not marked as dirty and changes cannot be saved unless further edits are made in the editor. opw-5999752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that timesheet changes consistently recalculate the cost of sale order lines, regardless of the invoice policy (ordered_prepaid, delivered_manual, or delivered_milestones). Previously, this calculation was inconsistent, leading to potential discrepancies in sales reporting. This fix improves the accuracy of cost tracking for sales orders.
Original PR description
Originally, timesheet updates for tasks associated with sale order lines would cause the cost (purchase_price) to be recomputed. However, this was prevented if the invoice policy was 'ordered_prepaid.' This should also apply to 'delivered_manual' and 'delivered_milestones.' Otherwise, any timesheet updates will recompute the sales.order.line purchase_price field. Steps to reproduce: Create a service product that creates a project/tasks Create a sales order with the product and manually set the cost Assign the timesheets of the task to an employee Have the employee update their timesheet for the task The cost on the sales order line gets recomputed to the default product price Duplicate of pr-250495 task-5902688 related-pr-205415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr