Monday, August 31, 2026
21 changes · saas-19.4
Enhancements to existing features
The contract template screen now hides the Tax Deductions section when Professional Tax is not enabled in payroll settings. This avoids showing an empty or irrelevant section, making the setup experience cleaner for users.
Original PR description
Prior to this commit, the "Tax Deductions" group caption on the contract template view remained visible even when Professional Tax (PT) was not enabled in the Payroll settings. This commit updates the visibility condition of the "Tax Deductions" group on the contract template view to be hidden when PT is disabled (`not l10n_in_pt`), preventing empty settings sections from displaying to users. Task: 6514274 Forward-Port-Of: odoo/enterprise#129703
Resolved issues and error corrections
The timesheet assistant now displays its add and remove suggestion buttons within the intended border. This prevents small layout issues and keeps the interface cleaner for users entering or adjusting timesheets.
Original PR description
This commit ensures that the buttons to add/remove suggestions fit the border. task-6492978 Forward-Port-Of: odoo/enterprise#129345
Features or functions removed from Odoo
The French PDP e-invoicing setup no longer shows the pilot phase option because the early participation period has ended. This simplifies configuration and aligns the registration flow with the current legal timeline.
Original PR description
The pilot phase was there if people wanted to send before the deadline. The deadline has been reached, so we can remove the field from the view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285268 Forward-Port-Of: odoo/odoo#284186
Deleting the final task in a recurring task series now correctly removes the Recurrent indication from the tasks left behind. This avoids confusion where tasks appeared to be recurring even though no future tasks would be created.
Original PR description
**Problem:** Deleting one task of a recurrence suite ends the recurrence, but the tasks that stay behind keep the "Recurrent" option ticked. They look recurrent while no recurrence exists any more,…
**Problem:** Deleting one task of a recurrence suite ends the recurrence, but the tasks that stay behind keep the "Recurrent" option ticked. They look recurrent while no recurrence exists any more, so closing one of them never produces the next occurrence. **Steps to reproduce:** 1. Create a project with "Recurring Tasks" enabled 2. Create a task, tick "Recurrent" and mark it as done 3. Repeat on each generated occurrence until 3 or 4 tasks exist 4. Delete the last generated task 5. Open one of the tasks left in the suite **Current behavior:** The remaining tasks still show "Recurrent" ticked, but marking one as done creates no new occurrence and the recurring tasks smart button is empty. **Expected behavior:** Ending the recurrence should turn the "Recurrent" option off on every task that was part of it. **Cause of the issue:** `unlink` deletes the `project.task.recurrence` when the last task of the suite is removed, and `recurrence_id` is set to NULL on the other tasks by the database. Nothing resets their `recurring_task` boolean, so it stays `True` with no recurrence behind it. The two other places that end a recurrence, `write` and `action_unlink_recurrence`, already clear the flag on the whole suite. **Fix:** Aligning `unlink` with those two paths keeps a single meaning for `recurring_task`: it is only ticked while a recurrence actually exists. The suite has to be read before the recurrence is deleted, since the one2many is empty afterwards, and the tasks of the batch being deleted are left out so that no write lands on records that are about to disappear. opw-6425292 Forward-Port-Of: odoo/odoo#282535
Users can now click links in read-only website content to open the link details popover. This makes it possible to inspect or open non-editable links instead of having clicks appear to do nothing.
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#285445 Forward-Port-Of: odoo/odoo#280224
The AI assistant's "snappy and creative" response style now uses lighter reasoning settings, making it more distinct from the standard style. This helps align response behavior with user expectations for quicker, more concise creative answers.
Original PR description
Prior to this commit, the response style `snappy_and_creative` configuration for agent has been using the same reasoning level as the `standard` response style. With the response style instructions being dropped in prior commit, we now lower the reasoning from `standard` to `minimal` (`none`) so that it reflects better its category, and so that we have a proper distinction between different response style.
The WhatsApp connection flow now sends required proxy details in the format the service expects. This helps ensure subscription checks receive the needed database identifier and reduces the chance of failed WhatsApp setup or proxy calls.
Original PR description
The calls to the WhatsApp proxy sent their parameters as a JSON body, which a `type='http'` route does not unpack into its arguments, so the proxy needed a decorator to read them back before `check_subscription` could see `db_uuid`. Send them as form fields instead. `requests` encodes a dict as `application/x-www-form-urlencoded` and sets the header itself, so the routes fill their arguments on their own and the decorator goes away on the proxy side. Forward-Port-Of: odoo/enterprise#129815
Gantt charts using a weekly view now place tasks in the correct week based on the user's localization, such as weeks starting on Sunday. This prevents confusing extra empty columns and keeps scheduling views aligned with regional expectations 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). Forward-Port-Of: odoo/enterprise#129249 Forward-Port-Of: odoo/enterprise#118625
LinkedIn posts in the Social app now show hashtags properly in the feed view. This helps users review published or scheduled content accurately and avoids confusion caused by incorrectly formatted post text.
Original PR description
Task-6323897 Forward-Port-Of: odoo/enterprise#124233
This fix prevents a rare crash when Intrastat reporting logic is run in company access situations that are not normally reachable through the standard interface. It makes Danish, Lithuanian, and Swedish Intrastat handling more resilient for future customizations or edge cases without changing normal user workflows.
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#129083 Forward-Port-Of: odoo/enterprise#128217
This fixes a mismatch in the French PDP registration process caused by renamed routing fields. It helps ensure registration uses the correct information and avoids errors for businesses setting up French e-invoicing.
Original PR description
The fields have been renamed in routing_... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a missing dependency that could prevent the Brazilian AvaTax sales module from being installed in certain deployment modes. The change helps ensure installations complete reliably without missing-field errors.
Original PR description
Installing the module with `--skip-auto-install` fails because the field `l10n_br_avatax_warnings` can not be found in `sale.order`. `l10n_br_avatax` defines the field on `account.external.tax.mixin`, but that mixin is only added to `sale.order` by `sale_external_tax`. https://runbot.odoo.com/odoo/error/946049
Calendar invitations now include the online meeting link in a standard field that calendar apps can recognize. This helps recipients find and open the video call directly from their calendar event.
Original PR description
Add the meeting's videocall_location as a URL property in generated iCalendar (.ics) invitation files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283934 Forward-Port-Of: odoo/odoo#283562
Belgian payroll meal voucher reports now handle employees with a zero meal voucher amount without failing. This lets payroll teams generate the report successfully and still see the employee line with a zero total when applicable.
Original PR description
**Steps to reproduce:** - In a belgium company - Put an employee in sick time off during a whole month - Generate a mealvoucher report for this month Another steps to reproduce: - Create a payslip for an employee that has mealvoucher input > 0 - Mark the payslip as paid - Put the mealvoucher input at 0 for the employee - Correct the payslip - Generate a mealvoucher for the payslip month **Current behavior:** Crash **Expected behavior:** The line should show lorie poiret in the report with 0 total. It is debatable to either filter out the 0 line from the report or not as it is not a standardized report and that all providers has their interpretation. We decided to show it. task-6487876 Forward-Port-Of: odoo/enterprise#128716
In Swiss payroll, the employee certificate field now filters out non-Swiss certificate options. This reduces confusion for HR users and helps ensure the correct Swiss-specific certificate is selected.
Original PR description
The certificate field on the employee model was being extended by the swiss localization to add the swiss-specific certificates. This was done using selection_add on the field which was causing the selection to also show the original values defined on the base employee model. We don't want to see the original values but only the swiss ones when we operate in the swiss localization. At the same time, we can't just override the field (without using selection_add) because a warning is triggered. Other possible solustions like using the result of a function or changing the type of the field to Many2one to use a domain are either not working on a record-per-record basis or not stable compliant. The only working solution for stable is to keep the selection_add working and filter the results in the views using the filterable_selection widget. Task: 5948460 Forward-Port-Of: odoo/odoo#250046
The Accounting dashboard now shows the Import File button for credit card and cash journals when file import is enabled. This makes the import option visible and usable for these journal types, reducing confusion for users who had already configured file-based transaction feeds.
Original PR description
The "Import File" button on the dashboard card only shows up for bank journals. Credit card journals are treated the same way as bank journals pretty much everywhere else: the dashboard card itself,…
The "Import File" button on the dashboard card only shows up for bank journals. Credit card journals are treated the same way as bank journals pretty much everywhere else: the dashboard card itself, the statements list, the "Transaction Feeds" setting on the journal form (where you can pick the file import option), and even `create_document_from_attachment` in this module, which already accepts them. So you end up with a credit card journal set to import files but nothing on its card to actually do it, and people assume the feature is simply not there. Show the button on credit card journals too. Steps to reproduce: - Install account_bank_statement_import_csv (or any other import format) - Create a "Credit Card" journal and set its Transaction Feeds to the file import option - Go to the Accounting dashboard - The bank journal card has an "Import File" button, the credit card one doesn't --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#129546
This fix ensures that non-Latin characters, such as Chinese or Arabic text, remain readable when views are combined in the Studio XML editor. It prevents those characters from being converted into code-like entities, reducing confusion for users editing multilingual content.
Original PR description
Currently, when we combine the arch for the base views in the xml editor, we encode the text using the etree default of us-ascii. This causes special characters (chinese, arabic, etc.) to be converted to html codes. To rectify this issue, we set the encoding of the string to unicode. ### Before <img width="739" height="334" alt="before" src="https://github.com/user-attachments/assets/ad77fc47-08a0-42ed-b34b-d033779e9fc2" /> ### After <img width="673" height="334" alt="after" src="https://github.com/user-attachments/assets/1dae36c6-46d1-4189-b448-790aee18f319" /> opw-6325841 Forward-Port-Of: odoo/enterprise#128336
This update corrects how Odoo handles static file paths on Windows. It prevents path separator issues that could stop static resources from being located correctly in Windows environments.
Original PR description
In commit 31aad6c, path normalization was added which also resulted in `/` being converted into `\` on Windows. There the `path.split('/')` did not work.
This commit changes the `'/'` to `os.sep` to fix the issue.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#285265
Forward-Port-Of: odoo/odoo#285216The Swedish tax report now shows Field 42 amounts as positive when appropriate, instead of incorrectly displaying them as negative. This helps Swedish companies review and submit tax reporting figures with the correct presentation.
Original PR description
**Steps to reproduce:** - Install the `l10n_se` module and switch to a SE Company. - Navigate to Invoicing > Configuration > Taxes. - Create a tax and set the tax grid to `se_42`. - Create and…
**Steps to reproduce:** - Install the `l10n_se` module and switch to a SE Company. - Navigate to Invoicing > Configuration > Taxes. - Create a tax and set the tax grid to `se_42`. - Create and confirm an invoice for a Swedish customer using this tax. - Navigate to Reporting > Tax Report. - Check the amount of `Fält 42` under `Block E`. **Observation:** The `Fält 42 – Övrig försäljning m.m.` field shows the amount as negative instead of positive. **Root Cause:** At [1], the `se_42` formula is missing the negative sign. These lines were missed by the `tax_tag_invert` revamp done in https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b. **Fix:** This commit adds the missing negative sign to the `se_42` formula, ensuring that the amount for `Fält 42` is displayed as positive in the Swedish tax report, similar to [2]. [1]: https://github.com/odoo/odoo/blob/a56038c97e807388772ccc3a794cf0bf658a2076/addons/l10n_se/data/account_tax_report_data.xml#L356-L368 [2]: https://github.com/odoo/odoo/commit/b8125f38e80c1977eedda5fc6b9466ece5e9fd89 opw-6457529 Forward-Port-Of: odoo/odoo#281925
Fixed an issue in the UAE FAF accounting reports where clicking the company details link from the General Ledger could show an error instead of opening the company form. This helps users complete required company 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 Forward-Port-Of: odoo/enterprise#128327
This update prevents an access error when checking whether leave allocations are valid in Belgian payroll. It helps payroll and HR users complete allocation-related processes without being blocked by incorrect permission handling.
Original PR description
A sudo was missing in the check of the validity of the allocation. Forward-Port-Of: odoo/enterprise#129652