Monday, September 16, 2024
19 changes · saas-17.2
Resolved issues and error corrections
VoIP automated tests now prevent ringtone sounds from playing while tests run. This keeps development and testing environments quieter without changing the customer-facing VoIP experience.
Original PR description
Patch the voip.ringtone service in all voip tests to avoid playing ringtones while tests are running.
Project notification emails now keep the View Project button visible for internal users. The button is only hidden from customer portal recipients when the project is private, helping staff access project details directly from email while preserving intended customer visibility rules.
Original PR description
Before this commit, due to 715d6be, the `View Project` button in the email sent even if the receiver is an internal user, which is not really expected. This commit makes sure the button is only hidden for the customer portal when the project is private. X-Original-Commit: 715d6be Forward-port of #180257
Opening a CRM lead directly from a link now keeps the breadcrumb trail accurate, including the option to return to the broader list of records. This helps users navigate consistently when actions are launched indirectly in Odoo.
Original PR description
Before this commit when opening a CRM Lead from the URL, the breadcrumb doesn't show the multi-record controller. This occurs, because the CRM action is a server action that returns a window action, and the lazy controller is never created. Now, the lazy controller is correctly created also for the server actions.
Miscellaneous changes
When the customer creates a helpdesk ticket and the user of helpdesk team is deleted, a traceback will appear. Steps to reproduce the error: - Go to Settings > Users & Companies > Users > Create a user - Go to Helpdesk > Configuration > Helpdesk Teams > Open Team A Select Assignment Method: Random > Select that user in the members > Save - Delete that user - Go to Helpdesk > All Tickets > Create a ticket > Select Team A Traceback: ``` IndexError: list index out of range File "
Original PR description
When the customer creates a helpdesk ticket and the user of helpdesk team is deleted, a traceback will appear. Steps to reproduce the error: - Go to Settings > Users & Companies > Users > Create a…
When the customer creates a helpdesk ticket and
the user of helpdesk team is deleted, a traceback will appear.
Steps to reproduce the error:
- Go to Settings > Users & Companies > Users > Create a user
- Go to Helpdesk > Configuration > Helpdesk Teams > Open Team A
Select Assignment Method: Random > Select that user in the members > Save
- Delete that user
- Go to Helpdesk > All Tickets > Create a ticket > Select Team A
Traceback:
```
IndexError: list index out of range
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 866, in onchange
defaults = self.default_get(missing_names)
File "home/odoo/src/enterprise/saas-17.2/helpdesk/models/helpdesk_ticket.py", line 40, in default_get
result['user_id'] = team._determine_user_to_assign()[team.id].id
File "home/odoo/src/enterprise/saas-17.2/helpdesk/models/helpdesk_team.py", line 959, in _determine_user_to_assign
result[team.id] = self.env['res.users'].browse(member_ids[index])
```
https://github.com/odoo/enterprise/blob/947b6ab9447aa069fd5edd150c932d9a0884a3cb/helpdesk/models/helpdesk.py#L502 When the related user is deleted, "member_ids" will be an empty list.
so when it tries to access the index of "member_ids",
it will lead to the above traceback.
behavior after the commit:
It will ensure that at least one user is selected in "member_ids".
sentry-5630888721
Forward-Port-Of: odoo/enterprise#70085
Forward-Port-Of: odoo/enterprise#67240Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this
Original PR description
Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. This change adds the necessary override in enterprise. See change in community here: https://github.com/odoo/odoo/pull/162927 opw-3841495 Forward-Port-Of: odoo/enterprise#61731
Purpose ======= Fix the inactive records fetching in the gantt view. Specification ============= When fetching the records to display in the gantt view from their ids, we don't specify if the inactive records need to be included in the search. This is an issue as further down the execution flow, the '_where_calc' method by default excludes inactive records except if they are explicitly asked for. => This means that filtering on inactive records doesn't display any records. Fixing that
Original PR description
Purpose ======= Fix the inactive records fetching in the gantt view. Specification ============= When fetching the records to display in the gantt view from their ids, we don't specify if the inactive records need to be included in the search. This is an issue as further down the execution flow, the '_where_calc' method by default excludes inactive records except if they are explicitly asked for. => This means that filtering on inactive records doesn't display any records. Fixing that by setting the 'active_test' key in the context to 'False' to be sure we search records with these ids both in active and inactive records. Related commit: 836909419893b522890776d3ec2f16476ae21108 Forward-Port-Of: odoo/enterprise#70032
**Current behavior:** After creating a subscription for a recurring product which creates a project/task, invoicing the original order and posting it, then creating the renewal order, if you create a purchase order for some expensable service product that has an `expense_policy == 'sales_price'` and attempt to create the vendor bill for the purchase order, you will get a UserError about the original sale order being locked. **Expected behavior:** Because there is a renewed order which
Original PR description
**Current behavior:** After creating a subscription for a recurring product which creates a project/task, invoicing the original order and posting it, then creating the renewal order, if you create a…
**Current behavior:**
After creating a subscription for a recurring product which
creates a project/task, invoicing the original order and posting
it, then creating the renewal order, if you create a purchase
order for some expensable service product that has an
`expense_policy == 'sales_price'` and attempt to create the
vendor bill for the purchase order, you will get a UserError
about the original sale order being locked.
**Expected behavior:**
Because there is a renewed order which is not locked, the
expense should use that instead of the original subscription
order.
**Steps to reproduce:**
1. Create a recurring service product which is set to create a
project and task that has an associated analytic account
2. Create a subscription for the product and confirm it, create
the invoice and post it (locking the order)
3. Renew the subscription, confirm it, create the invoice but do
not post it
4. Create a service product which can be expensed and uses the
expense policy of sales price
5. Create a purchase order for the expensable service and set
analytic distribution on the order line to use the same one
from the subscription
6. Confirm the purchase order and create an invoice, then try to
post it -> UserError
**Cause of the issue:**
The original subscription order is found via the shared analytic
account and generates the error because it is now in a locked
state.
**Fix:**
Check if a found order is in the renewed subscription state and
then search for the lowest id order in DB with the originally
found subscription as its origin order- if one exists, use this
record instead of the original order in the
`_sale_determine_order()` mapping.
opw-4061484
Forward-Port-Of: odoo/enterprise#68820As we replaced the individual config files by a single `odoo.conf`, we need to adapt the code to keep compatibility between updated and non-updated IoT Boxes. As we did not update this one in the migration method from [this PR](https://github.com/odoo/odoo/pull/173866), we have to try both old and new methods to get the config value. opw-4183138 Forward-Port-Of: odoo/enterprise#70033
Original PR description
As we replaced the individual config files by a single `odoo.conf`, we need to adapt the code to keep compatibility between updated and non-updated IoT Boxes. As we did not update this one in the migration method from [this PR](https://github.com/odoo/odoo/pull/173866), we have to try both old and new methods to get the config value. opw-4183138 Forward-Port-Of: odoo/enterprise#70033
Inside `_compute_component_data`, we assign `component_uom_id` but this field is actually a related field and shouldn't be assigned outside its compute. This useless assignment will update the record every time it's read (will update _log_access fields) and can cause a lot of performance degradation: see https://github.com/odoo/odoo/issues/136044#issuecomment-2348689221. Forward-Port-Of: odoo/enterprise#70046 Forward-Port-Of: odoo/enterprise#70025
Original PR description
Inside `_compute_component_data`, we assign `component_uom_id` but this field is actually a related field and shouldn't be assigned outside its compute. This useless assignment will update the record every time it's read (will update _log_access fields) and can cause a lot of performance degradation: see https://github.com/odoo/odoo/issues/136044#issuecomment-2348689221. Forward-Port-Of: odoo/enterprise#70046 Forward-Port-Of: odoo/enterprise#70025
Sequences of optional employer insurance payments should come before gross Forward-Port-Of: odoo/enterprise#70070
Original PR description
Sequences of optional employer insurance payments should come before gross Forward-Port-Of: odoo/enterprise#70070
To reproduce: ============= 1. Add an image field on a worksheet template 2. Create a new task 3. Add a picture on the worksheet 4. Send the report to the customer -> the image is not displayed on the protal -> after signing the report, the image is not displayed on the signed report Problem: ======== - the image added to the worksheet is a binary field, so when compiling the Qweb template, this field can be either a base64 string or a url to the image. https://github.com/odoo/odoo
Original PR description
To reproduce: ============= 1. Add an image field on a worksheet template 2. Create a new task 3. Add a picture on the worksheet 4. Send the report to the customer -> the image is not displayed on the protal -> after signing the report, the image is not displayed on the signed report Problem: ======== - the image added to the worksheet is a binary field, so when compiling the Qweb template, this field can be either a base64 string or a url to the image. https://github.com/odoo/odoo/blob/f0af31dbe36bc77d50ec36e88b49e1e521b809c1/addons/web/models/ir_qweb_fields.py#L68-L74 - in this case the field is url to the image, so when the customer opens the worksheet on portal, the image is not loaded as the customer does not have read access to the binary field representing the image. Solution: ========= - represent image binary fields as base64 strings in the Qweb template insted of urls to the image. opw-3944993 Forward-Port-Of: odoo/enterprise#67156
Versions -------- - 17.0+ Steps ----- 1. Create a subscription SO w/ a subscription product; 2. set recurrence to monthly; 3. set start date to 3+ months ago; 4. confirm & create invoice. Issue ----- In the Other Info tab, the Invoice Status is displayed as fully invoiced, despite there still being several months to invoice. Cause ----- The `_compute_invoice_status` method doesn't doesn't check `next_invoice_date` to decide whether a line's status should be `invoiced` or `to
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a subscription SO w/ a subscription product; 2. set recurrence to monthly; 3. set start date to 3+ months ago; 4. confirm & create invoice. Issue ----- In the Other Info tab, the Invoice Status is displayed as fully invoiced, despite there still being several months to invoice. Cause ----- The `_compute_invoice_status` method doesn't doesn't check `next_invoice_date` to decide whether a line's status should be `invoiced` or `to invoice`. Solution -------- Modify the override for `_compute_invoice_status` in sale_subscription, to change the `invoice_status` from `invoiced` to `to invoice` if the `next_invoice_date` is today or earlier. Also change compute dependency from `order_id.is_subscription` to `order_id.next_invoice_date`. This maintains a transitive dependency to `order_id.is_subscription`. opw-3849059 Forward-Port-Of: odoo/enterprise#65864
The aim of this commit is fixing the connected until widget to show the reconnect bank button when the expiration date is for today. The right to fix that, is doing the fix in the view but to avoid breaking the stable policy, we decide to make the change in the JS widget. task-4058051 Forward-Port-Of: odoo/enterprise#69858
Original PR description
The aim of this commit is fixing the connected until widget to show the reconnect bank button when the expiration date is for today. The right to fix that, is doing the fix in the view but to avoid breaking the stable policy, we decide to make the change in the JS widget. task-4058051 Forward-Port-Of: odoo/enterprise#69858
The donation test relies on a complete payment flow using demo data. To avoid failures in environments without demo data, the test is now skipped when demo data is not loaded. This adjustment ensures accurate test results and prevents unnecessary failures in such environments. **During FW to 16:** Add check to be sure that payment_demo is available ```python payment_demo = self.env['ir.module.module']._get('payment_demo') if payment_demo.state != 'installed': self.skipTest("pay
Original PR description
The donation test relies on a complete payment flow using demo data.
To avoid failures in environments without demo data, the test is now
skipped when demo data is not loaded. This adjustment ensures accurate
test results and prevents unnecessary failures in such environments.
**During FW to 16:**
Add check to be sure that payment_demo is available
```python
payment_demo = self.env['ir.module.module']._get('payment_demo')
if payment_demo.state != 'installed':
self.skipTest("payment_demo module is not installed")
```
runbot-76571
Forward-Port-Of: odoo/odoo#179815
Forward-Port-Of: odoo/odoo#179765### Steps to reproduce: - Create a product tracked by lot and register 4 lots of 10 units in stock : LOT001, LOT002, LOT003, LOT004 - Inventory > Configuration > Products > Product Categories - Change the Removal strategy of the "All" category to LIFO - Create and confirm a delivery order for 40 units of your product > Move lines are created for reservation in order LOT003, LOT002, LOT001 - Do not click on the detailed operation to see these LOTS and decrease the quantity of the move to
Original PR description
### Steps to reproduce: - Create a product tracked by lot and register 4 lots of 10 units in stock : LOT001, LOT002, LOT003, LOT004 - Inventory > Configuration > Products > Product Categories -…
### Steps to reproduce: - Create a product tracked by lot and register 4 lots of 10 units in stock : LOT001, LOT002, LOT003, LOT004 - Inventory > Configuration > Products > Product Categories - Change the Removal strategy of the "All" category to LIFO - Create and confirm a delivery order for 40 units of your product > Move lines are created for reservation in order LOT003, LOT002, LOT001 - Do not click on the detailed operation to see these LOTS and decrease the quantity of the move to 15 units ### Expected behavior: Since the lines were created respecting the removal strategy, they should be removed accordingly from the last one created to the first created > LOT001 and LOT002 should be removed and 5 units should be decreased from LOT003 ### Current behavior: LOT004 and LOT004 are removed and 5 units is removed from LOT002 ### Cause of the issue: On qty decrease, the `_process_decrease` of the `set_quantity` is called to decrease the qties on the associated sml and to unlink the one resulting with a 0 qty. However, the loop used to make this action is not based on the reversed order of creation of the lines but on their order itself. #### Note: This doe snot solve the issue for complex removal strategy that would require a complete recompute of the reservation on qty decrease such as "use the minimal amount of packages". ### Note 2: An other issue exists when you increase the demand of the move instead of decreasing it: while the qty done is increased no assignments are done so that a move line without lot id would be created to fulfill the increase of qty. This is because the `_action_assign` can not be triggered again in this process increase since the stockpocalypse the line was even commented here: https://github.com/odoo/odoo/blob/9f364cde276b8b3be73c30617515bd55a9f25aba/addons/stock/models/stock_move.py#L376-L378 he reason is that if an `_action_assign` was performed instead and if the units were not in stock to fulfill it the qty would only be increased by the available qty and the desired flow would be bloqued. THe behavior is being improved in master (18.0+) but the required change of the `_process_increase` is to risky to be applied in stable. co-authored by @naja628 opw-4074174 and opw-4071479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180082
Steps --- * create a set-up with 2 companies using different currencies. eg: * company 1: usd * company 2: eur * from the company 2: set a conversion rate from eur to usd in *Currencies* * from company 1: create a based on rules shipping method (with prices in usd) * from company 2: * create an SO for some products * add the shipping method * => the price in dollars is used unconverted as the price in eur Cause --- when we have a base_on_rule delivery without a speci
Original PR description
Steps --- * create a set-up with 2 companies using different currencies. eg: * company 1: usd * company 2: eur * from the company 2: set a conversion rate from eur to usd in *Currencies* * from company 1: create a based on rules shipping method (with prices in usd) * from company 2: * create an SO for some products * add the shipping method * => the price in dollars is used unconverted as the price in eur Cause --- when we have a base_on_rule delivery without a specified company, we convert prices as if the price was in the current company's currency. Fix --- Consider the price to be in the main company's currency instead opw-4105047 Forward-Port-Of: odoo/odoo#180123 Forward-Port-Of: odoo/odoo#177932
Removing Mantux11 from our CLA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180235
Original PR description
Removing Mantux11 from our CLA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180235
Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows t
Original PR description
Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. opw-3841495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162927
This commit will remove the readonly constraint on the journal when an account move has been posted. task: 4028973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180266 Forward-Port-Of: odoo/odoo#171710
Original PR description
This commit will remove the readonly constraint on the journal when an account move has been posted. task: 4028973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180266 Forward-Port-Of: odoo/odoo#171710