Monday, August 24, 2026
7 changes · 18.0
Resolved issues and error corrections
Credit notes created from existing Turkish customer invoices now use the sales return account set on the journal, matching manually entered credit notes. This keeps sales and returns separated correctly in Turkish accounting reports while preserving exact reversals used to cancel entries.
Original PR description
The Turkish chart of accounts keeps sales and sales returns on separate accounts, and the sales journal carries the account to use for returns. A credit note typed in by hand already lands on it, but one created from an existing customer invoice did not. Reversing an invoice copies `account_id` over from the invoice line, and since that field is a stored compute without depends, nothing ever recomputes it, so the return kept the sales account. Set the journal account on the copied product lines instead. Reversals made to cancel an entry are left alone, as those have to mirror the original move exactly for the two to net out, and a plain duplicate is untouched. Task-6438412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
French VAT XML submissions now handle long holder names by splitting them into two allowed parts. This prevents report submissions from being rejected when a company or account holder name exceeds the official 35-character limit.
Original PR description
The XSD for XML-EDI does not allow strings longer than 35 for TitulaireDesignation This commit splits the holder name in 2 parts when it is more than 35 characters task-6476440
This fix keeps certificate handling working smoothly across both older and newer server environments. It prevents compatibility warnings or errors caused by changes in a third-party security library, reducing upgrade friction for deployments on recent operating systems.
Original PR description
Starting in pyOpenSSL 24.3.0, the library began phasing out legacy `OpenSSL.crypto` wrapper objects in favor of native `cryptography` primitives. On newer operating systems (such as Debian Trixie or recent Ubuntu releases), passing `OpenSSL.crypto` objects emits a `DeprecationWarning`. However, directly adopting native `cryptography` objects creates a breaking change for older environments (pyOpenSSL < 24.3.0), which strictly expect `OpenSSL.crypto` instances and raise a `TypeError` otherwise. To maintain compatibility across both legacy and modern environments, the adapter needs to detect the installed pyOpenSSL version at import time and provide the corresponding object type expected by the underlying library. Additionally, the local `x509` variable in `init_poolmanager` is renamed to `x509_cert` to prevent namespace shadowing with the `cryptography.x509` module. runbot-944176
This fix prevents images set to full width in email templates from being duplicated in Outlook-specific HTML during mailing conversion. It keeps saved email content cleaner and avoids displaying or storing unnecessary duplicate image markup.
Original PR description
Problem: An `img-fluid` image ended up duplicated twice inside `[if mso]` comments instead of once when converting a mailing body to inline HTML. `classToStyle` resets the image's `width` attribute back to `100%` after the img-fluid fix already hid it and added its Outlook clone, making it match `enforceImagesResponsivity`'s selector again and get duplicated a second time. Solution: Mark images already handled by the img-fluid fix with a dedicated `mso-hidden` class and exclude them from `enforceImagesResponsivity`'s selector. Steps to reproduce: - Add an image in a new email template. - Set its width to "100%". - Save. - Observe the saved HTML has two mso comments for one image. opw-6411348 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282199
This fix updates a Mexican electronic invoicing point of sale test so the product is properly available in the POS flow. It helps ensure refunded orders with discounts display correctly during automated checks, reducing the risk of regressions in that workflow.
Original PR description
Before this commit: * `available_in_pos` was not set on the product in the test, causing it to be missing from the ticket screen when fetching paid orders using `callRelated`. After this commit: * Set `available_in_pos` on the product so it is loaded correctly and appears in the ticket screen when fetching paid orders, fixes test case `test_mx_pos_refund_discount_order`. task-5890998 related pr: https://github.com/odoo/odoo/pull/247127
Gantt charts using a weekly view now place tasks in the correct week according to the user's locale, such as weeks starting on Sunday. This prevents unexpected empty columns and keeps planning timelines aligned with local business practices without changing existing standard views.
Original PR description
In Gantt views, for a given focus date, the appropriate time interval is displayed by finding its start and end date, based on the scale. For example, if I focus on 18 may 2026 with a month scale,…
In Gantt views, for a given focus date, the appropriate time interval is displayed by finding its start and end date, based on the scale. For example, if I focus on 18 may 2026 with a month scale, then the whole month of may is displayed. The behaviour was as expected in standard code, because all localisations agree on the beginning of the available scales (day, month, year). In custom code, however, some customer requires to see the gantt charts with a weekly scale. The differences in start of the week based on the localisations and the inconsistencies of use of localStartOf breaks the view. For example, if the localization has the start of the week on a sunday, and a task on the first column starts on a sunday as well, it will get assigned to column before (because it considers sunday as the last day of the previous week). The column before the first column does not exist, so one empty column is created to put the task in it. This commit fixes these inconsistencies so that GanttRenderer behaves as expected with weekly scales, without changing the standard behaviour. Tests are written to check both that the task is assigned to the proper localized week (starting on Sunday) and column (1, not 0).
The LinkedIn integration now handles cases where LinkedIn returns no account statistics during a refresh. This prevents an unexpected crash and keeps social account data updates running smoothly.
Original PR description
Bug === When the LinkedIn API returns no statistics for the account, the refresh crashes. Task-6425391 Forward-Port-Of: odoo/enterprise#126326