Friday, October 18, 2024
10 changes · 17.0
Resolved issues and error corrections
Users who try to enable desktop notifications in Brave will now see a helpful message instead of an unexpected error. The message explains the browser setting needed for Brave, while other browsers receive a general failure message.
Original PR description
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214
This fix makes advanced automation rule filters visible in debug mode and clarifies when certain filters apply. It helps prevent emails or other automated actions from running for the wrong records when users configure conditions on record creation.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enter debug mode; 2. create an Automation Rule; 3. select Task as model; 4. set trigger to Stage is set to New; 5. set domain to a specific customer; 6. add…
Versions -------- - 17.0+ Steps ----- 1. Enter debug mode; 2. create an Automation Rule; 3. select Task as model; 4. set trigger to Stage is set to New; 5. set domain to a specific customer; 6. add send email as action; 7. create a task. Issue ----- Email is sent after task creation, regardless of the customer. Cause ----- The triggers added to 0a744accc2aa automatically compute the `filter_domain` value, and hide the field in view. With debug mode enabled, the `filter_pre_domain` field is still visible & editable. The newly added triggers are applied on both create & update, while `filter_pre_domain` is only applied on update. This leads to confusion when clients add a domain which appears to be ignored, as the selected trigger is immediately hit on creation. Solution -------- 1. Specify in the help string that `filter_pre_domain` is ignored on creation. 2. When entering debug mode, also show the `filter_domain` field, allowing users to further modify the domain computed by the selected trigger, and helping to distinguish itself from `filter_pre_domain`. opw-3928082
The expense form now shows the Total label only when it is relevant: for single-currency expenses with a product cost. This avoids repeated or missing labels, making the expense entry screen clearer for users.
Original PR description
Updated the label for `total_amount` to display `Total` when the expense is not in multiple currencies and the product has a cost, and to show an empty label in the other previously considered cases. This change ensures that the label is displayed correctly without repetitions or omissions in the relevant scenarios. Current behavior before PR: <img width="438" alt="Screenshot 2024-10-10 at 11 05 52 PM" src="https://github.com/user-attachments/assets/af93e767-bc0f-487b-bb35-49ad4602f0ba"> Desired behavior after PR is merged: <img width="450" alt="Screenshot 2024-10-10 at 11 04 51 PM" src="https://github.com/user-attachments/assets/40f531a8-0d79-4eb6-a3d6-cd80abcb145c"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a bug that could block updates to manufacturing bills of materials when their order sequence was changed. The change helps users save BOM updates reliably and avoids an unexpected system error in manufacturing workflows.
Original PR description
Issue: if 'sequence' in vals and self and self[-1].id == self._prefetch_ids[-1]: TypeError: 'PrefetchX2many' object is not subscriptable Cause of the issue: PrefetchX2many object does not have __getitem__ method, only __iter__ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening some bank journal items no longer triggers an error caused by a file name check on binary fields. This makes the journal item form more reliable for accounting users and avoids interruption during review workflows.
Original PR description
* STEP TO REPRODUCE: install account -> journals -> Bank journal -> View Journal Items -> Click on any bank journal item -> traceback * REASON: When click on Bank journal item, system take use to account.bank.statement.line form view , there we have some field for example needed_terms is binary so the system try to retreive filename for it but it fails because when using this.props.record.data[this.props.name] it will return a proxy object which is not a string * SOLUTION: check the return value if a string we do a slice for it else return empty string Video reproduce on runbot (17/10/2024): https://github.com/user-attachments/assets/b520e27a-09db-4f55-9b6d-4a2ef202047e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Issue ----- The activities from the calendar, which should be today's meetings, are in some circumstances displaying meetings from the next day. Steps ----- - Set the user timezone to "Asia/Manila". - In Calendar, create a meeting early (before 18:00) the next day. - Check the activities (clock in the navbar), tomorrow's meeting appears. Cause ----- `datetime.datetime` objects are not timezone aware, and using the `replace` function on them will simply lead to a naive convers
Original PR description
Issue
-----
The activities from the calendar, which should be today's
meetings, are in some circumstances displaying meetings
from the next day.
Steps
-----
- Set the user timezone to "Asia/Manila".
- In Calendar, create a meeting early (before 18:00) the
next day.
- Check the activities (clock in the navbar), tomorrow's
meeting appears.
Cause
-----
`datetime.datetime` objects are not timezone aware, and using
the `replace` function on them will simply lead to a naive
conversion which causes potential issues.
Example:
```
import pytz
import datetime
dt = datetime.datetime(2024,1,1,0,0)
dt = dt.replace(tzinfo=pytz.timezone("Asia/Manila")).astimezone(pytz.UTC)
print(dt)
>>> 2024-01-01 15:56:00+00:00 # 1 day offset to expected result
```
Instead, it is better to use the pytz `localize` function.
opw-4142911
Forward-Port-Of: odoo/odoo#181795There are two paths for a successful login via web_totp 1. The user has a cookie saved which saves them from having to enter the TOTP 2. The user is a new device / browser, enter the TOTP and a form is submitted Both call self._login_redirect but only the latter updates the env and context. This is a snippet to reproduce the bug: ```python @http.route() def web_totp(): response = super().web_totp(*args, **kw) if not request.env.user or request.env.user.is_public:
Original PR description
There are two paths for a successful login via web_totp 1. The user has a cookie saved which saves them from having to enter the TOTP 2. The user is a new device / browser, enter the TOTP and a form…
There are two paths for a successful login via web_totp
1. The user has a cookie saved which saves them from having to enter the TOTP
2. The user is a new device / browser, enter the TOTP and a form is submitted
Both call self._login_redirect but only the latter updates the env and context.
This is a snippet to reproduce the bug:
```python
@http.route()
def web_totp():
response = super().web_totp(*args, **kw)
if not request.env.user or request.env.user.is_public:
return response
do_something()
...
```
This would call `do_something` only when a user successfully logs in by putting the TOTP explicitly but not when they log in thanks to a cookie being set.
Description of the issue/feature this PR addresses:
Makes web_totp consistent for the 2 flows (submit totp or use cookie)
Current behavior before PR:
A code logic that works for web_login does not work for web_totp, or rather, it works only for one flow but not the other
Desired behavior after PR is merged:
A code logic that works for web_login also works for web_totp
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183838Filter name match with a field name and when you use search_default_sale_order_id the records are grouped by sale_order_id. https://github.com/odoo/odoo/blob/5b63d6f8e75df06b8a83c93b15c7d3451eb9dbbc/addons/sale_project/models/sale_order.py#L95  The problem is that when clicking from the sales order form view on the smartbutton tasks, the tasks are grouped by sales order instead of by stage, which is
Original PR description
Filter name match with a field name and when you use search_default_sale_order_id the records are grouped by sale_order_id. https://github.com/odoo/odoo/blob/5b63d6f8e75df06b8a83c93b15c7d3451eb9dbbc/addons/sale_project/models/sale_order.py#L95  The problem is that when clicking from the sales order form view on the smartbutton tasks, the tasks are grouped by sales order instead of by stage, which is the expected grouping. The original filter is maintained by removing the context during stable releases, to avoid inheritance problems in case the filter name has been used to extend views. @Tecnativa TT50965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182958 Forward-Port-Of: odoo/odoo#181139
Steps to reproduce: - install project app - create project without any task - change the language Issue: The helper string is not being translated. Reason: This issue occurs because the existing context is lost, particularly the `lang` variable, which impacts the translation functionality. Solution: In this commit, we have updated the method from with_context({'active_id': self.id}) to with_context(active_id=self.id). This fix ensures that the previous context is ret
Original PR description
Steps to reproduce:
- install project app
- create project without any task
- change the language
Issue: The helper string is not being translated.
Reason:
This issue occurs because the existing context is lost, particularly
the `lang` variable, which impacts the translation functionality.
Solution:
In this commit, we have updated the method from
with_context({'active_id': self.id}) to with_context(active_id=self.id).
This fix ensures that the previous context is retained.
task-3940540
Forward-Port-Of: odoo/odoo#170720**Rational:** for the time being pos.order model has a classic ir.rule ([('company_id', 'in', company_ids)]). However pos.order.line doesn't have such rule. So if we create a new menu and action to display pos.order.line model, it will display all the order lines, regardless the current companies of the user. **Note:** We apply exactly the same logic as for the model sale.order and sale.order.line. See : https://github.com/odoo/odoo/blob/16.0/addons/sale/security/ir_rules.xml#L5-L15 F
Original PR description
**Rational:**
for the time being pos.order model has a classic ir.rule ([('company_id', 'in', company_ids)]). However pos.order.line doesn't have such rule. So if we create a new menu and action to display pos.order.line model, it will display all the order lines, regardless the current companies of the user.
**Note:**
We apply exactly the same logic as for the model sale.order and sale.order.line.
See : https://github.com/odoo/odoo/blob/16.0/addons/sale/security/ir_rules.xml#L5-L15
Forward-Port-Of: odoo/odoo#183045