Friday, August 28, 2026
15 changes · 19.0
Resolved issues and error corrections
This fix updates forum access tests so they use the intended helper forum and correctly check that users need enough karma to comment on someone else's post or reply. It helps ensure forum permission rules are validated reliably and prevents misleading test results caused by demo data overrides.
Original PR description
**Issue:**
`website_helpdesk_forum` overrides the `ref('website_forum.forum_help')` in its demo data, allowing anyone to comment / post on it.
**Fix:**
Use the helper forum instead and properly requires `KARMA['com_all']` when posting a comment on someone else post/reply.
related: https://github.com/odoo/odoo/commit/ba19ef413e400a65e9f43a6fc6c4bc1586ea8983
runbot-944703Users can now add a new group in grouped list views that show totals without hitting an error. This keeps workflows such as CRM contact grouping stable when creating records directly from the list.
Original PR description
Adding a new group on a grouped list view with aggregates gives a traceback. This comes from `getFieldCurrencies` and `computeAggregates` which didn't guard for group with no currency aggregates (like a newly created group). Steps to reproduce: - open a list view (CRM) - group by a m2o (Contact) - click on 'Add a Contact' - press Enter => Traceback
When a recurring task sequence is ended by deleting its latest task, the remaining tasks no longer incorrectly appear as recurring. This prevents confusion for users by making the task status match the fact that no future tasks will be generated.
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
A Swedish tax report field now shows certain sales amounts as positive instead of negative. This helps businesses using Swedish localization see accurate figures in Field 42 and avoid confusion when reviewing tax reports.
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
This fixes a Windows-specific issue where static file paths could be split incorrectly after path normalization. It helps ensure Odoo can reliably serve static resources on 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#285216The inventory report now prints with correctly aligned rows and borders when warehouse locations are shown. This prevents confusing or unprofessional-looking PDF reports caused by missing gridlines.
Original PR description
When new columns were added to the stock inventory report, the location grouping row was not updated. This results in mismatched column counts, causing missing gridlines and broken borders in the PDF output Fixed by ensuring the location row's column count matches the header <img width="603" height="200" alt="image" src="https://github.com/user-attachments/assets/86872bee-f315-4bdd-b3f2-a525e3bb5fe0" /> ### Steps to reproduce: - Ensure warehouses are activated in the settings - Go to Barcode -> Count Inventory - Add a Product - Select the gear Icon then "Print Inventory" - You will notice that the location row has missing gridlines opw-6307728 Forward-Port-Of: odoo/odoo#275918
Fixed a permissions mismatch in Payroll contract cards that could trigger access rights inconsistency warnings after Payroll was installed. The contract card fields now follow the stricter Payroll access rules, reducing confusing warnings for HR and payroll users.
Original PR description
Since `hr_payroll` narrows `contract_type_id`, `structure_type_id`, `is_future`, and `is_past` to `group_hr_payroll_user` (tighter than the `group_hr_manager` used in the base `hr` view), showing these on the card triggered access rights inconsistency warnings once `hr_payroll` was installed. This was fixed with an inherited view in `hr_payroll` that tightens the relevant groups to match, following the same pattern already used there for the search view's date filters. opw-6475797
In the Swiss payroll localization, employee certificate choices are now limited to Swiss-specific certificates instead of also showing the standard options. This reduces confusion for HR users and helps them select the correct certificate values when working with Swiss employee records.
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
Fixes formatting problems in the Mail and Taiwan E-Invoicing app descriptions so they display correctly on the Apps page. This removes confusing raw text or incorrectly formatted lists and prevents repeated rendering errors behind the scenes.
Original PR description
Two module manifests hold a `description` whose reStructuredText does not parse. Both are rendered by `ir.module.module._get_desc` (these modules have no `static/description/index.html`, so the RST…
Two module manifests hold a `description` whose reStructuredText does not parse. Both are rendered by `ir.module.module._get_desc` (these modules have no `static/description/index.html`, so the RST path is the one used on the Apps page). ### `mail` The line introducing the list of email-enabled documents is followed by a row of dashes. In reStructuredText an underline directly below a line of text makes it a section title, so docutils treats a 102-character sentence as a heading, then fails on the indented list that follows without a blank line: ``` <string>:38: (ERROR/3) Unexpected indentation. <string>:43: (WARNING/2) Block quote ends without a blank line; unexpected unindent. ``` These are logged every time the description is rendered, and the bullet list ends up rendered as a block quote instead of a list. The dashes are dropped, since the line is a regular sentence and not a section title, and the list is surrounded by blank lines. ### `l10n_tw_edi_ecpay` The whole description is indented, which makes reStructuredText read it as a block quote. A section title is not allowed inside a block quote: ``` <string>:3: (SEVERE/4) Unexpected section title. ``` At SEVERE level this reaches the default `halt_level`, so rendering raises instead of returning a document and `_get_desc` falls back to showing the raw description in a `<pre>` block. The indentation is removed. --- Checked by rendering the `description` of every manifest under `addons/` and `odoo/addons/` with the same docutils settings `_get_desc` uses: these were the only two that reported anything, and both are clean after the change.
The French PDP registration wizard no longer shows a redundant “Production” label when the system is already in production mode. This avoids confusing users during registration and makes the screen wording more relevant.
Original PR description
It makes no sense to mention (Production) on pdp registration wizard when you are in prod mode Forward-Port-Of: odoo/odoo#280501 Forward-Port-Of: odoo/odoo#280360
This fix prevents an unexpected error from appearing when Odoo handles certain report actions. It improves reliability for users generating or accessing reports, with no expected change to normal workflows.
Original PR description
opw-6360013 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274977
Invalid VAT number warnings now display the exact value entered by the user, instead of accidentally dropping part of the country prefix. This reduces confusion when users save or import contact VAT details and helps them identify the value that needs correction.
Original PR description
Before this change: When entering or importing a VAT number (e.g., CHE-115.391.649), an invalid VAT warning displays a string missing its country_id (e.g., E-115.391.649). This confuses users and masks the actual input string that triggered the validation failure. To reproduce: 1. Open any contact record and set the Country to Switzerland. 2. Enter an invalid or manually formatted Swiss VAT number like `CHE-115.391.649`. 3. Save or trigger the VAT validation check. 4. Observe the warning banner showing `E-115.391.649` instead of `CHE-115.391.649`. After this change: The validation warning logic preserves the original user input when constructing the alert message, ensuring error notifications accurately display VAT number. Issue introduced by: * https://github.com/odoo/odoo/commit/ac95d2d6d80a368dfb190d0ac21da2af479a8488 * https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0 opw-6474217 Forward-Port-Of: odoo/odoo#284305
Notifications from the IAP mail flow now use the standard button feature instead of embedding button markup inside the message text. This makes alerts cleaner, more consistent, and easier for users to interact with across related workflows such as lead enrichment and snail mail.
Original PR description
Before this commit, the iap_mail was showing button with a markup in the message of the notification. Now, it use the buttons props that is made for the purpose. TASK-ID: 5088945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated walkthrough for field service sales by ensuring the signing flow handles page changes in the right order. It helps keep quality checks reliable so future updates are less likely to break this workflow unnoticed.
Original PR description
Solution: Reorder the signing steps and add `expectUnloadPage` when needed runbot-939241 Forward-Port-Of: odoo/enterprise#127442
This fixes how action buttons appear in IAP mail notifications for document extraction. Users now see the button through the standard notification layout, improving consistency and reducing display issues.
Original PR description
Before this commit, the iap_mail was showing button with a markup in the message of the notification. Now, it use the buttons props that is made for the purpose. TASK-ID: 5088945