Wednesday, October 22, 2025
15 changes · saas-18.4
Enhancements to existing features
Users can now download invoice exports as a single ZIP containing all supported formats, such as PDF and XML. This makes it easier for businesses to share sales and purchase invoices with accountants who may use different tools, especially in PEPPOL workflows.
Original PR description
With PEPPOL, many clients use Odoo for invoicing while their accountant uses another tool. To easily send invoices to the accountant, it’s important to export invoices for both sales and purchase. Adding a `Export ZIP` option to download invoices in all supported extensions (pdf, xml, ..etc) in the same zip. task-4946367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer statement and follow-up reports now have a cleaner header with centered titles and less clutter. They also show the partner bank account below the Tax ID, making key payment information easier to find.
Original PR description
This commit updates the layout for follow-up and customer statement reports. Changes made: --- **Follow-up & Customer Statement Reports:** - remove journal and filter details from header. - centered the title of the report. - Added the partner bank account display below the Tax ID. --- task-4823880 Forward-Port-Of: odoo/enterprise#90068
Resolved issues and error corrections
Fixed an issue where company-specific special products could be missing from Point of Sale setups for that same company. This ensures PoS users can reliably access the products configured for their company after reloading data.
Original PR description
### Problem When assigning a special product to a company, the product will not be loaded when accessed from a PoS config of the same company. The issue occurs because `product.sudo().company_id == self.company_id` fails as `self` is an empty recordset. ### Steps to Reproduce on Runbot * Add a company to the special PoS product. * Access a PoS config on the same company. * Reload data. * The product will not be loaded. original PR: https://github.com/odoo/odoo/pull/194451 opw-5157959 Forward-Port-Of: odoo/odoo#231273
This fixes Turkish Nilvera export e-invoices so delivery information is only included when required and placed correctly. It prevents Nilvera from rejecting export e-invoices that include discounts, helping affected invoices process successfully.
Original PR description
The Delivery node is only required for Export E-Invoices. Additionally, the position of the Delivery node should not follow the AllowanceCharge node. This inconsistency in node positioning causes a blocking issue on Nilvera’s side, preventing the successful processing of export E-Invoices with discounts. task-5155802 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230935
French VAT report submissions now follow ASPOne’s required data format more closely. This reduces the risk of rejected filings caused by outdated address fields or overly long postal code and city values.
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
Users who choose to handle notifications in Odoo and have browser push notifications enabled will no longer receive two alerts for the same message. This reduces confusion and notification noise when Odoo is open in another tab.
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#221259Job applications created by email now keep the company from the job position when the linked department has no company set. This prevents recruitment users from losing company context and avoids issues when 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 matching the whole budget. This prevents amounts from being doubled when a vendor bill is split across 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
Fixed an issue where creating multiple payslips for the same employee in one batch could duplicate the full expense amount across payslips. Expenses are now assigned and calculated only on the correct payslip, helping avoid payroll overstatements.
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
Fixed Trial Balance PDF exports so search filters are applied correctly, including when hierarchy and subtotals are enabled. This ensures users exporting filtered reports see the expected accounts and account groups instead of missing or unfiltered results.
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
Spreadsheet print styling was removed from a general backend asset bundle because it could interfere with printing Knowledge articles. This helps prevent blank print or export pages while keeping spreadsheet printing available through its dedicated print setup.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing Print Assets (Public View)** The knowledge public templates were also missing the `web.assets_web_print` bundle, preventing proper article rendering in print mode. ### Fix This PR addresses the first issue by removing spreadsheet print assets from the `web.assets_backend` bundle, since they're already available through their dedicated `spreadsheet.assets_print` bundle. The remaining issues are tackled in odoo/enterprise#92665 opw-4816241 Forward-Port-Of: odoo/odoo#230639 Forward-Port-Of: odoo/odoo#223434
Knowledge articles now print and export correctly for portal and public users instead of showing blank pages. This improves document sharing and access for external users by ensuring the right print layout is loaded and conflicting styles are removed.
Original PR description
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3.…
### Reproduction Steps 1. Install `knowledge`, `spreadsheet`, and `planning` modules 2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user 3. Log in as the portal user and attempt to print/export the article 4. Also attempt to print/export the same article from the public (unauthenticated) view **Result**: * As a portal user: a blank page is displayed instead of the article. * As a public user: a blank page is also displayed instead of the article. ### Root Cause The blank print issue comes from multiple problems with CSS asset loading in print mode: 1. **Spreadsheet Conflict (Portal View)** The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend. 2. **Missing Print Assets (Portal View)** The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting. 3. **Planning Conflict (Public View)** The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles. 4. **Missing CSS rules (Public View)** The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode. ### Fix This PR fixes problems 2, 3 and 4 by: * Removing the unused/irrelevant planning print styles * Ensuring `web.assets_web_print` is loaded in portal * Creating a new print bundle for the frontend view * Hiding the knowledge header in the public view when printing (to improve layout) The first issue is tackled in odoo/odoo#223434 opw-4816241 Forward-Port-Of: odoo/enterprise#96656 Forward-Port-Of: odoo/enterprise#92665
This fix prevents the editor from subscribing users to page update channels when they do not have the necessary access rights. It avoids repeated reconnection attempts and excessive log messages, improving stability and reducing noise for administrators.
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
Deferred dates are now preserved correctly on bill receipts, and deferral entries use the proper account when a bill is switched to receipt type. This prevents incorrect accounting entries and reduces manual corrections for finance teams using receipt 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.…
## 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#97824 Forward-Port-Of: odoo/enterprise#97653
Project and Sales administrators can now open and update the SMS templates used for projects and tasks without hitting an access rights error. The fix corrects permissions so authorized managers can manage these templates as expected.
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#232676 Forward-Port-Of: odoo/odoo#228590