Wednesday, October 22, 2025
18 changes · saas-18.3
Enhancements to existing features
Finnish accounting reports now include an export file for tax reporting, helping customers prepare submissions for the Finnish tax administration. The update also improves report export testing so the correct export options are used consistently.
Original PR description
The aim of this commit is adding the tax report export file to allow our customers to send their tax reports to their administration. task-5135868 Forward-Port-Of: odoo/enterprise#97799 Forward-Port-Of: odoo/enterprise#96256
Belgian contacts are now checked on the Peppol network using the two most common identifiers, improving the chance of correctly finding business partners. The update also removes outdated warning messages because the preferred Belgian identifier is now handled automatically during Peppol registration.
Original PR description
1. For belgian partner, we now check for 0208 and 9925 which are the two most used EAS when looking for partner existence on the Peppol network. 2. Remove the warnings about the recommended EAS: 0208 is now the mandatory EAS, this will be handled directly on IAP where the Peppol Access Point will try to register 0208 in all cases with an alias system. Note that we have always computed 0208 as recommended value in registration process. task-4852903 Forward-Port-Of: odoo/odoo#230089 Forward-Port-Of: odoo/odoo#227431
Resolved issues and error corrections
French VAT report submissions now better match ASPOne's required format. This reduces the risk of rejected filings caused by outdated address fields or address values that are too long.
Original PR description
This commit check that all the information that we send to aspone follow the constraint. By checking the xsd file, here what has been modified: - AdresseType is depreciated so we add AdresseRepetabilite - Adding a comment to remove a template not used in master - postal_code needs to have maximum 17 character - city needs to have maximum 35 character task-5169258 Forward-Port-Of: odoo/enterprise#97346
This fixes the payable total shown on Turkish e-invoice XMLs for invoices marked as Registered For Export. The amount now correctly reflects VAT deductions, helping ensure exported invoice documents match legal and accounting expectations.
Original PR description
When the invoice's type is "Registered For Export", the total of the invoice which is shown in the cbc:PayableAmount node in XML, has to reflect the VAT deducted amount. This PR fixes the given issue. task-5159638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231221
Users who choose to handle notifications inside Odoo could receive two browser alerts for the same message when push notifications were enabled and an Odoo tab was open. This fix prevents the duplicate alert so users receive a single, clearer notification.
Original PR description
**Steps to reproduce:** - Sign into one user - Go to his `Preferences` menu - Set notification to `Handle in Odoo` (`notification_type='inbox'`) - Enable push notification in the browser - Go to…
**Steps to reproduce:**
- Sign into one user
- Go to his `Preferences` menu
- Set notification to `Handle in Odoo` (`notification_type='inbox'`)
- Enable push notification in the browser
- Go to another window / browser (at the same time as the first one is opened)
- Log in with another user
- Go to any record with a chatter, then ping the first user with a message
- Two push notifications are received by the first user, for the same message
(This only happens if the receiving user tab is still open)
**Issue:**
When using default `notification_type='email'`, notification is created by
the mail part and sent with a web_push.
(`_notify_thread_by_email` and `_notify_thread_by_web_push`)
When using `notification_type='inbox'`, it is triggered as a bus notification and
a web_push, which led to duplicates on the user side.
(`_notify_thread_by_inbox` and `_notify_thread_by_web_push`)
Also, we can't just remove any of the two as they serve different purposes.
```
-> (backend) -> mail.thread
-> _notify_thread_by_inbox -> user with mail.thread -> bus.bus
-> (frontend) -> bus_service -> mail.out_of_focus -> notify -> serviceWorker -> "message" event -> browser web_push
-> _notify_thread_by_web_push -> stored devices -> push_to_end_point
-> (frontend) -> device -> serviceWorker -> "push" event -> browser web_push
```
**Fix:**
Reapply this fix https://github.com/odoo/odoo/commit/4fc16a3cc469dbdc206260487693a572ba62cbbe
to explicitly check for redundant notification when `this.store.self.notification_preference === inbox`.
The service worker only shows a push notification if no open tab refuses it, this is done
by sending a `notification-display-request` and if any tab answers with a
`notification-display-response` the notification is removed.
Seems to kind of work, but the notification might be rethrown in edge cases (quick refresh ?).
The fix ensures the browser ignore duplicate inbox push notifications since
they're already handled by `mail.message/inbox` bus notifications, and
the `modelsHandleByPush` heuristic in `out_of_focus_service.js` isn't reliable
enough to detect these cases. The logic should probably be improved in master.
opw-4639507
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221259Email-based job applications now keep the company from the job position when the related department has no company set. This prevents recruitment teams from losing key application permissions, such as assigning recruiters or interviewers.
Original PR description
When an applicant applied to a job position with a company_id and department_id, but the department itself had no company_id set, the application would have company_id set to False rather than the company_id from the job position. This caused bunch of issues such as the inability to add a recruiter or interviewers to the application.The bug seems to come from the default values created in the method `_alias_get_creation_values` on the job position, which sets the default company_id to the department's company_id when the job has a department that can result in False when the department exists but has no company set. task-5184275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232492
Budget line reports now show the committed amount for the specific budget line instead of counting amounts from the whole budget. This prevents duplicated committed values when budgets use multiple analytic plans, giving users accurate budget reporting.
Original PR description
Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677 Forward-Port-Of: odoo/enterprise#97514
Deferred dates on bill receipts are now kept correctly, and deferral entries use the right account when a bill is changed to a receipt. This helps prevent incorrect deferred revenue or expense accounting for receipt-type documents.
Original PR description
## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5. The account of the generated deferral entries is incorrect ## Fix While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value. In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates. In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator. For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account. opw-5129561 Forward-Port-Of: odoo/enterprise#97653
This fixes an issue where employee time off balances could be recalculated differently from the original approved duration, leading to incorrect remaining leave amounts. The change restores the previous calculation behavior so leave balances remain accurate and consistent.
Original PR description
The commit [2d536ae](https://github.com/odoo/odoo/commit/2d536ae02d75d15fa81efa03c54d8ea5fde39902) changed the duration compute for leaves balances, recomputing from scratch the duration and sometimes giving off results different than the original duration, giving off a wrong balance This commit reverts it. Forward-Port-Of: odoo/odoo#232196 Forward-Port-Of: odoo/odoo#231893
Fixed an issue where delivery operations using IoT printing would print only one label when multiple label files were attached. This ensures all required shipping labels are printed, reducing manual follow-up and helping warehouse teams complete shipments accurately.
Original PR description
Before this commit, only 1 label get printed even if multiple files are in the chatter After this commit we handle the cases with multiple files + revert suppression of public method for API opw-5181209 Forward-Port-Of: odoo/enterprise#97805
This fix prevents active customer live chat conversations from being accidentally canceled when a customer opens another chat. It ensures only still-pending chat requests are canceled, improving continuity for customers who may use multiple devices or sessions.
Original PR description
The website livechat module allows agents to start conversations with customers, but conversations are only displayed on the next navigation. Previously, pending chat requests were canceled whenever a customer opened a new live chat. The search condition for pending chats was too broad: it did not consider who started the conversation or whether it was already ongoing. As a result, ongoing chats could be unintentionally canceled. Customers could have multiple conversations (e.g. on different devices). This change ensures that only pending chat requests are canceled, leaving ongoing chats intact. task-5186567 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
Fixed Trial Balance PDF exports so search filters are applied correctly when hierarchy and subtotals are enabled. Users can now filter exported reports by account names, account codes, or account group names, helping exported PDFs match what they expect from the selected reporting options.
Original PR description
…xported pdf #### Issue In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name. #### Step to reproduce: - Create…
…xported pdf #### Issue In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name. #### Step to reproduce: - Create an account group (e.g Group_101 from 101 to 101) - Create some AML in an account related to the previously created group (e.g. in 101501 Cash) - Go to the Trial Balance ( Accounting > Reports > Audit Reports > Trial balance ) - In the Options select "Hierarchy and subtotals" - Add a filter including your group name (e.g. Group_101) - Export to pdf #### Current behavior: - No lines are displayed in the pdf as the backend uses only the account name to apply the filter #### Expected behavior: - Lines are displayed using account name and group name to filter #### Cause: - Filter was applied only on account name #### Solution: - If hierarchy is enabled, display accounts where filter appears on either account or group opw-4906593 Forward-Port-Of: odoo/enterprise#96338 Forward-Port-Of: odoo/enterprise#90403
Fixed an issue where creating multiple payslips for the same employee in one batch could duplicate the full expense amount across payslips. Expense amounts are now assigned to the correct payslip, helping ensure payroll calculations remain accurate.
Original PR description
since 9435b76 an issue arise when an employee gets two payslip generated for them in the same batch as both would get the full expense input line amount whereas only one gets the expenses linked to it. This adds a context key to bypass the computation when the payslips are created from a batch and trusting the create of the payslip to handle the proper assignation of expenses and computation of the lines Forward-Port-Of: odoo/enterprise#97776 Forward-Port-Of: odoo/enterprise#81987
This fix prevents the web editor's page monitoring service from repeatedly reconnecting when a user lacks permission to access a related document. It avoids unnecessary log noise and keeps the system more stable by only adding notification channels the user is allowed to use.
Original PR description
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img…
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" /> Each reconnect attempt causes a log entry: ``` 2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Marc Demo (id=6) doesn't have 'write' access to: - Lead/Opportunity, Modern Open Space (crm.lead: 25) Blame the following rules: - Personal Leads If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. ``` Current behavior before PR: Reconnect loop. Desired behavior after PR is merged: Do not add channels without sufficient rights. Related to: https://www.odoo.com/de_DE/my/tasks/5026412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231599 Forward-Port-Of: odoo/odoo#223890
This fix makes the website editor correctly recognize internal and frontend page links, including pages such as Contact Us, Shop, and category pages. Users should no longer see preview warnings or browser console errors, and link popovers can now show the page description when available.
Original PR description
Cherry pick of two commits from 18.4 Commit 1: 379d324 Previously, the link popover did not support frontend website pages (e.g., /contactus, /shop, etc.). Steps to reproduce: - Enter edit mode. -…
Cherry pick of two commits from 18.4 Commit 1: 379d324 Previously, the link popover did not support frontend website pages (e.g., /contactus, /shop, etc.). Steps to reproduce: - Enter edit mode. - Click on a link to a frontend page, such as "Contact Us". - An error was thrown in the browser console. - Also, the link popover did not show the page description (even if it existed). This commit: - Fixes the error that occurred in the browser console. - Adds support for frontend website pages in the link popover. - Displays the page description in the linkpopover, if available. (The page description refers to the SEO field that can be set via: Site > This Page > Optimize SEO > Description) Commit 2: b8908f3 Before this commit: the condition to check if an url is internal is not complete as the user could user the odoo instance domain instead of the real domain. The check if an internal url is a frontend one is rather naive as there are cases where the url ends with a number but actually not leading to a record. Reproduction for the second use case: 1. create a link with frontend url for example `/shop/category/16` 2. click on the link, when it loads the preview, a warning pops up After this commit, the cases explained above are included. task-4971829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232537
Website form fields that are still in use can no longer be deleted from the underlying model. This prevents crashes when editing website forms and guides users to remove the field from the form before deleting it.
Original PR description
The system crashes when a user tries to edit a website form field and that field has already been deleted from the model. **Steps to produce:-** - Install the `website` module. - Create a `new custom…
The system crashes when a user tries to edit a website form field and that field has already been deleted from the model. **Steps to produce:-** - Install the `website` module. - Create a `new custom field` on a model(for example, a field on the `mail.mail` model). - Website > edit > `add Form` widget to a page, and configure it to use the `mail.mail` model. - Add the newly created custom field to the form and save the page. - Now, `delete` the custom field which is created previously. - Return to the website page > edit > mark the deleted field as required, and attempt to save the changes. **Error:-** `ValueError: Unable to whitelist field(s) [''] for model 'mail.mail'.` **Root cause:-** - At [1], we can see that in the current version, it `only logs an error` using the logger, but in later versions, it `raises a ValueError` instead. **Solution:-** - This fix prevents a field from being deleted if it is actively used in any website form. - It adds a validation check that blocks the deletion and raises an error, forcing the user to remove the field from the form first. [1]: https://github.com/odoo/odoo/blob/d4f424d731fa93ccd232d0def0a7612997345ef7/addons/website/models/website_form.py#L123-L126 **sentry-5689731444** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219590
This fix prevents an error that could block users when assigning an account to bank statement lines with similar references. It ensures the automatic reconciliation rule created in the background uses a valid matching pattern, keeping bank reconciliation workflows running smoothly.
Original PR description
Currently, when a user uses the 'Set Account' button to reconcile a statement line, the system may also create a reconciliation model for fees for the given journal/account combination, based on the…
Currently, when a user uses the 'Set Account' button to reconcile a statement line, the system may also create a reconciliation model for fees for the given journal/account combination, based on the previous statement line reference pattern. To extract a patter from the references, the system computes the normalised longest common substring. This will be used as regex matching pattern of the newly created reconciliation rule. However, the common substring may end up with '\\', which is not a valid termination of a regex, leading to the error: `Invalid operation. The regex is invalid.` Steps to reproduce: - Have an account '646000 Test Account' - Create a Bank statement with label 'TEST REFERENCE BNK 2024' - Set Account 646000 - Create a Bank statement with label 'TEST REFERENCE BNK.OTHER' - Set Account 646000 Issue: Error `Invalid operation. The regex is invalid.` will raise blocking the action [opw-5086638](https://www.odoo.com/odoo/project.task/5086638) [opw-5062965](https://www.odoo.com/odoo/project.task/5062965) [opw-5123963](https://www.odoo.com/odoo/project.task/5123963) [opw-5166160](https://www.odoo.com/odoo/project.task//5166160) [opw-5159871](https://www.odoo.com/odoo/project.task/5159871) [opw-5160108](https://www.odoo.com/odoo/project.task/5160108) [opw-5109454](https://www.odoo.com/odoo/project.task/5109454) [opw-5086638](https://www.odoo.com/odoo/project.task/5086638) ...
Project and Sales administrators can now open and update SMS templates used for projects and tasks without access errors. This fixes incorrect access rules so authorized managers can manage customer communication templates from the project workflow.
Original PR description
**Issue** Project administrators are not able to manage SMS templates related to project models. **Steps to reproduce** - Have `project_sms` and `sale_sms` installed. - Have a regular user (not admin) with Project: "Administrator" and Sales: "Administrator" rights. - Go to Project/Task kanban view > cog icon on top of columns > edit > try to open/modify the SMS template. Issue: access rights error **Cause** - the rule in `sale_sms` is problematic because it is the only record rule affecting read operations, while other modules only target CUD operations. It has the effect of restricting read operations for Sale:Administrator users. - the rule in `project_sms` was referencing the wrong models, SMS templates are linked to `project.project` and `project.task`. opw-4908909 Forward-Port-Of: odoo/odoo#228590