Thursday, January 18, 2024
5 changes · 17.0
Enhancements to existing features
This update prevents users from modifying or deleting GST Return (GSTR) records after they have been filed or received. Previously, users could change the reporting period or delete records even after submission, which could cause compliance and data integrity issues. Now these operations are restricted to protect the integrity of filed tax returns.
Original PR description
### Before this PR: User was allowed to do the following operations: - User was able to change month/quarter/year once the GSTR was filed/received - User was able to delete GSTR Period after sending/receiving data ### After this PR: - We restrict the user from doing the above operations as it could be problematic task-3672403
Resolved issues and error corrections
This update fixes two critical issues in subscription automation rules: email templates were not being saved when creating new rules, and editing existing rules would cause the system to freeze. These fixes ensure that automation rules for sending payment failure notifications and other emails work correctly without data loss or system errors.
Original PR description
Issue: ====== The email template isn't saved in automation rule Changing `Stage goes from` in existing automation rule will break too. Steps to reproduce the issue: ============================= - Install subscription - Go so subscription/configuration/automation rules - Create a new rule with the following values: name:anything - Action to do: `Send an email to the customer`, Email template:`Payment Failure` or anything else - Save - Change an existing automation rule `Stage goes from` it will break Origin of the issue: =================== Creation bug: `template_id` is now a related field. Upon creation , the `template_id` wasn't passed in the `action_values` so we lose the value entered by the user. Update bug: There is an infinite loop in write in `sale.order.alert`, write will call `_configure_alert` wich will call write and so on. opw-3645355
This fix updates the Intrastat reporting system to comply with post-Brexit regulations requiring the use of XU (United Kingdom) and XI (Northern Ireland) country codes instead of the outdated GB code. Since 2024, government authorities no longer accept GB codes, causing reports to be rejected. The update adds Northern Ireland as a selectable country of origin and automatically converts GB codes to XU in exported reports.
Original PR description
Steps to reproduce: - Install account_intrastat - Install a localization that should declare intrastat report (e.g. l10n_be) - Switch to a Belgian company - Create a product with the country of…
Steps to reproduce: - Install account_intrastat - Install a localization that should declare intrastat report (e.g. l10n_be) - Switch to a Belgian company - Create a product with the country of origin set to United Kingdom - Create an invoice with that product and set Intrastat country to any country except United Kingdom - Confirm the invoice - Go to "Accounting / Reporting / Audit Reports / Intrastat Report" - Filter on the period of the invoice - Export in XML Issue: The country code for United Kingdom in the report is GB. However, since Brexit, 2 different codes should be used for United Kingdom (XU) and Northen Ireland (XI). Since 2024, GB is not accepted anymore by the government and the intrastat report is rejected if XU/XI are not used instead. Solution: This fix adds Northern Ireland as a country, to be able to select it as a country of origin of a product. In the intrastat report, if the country code is GB, it will be changed to XU. opw-3669871 Forward-Port-Of: odoo/enterprise#54558 Forward-Port-Of: odoo/enterprise#54176
This update includes several important fixes and improvements across Odoo's accounting, manufacturing, stock, and web modules. Key improvements include fixing currency rate calculations in spreadsheets, resolving manufacturing order issues when adding components, significantly improving performance for large inventory lots (up to 100x faster in some cases), and enhancing user feedback when bulk operations fail. These changes address critical operational issues that were impacting user workflows and system performance.
Original PR description
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
This fix improves the checkout page loading speed by preventing unnecessary API calls to shipping carriers during page rendering. The system now only calculates rates upfront for simple rule-based carriers, while other carriers that depend on external APIs will calculate rates only when needed. This resolves significant performance slowdowns that customers experienced on the payment page.
Original PR description
Following a fix in 16.3 with 5052b9e4a15155c694cf005fdf330997770c6cac, backported in 16.0+ with commit d28a8f67da06e58358b40636d1dca1f91a84e1ad, the rates for the different carriers were computed on page loading, to make sure unavailable carriers were hidden. Nevertheless, this leads to significant increases of /shop/payment page loading time depending on the enabled carriers. This commit restricts the previous fix to the targeted type of carriers, aka `base_on_rule` ones, whose rates do not depend on third party API requests. Forward-Port-Of: odoo/odoo#149602 Forward-Port-Of: odoo/odoo#149363