Monday, August 31, 2026
18 changes · saas-19.3
Resolved issues and error corrections
The timesheet assistant now displays the add and remove suggestion buttons correctly within their border. This prevents visual overflow and makes the assistant easier and cleaner to use.
Original PR description
This commit ensures that the buttons to add/remove suggestions fit the border. task-6492978 Forward-Port-Of: odoo/enterprise#129345
When a recurring task series is ended by deleting the latest task, remaining tasks no longer keep the Recurrent option selected by mistake. This avoids confusing users into thinking those tasks will continue generating future tasks when the recurrence has already stopped.
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
WhatsApp proxy calls now send subscription details in the format the receiving service expects. This helps ensure WhatsApp OAuth subscription checks can read the needed database identifier reliably, reducing failed connection or validation flows.
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
This fix prevents rare crashes in Intrastat reporting when company data is accessed under unusual permission conditions. It mainly protects future customizations or edge cases, with no expected change to normal day-to-day use.
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 forum access test so it uses the correct helper forum and verifies that users need the right karma level to comment on someone else's post or reply. It helps ensure forum participation rules are tested accurately and reduces the risk of permission issues going unnoticed.
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-944703
Forward-Port-Of: odoo/odoo#281757Calendar invitation files now include the meeting's video call link in a standard URL field. This helps recipients and external calendar apps surface the join link more reliably.
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
Users can now click non-editable links to open the link information popover, even when the content is read-only. This makes it possible to view or inspect inserted links instead of having clicks 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#285310 Forward-Port-Of: odoo/odoo#280224
This update adjusts how Odoo loads email and certificate credentials so it remains compatible with newer operating system versions of a supporting security library. It prevents unnecessary warning messages in automated builds while keeping existing behavior for older environments.
Original PR description
pyOpenSSL 24.3.0 deprecated passing its own X509/PKey objects to Context.use_certificate()/use_privatekey(), and started accepting cryptography objects instead. Odoo pins pyopenssl 24.1.0, but the distro builds run the version shipped by the OS: since the test added by f0fb287c6502 covers that path, they now add a warning in the logs. Load the certificate and the key as cryptography objects when the installed pyOpenSSL supports them, keep the previous loaders otherwise. Reference: https://github.com/pyca/pyopenssl/commit/b0cb4b4 This fix is based on https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/odoo/addons/base/models/ir_mail_server.py#L34-L46 runbot-944176 Forward-Port-Of: odoo/odoo#284802 Forward-Port-Of: odoo/odoo#277449
Users configuring the French PDP service now see a consistent message when a migration has been requested. This avoids misleading timing such as “available tomorrow” and gives clearer expectations while the migration status is pending.
Original PR description
Currently when the user requested a migration, we don't show it in any way to the user, and the only timeline we give ("available tomorrow") is completely false. Because we don't have any field we could use for this client-side (maybe from 19.3 we can use the catch-all-json field) So just make the message same for everybody.
no-task
Forward-Port-Of: odoo/odoo#283702
Forward-Port-Of: odoo/odoo#283594LinkedIn posts now show hashtags properly in the feed view. This makes social content easier to read and helps users review published or scheduled posts with the expected formatting.
Original PR description
Task-6323897
Vendor bill payments with withholding tax no longer crash if the currency field is cleared during payment. The system now temporarily falls back to the company currency, keeping the payment flow stable while still requiring a currency before saving.
Original PR description
Currently, an error occurs when user tries to pay on a vendor bill and removes the currency. Steps to replicate: - Install `l10n_account_withholding_tax`and activate multiple currencies. - Open…
Currently, an error occurs when user tries to pay on a vendor bill and removes the currency.
Steps to replicate:
- Install `l10n_account_withholding_tax`and activate multiple currencies.
- Open Invoicing > Vendors > Bills and create a new bill and add a vendor and bill date.
- Add a product and tax `2% WTH`.
- From the Cog menu > Click Pay > Remove the Currency.
Error:
```
File '/home/odoo/src/odoo/saas-19.4/addons/l10n_account_withholding_tax/models/account_withholding_line.py', line 208, in _compute_original_amounts
line.original_base_amount = line_curr.round(base_amount * rate)
File '/home/odoo/src/odoo/saas-19.4/odoo/addons/base/models/res_currency.py', line 264, in round
self.ensure_one()
File '/home/odoo/src/odoo/saas-19.4/odoo/orm/models.py', line 5342, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: res.currency()
```
Cause:
- As the user removed currency, the `comodel_currency_id`is received as false.
- Later when we call `round()` on the empty res.currency recordset causes this error to occur.
Solution:
- Added the company currency as a fallback value when `currency_id` is removed by user, since `currency_id` is a required field user will need to select a currency when saving.
sentry-7616890592
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#283405
Forward-Port-Of: odoo/odoo#277507This fixes an issue where static file paths could be split incorrectly on Windows because the wrong path separator was used. It helps ensure Odoo can reliably serve static resources across operating systems without disrupting users.
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 Accounting dashboard now shows the Import File button for credit card and cash journals when file-based transaction feeds are enabled. This removes a confusing gap where users could configure file imports but had no visible way to start them from the journal card.
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
The Swiss payroll localization now limits the employee certificate dropdown to Swiss-specific choices. This prevents users working in the Swiss localization from seeing irrelevant default certificate options, reducing confusion and data entry mistakes.
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
This fix ensures that when employees join a course linked to skills, the related join notification is not posted more than once. It keeps activity messages cleaner and avoids confusing duplicate updates for users and managers.
Original PR description
`super` is idempotent, but the override is not --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed the Swedish tax report so Field 42 shows qualifying sales amounts as positive instead of negative. This helps Swedish companies review VAT reporting figures accurately and reduces confusion during tax checks.
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
Romanian SAF-T (D406) XML exports now use the officially expected AuditFileVersion value of 2.0 instead of 2.4.8. This helps companies generate compliant files for Romanian tax reporting and avoids potential validation or submission issues.
Original PR description
**Steps to reproduce:** - Install the `l10n_ro_saft` module and switch to the RO Company. - Navigate to Accounting > Reporting > General Ledger. - Click the gear icon > SAF-T (D406 Declaration). - Open the generated XML file and check the `AuditFileVersion` node. **Observation:** The `AuditFileVersion` node is set to `2.4.8`. **Expected behavior:** The `AuditFileVersion` node should be set to `2.0` (confirmed with the PO [1]) **Root Cause:** At [2], the `file_version` value is incorrectly set to `2.4.8` instead of `2.0`. [1]: https://www.odoo.com/mail/message/1144385840 [2]: https://github.com/odoo/enterprise/blob/ce2ad80c91aea27b143a80018aa73ed10d16cdbe/l10n_ro_saft/models/account_general_ledger.py#L179-L183 opw-6452918 Forward-Port-Of: odoo/enterprise#127935
The UAE FAF accounting report now opens the company details form correctly when users click the company warning link. This prevents an error that blocked users from completing required company information from the General Ledger.
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