Thursday, March 20, 2025
15 changes · saas-17.4
Enhancements to existing features
Spreadsheet sheets created from pivot or list data sources now clean up unsupported characters in their names before creation. This prevents errors or compatibility issues when source names include characters that spreadsheet tools do not allow.
Original PR description
Some datasource functionalities (i.e. insert PIVOT and LIST) create a new sheet based on the source name. Unfortunately, sheet names cannot contain some predefined characters (mostly for excel compatibility purpose). This revision adds a sanitization of the source name before creating the sheet. task-4347719
Resolved issues and error corrections
Vendor bills created from forwarded emails by employees without system user accounts will no longer incorrectly list that employee as the vendor. This keeps vendor bill records cleaner and avoids confusion when an employee is only forwarding a supplier document on behalf of the company.
Original PR description
The aim of this commit is to allow non-users employee to be considered as "forwarding" vendor bills instead of sending it in their name, as the vendor would be the company anyway Steps to reproduce: - Create a fresh db with the mailing aliases setup and employee and account apps installed - Choose a demo data employee that has no user and set the parent_id as the db company. - Make sure the company doesn't have an email set. - Send an email from that employee work_email to the email alias of the Vendor Bills journal. Problem, the created bill has the employee set as the vendor. Expected behavior is that no vendor is set. opw-4516730 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
Miscellaneous changes
Mercado Pago requires the X-platform-id header to be passed in all requests to their platform to keep track of the amount of odoo customers that exist. This key is not secret and perfectly fine to be committed in this repo without worry. task-4628319 Forward-Port-Of: odoo/odoo#200864
Original PR description
Mercado Pago requires the X-platform-id header to be passed in all requests to their platform to keep track of the amount of odoo customers that exist. This key is not secret and perfectly fine to be committed in this repo without worry. task-4628319 Forward-Port-Of: odoo/odoo#200864
This fix stops Odoo from creating an extra sales order line when a transit location is only an intermediate step before delivery to the customer. It helps keep sales orders accurate for delivery routes that pass through transit locations.
Original PR description
Commit 0bdfda2af4d70a6c33773ecd4aaa717ef6a17d62 introduced a new behavior where delivery transfer to transit locations (inter companies transfer) could create a new Sale Order Line if necessary. However, we do not want this behavior if the transit location is just a step in the delivery to the Customer location.
Hence, if there are any destination moves, we do not create a new sale order line.
OPW-4643937
---
Test result without fix:
```
2025-03-19 16:08:42,057 57047 ERROR oes_test_17.4 odoo.addons.sale_stock.tests.test_sale_stock: FAIL: TestSaleStock.test_custom_delivery_route_new_sale_line
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/saas-17.4/odoo/addons/sale_stock/tests/test_sale_stock.py", line 2197, in test_custom_delivery_route_new_sale_line
self.assertEqual(len(sale_order.order_line), 1)
AssertionError: 2 != 1
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Planning app now shows the "I Take It" button consistently across different schedule views. This reduces confusion for employees trying to claim available shifts and makes the workflow more predictable.
Original PR description
Before this commit: The "I Take It" button visibility was inconsistent across different view because different conditions were used to determine its visibility in each view. After this commit: This commit enhance the visibility of the "I Take It" button now it has consistent visibility across the views by follow same condition for every view. task-4455488
Description of the issue/feature this PR addresses: This commit addresses inaccurate calculation of statistics in surveys. The survey fields `answer_score_avg` and `success_ratio` are affected. Current behavior before PR: These are currently using the number of completed surveys as the total number of surveys, but they are gathering data from all surveys, completed or not. This results in broken statistics when there are in progress or incomplete surveys. The values become too high, in
Original PR description
Description of the issue/feature this PR addresses: This commit addresses inaccurate calculation of statistics in surveys. The survey fields `answer_score_avg` and `success_ratio` are affected. Current behavior before PR: These are currently using the number of completed surveys as the total number of surveys, but they are gathering data from all surveys, completed or not. This results in broken statistics when there are in progress or incomplete surveys. The values become too high, including `success_ratio` being above 100%! Desired behavior after PR is merged: The proposed solution is simply to consider all answers to the survey so that the statistics can accurately reflect the scores across all initiated surveys. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197849
In #195395, the following test suite should first check if the global_result is already stopped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201800
Original PR description
In #195395, the following test suite should first check if the global_result is already stopped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201800
[FIX] account: default_account_id removal from context when reversing analytic distribution When accessing journal items from a report, the context often includes default_account_id. When changing the account of a journal item, new analytic items are created, inheriting an account_id field. If account_id is False, it is automatically populated from default_account_id, which is sourced from account.account instead of account.analytic.account. This mismatch leads to the error: ```The operatio
Original PR description
[FIX] account: default_account_id removal from context when reversing analytic distribution When accessing journal items from a report, the context often includes default_account_id. When changing the account of a journal item, new analytic items are created, inheriting an account_id field. If account_id is False, it is automatically populated from default_account_id, which is sourced from account.account instead of account.analytic.account. This mismatch leads to the error: ```The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.``` This fix moves when we remove the default_account_id from context to ensure it is removed despite the call stack not including the function _inverse_analytic_distribution opw-4443816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200200
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + fre
Original PR description
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + french translation added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174647 Forward-Port-Of: odoo/odoo#174511
The system automatically fill the Bank Account info on invoices, however this does not work as expected when the move type is changed after creation Steps to reproduce: - Create an invoice, set partner with bank account defined - Switch to credit note - Check 'Other info' tab Issue: Bank Partner will be left blank, but it should be the partner bank account opw-4640629 Forward-Port-Of: odoo/odoo#202369
Original PR description
The system automatically fill the Bank Account info on invoices, however this does not work as expected when the move type is changed after creation Steps to reproduce: - Create an invoice, set partner with bank account defined - Switch to credit note - Check 'Other info' tab Issue: Bank Partner will be left blank, but it should be the partner bank account opw-4640629 Forward-Port-Of: odoo/odoo#202369
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 Forward-Port-Of: odoo/odoo#202322 Forward-Port-Of: odoo/odoo#201780
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 Forward-Port-Of: odoo/odoo#202322 Forward-Port-Of: odoo/odoo#201780
Before this change, sometimes round(i, 2) != float_round(i, 2), which leads a bad float representation visible in the url. This happens on many such values like 6.14. opw-4601734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202209
Original PR description
Before this change, sometimes round(i, 2) != float_round(i, 2), which leads a bad float representation visible in the url. This happens on many such values like 6.14. opw-4601734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202209
Forward-Port-Of: odoo/enterprise#81688 Forward-Port-Of: odoo/enterprise#81465
Original PR description
Forward-Port-Of: odoo/enterprise#81688 Forward-Port-Of: odoo/enterprise#81465
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Po
Original PR description
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Port-Of: odoo/enterprise#80760
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at least two times the same product's barcode; - Validate. - Re-open the same receipt and click on "Return Products"; - Scan one product then validate -> The return is correctly validated but an "Invalid Operation" error is raised. Cause of the issue ================== The return's move is d
Original PR description
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at…
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at least two times the same product's barcode; - Validate. - Re-open the same receipt and click on "Return Products"; - Scan one product then validate -> The return is correctly validated but an "Invalid Operation" error is raised. Cause of the issue ================== The return's move is done but `_split` is called and calling this method on a done move is forbidden. How to fix ========== In the `split_uncompleted_moves` move's method, done and cancel move are skipped. Also, the JS method who call `post_barcode_process` will now doesn't call it if operation is done or cancelled or if there is no moves (to avoid to do useless RPC.) [OPW-4535205](https://www.odoo.com/odoo/project/49/tasks/4535205) [OPW-4535257](https://www.odoo.com/odoo/project/49/tasks/4535257) Forward-Port-Of: odoo/enterprise#81312