Tuesday, March 25, 2025
16 changes · saas-17.4
Resolved issues and error corrections
The Twitter integration setting now uses a more specific label to avoid a naming conflict with another integration setting. This prevents unnecessary system warnings during module loading without changing user workflows.
Original PR description
The field `res.config.settings.twitter_api_key` has the same label `API Key` as the field `res.config.settings.employment_hero_api_key` from module `employment_hero`, which takes it from its related…
The field `res.config.settings.twitter_api_key` has the same label `API Key` as the field `res.config.settings.employment_hero_api_key` from module `employment_hero`, which takes it from its related field `res.company.employment_hero_api_key`[[1]](https://github.com/odoo/enterprise/blob/365fbed2db68626bc175aed4a349c09d872cc717/l10n_employment_hero/models/res_company.py#L19C5-L19C28)[[2]](https://github.com/odoo/enterprise/blob/365fbed2db68626bc175aed4a349c09d872cc717/l10n_employment_hero/models/res_config_settings.py#L9). Having multiple fields on the same model with the same label generates [warnings](https://github.com/odoo/odoo/blob/1ca879612fe546108fd1067839924ae8c25b2bb9/odoo/addons/base/models/ir_model.py#L1193-L1196) when loading the module. The [view](https://github.com/odoo/odoo/blob/ef3aac00ce7737498589a3df68be47c7a3b45d24/addons/website_twitter/views/res_config_settings_views.xml#L12-L16) using the twitter_api_key field already sets the same label. The module is removed in 18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices from the list view does not raise the same error, yet it should. To replicate: 1. [Activate](https://www.odoo.com/documentation/18.0/applications/finance/accounting/reporting/analytic_accounting.html) Analytic accounting: a. Install `accountant` b. In Settings, activate Analytic Accounting
Original PR description
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices…
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices from the list view does not raise the same error, yet it should. To replicate: 1. [Activate](https://www.odoo.com/documentation/18.0/applications/finance/accounting/reporting/analytic_accounting.html) Analytic accounting: a. Install `accountant` b. In Settings, activate Analytic Accounting c. Create an Analytic plan (with an Analytic account associated) 2. Set its default applicability to mandatory 3. Create two invoices, remove the analytic distribution from one of the lines in one invoice. 4. In the invoices list view, select both newly created invoices, click on Actions > Confirm Entries 5. Click Confirm 6. The invoices were posted, even though they have no analytic distributions. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4603919) opw-4603919 Forward-Port-Of: odoo/odoo#203006 Forward-Port-Of: odoo/odoo#201560
Before this commit: When sample data was visible in the view, the pager was also displayed, showing a record count, which could be misleading. After this commit: Now, when sample data is visible, the pager is hidden. Task-4489033 Forward-Port-Of: odoo/odoo#203105 Forward-Port-Of: odoo/odoo#200624
Original PR description
Before this commit: When sample data was visible in the view, the pager was also displayed, showing a record count, which could be misleading. After this commit: Now, when sample data is visible, the pager is hidden. Task-4489033 Forward-Port-Of: odoo/odoo#203105 Forward-Port-Of: odoo/odoo#200624
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt
Original PR description
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded…
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt it if "PyCryptodome" library is installed. Otherwise, it will raise a "DependencyError", which is not handled in the "except" clause. As "PyCryptodome" library is not part of Odoo requirements, we should handle the raised "DependencyError". **Solution:** Try to import "DependencyError" from "PyPDF2.errors" and catch that exception when adding the banner to the PDF. Our own "DependencyError" exception should be created because version 1.26.0 of PyPDF2 doesn't declare "DependencyError" and therefore the import will fail. "NotImplementedError" is used instead in version 1.26.0 and is already handled. opw-4634417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203005 Forward-Port-Of: odoo/odoo#202129
Since [1] the widget displayed on a server action form view when it is set up as "Update a o2m field on a record" was not displaying the fields in the proper way. Before: the value field was a text field expecting the user to input the record id by hand. After: the value field is now a many2one selector. [1]: https://github.com/odoo/odoo/commit/0a744accc2aaa965d5353e854317895d822ad954 Forward-Port-Of: odoo/odoo#202930
Original PR description
Since [1] the widget displayed on a server action form view when it is set up as "Update a o2m field on a record" was not displaying the fields in the proper way. Before: the value field was a text field expecting the user to input the record id by hand. After: the value field is now a many2one selector. [1]: https://github.com/odoo/odoo/commit/0a744accc2aaa965d5353e854317895d822ad954 Forward-Port-Of: odoo/odoo#202930
**Problem**: When copying text from the editor that contains `nbsp`, pasting it into a code editor results in invalid characters, causing issues like compilation errors. **Solution**: Replace `nbsp` with normal spaces when copying text. **Steps to Reproduce**: 1. Add text: `"a b"` (with double spaces). 2. Copy the text. 3. Paste it into a **code editor**. - **Issue**: The invisible `nbsp` causes compilation errors. **opw-4645678** --- I confirm I have signed the CLA and re
Original PR description
**Problem**: When copying text from the editor that contains `nbsp`, pasting it into a code editor results in invalid characters, causing issues like compilation errors. **Solution**: Replace `nbsp` with normal spaces when copying text. **Steps to Reproduce**: 1. Add text: `"a b"` (with double spaces). 2. Copy the text. 3. Paste it into a **code editor**. - **Issue**: The invisible `nbsp` causes compilation errors. **opw-4645678** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202904
Estonia updated their tax report scheme to KMD5, mandatory from 01/01/2025 More info: https://www.emta.ee/en/business-client/taxes-and-payment/value-added-tax#from-01012025 https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#tsd https://www.emta.ee/sites/default/files/documents/2025-02/vorm_kmd_2025_eng.pdf Backport of e2d795e9b15b1c522fe60e1cf38041e16ac73743 opw-4587040 opw-4610009 Forward-Port-Of: odoo/odoo#203073 For
Original PR description
Estonia updated their tax report scheme to KMD5, mandatory from 01/01/2025 More info: https://www.emta.ee/en/business-client/taxes-and-payment/value-added-tax#from-01012025 https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#tsd https://www.emta.ee/sites/default/files/documents/2025-02/vorm_kmd_2025_eng.pdf Backport of e2d795e9b15b1c522fe60e1cf38041e16ac73743 opw-4587040 opw-4610009 Forward-Port-Of: odoo/odoo#203073 Forward-Port-Of: odoo/odoo#202753
Upgrade scripts are run only when there is an update of the module version. This is not flexible enough. After a major upgrade developers need to upgrade their custom modules. Unfortunately the tools in `upgrade-util` repo that modify modules (`merge_module`, `rename_module`, ...) should be done before loading base module. The latter is already upgraded after a major upgrade thus no upgrade scripts are run for it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
Upgrade scripts are run only when there is an update of the module version. This is not flexible enough. After a major upgrade developers need to upgrade their custom modules. Unfortunately the tools in `upgrade-util` repo that modify modules (`merge_module`, `rename_module`, ...) should be done before loading base module. The latter is already upgraded after a major upgrade thus no upgrade scripts are run for it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202583 Forward-Port-Of: odoo/odoo#202014
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations.
Original PR description
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations. All tokens, > including those that look like SassScript, are passed through to CSS > as-is. The only exception is interpolation, which is the only way to > inject dynamic values into a custom property. Reference: https://sass-lang.com/documentation/style-rules/declarations/#custom-properties Forward-Port-Of: odoo/odoo#203134
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were p
Original PR description
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were provided from FedEx support. opw-4461150 Forward-Port-Of: odoo/enterprise#81977 Forward-Port-Of: odoo/enterprise#79617
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations.
Original PR description
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations. All tokens, > including those that look like SassScript, are passed through to CSS > as-is. The only exception is interpolation, which is the only way to > inject dynamic values into a custom property. Reference: https://sass-lang.com/documentation/style-rules/declarations/#custom-properties Forward-Port-Of: odoo/enterprise#82012
Estonia updated their tax report scheme to KMD5, mandatory from 01/01/2025 More info: https://www.emta.ee/en/business-client/taxes-and-payment/value-added-tax#from-01012025 https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#tsd https://www.emta.ee/sites/default/files/documents/2025-02/vorm_kmd_2025_eng.pdf Backport of dde492541aa253771f905d0a77650aa35fea0e8c opw-4587040 opw-4610009 Forward-Port-Of: odoo/enterprise#8198
Original PR description
Estonia updated their tax report scheme to KMD5, mandatory from 01/01/2025 More info: https://www.emta.ee/en/business-client/taxes-and-payment/value-added-tax#from-01012025 https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#tsd https://www.emta.ee/sites/default/files/documents/2025-02/vorm_kmd_2025_eng.pdf Backport of dde492541aa253771f905d0a77650aa35fea0e8c opw-4587040 opw-4610009 Forward-Port-Of: odoo/enterprise#81985 Forward-Port-Of: odoo/enterprise#81863
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to reproduce ================ 1. Create two products with a barcode; 2. Open the Barcode app and create an operation; 3. Scan a product then click on the edit button to open the form view; 4. Update the product quantity field; 5. While still in the form view, scan another barcode -> You can s
Original PR description
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to…
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to reproduce ================ 1. Create two products with a barcode; 2. Open the Barcode app and create an operation; 3. Scan a product then click on the edit button to open the form view; 4. Update the product quantity field; 5. While still in the form view, scan another barcode -> You can see the quantity was reset; 6. Update again the quantity and save; 7. Try to exit the operation -> Bim badaboum, traceback 💥! Cause of the issue ================== When a barcode is scanned, the app doesn't check where is the current state and process the barcode anyway which lead to strange behavior and inconsistencies between the current lines and the lines to save. Solution ======== Disable the scan while somewhere else that in the barcode line view. Miscellaneous ============= Remove an old forgotten `console.warn` 😬 [OPW-4567723](https://www.odoo.com/odoo/project/49/tasks/4567723) Forward-Port-Of: odoo/enterprise#81512
Steps to reproduce the bug: - Install l10n_es_real_estate module - Create a customer invoice on the accounting app - Invoice's AEAT data should be real estate type for mod347 doc - Generate the BOE of tax report document of mod 347 Traceback is thrown while generating the boe of the mod347 document, the traceback is for an issue related to the param of the operation key and that was because the function _call_on_partner_sublines is run for each real estate invoice and it has a callback
Original PR description
Steps to reproduce the bug: - Install l10n_es_real_estate module - Create a customer invoice on the accounting app - Invoice's AEAT data should be real estate type for mod347 doc - Generate the BOE of tax report document of mod 347 Traceback is thrown while generating the boe of the mod347 document, the traceback is for an issue related to the param of the operation key and that was because the function _call_on_partner_sublines is run for each real estate invoice and it has a callback to be executed on each of them. The callback function is _write_type2_partner_record which should have the report option as param, but it wasn't sent that made a traceback for the params. After fixing that, another traceback was thrown because the xmlid of the real estate invoices of both sold and bought are not in the invoice types map of _write_type2_partner_record function. opw-4589314 Forward-Port-Of: odoo/enterprise#81948 Forward-Port-Of: odoo/enterprise#81033
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#81943
Original PR description
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#81943
As defined in https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/form/form_controller.js#L322 A record save in Form Controllers can be prevented when `onWillSaveRecord` returns `false`. But since the override in `HelpdeskTeamController` did not consider `super`, it would always break such a flow. Forward-Port-Of: odoo/enterprise#81769
Original PR description
As defined in https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/form/form_controller.js#L322 A record save in Form Controllers can be prevented when `onWillSaveRecord` returns `false`. But since the override in `HelpdeskTeamController` did not consider `super`, it would always break such a flow. Forward-Port-Of: odoo/enterprise#81769