Wednesday, April 17, 2024
3 changes · 17.0
Enhancements to existing features
The system now uses more precise targeting to locate the fiscal position field in invoice forms, making the code more reliable and easier to maintain. This change fixes compatibility issues with customizations while improving how the system identifies and modifies form fields.
Original PR description
Currently, an inherited view for `account.view_move_form` targets field `fiscal_position_id` directly with an xpath. While that works for standard modules, it is a very broad xpath that only succeeds in selecting the correct field because it appears before other ocurrences of identically named fields. This commit narrows down the xpath to make it explicit that we target the field located in `account.move`'s "Other Info" page. This fixes an ongoing issue with a customization (described in the task) while improving readability and extensability of `account_invoice_form_inherit`. Task link: [odoo/task#3837027](https://www.odoo.com/web#model=project.task&id=3837027) Task-3837027 Forward-Port-Of: odoo/enterprise#60358
This update improves the documentation and testing of the throttleForAnimation function to help developers understand how to properly handle browser events that lose their context during asynchronous operations. The change includes better guidance and test cases showing how to track scroll event targets in Chrome, preventing potential issues when animations are throttled.
Original PR description
This is a followup on [1]. In Chrome the event's currentTarget is cleared after events such as "scroll" are handled. For asynchronously called methods to be able to access it, the current value of currentTarget needs to be kept. To help developers that might stumble on this issue when using `throttleForAnimation`, this commit emphasizes the fact that usage of that function is not limited to event handlers, and it adds a test case that illustrates a solution for tracking the lost scroll event target. No scenario was identified in 15.0, but this could be used as an alternative solution for [1]. [1]: https://github.com/odoo/odoo/commit/0ba601d2ef5c4e2f846818e78dcd23966d6f563d task-3449843 Forward-Port-Of: odoo/odoo#160969 Forward-Port-Of: odoo/odoo#131259
Odoo now successfully imports UBL electronic invoice files that have namespaces formatted on individual lines instead of just in the root element. This improvement ensures that invoice data can be properly extracted from a wider variety of UBL file formats, reducing import failures and improving compatibility with different EDI systems.
Original PR description
Backporting: https://github.com/odoo/odoo/commit/1e24b151c6ad0023769b5a561690cb62bcda1d8a When importing a UBL file, Odoo expects the UBL specific namespaces to be in the root element of the file. This is not always the case as these namespaces could exist in every element in the file. When a file is formatted this way, Odoo cannot extract the necessary data from it because it is missing the necessary namespaces. To cover this case we use the lxml.etree.Element.find function instead, and pass in the UBL specific namespaces to successfully extract the data. task-3657563 opw-3839398 Forward-Port-Of: odoo/odoo#161857 Forward-Port-Of: odoo/odoo#161034