Monday, February 24, 2025
16 changes · master
Enhancements to existing features
Required author information was added to many app manifest files so the modules meet the latest packaging requirements. This is an internal metadata update that supports consistency and compliance without changing user-facing functionality.
Original PR description
The author field was made required by the previous commit, this commit add the missing field in all manifests. The upgrade-code script `18.2-01-manifest-author.py` was used. See related community branch (same commit title). task-4485983
Miscellaneous changes
…eneral info The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 X-original-commit: 68f6c1f9fd3ff6762c98e1a405ade035129efce0 Forward-Port-Of: odoo/enterprise#80008
Original PR description
…eneral info The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 X-original-commit: 68f6c1f9fd3ff6762c98e1a405ade035129efce0 Forward-Port-Of: odoo/enterprise#80008
Instead of sending a confusing customer statement that includes invoices from the last period regardless of their status. Adding a new Partner ledger variant that will be sent as a follow-up report that provides the current year's customer statement including only customer invoices with separating Due and OverDue invoices. task-4454196 Forward-Port-Of: odoo/enterprise#79961 Forward-Port-Of: odoo/enterprise#78534
Original PR description
Instead of sending a confusing customer statement that includes invoices from the last period regardless of their status. Adding a new Partner ledger variant that will be sent as a follow-up report that provides the current year's customer statement including only customer invoices with separating Due and OverDue invoices. task-4454196 Forward-Port-Of: odoo/enterprise#79961 Forward-Port-Of: odoo/enterprise#78534
### Steps to reproduce: - Install 'l10n_ch' and switch to a Swiss company - Go in Payroll app - Create a contract, go to its payslip - Click on "Create Payment Report" - Select SEPA as Report Format - The generated XML uses pain.001.001.09 but should use pain.001.001.03.ch.02 ### Cause: pain.001.001.03.ch.02 became a payment_method since this [commit](https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e). But in the payroll app there is only the option to
Original PR description
### Steps to reproduce: - Install 'l10n_ch' and switch to a Swiss company - Go in Payroll app - Create a contract, go to its payslip - Click on "Create Payment Report" - Select SEPA as Report Format - The generated XML uses pain.001.001.09 but should use pain.001.001.03.ch.02 ### Cause: pain.001.001.03.ch.02 became a payment_method since this [commit](https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e). But in the payroll app there is only the option to choose SEPA and by doing this it uses the 'sepa_ct' payment method: https://github.com/odoo/enterprise/blob/033b3f7773e0dd41cb1dfcc5542d19b22f5fe609/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L26 ### Solution: Add a new value to choose from other than SEPA for the Report Format and make this format use the payment method iso20022_ch. opw-4437968 Forward-Port-Of: odoo/enterprise#79971 Forward-Port-Of: odoo/enterprise#79858
### Before this commit: When clicking on any budget, even if there was only one budget line, the list view opened with all budget.line records, regardless of the associated budget. ### After this commit: - When there are one or multiple budget line records in a budget, the form view of that budget will be opened. **task-4195738** Forward-Port-Of: odoo/enterprise#79928 Forward-Port-Of: odoo/enterprise#73799
Original PR description
### Before this commit: When clicking on any budget, even if there was only one budget line, the list view opened with all budget.line records, regardless of the associated budget. ### After this commit: - When there are one or multiple budget line records in a budget, the form view of that budget will be opened. **task-4195738** Forward-Port-Of: odoo/enterprise#79928 Forward-Port-Of: odoo/enterprise#73799
Community: https://github.com/odoo/odoo/pull/198562 Design Themes: https://github.com/odoo/design-themes/pull/1049 Forward-Port-Of: odoo/enterprise#79833
Original PR description
Community: https://github.com/odoo/odoo/pull/198562 Design Themes: https://github.com/odoo/design-themes/pull/1049 Forward-Port-Of: odoo/enterprise#79833
This commit's purpose is to fix some runbot issue with the the timesheet header js test in the list & kanban view Forward-Port-Of: odoo/enterprise#79935
Original PR description
This commit's purpose is to fix some runbot issue with the the timesheet header js test in the list & kanban view Forward-Port-Of: odoo/enterprise#79935
This commit ensures that the transaction_details field in account.bank.statement.line.transient is not sanitized when importing missing transactions. Before this commit: - `transaction_details` was stored in an HTML field, which attempted to sanitize the data. - A recent change in Odoo Fin modified the data format from a stringified JSON to a dictionary. - As a result, the HTML field could not sanitize the dictionary and returned an error: "Unknown error when sanitizing". Fix: - Preven
Original PR description
This commit ensures that the transaction_details field in account.bank.statement.line.transient is not sanitized when importing missing transactions. Before this commit: - `transaction_details` was stored in an HTML field, which attempted to sanitize the data. - A recent change in Odoo Fin modified the data format from a stringified JSON to a dictionary. - As a result, the HTML field could not sanitize the dictionary and returned an error: "Unknown error when sanitizing". Fix: - Prevent sanitization of `transaction_details` by setting `sanitize=False`. - Convert the value on the fly from an html element to a json by using `html2plaintext` and `json` library. opw-4589740 Forward-Port-Of: odoo/enterprise#79955
Before this commit, after using the split tool new documents are created and should be automatically selected but aren't. This commit fix this issue. Task-4555273 Forward-Port-Of: odoo/enterprise#79962 Forward-Port-Of: odoo/enterprise#78692
Original PR description
Before this commit, after using the split tool new documents are created and should be automatically selected but aren't. This commit fix this issue. Task-4555273 Forward-Port-Of: odoo/enterprise#79962 Forward-Port-Of: odoo/enterprise#78692
These fields shouldn't have a namespace. Removing them indeed makes the validation with the xsd succeed. We also clean the xml, by removing whitespaces. Forward-Port-Of: odoo/enterprise#79347 Forward-Port-Of: odoo/enterprise#79200
Original PR description
These fields shouldn't have a namespace. Removing them indeed makes the validation with the xsd succeed. We also clean the xml, by removing whitespaces. Forward-Port-Of: odoo/enterprise#79347 Forward-Port-Of: odoo/enterprise#79200
Before this commit, If you have multiple signatures/initials on the page and you sign on the first signature and want to sign for other sign fields as well, it's not possible due to the "sign all" button's disability (if no change is made in the sign wizard). After this commit, The sign-all button is enabled, even if there is no change is made in the sign wizard. task-4466854 Forward-Port-Of: odoo/enterprise#77120
Original PR description
Before this commit, If you have multiple signatures/initials on the page and you sign on the first signature and want to sign for other sign fields as well, it's not possible due to the "sign all" button's disability (if no change is made in the sign wizard). After this commit, The sign-all button is enabled, even if there is no change is made in the sign wizard. task-4466854 Forward-Port-Of: odoo/enterprise#77120
\* = appointment, website_helpdesk_livechat Enterprise counter-part. https://github.com/odoo/odoo/pull/198681
Original PR description
\* = appointment, website_helpdesk_livechat Enterprise counter-part. https://github.com/odoo/odoo/pull/198681
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2. Switch company settings from YourCompany to BR Company. 3. Navigate to Products > Sales Tab. 4. Fiscal information fields appear under the "Ecommerce Shop" group. Expected Behavior: BR fiscal product fields should be displayed inside a specific
Original PR description
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting,…
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2. Switch company settings from YourCompany to BR Company. 3. Navigate to Products > Sales Tab. 4. Fiscal information fields appear under the "Ecommerce Shop" group. Expected Behavior: BR fiscal product fields should be displayed inside a specific section inside the accounting group. Actual Behavior: BR fiscal product fields are incorrectly placed in the Ecommerce Shop group. **Root Cause** The issue occurs because the code mistakenly modifies the Extra Info group, adds eCommerce-related fields inside it, and then renames it to Ecommerce Shop. This causes the Extra Info group to disappear, leading to fiscal information being displayed incorrectly. **Fix** To avoid modifying a module unrelated to Brazilian taxes, which might have a broader impact, the existing behaviour is left unchanged. Instead, a new section has been added within the accounting tab to display the necessary information. This ensures that only the l10n_br_avatax module is modified. Opw-4533760 Forward-Port-Of: odoo/enterprise#79245
Core logic of addresses management is now moved to portal, where portal users are now able to edit their addresses. Most ecommerce localizations logic can be moved to their base module to be handled both in portal and ecommerce. Also, now that mosts ecommerce localizations modules are 'useless', their tests are moved to a specific test module dedicated to ecommerce localizations. task-3628329 Backport of: https://github.com/odoo/enterprise/pull/75472 Forward-Port-Of: odoo/ente
Original PR description
Core logic of addresses management is now moved to portal, where portal users are now able to edit their addresses. Most ecommerce localizations logic can be moved to their base module to be handled both in portal and ecommerce. Also, now that mosts ecommerce localizations modules are 'useless', their tests are moved to a specific test module dedicated to ecommerce localizations. task-3628329 Backport of: https://github.com/odoo/enterprise/pull/75472 Forward-Port-Of: odoo/enterprise#79782
Steps to reproduce: - Let's consider an helpdesk team HT - Let's consider a working calendar WC with flexible hours and no working hours - Set an SLA policy on HT and set WC as SLA schedule - Create a ticket in HT Bug: A traceback was raised because the function plan_hours was called in _compute_deadline with no deadline Expected behavior: With WC in flexible hours, a deadline is computed according to the SLA policies With WC not in flexible hours and not working hours, no dead
Original PR description
Steps to reproduce: - Let's consider an helpdesk team HT - Let's consider a working calendar WC with flexible hours and no working hours - Set an SLA policy on HT and set WC as SLA schedule - Create a ticket in HT Bug: A traceback was raised because the function plan_hours was called in _compute_deadline with no deadline Expected behavior: With WC in flexible hours, a deadline is computed according to the SLA policies With WC not in flexible hours and not working hours, no deadline is computed (bad configuration) opw:4563223 Forward-Port-Of: odoo/enterprise#79674
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815
Original PR description
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815