Tuesday, July 2, 2024
24 changes · saas-17.2
Resolved issues and error corrections
Users can now insert list or pivot view links into spreadsheets without triggering an error. The fix ensures the action has the needed background information, making the spreadsheet insertion flow more reliable.
Original PR description
## Description: Clicking the "Insert in Spreadsheet" button within the pivot view previously failed to pass the necessary context, leading to a traceback. This PR resolves the problem by ensuring the context is properly passed to the action. Task ID: [3880304](https://www.odoo.com/web#id=3880304&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Fixes an issue where spreadsheet links to list or pivot views could fail because required context was not passed along. Users can now open these linked views from spreadsheets without encountering errors.
Original PR description
## Description: navigateTo helper function in helpers.js was not passing the context to the action. This commit resolves the problem by ensuring the context is properly passed to the action. task-3880304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The Project app's automated tests were converted to a newer testing approach and shared chart-checking utilities were moved into a reusable location. This is an internal quality improvement that helps developers maintain project features more reliably without changing day-to-day user behavior.
Miscellaneous changes
Removed dependency on demo data for the TestInvoiceExtractPurchase tests, as they would previously fail if the demo data had not been loaded. Now the results will be consistent, no matter if the demo data is present. Task-3957718 Forward-Port-Of: odoo/enterprise#65805 Forward-Port-Of: odoo/enterprise#65660
Original PR description
Removed dependency on demo data for the TestInvoiceExtractPurchase tests, as they would previously fail if the demo data had not been loaded. Now the results will be consistent, no matter if the demo data is present. Task-3957718 Forward-Port-Of: odoo/enterprise#65805 Forward-Port-Of: odoo/enterprise#65660
This change updates the internal test setup for Project Todo to use Odoo's newer testing approach. It helps maintain reliability for future changes without altering day-to-day user functionality.
Steps to Reproduce: ------------------- 1. Install hr_contract_salary module, create an advantage. 2. In the advantages 'Display Type' field should be 'Always selected'. 3. Leave the res_field_id field empty. 4. Put this advantage as Mandatory Advantage for another field. 5. Open Recruitement App, create and send an offer. 6. Go to Offers smart button and open the Offer link. 7. There will be an Internal Server Error. To resolve this issue we'll just continue wherever the res
Original PR description
Steps to Reproduce: ------------------- 1. Install hr_contract_salary module, create an advantage. 2. In the advantages 'Display Type' field should be 'Always selected'. 3. Leave the res_field_id…
Steps to Reproduce:
-------------------
1. Install hr_contract_salary module, create an advantage.
2. In the advantages 'Display Type' field should be 'Always selected'.
3. Leave the res_field_id field empty.
4. Put this advantage as Mandatory Advantage for another field.
5. Open Recruitement App, create and send an offer.
6. Go to Offers smart button and open the Offer link.
7. There will be an Internal Server Error.
To resolve this issue we'll just continue wherever the res_field_id is not set. Because
if the res_field_id is not set it'll have no value which in return gives False(bool) which
can't be appended.
Traceback:
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1770, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1797, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1914, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 725, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 231, in salary_package
values = self._get_default_template_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 131, in _get_default_template_values
values = self._get_salary_package_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 411, in _get_salary_package_values
mapped_benefits, mapped_dependent_benefits, mandatory_benefits, mandatory_benefits_names, benefit_types, dropdown_options_2, dropdown_group_options, initial_values_2 = self._get_benefits_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 397, in _get_benefits_values
dependent_name = dependent_benefit.field + '_' + dependent_benefit.display_type
TypeError: unsupported operand type(s) for +: 'bool' and 'str'
```
Forward-Port-Of: odoo/enterprise#62255When a contact is created with an RFC (VAT number) but no country configured, signing an invoice for that contact results in the invoice being signed correctly. However, the PDF shows the partner's RFC, while the XML file shows the generic RFC (XAXX01010101). This discrepancy misleads users into believing their setup is correct, as no error or alert is provided. This commit introduces a non-blocking warning message in the 'Send and Print' wizard for cases where the contact's country is missin
Original PR description
When a contact is created with an RFC (VAT number) but no country configured, signing an invoice for that contact results in the invoice being signed correctly. However, the PDF shows the partner's RFC, while the XML file shows the generic RFC (XAXX01010101). This discrepancy misleads users into believing their setup is correct, as no error or alert is provided. This commit introduces a non-blocking warning message in the 'Send and Print' wizard for cases where the contact's country is missing. opw-3891896 Forward-Port-Of: odoo/enterprise#63255
This commit fixes an issue withthe embedded views inside the columns block in the editor. The embedded views were overlapping the columns on their right meaning that some text could be hidden behind them. To fix this a new rule is added to these blocks so that when they are inside a column block that is not the last one we remove the negative margin-right. This way we preserve their style when inside the right-most column. task-3901864 Forward-Port-Of: odoo/enterprise#63480
Original PR description
This commit fixes an issue withthe embedded views inside the columns block in the editor. The embedded views were overlapping the columns on their right meaning that some text could be hidden behind them. To fix this a new rule is added to these blocks so that when they are inside a column block that is not the last one we remove the negative margin-right. This way we preserve their style when inside the right-most column. task-3901864 Forward-Port-Of: odoo/enterprise#63480
When a document has an attachment, the export done through the general ledger and "Datev + ATCH (zip)" should have a column filled with the guid of the document, which is not the case currently. To solve it, use the helper to get the attachments opw-3984450 Forward-Port-Of: odoo/enterprise#65756
Original PR description
When a document has an attachment, the export done through the general ledger and "Datev + ATCH (zip)" should have a column filled with the guid of the document, which is not the case currently. To solve it, use the helper to get the attachments opw-3984450 Forward-Port-Of: odoo/enterprise#65756
## How to reproduce: 1. Go to Documents > Settings > Change the deletion days of docs. (Optional) 2. Go to Documents > Trash #### Issue - The Deletions Days shown 'undefined'. It says: 'Items in trash will be deleted forever after undefined days.' ## After this commit: Deletions Days will be shown there even after you update them. Task-3984627 Forward-Port-Of: odoo/enterprise#64538
Original PR description
## How to reproduce: 1. Go to Documents > Settings > Change the deletion days of docs. (Optional) 2. Go to Documents > Trash #### Issue - The Deletions Days shown 'undefined'. It says: 'Items in trash will be deleted forever after undefined days.' ## After this commit: Deletions Days will be shown there even after you update them. Task-3984627 Forward-Port-Of: odoo/enterprise#64538
### Steps to reproduce: - Create and mark as to do a delivery order for a partner with a move: - 2 x Product P - Set the quantity of the move to 1 - Create and confirm a batch transfer containing your picking - Validate the batch transfer and create a backorder #### > The picking is removed from the batch ### Cause of the issue: The pickings are removed from the batch by these lines: https://github.com/odoo/odoo/blob/b4872364f9f8926bbf5b843db014f33652124cb9/addons/stock_picking_ba
Original PR description
### Steps to reproduce: - Create and mark as to do a delivery order for a partner with a move: - 2 x Product P - Set the quantity of the move to 1 - Create and confirm a batch transfer containing your picking - Validate the batch transfer and create a backorder #### > The picking is removed from the batch ### Cause of the issue: The pickings are removed from the batch by these lines: https://github.com/odoo/odoo/blob/b4872364f9f8926bbf5b843db014f33652124cb9/addons/stock_picking_batch/models/stock_picking.py#L141-L145 However, they should only be removed if at least one of the pickings is not backordered. opw-4001981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171218
Current behaviour: --- Product name can overflow from the label box Expected behaviour: --- Truncate the name if it's too long Steps to reproduce: --- 1. Go to Inventory > Products > Lots/Serial Numbers 2. Open one Serial Number > open its product 3. Rename product with long name 4. Go back to Lots/Serial Numbers 5. Select the Serial Number with renamed product 6. Click on Print > PDF 7. Barcode is out of the box Cause of the issue: --- Caused by: https://github.com/odoo/o
Original PR description
Current behaviour: --- Product name can overflow from the label box Expected behaviour: --- Truncate the name if it's too long Steps to reproduce: --- 1. Go to Inventory > Products > Lots/Serial Numbers 2. Open one Serial Number > open its product 3. Rename product with long name 4. Go back to Lots/Serial Numbers 5. Select the Serial Number with renamed product 6. Click on Print > PDF 7. Barcode is out of the box Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/a5924bfe11cd9324e2ba056e0ac1d449aed730c8 Fix: --- Reverting: https://github.com/odoo/odoo/commit/a5924bfe11cd9324e2ba056e0ac1d449aed730c8 opw-3819349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169226
## Description Following a1bc13b39559fa82763a9f0b3b603f6026b8a151 the field `One2many: applicant_ids` becomes `Many2one: applicant_id`. The field is used in lookups (ir.rules) and is also the inverse of `hr.applicant.response_ids`, and is present on the model `survey.user_input`, which is a large table, therefor should be indexed. ## Reference task-4011294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170918
Original PR description
## Description Following a1bc13b39559fa82763a9f0b3b603f6026b8a151 the field `One2many: applicant_ids` becomes `Many2one: applicant_id`. The field is used in lookups (ir.rules) and is also the inverse of `hr.applicant.response_ids`, and is present on the model `survey.user_input`, which is a large table, therefor should be indexed. ## Reference task-4011294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170918
**Description of the issue/feature this PR addresses:** The field condition is used but it is not show in any view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169077
Original PR description
**Description of the issue/feature this PR addresses:** The field condition is used but it is not show in any view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169077
Before this PR, the `Channel subscription is renewed when channel is manually added` test was sometimes failing. This test ensures the bus subscription is renewed when the user joins a channel. To do this, the test relies on the `assert.step` API: the channel is added, we wait for a tick, and then we assert that the step was correctly registered. However, a tick is sometimes not enough. This PR replaces the usage of QUnit's tep API with the web one that waits for the step to be triggered,
Original PR description
Before this PR, the `Channel subscription is renewed when channel is manually added` test was sometimes failing. This test ensures the bus subscription is renewed when the user joins a channel. To do this, the test relies on the `assert.step` API: the channel is added, we wait for a tick, and then we assert that the step was correctly registered. However, a tick is sometimes not enough. This PR replaces the usage of QUnit's tep API with the web one that waits for the step to be triggered, which is far more robust. fixes runbot-61018 Forward-Port-Of: odoo/odoo#171401
The `Message shows up even if channel data is incomplete` test sometimes fails. This test ensures that a message received on a partially known channel still appears. To achieve this, the test needs to manually refresh the bus subscription and wait for this subscription to complete before sending a notification on the bus. Sometimes, the notification occurs before `waitUntilSubscribe` is called. Consequently, the `waitForSubscribe` function hangs because the expected subscription for
Original PR description
The `Message shows up even if channel data is incomplete` test sometimes fails. This test ensures that a message received on a partially known channel still appears. To achieve this, the test needs to manually refresh the bus subscription and wait for this subscription to complete before sending a notification on the bus. Sometimes, the notification occurs before `waitUntilSubscribe` is called. Consequently, the `waitForSubscribe` function hangs because the expected subscription for the test has already been completed. This PR resolves this issue. runbot-59270 Forward-Port-Of: odoo/odoo#171404
When you take a time off for which there is no need of validation, you can refuse it, although you don't have any time off rights. This fixes the issue, you have to be either a time off officer or the manager of the one who took the time off. Task: 3981373 Forward-Port-Of: odoo/odoo#170514
Original PR description
When you take a time off for which there is no need of validation, you can refuse it, although you don't have any time off rights. This fixes the issue, you have to be either a time off officer or the manager of the one who took the time off. Task: 3981373 Forward-Port-Of: odoo/odoo#170514
Use of the record.{field}.value was causing the displayed (string) values to be used in the kanban card's t-if logic rather than the actual value of the field. This resulted in - `record.cap_accrued_time.value` ALWAYS being evaluated as True (since "False" is True) - `record.maximum_leave.value > 0` evaluating as True when the language wasn't a language that uses "." as it's decimal separator. e.g. "5.00" > 0 == True but "5,00" > 0 == False opw-3999753 Also, re-export the po
Original PR description
Use of the record.{field}.value was causing the displayed (string) values
to be used in the kanban card's t-if logic rather than the actual value
of the field. This resulted in
- `record.cap_accrued_time.value` ALWAYS being evaluated as True (since
"False" is True)
- `record.maximum_leave.value > 0` evaluating as True when the language
wasn't a language that uses "." as it's decimal separator. e.g.
"5.00" > 0 == True but "5,00" > 0 == False
opw-3999753
Also, re-export the pot file since it was noticed that it's no longer correct.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#171394
Forward-Port-Of: odoo/odoo#170321same as: https://github.com/odoo/odoo/pull/159321 opw-3786308 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170807
Original PR description
same as: https://github.com/odoo/odoo/pull/159321 opw-3786308 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170807
Steps to reproduce the bug: - Create a storable product “P1” with BoM - Operation: OP1, OP2 - OP2 blocked by OP1 - Navigate to Mrp > Configuration > Operations - Select OP1 and select another BoM - Return to the BoM of “P1” Problem: The OP2 is still linked to OP1, And a traceback when attempting to duplicate the BoM. Solution: Remove the link between OP2 and OP1 opw-3948817 Forward-Port-Of: odoo/odoo#171054 Forward-Port-Of: odoo/odoo#169417
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM - Operation: OP1, OP2 - OP2 blocked by OP1 - Navigate to Mrp > Configuration > Operations - Select OP1 and select another BoM - Return to the BoM of “P1” Problem: The OP2 is still linked to OP1, And a traceback when attempting to duplicate the BoM. Solution: Remove the link between OP2 and OP1 opw-3948817 Forward-Port-Of: odoo/odoo#171054 Forward-Port-Of: odoo/odoo#169417
Steps --- * create MO * confirm > produce all * unlock > set produced quantity to 0 * click 'Overview' => Traceback (zero div) Fix --- set overview fields that do not make sense when the final production quantity is 0 to `False`, so they are left blank on the report opw-3958811 Forward-Port-Of: odoo/odoo#168529
Original PR description
Steps --- * create MO * confirm > produce all * unlock > set produced quantity to 0 * click 'Overview' => Traceback (zero div) Fix --- set overview fields that do not make sense when the final production quantity is 0 to `False`, so they are left blank on the report opw-3958811 Forward-Port-Of: odoo/odoo#168529
## Description The `web_read_group` done when loading the "All Applicants" view is slow when having a large quantity of `hr.applicant` ## Analysis The query done by the `web_read_group` will get all the `active` `hr.applicant`, but the field isn't indexed, so even if only a small portion of applicants are active, we are still scanning the whole table to filter out the applicants. ## Solution Index the `active` field. ## Benchmark On a DB with 900k `hr_applicant`, where only 80k are
Original PR description
## Description The `web_read_group` done when loading the "All Applicants" view is slow when having a large quantity of `hr.applicant` ## Analysis The query done by the `web_read_group` will get all the `active` `hr.applicant`, but the field isn't indexed, so even if only a small portion of applicants are active, we are still scanning the whole table to filter out the applicants. ## Solution Index the `active` field. ## Benchmark On a DB with 900k `hr_applicant`, where only 80k are `active`, the main query for the `web_read_group` takes | | Before | After | |---------|--------|-------| | Timings | 320ms | 80ms | ## Reference task-4011294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171000
Since the automation revamp, it is not possible to update read-only fields without executing Python code. This commit removes this limitation as some use-cases are useful: - Automatically update the invoice status of SO when an action is executed. - Force the SO status to "sent" without sending the email. Task: 3983645 Forward-Port-Of: odoo/odoo#170729
Original PR description
Since the automation revamp, it is not possible to update read-only fields without executing Python code. This commit removes this limitation as some use-cases are useful: - Automatically update the invoice status of SO when an action is executed. - Force the SO status to "sent" without sending the email. Task: 3983645 Forward-Port-Of: odoo/odoo#170729
**Steps to reproduce the bug:** - Parent company: CompanyA with a purchase tax of “15%” - Create a branch from Company - select only the brunch as current company - Create a storable product P1: - Add vendor: Azure Interior, price: $10 per unit - Create a recording rule: - Trigger: Manual - Route: Buy - Minimum quantity: 10 - save - Click on order **Problem**: A purchase order is created with Azure Interior as the vendor and 10 units
Original PR description
**Steps to reproduce the bug:**
- Parent company: CompanyA with a purchase tax of “15%”
- Create a branch from Company
- select only the brunch as current company
- Create a storable product P1:
- Add vendor: Azure Interior, price: $10 per unit
- Create a recording rule:
- Trigger: Manual
- Route: Buy
- Minimum quantity: 10
- save
- Click on order
**Problem**:
A purchase order is created with Azure Interior as the vendor and 10 units of P1, but the tax is not set. This happens because when the PO line values are prepared, the tax is retrieved from the supplier tax, but it is filtered by the current company, So only the branch taxes. However, it should also check in the parent company.
opw-3937178
Forward-Port-Of: odoo/odoo#171052
Forward-Port-Of: odoo/odoo#169635