Sunday, April 19, 2026
6 changes · saas-19.2
Resolved issues and error corrections
This update fixes a bug that prevented messages from being sent through the portal when an opportunity was assigned to a company partner instead of a specific contact. The change improved the system's ability to correctly identify and authorize access to chatter, ensuring seamless communication within the Odoo CRM.
Original PR description
Steps to reproduce: 1) Create a partner contact form 2) Create a child contact for this partner, and grant it portal access 3) Create a customer contact form 4) Create an opportunity for the customer, with the previously created partner as "assigned partner" 5) Connect on the portal account of the partner 6) Send a message from an opportunity When a company partner is assigned to an opportunity (instead of a specific contact person), posting a message in the chatter raised a 404 NotFound error. _mail_get_operation_for_mail_message_operation was using a strict equality check (partner_assigned_id == user.partner_id), which fails when the assigned partner is the company and the user is a child contact under it. Replace the equality check with a child_of domain filter on commercial_partner_id, consistent with the logic already used in _assert_portal_write_access. Forward-Port-Of: odoo/odoo#252854
This update fixes an issue where calendar synchronization was incorrectly sending invitation emails for past events. The fix ensures that notifications aren't triggered when attendees are added to historical events, streamlining communication and reducing unnecessary emails. Further investigation is needed to understand the root cause.
Original PR description
## Problem: Calendar synchronization (Google/Outlook) is retroactively adding attendees to historical events. This triggers Odoo's default invitation logic, sending unnecessary emails to partners for…
## Problem: Calendar synchronization (Google/Outlook) is retroactively adding attendees to historical events. This triggers Odoo's default invitation logic, sending unnecessary emails to partners for meetings that occurred in the past. It is not yet clear why this is happening (needs more investigation), but we quick fix this by correctly checking that an attendee is not part of an event on an past date before triggering emails during the `write`. ## Steps to reproduce the bug: 1. Create an new event in the past and save 2. Add a new attendee (partner) to the event SHOULD NOT create a notification email (but it does) ## Remarks: - readapting existing unit test for `test_event_creation_mail`, but a proper new unit test might be needed in a proper refactor. As of now we were never testing if emails are triggered when adding new attendees on an event in past - giving this, this bug might be affecting previous versions. Might need to be backported and tested if needed - added time freeze to `test_event_creation_internal_user_invitation_ics` to account for the fact that implicitly the tested event was in the past - `freeze_time` for certain tests using the class event, which has hard coded dates OPW-6125052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259844
This update fixes a potential issue where Odoo would attempt to run a monitoring function during the shutdown process, when the necessary system resources were no longer available. This change ensures that the system gracefully handles shutdown, preventing errors and maintaining stability.
Original PR description
Odoo registers a callback function to track how much time is spent in garbage collection. But while the Python interpreter is shutting down and clearing out global modules and variables to free up memory and the Garbage Collector triggers one last time, the callback function `_timing_gc_callback` tries to run, but the function it depends on (like time.thread_time_ns) have already been set to None by the interpreter. Forward-Port-Of: odoo/odoo#259328
This update fixes a recent issue where generated invoice PDFs were displaying company information incorrectly. The change reverses the order of issuer and receiver addresses, improving the document's clarity and presentation. Switching to a simpler internal layout ensures the PDF clearly identifies it as an Odoo-generated document.
Original PR description
When an invoice is received through Peppol, it may not contain an embed PDF. If no, we create one. However, due to several complaints, this commit exchange the place of the issuer and receiver addresses and information. Company information were rendered in the header of the document through the external_layout. Switching to the internal layer avoid doing so. opw-5980655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259578 Forward-Port-Of: odoo/odoo#254693
This update ensures that Odoo's module uninstall process clears all relevant data caches, preventing issues with incorrect tracking of related fields and relationships. Previously, outdated references lingered, causing potential problems with subsequent operations. This change enhances the reliability and stability of module uninstalls.
Original PR description
When uninstalling a module, the ORM may replace field objects in the registry via a prefetch patch to avoid fetching deleted fields. The previous code only called lazy_property.reset_all(), which resets lazy-property caches, but left _field_trigger_trees and _is_modifying_relations intact. Those structures still held references to the old field objects, and could be consulted by subsequent ORM operations, leading to incorrect trigger resolution or relation tracking. Clear both caches whenever a shared field has been patched so all registry state stays consistent with the new field objects. runbot-242251 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#259941 Forward-Port-Of: odoo/odoo#259820
This update resolves an issue where invoices could fail to process correctly with the Peppol system. The fix involved a minor adjustment to how the system handles invoice status updates, preventing a key error that was causing the process to halt. This ensures invoices are properly tracked and updated within the Peppol network.
Original PR description
1. Send an invoice that will return an error when send to IAP 2. Send the invoice 3. Click "Fetch Peppol Invoice status" on the dashboard 4. There is a traceback (see the bottom of this message) To…
1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)
To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
edi_users._peppol_get_message_status()
File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
peppol_response = uuid_to_record[uuid]
^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```
task-None
Forward-Port-Of: odoo/odoo#259834