Daily updates from Odoo
Saturday, August 8, 2026
9 changes · saas-19.4
Enhancements to existing features
Calendar events are now matched to the right project or task using the event's linked record before falling back to partner history. This makes suggested timesheets more accurate and reduces manual corrections for users who track time from calendar entries.
Original PR description
…the 'linked to' field Before this commit: - Calendar events are matched based on the most timesheet project of the partners. After this commit: - Calendar events are matched to projects/tasks via the "linked to field" before looking to partners projects. task-6238332 Forward-Port-Of: odoo/enterprise#123158
Resolved issues and error corrections
Payroll warning information is now consistently visible in payslip and pay run list views instead of appearing as an unnamed optional column. This improves clarity for payroll users and prevents confusing empty entries in the column selection menu.
Original PR description
Currently, in the payslip and payrun view, we can see empty label in optional dropdown. Having empty label isn't UX friendly. This empty label is refered to payslip warnings. In this PR expected to change visibility of warning fields, The visibility must be always visible and the field is no longer optional. This condition applies to PayRun and Paylist ListViews. task-6424657 Forward-Port-Of: odoo/enterprise#127224 Forward-Port-Of: odoo/enterprise#125860
The exchange rate update link for the Romanian National Bank has been changed to the new official domain. This prevents future disruption to automatic currency rate updates after the old address stops serving XML files.
Original PR description
As of 6 August 2026, the XML files used by software applications to retrieve daily exchange rates will no longer be available directly through addresses on the www.bnr.ro domain and will be accessible exclusively via the curs.bnr.ro subdomain. The XML file names will remain unchanged; only the access domain will be modified. no-task Forward-Port-Of: odoo/enterprise#127177
This update fixes a Swiss payroll transmission issue where a required value was not being recorded in the payroll logs. This helps payroll teams keep more complete records for compliance checks and troubleshooting.
Original PR description
Forward-Port-Of: odoo/enterprise#127241
`_selection_target_model()` searched all records of ir_model and due to some prefetch issues, multiple queries ran depending on the number of models in db. By using search_fetch we eliminate this. Partial backport of odoo/odoo#281215 Forward-Port-Of: odoo/odoo#281229
Original PR description
`_selection_target_model()` searched all records of ir_model and due to some prefetch issues, multiple queries ran depending on the number of models in db. By using search_fetch we eliminate this. Partial backport of odoo/odoo#281215 Forward-Port-Of: odoo/odoo#281229
Before this commit, the unread badge of the Chat action could stay empty after a click on "Mark as Unread" in the meeting view: FAILED: [17/24] Tour discuss.meeting_view_public_tour Step .o-mail-Meeting [title='Chat']:has(.badge:contains(1)) This happens because a mark as read and a mark as unread write the same fields of the channel member in two requests, and the server applies them in the order it receives them, not the order they are sent. Under CI load, a mark as read sent be
Original PR description
Before this commit, the unread badge of the Chat action could stay empty after a click on "Mark as Unread" in the meeting view:
FAILED: [17/24] Tour discuss.meeting_view_public_tour
Step .o-mail-Meeting [title='Chat']:has(.badge:contains(1))
This happens because a mark as read and a mark as unread write the same fields of the channel member in two requests, and the server applies them in the order it receives them, not the order they are sent. Under CI load, a mark as read sent before the click reached the server after the mark as unread, marking the member read again and hiding the badge through its bus push.
This commit requests the mark as unread through the queue of the mark
as read, which sends one request at a time.
This also drops the check the mark as read made against a mark as unread requested in between, as the queue keeps only the last request and replaces the waiting one.
https://runbot.odoo.com/odoo/error/944432
Forward-Port-Of: odoo/odoo#280946Steps to reproduce ------------------ 1. Install `l10n_pe_pos`. 2. Create a contact with the identification type DNI and a number. 3. Sell a product to this contact and print the receipt. -> the receipt shows "RUC" in front of the number, even though the number is a DNI and not a RUC. Why it's happening ------------------ Since `aeaca097ae39` the number of the contact is printed with a label in front of it, before there was no label at all. This label is the `vat_label` of the country,
Original PR description
Steps to reproduce ------------------ 1. Install `l10n_pe_pos`. 2. Create a contact with the identification type DNI and a number. 3. Sell a product to this contact and print the receipt. -> the…
Steps to reproduce ------------------ 1. Install `l10n_pe_pos`. 2. Create a contact with the identification type DNI and a number. 3. Sell a product to this contact and print the receipt. -> the receipt shows "RUC" in front of the number, even though the number is a DNI and not a RUC. Why it's happening ------------------ Since `aeaca097ae39` the number of the contact is printed with a label in front of it, before there was no label at all. This label is the `vat_label` of the country, so "RUC" for Peru. But in Peru each contact can have a different identifier, and the type is on the contact in `l10n_latam_identification_type_id`. The fix ------- In `l10n_pe_pos` we set `partner_vat_label` with the name of the identification type of the contact. If the contact has no identification type we keep the number alone. Before vs After for a customer identified with DNI ------------------------------------------------- <img width="465" height="203" alt="Capture d’écran 2026-07-30 à 14 45 17" src="https://github.com/user-attachments/assets/85c921df-c1fd-430b-b4e6-341bc183bd61" /> <img width="467" height="253" alt="Capture d’écran 2026-07-30 à 14 49 36" src="https://github.com/user-attachments/assets/3ac243c6-04fe-47a4-a662-c59b88276db7" /> opw-6422619 Forward-Port-Of: odoo/odoo#279409
Otherwise using the "Update Apps List" wizard (`base.action_view_base_module_update`) and then trying to `_get` the new module may not work because `_get_id` is `ormcache`ed. To reproduce: 1. Install `account_peppol` and `l10n_fr` 2. Delete the `l10n_fr_pdp` module from the apps 3. Go to the settings and click "Activate Electronic Invoicing" 4. Make sure "France FRCTC Electronic Address" is selected 5. Click on "Activate Peppol (Demo)" 6. Click on "Update App List" in the warning 7. Cl
Original PR description
Otherwise using the "Update Apps List" wizard (`base.action_view_base_module_update`) and then trying to `_get` the new module may not work because `_get_id` is `ormcache`ed. To reproduce: 1. Install `account_peppol` and `l10n_fr` 2. Delete the `l10n_fr_pdp` module from the apps 3. Go to the settings and click "Activate Electronic Invoicing" 4. Make sure "France FRCTC Electronic Address" is selected 5. Click on "Activate Peppol (Demo)" 6. Click on "Update App List" in the warning 7. Click on "Update" 8. Start over at step 3. and the same warning appears again, but the module can be found in the "Apps" already. Everything works fine after a server restart. task-None Forward-Port-Of: odoo/odoo#281299 Forward-Port-Of: odoo/odoo#280938
### Issue before this commit: When generating ZUGFeRD or Factur-X electronic invoices, including an HTML hyperlink (such as an email or website) in the document layout caused the final PDF to fail PDF/A validation. Portals would reject the file with the error: "An annotation dictionary does not contain the key F". ### Steps to reproduce the issue: 1. Download Accounting and l10n_de 2. Go to Contacts > set Tax ID for company Bloem GmbH and also for DE company 3. Activate ZUGFeRD from setti
Original PR description
### Issue before this commit: When generating ZUGFeRD or Factur-X electronic invoices, including an HTML hyperlink (such as an email or website) in the document layout caused the final PDF to fail…
### Issue before this commit: When generating ZUGFeRD or Factur-X electronic invoices, including an HTML hyperlink (such as an email or website) in the document layout caused the final PDF to fail PDF/A validation. Portals would reject the file with the error: "An annotation dictionary does not contain the key F". ### Steps to reproduce the issue: 1. Download Accounting and l10n_de 2. Go to Contacts > set Tax ID for company Bloem GmbH and also for DE company 3. Activate ZUGFeRD from settings 4. Go to settings and click on Configure Document Layout and insert something like <a href="mailto:info@company.de_skr03example.com"> info@company.de_skr03example.com</a> into the footer 5. Create an invoice to Bloem GmbH and send it through ZUGFeRD 6. Download PDF and upload it on https://www.portinvoice.com/ 7. See error: An annotation dictionary does not contain the key F. With the exception of annotation dictionaries whose subtype value is Popup, all annotation dictionaries must contain the key F. ### Cause of the issue: The underlying PDF generation engine creates hyperlinks as PDF annotations but omits the /F (Flags) key. During Odoo's PDF/A conversion process, these annotations were left unmodified. This violates the strict PDF/A specification, which mandates that all non-Popup annotations must explicitly define the /F key. ### Reason to introduce the fix: This fix ensures full PDF/A compliance by iterating through all page annotations and injecting the missing /F key for any annotation that is not a Popup. This allows users to safely include clickable links in their invoice templates without breaking electronic document validation. opw-6388212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281275 Forward-Port-Of: odoo/odoo#279024