Tuesday, July 23, 2024
18 changes · saas-17.2
Enhancements to existing features
The invoice extraction module’s automated tests were migrated from an older testing framework to the newer HOOT framework. This is an internal quality improvement that helps keep the module maintainable and aligned with current testing standards, with no expected change for end users.
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666
The sales timesheet test suite has been updated from an older testing approach to the newer HOOT framework. This improves long-term maintainability and reliability of internal quality checks without changing customer-facing behavior.
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666
Miscellaneous changes
Steps: - Install l10n_nl_reports - Open GL for the year 2024 - Export XAF -> Period numbers are displayed from 401 to 412, instead of 01 to 12 in the exported file opw-3999985 Forward-Port-Of: odoo/enterprise#67127 Forward-Port-Of: odoo/enterprise#67098
Original PR description
Steps: - Install l10n_nl_reports - Open GL for the year 2024 - Export XAF -> Period numbers are displayed from 401 to 412, instead of 01 to 12 in the exported file opw-3999985 Forward-Port-Of: odoo/enterprise#67127 Forward-Port-Of: odoo/enterprise#67098
Moved iot.box view technical information to "Technical Information" tab. Task: 4033301 Forward-Port-Of: odoo/enterprise#66306
Original PR description
Moved iot.box view technical information to "Technical Information" tab. Task: 4033301 Forward-Port-Of: odoo/enterprise#66306
Only a few templates are fetched when the user tries to sync all the templates from the `WhatsApp Business Account` form view. Problem: The API request used to fetch all templates incorporates pagination. In the current scenario, the next URL to the subsequent page is included in the response, but we are not using it. Also, the limit parameter is not utilized in our API request to restrict the number of templates on a single page. Consequently, by default, 25 templates are received on the
Original PR description
Only a few templates are fetched when the user tries to sync all the templates from the `WhatsApp Business Account` form view. Problem: The API request used to fetch all templates incorporates pagination. In the current scenario, the next URL to the subsequent page is included in the response, but we are not using it. Also, the limit parameter is not utilized in our API request to restrict the number of templates on a single page. Consequently, by default, 25 templates are received on the first page. As a result, only templates received on the first page are being created or updated(i.e. 25). Solution: The limit to fetch 200 templates on a single page is added to obtain 200 templates in the first request. However, if there are more than 200 templates, the remaining ones will be fetched from the next page. This process will continue in a loop until all templates are received. Task-3903321 Forward-Port-Of: odoo/enterprise#62460
…ights The setup of the password from a related field would throw errors to user with accountant rights but no administration (settings) rights. This showed other access rights problems with the SBR implementation. The way we want to work with this is: an accountant without settings rights can set up the password through the wizard if no password is stored on the company (for databases that didn't start SBR with the status info module). Once the password is set and is correct (it is the ri
Original PR description
…ights The setup of the password from a related field would throw errors to user with accountant rights but no administration (settings) rights. This showed other access rights problems with the SBR implementation. The way we want to work with this is: an accountant without settings rights can set up the password through the wizard if no password is stored on the company (for databases that didn't start SBR with the status info module). Once the password is set and is correct (it is the right one for the certificate), it shouldn't ask the user to put it again and is thus hidden in the wizard. ticket-4024344 Forward-Port-Of: odoo/enterprise#66096
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add shipping, and select sendcloud. - Add 'Total order weight'(e.g 0.5kg) - Click 'Get rate' Returned rate for shipping is unusually big ammout. Before this commit: For sendcloud shipping if sendcloud_default_package_type_id is set, max_weight is stored in kilograms. When checking if the pack
Original PR description
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add…
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add shipping, and select sendcloud. - Add 'Total order weight'(e.g 0.5kg) - Click 'Get rate' Returned rate for shipping is unusually big ammout. Before this commit: For sendcloud shipping if sendcloud_default_package_type_id is set, max_weight is stored in kilograms. When checking if the package needs to be splitted, the target_weight is not being converted whereas the total_weight is.(check link at the bottom for details) Also in shipping rate request for sendcloud `max_weight` was sent in kilograms with `unit` being 'gram'. After this commit: `max_weight` is converted into grams before adding to the shipping rate request. split shipping code: https://github.com/odoo/enterprise/blob/d3b39fe78bc0ae366d32e80e325e89d2a4bb353c/delivery_sendcloud/models/sendcloud_service.py#L160-L162 opw-4035569 Forward-Port-Of: odoo/enterprise#66594
Update Cla for Openforce --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168681
Original PR description
Update Cla for Openforce --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168681
The adaptation for 3.12 broke some of the 3.11 packages compatibility This commit should fix them. See #173788 for more info Forward-Port-Of: odoo/odoo#173913
Original PR description
The adaptation for 3.12 broke some of the 3.11 packages compatibility This commit should fix them. See #173788 for more info Forward-Port-Of: odoo/odoo#173913
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as "[analytic.analytic_plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/project/models/res_config_settings.py#L18-L22)" However, the default key was set different "[account.plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507
Original PR description
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as…
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as "[analytic.analytic_plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/project/models/res_config_settings.py#L18-L22)" However, the default key was set different "[account.plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/analytic/data/analytic_data.xml#L13)" - And during the migration from v16.0 to v17.0, the default key generated in v16.0 is [removed](https://github.com/odoo/upgrade/blob/20faf7ba48595c61fc028ba1b4cf278d2c44e3cc/migrations/analytic/saas~16.5.1.1/pre-migrate.py#L10-L18) in saas~16.5 and new key will be set which this only "account.plan_projects" . - Because of the incorrect key value of 'analytic plan'(analytic_plan_id) is null. **Steps to reproduce:** - Install project module. - Go to Setting > Projects > got to Analytics section in that Analytic Plan. - Default analytic plan value is not there. **Solution:** - Set the correct key `analytic.project_plan` for the 'analytic_plan_id' field. **Current behavior in 16.0 :**  **Current behavior in 17.0 before pr:**  **Desired behavior after PR is merged:**  task-3941668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172123
Problem: When attempting to paste text (either via right-click -> paste or using CTRL-V) into the chatter of a shared project, the action fails. This issue was caused by the addition of `event.preventDefault()` in the `ProjectSharingFormController` form. This does not affect the description field as it is also managed by `OdooEditor`. Steps to reproduce: 1. Share a project with a user. 2. Impersonate the user and navigate to the project from the portal. 3. Select a task. 4. Attempt to
Original PR description
Problem: When attempting to paste text (either via right-click -> paste or using CTRL-V) into the chatter of a shared project, the action fails. This issue was caused by the addition of `event.preventDefault()` in the `ProjectSharingFormController` form. This does not affect the description field as it is also managed by `OdooEditor`. Steps to reproduce: 1. Share a project with a user. 2. Impersonate the user and navigate to the project from the portal. 3. Select a task. 4. Attempt to paste something into the chatter. opw-4046529 Forward-Port-Of: odoo/odoo#173329
Steps to reproduce: - Create a kit BOM composed of 40kg of storable product X. - Set cost of X as 10$ - Sell 3 kits in POS - Select customer and create an invoice - in accounting check the the invoice lines - Odoo is calculating the COGS as 3kg instead of 120kg. (30$ instead of 120$) Bug: kit quantities not taken into consideration opw-3962665 Forward-Port-Of: odoo/odoo#171277
Original PR description
Steps to reproduce: - Create a kit BOM composed of 40kg of storable product X. - Set cost of X as 10$ - Sell 3 kits in POS - Select customer and create an invoice - in accounting check the the invoice lines - Odoo is calculating the COGS as 3kg instead of 120kg. (30$ instead of 120$) Bug: kit quantities not taken into consideration opw-3962665 Forward-Port-Of: odoo/odoo#171277
Users without administrative rights were unable to refund transactions because the call to `_send_refund_request` was made without `sudo`. This commit adds both the necessary `sudo` to bypass the access rights check on the transaction's payment acquirer and a manual access rights check on the transaction itself to prevent abusing RPC calls. opw-4033356 Forward-Port-Of: odoo/odoo#173953 Forward-Port-Of: odoo/odoo#173663
Original PR description
Users without administrative rights were unable to refund transactions because the call to `_send_refund_request` was made without `sudo`. This commit adds both the necessary `sudo` to bypass the access rights check on the transaction's payment acquirer and a manual access rights check on the transaction itself to prevent abusing RPC calls. opw-4033356 Forward-Port-Of: odoo/odoo#173953 Forward-Port-Of: odoo/odoo#173663
Currently, if you create a combo product, or modify an existing product into a combo product, the previous tax field is saved. Steps to reproduce: ------------------- * Create a new storable product with a tax set * Modify the product type to `Consumable` * Save > Observation: Next to the price we see "(=... tax incl) Why the fix: ------------ Combo products are not meant to have taxes set. It is confirmed by the fact that the field becomes invisible when we have combo products. Tax
Original PR description
Currently, if you create a combo product, or modify an existing product into a combo product, the previous tax field is saved. Steps to reproduce: ------------------- * Create a new storable product with a tax set * Modify the product type to `Consumable` * Save > Observation: Next to the price we see "(=... tax incl) Why the fix: ------------ Combo products are not meant to have taxes set. It is confirmed by the fact that the field becomes invisible when we have combo products. Taxes are computed once the product is added to the cart depending on the taxes of the products chosen. opw-4004978 Forward-Port-Of: odoo/odoo#172358
EAS codes 0037 and 0215 have been deprecated as of OpenPeppol eDEC codelists v8.9 https://docs.peppol.eu/edelivery/codelists/changelog.html We will place a warning in stable and remove it in master. no task Forward-Port-Of: odoo/odoo#173316
Original PR description
EAS codes 0037 and 0215 have been deprecated as of OpenPeppol eDEC codelists v8.9 https://docs.peppol.eu/edelivery/codelists/changelog.html We will place a warning in stable and remove it in master. no task Forward-Port-Of: odoo/odoo#173316
Steps to reproduce: - Install `l10n_fr_invoice_addr` - Switch to french company - Change "Colors" in "Document Layout" settings - Go to an invoice and click the "Preview" button Because of the inconsistent HTML tags used, the invoice styling wouldn't get applied to the columns added by `l10n_fr_invoice_addr`. This commit improves consistency with the pre-existing HTML hence fixing that issue See: #172497 task-4056046 Forward-Port-Of: odoo/odoo#174071 Forward-Port-Of: odoo/odoo#1732
Original PR description
Steps to reproduce: - Install `l10n_fr_invoice_addr` - Switch to french company - Change "Colors" in "Document Layout" settings - Go to an invoice and click the "Preview" button Because of the inconsistent HTML tags used, the invoice styling wouldn't get applied to the columns added by `l10n_fr_invoice_addr`. This commit improves consistency with the pre-existing HTML hence fixing that issue See: #172497 task-4056046 Forward-Port-Of: odoo/odoo#174071 Forward-Port-Of: odoo/odoo#173299
Steps to reproduce: ------------------- * Activate discount on lines on user parameters * Change the pricelist config to show discount to the customers * Open a PoS session with the modified pricelist * Create an order and apply some discount on the lines * Invoice and pay the order > Observation: On the invoice pdf you should have a line saying "Price discount from X -> X" but it's not there Why the fix: ------------ Before the fix we were comparing the `price_unit` on the line and
Original PR description
Steps to reproduce: ------------------- * Activate discount on lines on user parameters * Change the pricelist config to show discount to the customers * Open a PoS session with the modified pricelist * Create an order and apply some discount on the lines * Invoice and pay the order > Observation: On the invoice pdf you should have a line saying "Price discount from X -> X" but it's not there Why the fix: ------------ Before the fix we were comparing the `price_unit` on the line and the `lst_price` of the product. But if a discount was applied on the line the price unit is not affected, and so the line was never shown. To fix this we compare the `total_price` of the line with the `lst_price` multiplied by the quantity on the line. opw-4019107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173687 Forward-Port-Of: odoo/odoo#172754
Currently, when website snippets were translated and they had special characters in them, they would be escaped before adding them as the `data-name` attribute of the snippet, which escaped them again. When the snippet would be selected, the sidebar would get that `data-name` attribute and use it as the title, resulting in the characters still being escaped. This commit fixes that by not escaping the name beforehand, but only when used in raw HTML. Example of the problem (Mur d'images): !
Original PR description
Currently, when website snippets were translated and they had special characters in them, they would be escaped before adding them as the `data-name` attribute of the snippet, which escaped them again. When the snippet would be selected, the sidebar would get that `data-name` attribute and use it as the title, resulting in the characters still being escaped. This commit fixes that by not escaping the name beforehand, but only when used in raw HTML. Example of the problem (Mur d'images):  Forward-Port-Of: odoo/odoo#174018 Forward-Port-Of: odoo/odoo#173808