Saturday, July 19, 2025
4 changes
1 change
Resolved issues and error corrections
Scheduled messages from the chatter now send when the user requested instead of being delayed until a later email queue run. This improves reliability for planned customer or internal communications that depend on precise timing.
Original PR description
**Steps to reproduce:** - Go to the chatter of any record - Click on `Send message` - Click on `Full composer` icon on the bottom right - Prepare an email with custom subject / body - Click on `Send…
**Steps to reproduce:**
- Go to the chatter of any record
- Click on `Send message`
- Click on `Full composer` icon on the bottom right
- Prepare an email with custom subject / body
- Click on `Send Later` and set the scheduled time
- Mail is not sent on scheduled time
**Issue:**
For the timing issue, as the mail is sent by a cron job it obtains a context with `mail_notify_force_send` set to `False` due to the function `_get_eval_context` of `ir.actions.server`.
```
""" Override the method giving the evaluation context but also the
context used in all subsequent calls. Add the mail_notify_force_send
key set to False in the context. This way all notification emails linked
to the currently executed action will be set in the queue instead of
sent directly. This will avoid possible break in transactions. """
```
This context override the `force_send` value used when sending emails notifications. Everything is created properly but the mail is not sent directly and goes to the email queue manager (where it needs to wait until the next execution). This means that the time given previously is not explicitly used to send the mail and the mail is delayed (which doesn't seem to be the expected behavior).
```
if force_send := self.env.context.get('mail_notify_force_send', force_send):
force_send_limit = int(self.env['ir.config_parameter'].sudo().get_param('mail.mail.force.send.limit', 100))
force_send = len(emails) < force_send_limit
if force_send and (not self.pool._init or test_mode):
# unless asked specifically, send emails after the transaction to
# avoid side effects due to emails being sent while the transaction fails
if not test_mode and send_after_commit:
emails.send_after_commit()
else:
emails.send()
```
**Fix:**
Overwrite `mail_notify_force_send` value when posting the scheduled message in the cron job.
related: https://github.com/odoo/odoo/commit/df18d5257cef737f3e1d245a8b85769e1fe1a032
opw-4700253
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#219475
Forward-Port-Of: odoo/odoo#2115152 changes
Resolved issues and error corrections
Helpdesk reporting now opens ticket details correctly when users drill down from Ticket Analysis charts. The fix prevents report-only filters from being applied where they do not belong, avoiding errors and keeping analysis workflows usable.
Original PR description
Step to reproduce - Go to helpdesk - Go to Reporting > Ticket Analysis - Group by `Ticket` - Click on any of the blue bars Issue: since odoo/enterprise@d64db03f we now allow user to drill down to base model from report view, this causes issue when a field which is present in report model but not in base/main model. For now we directly pass the domain created for report view to base model. FIx: we remove such fields from domain and then load the view opw-4798353 related: https://github.com/odoo/odoo/pull/215167 Forward-Port-Of: odoo/enterprise#89488 Forward-Port-Of: odoo/enterprise#88356
1 change
Resolved issues and error corrections
Odoo Discuss now keeps inbox and history usable when a notification refers to a record that has since been deleted. This prevents users from seeing a general message loading error and helps them continue reviewing their messages normally.
Original PR description
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive…
This fixes an issue where incoming VoIP calls could fail because the call status was not handled correctly when creating the call record. Users should now be able to receive calls more reliably without encountering this error.
Original PR description
This commit fixes an error that arises on incoming call because the front end tries to create data with the attribute `state` which is not defined in the called method `create_and_format`. This commit adds this attribute to the API of `create_and_format`.
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive notification in Odoo - Install `mail_group` - Wait a few seconds to receive following user_notification from mail group: ``` on My Company News Hello, You have messages to moderate, please go for the proceedings. ``` - Go to related record then delete it - Go back to inbox or history => One of them show `An error occurred while fetching messages.` This happens because the related record is not a `mail.thread`, but still creates some `mail.message` to send user notifications. `mail.thread` cascade delete the messages in message list, but threadless records do not. Because the related record is deleted, these messages are attempted to be displayed in mailbox, but due to related record having no `display_name` by non-existing, the fetch data of inbox/history crashes with: ``` MissingError: Record does not exist or has been deleted ``` This commit fixes the issue by doing its best to show message even when the related record has been deleted. opw-4546920 Before  After 