Daily updates from Odoo
Saturday, July 18, 2026
5 changes · saas-19.3
Resolved issues and error corrections
VOIP call screens now hide related action buttons when a call is not linked to a contact, preventing errors from unexpected clicks. Subscription shortcuts are also shown consistently with the contact page behavior.
Original PR description
Same as in [1], we don't show smart buttons when no partner to prevent unexpected errors. Also remove `invisible="subscription_count == 0"` to make it same as smart button on res.partner. [1]: 0fbb730e02de22b196a45455f801e96321a75167 Forward-Port-Of: odoo/enterprise#124579
Refreshing an accounting report no longer leaves an old search filter hidden in the session. This ensures downloaded XLSX files match the partners shown on screen, avoiding incomplete or misleading report exports.
Original PR description
**Steps to reproduce:** - Install account_reports - Open "Partner Ledger" (make sure there are several partners) - Make a search to only display 1 partner - Download XLSX - Without changing the search text, refresh the page - Download XLSX again **Issue:** After refresh, the search text is empty and all the partners are displayed in the report. However, in the XLSX file, only the partner from the previous search is present. **Cause:** The current search is kept in the session and used when getting the XLSX. When refreshing or leaving the page, it's still kept in the session even if the search bar has been reset. opw-6333212 Forward-Port-Of: odoo/enterprise#124685
Steps to reproduce: - Go to Website - Upload an image in the company logo (navbar) - Open the website editor and click on the logo - Open the image info panel Current behavior: When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn'
Original PR description
Steps to reproduce: - Go to Website - Upload an image in the company logo (navbar) - Open the website editor and click on the logo - Open the image info panel Current behavior: When clicking on the…
Steps to reproduce: - Go to Website - Upload an image in the company logo (navbar) - Open the website editor and click on the logo - Open the image info panel Current behavior: When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn't. Reason: When clicking the logo, the editor tries to find the original, unprocessed version of the image so it can support cropping and other edits. It does this by asking the server to match the image's URL to a stored attachment. The website logo is served through a dynamic link (`/web/image/website/<id>/logo/<name>`) that isn't tied to a regular attachment record the way normal content images are, since it isn't uploaded through the usual media picker. Because of this, the server can't find a matching original, and the editor is left without a valid image source to work with. As a fallback, the editor tries to load a placeholder path instead of a real image. This request fails and silently resolves to Odoo's generic "image not found" placeholder. All further processing (and the size calculation) then happens on this small placeholder image instead of the actual logo, which is why the size shown never changes. Fix: When `get_image_info` does not return a usable `original`, `loadImageInfo` now falls back to using the image's own current src as `originalSrc`, instead of leaving it unset. This ensures `loadImage` always receives a valid, resolvable URL, so image processing (and the size shown) reflects the actual logo. opw-6260496 Forward-Port-Of: odoo/odoo#276733 Forward-Port-Of: odoo/odoo#273542
Saving the Settings will trigger the `_inverse_l10n_fr_pdp_pilot_phase` of the `res.config.settings`. Currently, the inverse will call `_l10n_fr_pdp_update_pilot_phase()` on the related company record even if there is no change to the field value. It leads to Odoo calling the Peppol proxy to register or unregister the company for the Pilot Phase of the French E-invoicing every time the Settings are saved. If the request returns an error, then the user is unable to save the Settings. Rel
Original PR description
Saving the Settings will trigger the `_inverse_l10n_fr_pdp_pilot_phase` of the `res.config.settings`. Currently, the inverse will call `_l10n_fr_pdp_update_pilot_phase()` on the related company record even if there is no change to the field value. It leads to Odoo calling the Peppol proxy to register or unregister the company for the Pilot Phase of the French E-invoicing every time the Settings are saved. If the request returns an error, then the user is unable to save the Settings. Related ticket: opw-6377006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276615
Backport of b667cacb (odoo/odoo#276156), currently on master. The guards of mark as read were only evaluated when requesting it, while the RPC itself goes through a sequential queue. A mark as read requested while another one was still in flight was thus executed later without any re-validation. Under CI load, the bus sync of a previous mark as read can lag enough for a focus-triggered mark as read to legitimately pass its guards on stale state and be queued. When the user then clicked "Ma
Original PR description
Backport of b667cacb (odoo/odoo#276156), currently on master. The guards of mark as read were only evaluated when requesting it, while the RPC itself goes through a sequential queue. A mark as read…
Backport of b667cacb (odoo/odoo#276156), currently on master.
The guards of mark as read were only evaluated when requesting it, while the RPC itself goes through a sequential queue. A mark as read requested while another one was still in flight was thus executed later without any re-validation.
Under CI load, the bus sync of a previous mark as read can lag enough for a focus-triggered mark as read to legitimately pass its guards on stale state and be queued. When the user then clicked "Mark as Unread", the queued mark as read executed right after and reverted that explicit action on the server, and through the resulting bus push, on the client as well. In the meeting view tour, the unread badge of the Chat action then never showed "1":
FAILED: [17/24] Tour discuss.meeting_view_public_tour
Step .o-mail-Meeting [title='Chat']:has(.badge:contains(1))
The state guards are now re-validated when the queued call actually executes: the member must still exist, the messages must not have been read in the meantime, and the channel must not have been marked as unread since the call was requested. The newest persistent message is still captured at request time as it is the payload of the intent: messages that arrived later have not been validated as read by the caller, their own triggers request another mark as read when appropriate.
https://runbot.odoo.com/odoo/error/941491
Forward-Port-Of: odoo/odoo#276555