Tuesday, August 25, 2026
19 changes · 19.0
Resolved issues and error corrections
Fixed an installation issue that could occur when the Ecuador electronic invoicing module was installed without optional payment features. Withholding portal pages now load reliably and only hide the payment “Paid” badge when it is actually relevant to that page setup.
Original PR description
When installing l10n_ec_edi with --skip-auto-install we receive an error on Runbot. Anchored on the sidebar title (always present on account.portal_invoice_page) rather than div[name='invoice_paid_badge'], which only exists when account_payment (not a dependency of this module) is installed and inherits this view to add it. Hides the account_payment "Paid" badge, if present, without requiring it to exist. runbot-237864
Users can now click links in read-only content to open the link popover and view link details. This removes a confusing dead click and makes it easier to inspect article or website links without needing edit access.
Original PR description
Problem: Clicking a non-editable link does nothing, making it impossible to open or inspect the link. Solution: Allow the link popover to open in read-only mode for non-editable links. Steps to reproduce: - Run `/article`. - Click on the inserted article link. - Observe that nothing happens. opw-6442026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281767 Forward-Port-Of: odoo/odoo#280224
Fixes an error that appeared when UAE accounting users clicked the company details link from the General Ledger warning. The link now opens the company form as expected, allowing users to complete missing information without interruption.
Original PR description
Currently, an error occurs when trying to fill in the company details from the General Ledger. Steps to Reproduce: - Install `l10n_ae_faf` with demo data. - Switch to the `AE Company`. - Go to…
Currently, an error occurs when trying to fill in the company details from the General Ledger. Steps to Reproduce: - Install `l10n_ae_faf` with demo data. - Switch to the `AE Company`. - Go to `Accounting` > `Reporting` > `Ledgers` > `General Ledger`. - Click on `your company` in the company details warning. `AttributeError: The method 'account.report.action_fill_company_details' does not exist` In this commit, the company details warning was added to the l10n_ae_faf module, similar to account_saft. However, the action_fill_company_details method is only defined in account_saft, which is not a dependency of l10n_ae_faf. Therefore, when the user clicks on "your company" to open the company form [1], the method is not available and an error is raised. This commit ensures that action_fill_company_details is added to l10n_ae_faf so that clicking on `your company` opens the company form, as it does in account_saft. [this commit]: https://github.com/odoo/enterprise/commit/dffc4412df42507457810a0895be3b8f4dc7ec3f [1]- https://github.com/odoo/enterprise/blob/c8c2f13b7fd17e215044fc62774f2b4a378aaf8c/l10n_ae_faf/static/src/components/general_ledger/filters/warnings.xml#L3-L10 sentry-7676719103
Gantt charts using a weekly view now place tasks in the correct week based on the user's locale, such as weeks starting on Sunday. This prevents extra empty columns and keeps schedules aligned correctly without changing standard day, month, or year 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). Forward-Port-Of: odoo/enterprise#118625
The Field Service demo tour now waits for and fills the correct worksheet field whether standard or demo data is installed. This prevents the tour from failing or producing reports with missing worksheet sections, improving reliability for demos and automated checks.
Original PR description
The FSM tour needs to wait until the worksheet view is fully loaded before filling it. Otherwise, the tour may continue too early and the worksheet is not saved properly, causing the worksheet…
The FSM tour needs to wait until the worksheet view is fully loaded before filling it. Otherwise, the tour may continue too early and the worksheet is not saved properly, causing the worksheet section to be missing when previewing the task report. A synchronization step was added for this purpose by waiting for `x_comments`, the default HTML field of a worksheet. (Related: https://github.com/odoo/enterprise/pull/116918) However, the demo Device Installation and Maintenance worksheet replaces the generated form view and does not render `x_comments`. It renders the `x_description` text field instead, causing the tour to time out when demo data is installed. To fix the discrepancy, we need to wait for the editable field of either worksheet variant directly. When the default worksheet is used, fill the `x_comments` HTML editor. When the demo worksheet is used, fill the `x_description` textarea instead. This keeps the synchronization needed to avoid the worksheet loading race while allowing the tour to run with and without demo data. [error-939242](https://runbot.odoo.com/odoo/error/939242)
Project filters that look at related tasks will no longer include template tasks by mistake. This keeps project search results focused on real work items and avoids confusion from template data appearing in day-to-day views.
Original PR description
Creating a custom filter for Projects with conditions on Tasks (`task.ids`) returns normal and template tasks. Template tasks are also `project.task` records. In all `project.task` views, there is a domain set to exclude all template tasks. Since this domain is only enforced in `project.task` views, if the search is done on another model's views, such as `project.project`, this domain is not enforced, resulting in template tasks being included in the search. Overriding `_search` on `project.task` ensures that when this method is called for `project.task` records, it will explicitly add the domain `['is_template', '=', False]`. The exceptions are when we're creating from project templates, looking at templates themselves, or checking access to a specific task. opw-6317164
Point of Sale cash in/out receipts now print correctly when the reason text is very long. This prevents company details at the bottom of the receipt from being squeezed into unreadable narrow columns, improving receipt readability for printed cash movement records.
Original PR description
Steps to reproduce ------------------ 1. link an epson printer to the PoS 2. open a session and make a cash out with a long line reason 3. print the receipt -> the company info at the bottom is…
Steps to reproduce ------------------ 1. link an epson printer to the PoS 2. open a session and make a cash out with a long line reason 3. print the receipt -> the company info at the bottom is printed on 2 or 3 characters per line and the reason is printed next to it Why it's happening ------------------ The reason value is a `float: right`, and with a long reason the float takes almost all the width of the receipt. The company info, which is below the reason since `fd8845b393fc`, is a `d-flex` block, and a flex container is not allowed to overlap a float, so it only gets the width that is left next to it. Its two columns become very narrow and, as they use `text-break`, the text is cut in the middle of the words. The fix ------- From 19.2 the receipt is rendered on the server and the label and the value are in a table, 2 cells side by side, so no overlaping there. We do the same here but with flex instead of tables, since it's simpler. We also add `text-break` on it for the reasons with a very long word. ### Before <img width="618" height="876" alt="image" src="https://github.com/user-attachments/assets/1580d040-a6f0-468e-9da4-830b9a71cdac" /> ### After <img width="682" height="651" alt="image" src="https://github.com/user-attachments/assets/d2ddf293-57b0-467e-aa87-7f761121915d" /> opw-6473483
The accounting dashboard now shows the full invoice or bill amount for items marked 'To Check', instead of only the unpaid balance. This avoids understating the value of documents that still need review, especially when partial payments already exist.
Original PR description
Currently, the "To Check" links on the dashboard display the residual amount of invoices and bills. Since the entire document needs to be checked regardless of partial payments, showing the remaining balance is misleading. This commit updates the `selects` list in `_get_to_check_payment_query` to use `amount_total` instead of `amount_residual`, ensuring the dashboard reflects the full value of the documents. Task-6478415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284171
The German tax report now preserves cents for the Kz83 amount instead of rounding or truncating it. This helps ensure XML tax filings show the correct two-decimal value, reducing the risk of inaccurate reported amounts.
Original PR description
Description of the issue this commit addresses: The German tax report XML casts Kz83 to an integer before formatting it. This truncates decimal values, causing amounts such as 26.40 to become 26.00. --- Desired behavior after this commit is merged: This commit preserves the Kz83 decimal value and formats it with two decimal places in the German tax report XML. --- task-6414439
This fix updates the Australian payroll API test setup so automated checks no longer fail because of authentication timeout constraints. It helps keep payroll-related validation reliable without changing day-to-day product behavior.
Original PR description
The constraints for the Australian payroll module caused the tests to fail on `auth_timeout`. This commit patches the test to bypass those constraints. runbot-231622
This fix ensures the mass mailing feature no longer treats temporary wizard screens as valid mailing targets. It prevents irrelevant or unusable options from appearing when users choose what records can receive mailings.
Original PR description
The search function ` _search_is_mailing_enabled` mistakenly used `model.is_transient()` (where the model is the `ir.model` record itself) to filter the transient models, which always returns `False` since `ir.model` is a regular persistent model. As a result, transient models (wizards) were never filtered out. This commit fixes it by using`self.env[model.model].is_transient()` to call `is_transient` on the actual model. Task-6458883 Forward-Port-Of: odoo/odoo#283781 Forward-Port-Of: odoo/odoo#282783
Credit card and cash journal statement lists can now open individual statements in form view from the accounting dashboard. This fixes a navigation issue that prevented users from reviewing statement details directly, reducing friction in day-to-day accounting work.
Original PR description
Issue: When opening the credit card statements list view from clicking the "Statements" button in the accounting dashboard of a credit card journal, the resulting list view does not allow clicking on any of the items to enter the form view Steps to reproduce: 1. Create a credit card journal and some credit card statements 2. Go to the accounting dashboard, and click on the button with three dots to the upper right of the credit card journal card and click "Statements" 3. Try to click on any of the statements in the list view and it won’t open any of them Cause: The window action for credit card journals (action_credit_statement_tree) was missing the form view in the view_mode Solution: Add form to the view_mode of action_credit_statement_tree. The cash journal bank statements window action (action_view_bank_statement_tree) was also missing the form view, so it was added as well opw-6449315 Forward-Port-Of: odoo/odoo#282816
Duplicating multiple projects at the same time now keeps each copied project’s milestones separate. This prevents copied projects from incorrectly receiving milestones that belonged to other selected projects, reducing cleanup and confusion for project teams.
Original PR description
Before this commit, duplicating several projects at once from the list view gave every copy the milestones of all the duplicated projects, because the copy loop assigned the milestones of the whole recordset instead of the ones of the project being copied. Duplicating a single project behaves correctly, which hid the issue. Steps to reproduce: - create two projects with milestones enabled, add a milestone to the first one and two others to the second one - select both projects in the list view and duplicate them Each copy contains the three milestones instead of only the milestones of its original project. Solution: Copy the milestones of the project being duplicated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278520
Email template images set to full width are no longer duplicated when prepared for Outlook. This keeps saved email HTML cleaner and prevents recipients using Outlook from seeing unintended duplicate image handling.
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#283874 Forward-Port-Of: odoo/odoo#282199
The lower TCS tax warning in Indian localization now correctly shows the link to view related journal items. This helps users quickly navigate from the warning to the accounting entries they need to review.
Original PR description
The `lower_tcs_tax` warning was using the "actions" key instead of "action". As a result, the warning message was displayed correctly, but the "View Journal Item(s)" action link was not shown. Forward-Port-Of: odoo/odoo#284095
This fixes an internal automated test for Knowledge calendar commands that was failing due to timing and input behavior. The change helps keep quality checks reliable so future updates to calendar-related Knowledge features can be validated without false failures.
Original PR description
In `knowledge_calendar_command_tour`, we were experiencing two issues 1. First, when we change the properties of a new calendar item, we were running into an issues where the tour would fail due to…
In `knowledge_calendar_command_tour`, we were experiencing two issues 1. First, when we change the properties of a new calendar item, we were running into an issues where the tour would fail due to not being able to locate the dropdown option to create a new property. This only occurs if you don't set a step delay on the tour. This happens because in the `editSelectMenuInput` helper, we first check if the dropdown is open bfore we proceed. Since the tour runs so fast, we detect that the dropdown for the first property is open, so we pass the check. However, this then closes since we've moved on to the next dropdown, and since nothing has been input into the next dropdown, the create option doesn't appear. Now, we ensure that the create option will be present before attempting to click it 2. Later in the tour, we attempt to edit the properties on a new calendar item. We previously used `edit` to edit the property name, however this resulted in the "Select a template" modal being opened, which broke the tour, since we needed to click elements behind it. Using `fill` instead to populate the text field doesn't produce this behavior, allowing the tour to proceed without error. [runbot-939647](https://runbot.odoo.com/odoo/error/939647?debug=assets)
This fix prevents a rare crash when Belgian Intrastat reporting checks company data in unusual access-rights situations. It mainly safeguards future customizations or edge cases, since the issue is not expected through the standard user interface.
Original PR description
Due to some trouble with tests, we found that in some cases, this function is called on the root company, and if the user does not have the access rights to read data from the company (users with system rights have them by default), it will cause a crash. This situation is not possible with the standard UI, but we fix it in case it becomes possible in a future version or customization. Forward-Port-Of: odoo/enterprise#128212
French VAT XML submissions now handle account holder names longer than the official 35-character limit by splitting them into two accepted fields. This helps prevent electronic filing rejections caused by long holder names.
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 Forward-Port-Of: odoo/enterprise#128239
A payment processing component was trying to use a function that no longer exists, which could cause errors when preparing ISO 20022 payment files. The fix updates the system to use the correct replacement function, helping keep payment exports working reliably.
Original PR description
Commit ba136c6bb4f3b18d885f6895e4961aa4f5ebd43d was forward-ported without removing a call to the `_sepa_sanitize_communication`, which did not exist in that version as it got removed in Odoo 18.1. This commit replaces that call with a proper function call. opw-6494497 opw-6498770 opw-6498768 Forward-Port-Of: odoo/enterprise#129019