Daily updates from Odoo
Sunday, April 19, 2026
11 changes · saas-19.2
Resolved issues and error corrections
Customers booking appointments or events will now see a simpler checkout by default, without having to re-enter full billing address details. This improves the buying experience and avoids asking for information that usually isn’t needed for these services.
Original PR description
Forward-Port-Of: odoo/enterprise#114098 Forward-Port-Of: odoo/enterprise#113575
This change brings back a simpler checkout experience for event tickets and similar service products by default, so customers are not asked to re-enter full billing details when they are not needed. It improves the buying flow and reduces friction, while still allowing businesses to require full address details through a system setting if needed.
Original PR description
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#259692 Forward-Port-Of: odoo/odoo#258347
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 resolves an issue where entering an invalid Taiwan VAT number (like '1234567A') would cause the invoicing system to crash. The fix adds validation to ensure the VAT number contains only digits, preventing the error and providing a clear warning message to the user.
Original PR description
**Steps to reproduce:** - Install the `base_vat` module. - Navigate to Invoicing > Customers. - Create a new contact and set the country to `Taiwan`. - Enter `1234567A` as the `Tax ID` and try to `save`. **Error:** `ValueError: invalid literal for int() with base 10: 'A'` **Root cause:** At [1], `check_vat_tw` is missing validation to ensure that the VAT number (without the country code) contains only digits, which causes an error when calling the `int()` method on the VAT number. **Fix:** This commit prevents errors and ensures users receive a `clear warning message`. [1]: https://github.com/odoo/odoo/blob/23398d24e108875b2838715d4b366df265d53234/addons/base_vat/models/res_partner.py#L929-L958 **No task Id** Forward-Port-Of: odoo/odoo#259936 Forward-Port-Of: odoo/odoo#259847
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 a bug where the Avatax integration in the checkout process caused the confirmation button to become unresponsive. The previous implementation unnecessarily called external tax APIs, leading to errors. This fix removes the problematic API call, ensuring a smoother checkout experience.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259728 Forward-Port-Of: odoo/odoo#256692
This update resolves an issue where the checkout process became unresponsive when using the Avatax module with CPF identification types. The previous implementation was unnecessarily calling external tax APIs, leading to errors that blocked the confirmation step. This fix removes the unnecessary API call, restoring normal checkout functionality.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#114109 Forward-Port-Of: odoo/enterprise#112515
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