Daily updates from Odoo
Wednesday, October 22, 2025
110 changes
13 changes
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
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
17 changes
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
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
9 changes
Enhancements to existing features
Finnish accounting reports can now be exported in the required file format for submission to the tax administration. This helps businesses prepare and send tax report data more easily and reduces manual handling.
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#96256
Resolved issues and error corrections
This fix updates French VAT report submissions so the address information sent to ASPOne follows the required format. It helps prevent rejected filings caused by postal codes or city names that exceed ASPOne's accepted limits.
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
Delivery label printing now includes every label attached to the delivery record, instead of printing only one when multiple files are present. This helps warehouse and shipping teams avoid missing labels and reduces manual reprints or shipping delays.
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
Fixes an issue where creating multiple payslips for the same employee in one batch could duplicate the full expense amount on each payslip. This helps ensure payroll expenses are assigned to the correct payslip and prevents overstatement of employee payments.
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#81987
Budget line reports now show committed amounts only for the selected budget line instead of counting matching amounts from the whole budget. This prevents overstated commitments when a bill is split across multiple analytic plans, helping users trust budget reporting figures.
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 checkout could load indefinitely when external tax calculation failed for Brazilian sales, such as missing product tax data or invalid addresses. Customers can now continue through checkout and see the relevant error message instead of getting stuck.
Original PR description
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with…
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with infinite loading. Examples include missing NCM codes or IAP service failures due to invalid addresses. **Steps to Reproduce** 1. Install Brazilian localizations (l10n_br, l10n_br_avatax, l10n_br_edi). 2. Configure Avatax Transfer API credentials (API ID and Key). 3. Create a website with a Brazilian company. 4. Add a product to the cart and proceed to checkout. 5. Choose a delivery method and observe that the UI gets stuck loading. **Root Cause** The `_order_summary_values` method in `website_sale_external_tax` called `_get_and_set_external_taxes_on_eligible_records()`, which could raise exceptions (e.g., IAPServerError). These exceptions were not handled, so they propagated to the frontend as generic RPC errors. The frontend has no built-in mechanism to display these exceptions as user-friendly messages, resulting in infinite loading. **Fix** Wrap the external tax calculation in `_order_summary_values` and catch `UserError`. Instead of letting the exception propagate as a generic RPC error, attach the error message to the result dictionary under `external_tax_error`. This prevents the frontend from hanging while still making the underlying problem visible in the next checkout step, where validation errors are properly handled and shown to the user. Opw-5052078 Forward-Port-Of: odoo/enterprise#95045
Bill and sales receipts now keep their deferred dates and generate deferral entries using the correct accounts. This prevents accounting errors when teams use receipt document types for deferred expenses or revenue.
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
Signature request and other inbox messages that are not tied to a specific record now show directly in the top messaging menu. This prevents users from seeing a notification count but finding no visible message when opening the menu, reducing confusion and missed requests.
Original PR description
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of…
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of the signature request, as the counter badge is updated. - When clicking on the badge, no new message is shown. **Issue:** Inbox messages are not considered in the `MessagingMenu` when they are not linked to any record. It's the case when a signature request is sent and while the notification counter is updated, the message can't be seen in the top bar menu, it's only visible in the `Discuss` app > Inbox which is quite confusing for the users. In previous versions the behavior was different as the signature request was either considered as an activity or no notification was sent. Also if the inbox message is linked to a record, it only appears in the `all` filter of the menu. **Fix:** Added the inbox explicitly to the top `MessagingMenu` to be able to read the corresponding messages. We could also link the signature to its record when sending the message instead of `self.env['sign.request']._message_send_mail()` but it might cause access rights issues. Also ensured that a category `others` was used for such messages, and prevented an error caused by clicking on the conversation when the `Discuss` app was opened. Unfortunatly doing this will show duplicates in the notifications of the menu for messages which are in the inbox but which have a record set. (e.g. when such message appears, it will have one line in the inbox and one for the record itself) So we need to filter out the messages which have a thread from their record in the views to avoid it. related: https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda opw-4969005
This fix prevents an error when users post WIP accounting entries while a manufacturing work order is still running. The system now handles active work orders without an end time, allowing the WIP wizard to open as expected and keeping costing workflows uninterrupted.
Original PR description
Issue: - Traceback when calculating the cost of a workorder Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" Current Behavior: - get a traceback Expected behaviour - open the WIP wizard Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. Solution: - check if the end date of the WO is defined Test: - in module mrp_workorder an override of button_start change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873 Forward-Port-Of: odoo/enterprise#93812
18 changes
Enhancements to existing features
The VoIP recent call experience is now cleaner and easier to use, with fewer visible buttons and related actions grouped into dropdown menus. Mobile users get the same actions in a bottom-sheet layout, making call follow-up tasks easier on smaller screens.
Original PR description
*: voip, voip_{ crm, hr_recruitment, sms } This commit introduces several improvements in the recent call tab in the VoIP interface: 1. There is always a maximum of 3 buttons to the left of the call…
*: voip, voip_{ crm, hr_recruitment, sms }
This commit introduces several improvements in the recent call tab in the VoIP interface:
1. There is always a maximum of 3 buttons to the left of the call card and one call button on the right.
<img width="466" height="188" alt="image" src="https://github.com/user-attachments/assets/ba7b3492-1205-4645-a101-42c2466bc196" />
2. Group all create actions in one dropdown menu.
<img width="381" height="313" alt="image" src="https://github.com/user-attachments/assets/dab7f172-2f24-43a1-a88d-952aca0b0a6c" />
3. Group regular actions + send actions in one dropdown menu with a separator. This also includes adding some actions that weren't there, like "subscriptions" and "tickets".
<img width="380" height="411" alt="image" src="https://github.com/user-attachments/assets/7d1f9284-6163-4a18-b0b7-f73018e2cc1e" />
4. All the mentioned dropdown menus above are open as a bottom sheet when opened on mobiles.
<img width="462" height="615" alt="image" src="https://github.com/user-attachments/assets/d5fa4233-d0e7-44b0-a0c9-d5fdb8e59c6e" />
Task-4962728Financial reports with many expanded lines now build display data more efficiently. This reduces waiting time for users viewing large account reports, with the provided benchmark improving from 2.65 seconds to 1.93 seconds.
Original PR description
The column dicts contains all the data needed for the ui to display each cell of a line. In order to compute them, we iterated over `aggregated_group_totals` ( which basically represents the data gotten from the query for each line) and then over each expression. But if we had a lot of lines, the operations we do with the expressions became expensive. With this commit, the operations on the expressions are processed first, then we iterate over the lines. Benchmark --------- For an `account.report` using a custom handler, containing 1 `account.report.line` and 6 `account.report.column`, which unfolds into ~5300 lines: | | Before | After | |-------------|-----------|---------| | Timings | 2.65s | 1.93s |
The German tax report has been reorganized after the removal of a balance column. This keeps the report logic aligned with the new layout and helps ensure tax reporting remains clear and reliable for German localization users.
Original PR description
After removing the balance column, we need to refactor the code that depends on it task-5046641
This draft update replaces several older pop-up, tooltip, notification, and menu elements with shared standard components across affected apps. This should make the user experience more consistent and easier to maintain, with a specific fix for planning calendar pop-ups.
Original PR description
Work in progress
Opening and folding the WhatsApp section in the Discuss sidebar is now more responsive. This improves day-to-day navigation for users who manage WhatsApp conversations in Odoo, reducing friction when switching between communication categories.
Original PR description
Part of Task-5003012
The softphone now shows direct buttons to a customer's helpdesk tickets and subscriptions. This helps sales and support teams get relevant customer context faster during calls, reducing navigation time and improving service responsiveness.
Original PR description
*: voip_helpdesk, voip_sale_subscription Task-4962728 Community: https://github.com/odoo/odoo/pull/225421
The Mexican localization demo company has been updated from Kemper School to a SAT-approved demo company that supports payroll stamping as well as existing electronic invoicing scenarios. This keeps demos and test flows usable for payroll, invoicing, stock, and accounting documents in Odoo 19.
Original PR description
The SAT has a list of ‘demo’ companies to enable invoicing demo operations through Electronic Data Interchange (EDI). Currently, in Odoo, the default demo company is Kemper School. However, with the release of payroll stamping in version 19, this company is no longer useful, as it cannot stamp payroll. So, instead of adding another company, we modified the Kemper School data to change it to another company that can stamp payroll and all other existing documents. The demo company data was changed, the certificates were changed, and a file that was never added to the manifest and therefore had no use was deleted. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95221
Follow-up and customer statement reports now have a cleaner header with centered titles and less clutter. Bank account information is shown near the tax ID, making key customer payment details 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#97546 Forward-Port-Of: odoo/enterprise#90068
Resolved issues and error corrections
Financial reports now use the correct closing exchange rate for currency translation adjustments, reverting a prior change that used the current rate. This helps ensure reported balances are more accurate and consistent for accounting and reporting decisions.
Original PR description
This reverts commit 0719c63a646c360a4b090745cd8105128332ef38. task-5085888 Forward-Port-Of: odoo/enterprise#97541 Forward-Port-Of: odoo/enterprise#97271
Manual AI server actions now include the current record information they need to complete follow-up actions such as creating records, scheduling activities, or sending emails. This makes manually triggered AI workflows behave consistently with automated ones and also improves access to AI auto-sort tools from the documents setup modal.
Original PR description
Purpose: -------- Currently, when an AI server action is triggered manually, the child server actions with state != code are not executed. Nothing happens because inside `_run`, the server action is executed on each record obtained by browsing the ids given by the `active_ids` and `active_id` keys in the context, which are not present (it works fine when the action is triggered by an automation because the record info is added in the context in `_process` in base automation). This commits adds the current records info in the context of the ai tools so that these server actions (such as create record, create activity or send mail) are now executed). Task-5107876 Forward-Port-Of: odoo/enterprise#95343
This fix ensures write-off entries created during journal item reconciliation are always treated as standard journal entries. It prevents errors caused by customized default entry types, helping accountants complete reconciliations reliably.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028
UPS shipment requests now include the VAT numbers for the sender and customer. This ensures commercial invoices generated for cross-border UPS deliveries show the required tax information instead of leaving VAT fields blank.
Original PR description
**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744 Forward-Port-Of: odoo/enterprise#82356
This update fixes several payroll accounting setup issues so salary structures receive the correct default journal regardless of installation order or active company. It also improves reliability of localization tests without demo data and prevents Chilean electronic invoicing logic from affecting documents for other countries.
Fixed an issue where budget line reports could show committed amounts twice when a bill used analytics from multiple plans. The report now matches the specific budget line, giving users accurate committed amounts for budget tracking.
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
Automatic printing after validating a delivery now includes both shipping labels and shipping documents in the normal validation flow. This prevents missed print actions when the page reloads, making delivery processing more reliable for users with connected IoT printers.
Original PR description
The `button_validate` method called clicking "Validate" returns a list of client actions to call. After these clients actions are executed, the page reloads. This reload makes our broadcasted action not to be caught by the client if there is only one connected. Anyway, this flow was overcomplicated and has been simplified overriding the method returning the client actions, adding the "shipping labels" and "shipping documents" to it. Forward-Port-Of: odoo/enterprise#97761 Forward-Port-Of: odoo/enterprise#97462
Public and portal users can now print or export shared Knowledge articles without getting blank pages. The fix ensures the right print styling is loaded and removes conflicting Planning print rules, improving reliability for customer-facing documentation and shared content.
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
Trial Balance PDF exports now correctly respect search filters when hierarchy and subtotals are enabled. Users can filter exported reports by account details or account group names, ensuring the PDF matches the report view and shows the expected lines.
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 accounting issue where deferred dates on bill receipts could be cleared and related deferral entries could use the wrong account. This helps ensure receipt-based deferred accounting is handled consistently with bills and sales 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
22 changes
Enhancements to existing features
The Taiwan localization now includes updated balance sheet and profit and loss reports that better match common Taiwanese business practices. The previous report versions are kept as legacy for now but are planned for removal in a future version.
Original PR description
This commit adds new improved accounting reports (balance sheet & profit & loss), providing users with improved reports that aligns better with the common Taiwanese business practices. The old balance sheet and profit & loss reports are depreciated and will be fully removed in later versions. [Task-4915057](https://www.odoo.com/odoo/project.task/4915057)
The Taiwan localization now includes a refined chart of accounts and updated default accounts aligned with common local business practices. This helps Taiwanese companies start with accounting structures that better reflect publicly listed company reporting formats.
Original PR description
This commit adds improved Chart of Accounts for Taiwan to better match common business practices. The chart of accounts, balance sheet, and profit and loss are referenced from the accounting structures used by publicly listed companies in Taiwan to ensure relevance and practicality. Updates: - Revise Taiwanese chart of accounts - Revise Taiwanese default accounts [Task-4915057](https://www.odoo.com/odoo/project.task/4915057) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mexican localization demo company has been replaced with one that supports payroll stamping as well as existing electronic invoicing demo flows. This keeps demos and testing usable for payroll, invoicing, stock, and accounting scenarios in Odoo 19.
Original PR description
The SAT has a list of ‘demo’ companies to enable invoicing demo operations through Electronic Data Interchange (EDI). Currently, in Odoo, the default demo company is Kemper School. However, with the release of payroll stamping in version 19, this company is no longer useful, as it cannot stamp payroll. So, instead of adding another company, we modified the Kemper School data to change it to another company that can stamp payroll and all other existing documents. The demo company data was changed, the certificates were changed, and a file that was never added to the manifest and therefore had no use was deleted. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Financial reports can now group account-based lines by account code before showing individual accounts when used across multiple companies. This makes cross-company reports easier to compare when different companies use matching account codes but separate account records.
Original PR description
If the report has a line that contains a group by `account_id` and if the report is multi-company, we allow the user the group per `account_code` before `account_id`. task-5092712
Equity transaction forms are now easier to read with fields in a clearer order and more understandable names for transactions, beneficial owners, and valuations. Price change tracking now shows the correct currency symbol, reducing confusion when reviewing transaction history.
Original PR description
This commit 1. Reorders fields on transaction form 2. Gives better display names for transactions, ubos, and valuations 3. Fixes the tracking of transaction security_price not having currency sign task-5144766
Follow-up and customer statement reports now have a simpler, more focused header with centered titles and fewer technical details. The reports also show the partner bank account below the Tax ID, making key payment information easier for customers 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
This change ensures older browsers load the compatibility support needed after users log into Odoo. It prevents backend crashes so affected users can continue using Odoo normally.
Original PR description
Description of the issue/feature this PR addresses: Old browsers crashing for Odoo 19.0 after logging into backend ``` TypeError: this._tables.difference is not a function\n at request.onsuccess (http://.../web/assets/d7f7d1b/web.assets_web.min.js:4763:464) ``` Current behavior before PR: Polyfill for Set difference() is only loaded in web.assets_frontend_minimal and not loaded after login since 2d56c0930f824ae9a8fd33c376e1dd9f34900ffa Desired behavior after PR is merged: Polyfill for Set difference() is also loaded in backend and the User can use Odoo. References: https://www.odoo.com/de_DE/forum/hilfe-1/error-code-new-to-odoo-278378 https://www.odoo.com/de_DE/forum/hilfe-1/there-is-an-error-please-solve-this-error-282526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Info @wt-io-it
This change prevents a client-side error that could appear when using Odoo 19 on mobile browsers, especially Safari on iOS. It replaces a browser-incompatible operation with a standard approach, improving reliability for mobile users on newly created databases.
Original PR description
Description of the issue/feature this PR addresses: Error occurred only on mobile device on v19.0 community installation with new created database. On the same device and browser no error on v18.0…
Description of the issue/feature this PR addresses:
Error occurred only on mobile device on v19.0 community installation with new created database.
On the same device and browser no error on v18.0 but always this error on v19.0
Error:
———————
UncaughtPromiseError > TypeError
Uncaught Promise > this._tables.difference is not a function. (In 'this._tables.difference(dbTables)', 'this._tables.difference' is undefined)
Occured on mydomain.fr on 2025-09-17 19:05:42 GMT
TypeError: this._tables.difference is not a function. (In 'this._tables.difference(dbTables)', 'this._tables.difference' is undefined)
@https://mydomain.fr/web/assets/debug/web.assets_web.js:48443:58 (https://mydomain.fr/web/assets/debug/web.assets_web.js:48443)
———————
Analyze:
——
Original: Using .difference()
const newTables = this._tables.difference(dbTables);
- This syntax assumes that _tables is a Set and that the difference method exists.
- However, native JavaScript has never defined Set.prototype.difference in the ECMAScript specification.
- In some environments (e.g., Node.js with a polyfill, or certain experimental JS engines), it might exist, but Safari does not have this method, which causes the error.
FIX: Using filter and new Set()
const newTables = new Set([...this._tables].filter(x => !dbTables.has(x)));
- Here, we convert _tables to an array, filter out elements that are not in dbTables, and then create a new Set.
- Everything is standard ECMAScript, so it works in all modern browsers, including Safari on iOS
Fix:
Use standardized JS function supported by all browsers in indexed_db.js
Test:
All is fine, no more error on client side
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue where company-specific special products could be missing from Point of Sale configurations for that same company. This ensures stores can reliably access the products assigned to their company after reloading PoS 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 the French VAT report submission so address details follow ASPOne’s required validation rules. It helps prevent rejected filings by limiting postal code and city values correctly and using the expected address field format.
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 inside Odoo and also enable browser push notifications will no longer receive two alerts for the same message. This reduces confusion and notification noise when users are working with Odoo open in a browser 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#221259The point of sale customer display now automatically scrolls to show the currently selected order line. This helps customers see the latest or active items clearly during checkout, reducing confusion at the register.
Original PR description
Steps to reproduce: - Turn on customer display in point of sale - Add some order lines - Customer display doesn't auto scroll Current behavior: - Customer display doesn't auto scroll Expected result: - Customer display should scroll to the selected lines
This fixes an issue where users configuring a website on iPhone or iPad Safari could not select dropdown values. The website setup flow now handles Safari's mobile behavior correctly, making configuration smoother on Apple mobile devices.
Original PR description
Scenario: - go to /website/configurator on safari iOS (ipad, iphone, …) - configure the website Result: the dropdown are not selecting a value Cause: 7a291d59909b2ee57111ddec35a20a2302291f29 fixed the issue on desktop safari by using pointerdown and pointerup handler, and handling the dropdown hiding in the pointerup. This work since events happen in order: pointerdown -> focusout -> pointerup -> focusin But on iOS safari the order is: pointerdown -> pointerup -> focusout -> focusin that is not taken into account by the fix. Fix: change the safari fix to close the dropdown on a focusin on another element following a focusout of a dropdown. opw-5129288
This fix prevents the mass mailing editor from crashing when users edit HTML content inside a pop-up and switch from text to an image. It improves reliability for users creating or editing email campaigns in modal windows.
Original PR description
Have a mass mailing html field in a modal click on some text then on some image Before this commit there was a crash. This was because some overlays use a sequence lower that the dialog they are related to. Hence, when the OverlayContainer reconciled its Owl list of element, the dialog got displaced, making the iframe unloading The Editor crashed subsequently, tryng to access the iframe's defaultView which did not exist anymore after unloading the iframe After this commit, this use case doesn't happen any more. This is really ad-hoc Owl cannot be fixed to account for iframes in that situation the web framework could do more to stack overlays in order to avoid this. related to task-5182993 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
Budget line reports now show committed amounts for the specific budget line instead of matching the whole budget. This prevents purchase or bill amounts from appearing doubled when multiple analytic plans are used, improving confidence in budget tracking.
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
Job applications created by email now keep the company from the job position when the linked department has no company set. This prevents hiring teams from losing key application settings, 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
Portal and public users can now print or export public Knowledge articles with the expected content and formatting. The fix adds the right print styling for Knowledge pages and removes a conflicting Planning print rule that could hide article content.
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 change prevents spreadsheet-specific print styling from being loaded in the general backend area, where it could interfere with printing Knowledge articles. Users should see fewer blank-page issues when printing or exporting content, while spreadsheet printing continues to use 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
Fixes an issue where changing rental dates in the online cart could shift the layout and make quantity buttons stop working. Customers can now adjust rental dates and quantities without the cart becoming difficult or impossible to use.
Original PR description
Steps to reproduce: =================== 1. Add a meeting product to the cart with the "Rental" option checked. 2. Go to the cart and change the date range. → The cart layout shifts to the left, and…
Steps to reproduce: =================== 1. Add a meeting product to the cart with the "Rental" option checked. 2. Go to the cart and change the date range. → The cart layout shifts to the left, and quantity buttons become unclickable. Cause: ====== Two separate issues caused this behavior: 1. **Layout shift:** When updating the date range, `cart_quantity` can be undefined. The logic that determines whether to toggle the `col-lg-7` class relies on this value. When undefined, it incorrectly assumes the cart is empty and shifts the layout to the left. 2. **Unclickable buttons:** The following line replaces the entire `.js_cart_lines` element: https://github.com/odoo/odoo/blob/abf9bc083c5a219a0b6fc0346dcd2a2cb503e081/addons/website_sale/static/src/js/website_sale_utils.js#L88 This removes all old elements (and their event listeners) and inserts new ones from the server. As a result, interactive buttons (e.g., quantity update) lose their functionality. Older versions didn't face this issue because they used jQuery event delegation, which automatically handled dynamic elements. Solution: ========= 1. Use a reliable check for cart emptiness by falling back on `data['website_sale.total']` when `cart_quantity` is undefined, 2. Restart the cart interaction after re-rendering to restore event bindings for clickable buttons. opw-5167866 related : https://github.com/odoo/enterprise/pull/97715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Trial Balance PDF exports now correctly apply search filters when hierarchy and subtotals are enabled. This ensures users see the expected account lines when filtering by either account details or group names, improving accuracy in exported audit reports.
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
Fiscal position tax mappings now ignore inactive taxes, preventing invoices from automatically using taxes that should no longer be available. This helps keep invoice tax calculations aligned with active accounting settings and reduces manual correction work.
Original PR description
With this commit we exclude inactive taxes from the tax mapping of fiscal positions. Steps: - Create a fiscal position FP that maps an active tax to an inactive one - Create an invoice, set FP and create add an invoice line with a product having the active tax -> The tax mapping is applied and the inactive tax is set, it shoudln't opw-5117775 Forward-Port-Of: odoo/odoo#231462 Forward-Port-Of: odoo/odoo#230729
Receipt-type bills now keep their deferred date settings and use the correct accounts when deferral entries are generated. This prevents accounting errors and avoids users having to re-enter deferred dates after changing document types.
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
14 changes
Enhancements to existing features
The device homepage now shows a clearer warning when downloading the SSL certificate fails. This helps users understand what went wrong directly on the page, reducing the need to inspect system logs or request technical support.
Original PR description
We improved the certificate status warning displayed on the homepage to avoid having to check the logs to know what went wrong while downloading the SSL certificate.
Resolved issues and error corrections
This update ensures French VAT report submissions sent to ASPOne follow the required format rules. It helps prevent submission errors by using the expected address field and limiting postal code and city values to accepted lengths.
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
Website editors can now open link previews for frontend pages like Contact Us or shop category pages without browser errors or incorrect warnings. The link popover also shows available page descriptions, making it easier to verify and manage links while editing content.
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
Odoo now correctly finds matching text even when it appears after a line break in longer descriptions or formatted content. This ensures automated rules and filters trigger as expected when using "contains" searches across multi-line text.
Original PR description
Problem: When the ilike comparator is applied in filtered_domain, it is unable to match text beyond a newline character (\n). This is due to the regex being used not having the DOTALL flag. Purpose: Add the DOTALL flag to the re.compile arguments when defining like_regex. Steps to Reproduce on Runbot: 1. Create an Automation Rule on the Task model with an Apply On condition of Description contains "test". 2. Create a Task and add an Info Banner element, then either within the element or afterwards include the "test" text, then save. 3. The automation rule does not trigger. opw-5134374
Delivery label printing now includes every attached label file in the chatter instead of printing only the first one. This ensures shipments with multiple label files are handled correctly, reducing manual reprints and fulfillment errors.
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
Public ecommerce customers could get stuck after a successful payment because the system hit an internal access error while confirming accounting records. This fix ensures the payment confirmation can complete reliably when restricted journal security settings are enabled.
Original PR description
Error in backend while public user payment confirmation Steps: - Install `website_sale` - Activate `restrict_mode_hash_table` on sale journal - From an incognito window, Make an order in ecommerce and pay it -> we get stucked on 'Your payment has been successfully processed' page because of an acces error in the backend This is because when posting a new move, we either to access or modify moves we get from `chain['moves']`, however these moves are returned with `sudo(False)` by `AccountMove._get_chain_info()`. opw-5128189
When users crop an image manually and then apply a shape, Odoo now keeps their chosen crop instead of reverting to the original image. Reset controls are also shown and styled more consistently, making image editing in the website editor clearer and more reliable.
Original PR description
Steps to reproduce: 1. Upload an image and manually crop it. 2. Apply a shape to the image. 3. We can see the image is original, not the one we just cropped. Issue: As part of task…
Steps to reproduce: 1. Upload an image and manually crop it. 2. Apply a shape to the image. 3. We can see the image is original, not the one we just cropped. Issue: As part of task [3678061](https://www.odoo.com/odoo/my-tasks/3678061), all shapes were applied using a 1:1 ratio for better UI. However, we didn’t account for cases where the user had manually cropped the image. In such cases, the shape was being applied to the original image with forced 1:1 cropping, ignoring the user's manual crop. Fix: Previously, applying a shape always cropped the image to 1:1 if crop was required and the aspect ratio wasn't already 1:1. This caused the user's custom crop area to be discarded. Now, a new `is-manual-crop` attribute is introduced. If present, the default 1:1 crop is skipped, preserving the user's manual crop. Also, the reset button didn’t appear for flexible crops(not using fixed ratios like 1:1 or 2:3) due to aspect ratio being 0/0. We now add the `o_we_image_cropped` class on save and remove it on reset to properly show or hide the reset button. After cropping, the reset button appears in red, while the transform reset button is grey. To maintain consistency, we are adding the `o_we_bg_danger` class to transformation button. This PR aims to respect the user’s manual crop when applying shapes. task-4718769
Website pages in right-to-left languages now load dynamic styling using the visitor's selected website language instead of the session language. This prevents portal pages with chatter from showing excessive blank horizontal space, improving usability for Arabic and other right-to-left users.
Original PR description
Scenario to reproduce from 18.0: - install right-to-left (eg. arabic) language on website - open a portal record with chatter (eg. /my/invoices/1) - switch to right-to-left language - scroll horizontally to the left Result: there is a huge amount of whitespace scrollable to the left. Cause: In 18.0, the chatter has an hidden textarea .o-mail-Composer-fake with position "left: -10000px; top: -10000px;". But the chatter assets (portal.assets_chatter_style) are called dynamically with getBundle which is using the session lang instead of the website lang. So the bundle is gotten with the wrong lang and the CSS is not rtlcss'ed and this create big whitespace to the left of the page. Fix: set the website request language when getting bundle for the frontend. Note: this PR also create a TestLangUrlCommon to prevent TestLangUrl tests of being run a second time in TestControllerRedirect. opw-5013485 Forward-Port-Of: odoo/odoo#223575
Point-of-sale orders are now synchronized one at a time instead of in large batches, reducing the risk of timeouts, missing orders, or incomplete synchronization. Loyalty coupon confirmations are also handled per order so rewards stay accurate even when syncing is delayed.
Original PR description
`syncAllOrders` method is now splitting the list of orders to synchronize them one by one. This allows to have better control over each order synchronization and error handling. Some customer were experiencing issues when synchronizing too many orders at once, leading to lost orders or orders not being synchronized properly. For example, synchronizing orders that needs to be invoiced takes too long and can lead to timeout issues. By synchronizing orders one by one, we ensure that each order is properly synchronized before moving to the next one. --- Modification in `pos_loyalty` module to adapt to this change: The `confirm_coupon_programs` method is now called for each order individually, instead of being called once for all orders in the `payment_screen`. This ensures that coupon programs are confirmed correctly for each order even when orders synchronization is delayed
This fixes an issue where deliveries linked to split manufacturing orders showed only the quantity from the original order, not the full produced amount. Businesses using make-to-order manufacturing will now see accurate delivery quantities after validating backorders, reducing shipping and fulfillment confusion.
Original PR description
Issue ----- After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity. Steps to…
Issue ----- After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity. Steps to reproduce ----- - Unarchive MTO route - Create a stored product - Routes MTO & Manufacturing - Empty BoM - Create a Sale Order for 3 units of the product & confirm it - Go to the linked MO and split it in 2 (quants of 1 and 2) - Confirm both MOs (and produce) - Go to the sale's delivery > The delivery's move only shows 1 unit of the product Why the move quantity is only 1 ----- After confirming the first of the 2 backorder productions, when we manufacture the product, we go through https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/mrp/models/mrp_production.py#L2054 Since the first backorder kept the existing move, it has the delivery move in `move_dest_ids` so we do https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091 Which creates a SML for the delivery move when reserving it https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1853-L1858 https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1950-L1971 This in turn triggers the computation of the move's quantity since it depends on the move's lines https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L382-L383 Our move ends up with a quantity of 1. When we proceed with the second MO, things are a little different since there is nothing in `moves_todo.move_dest_ids` when we do https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091 This means we don't create a new SML for the delivery move, so the quantity stays at 1. Why there is no move_dest_id ----- When splitting the production, we go through https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1815-L1829 We create new a MO and SM for the backorder. The SM is created here https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1894-L1915 When preparing the values, we correctly copy the `move_dest_ids` of the original MO's SM, see https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/stock_move.py#L646-L656 So when the backorder is created, its' SM has a correct `move_dest_ids`. The problem actually comes from what happens after `_split_productions` in `action_split` when we set the `date_start` https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/wizard/mrp_production_split.py#L68-L78 In the write, we get to a line where we access the production's state https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L931 This triggers a recompute of the field. https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L539-L552 In the compute, we access `move_finished_ids`, which again triggers a recompute. In this compute, we call `_create_update_move_finished` https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L800 The problem is that the move we create gets its' `move_dest_ids` from the MO instead of using the one populated using `group_orders` (098af2f). https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1142-L1167 ----- Ticket: opw-4865082
Project and Sales administrators can now open and update SMS templates used for projects and tasks without hitting an access error. This fixes incorrect access rules so authorized managers can maintain customer communication 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#228590
This fix ensures landed costs are applied only to the relevant remaining quantity in a lot, rather than the lot’s total remaining quantity. This prevents overstated inventory values when only part of a lot is affected, improving the accuracy of stock valuation and product costing.
Original PR description
## Issue: When a lot has remaining quantity not included in the landed cost’s moves, the resulting `stock.valuation.layer` amounts are incorrect Even though `compute_landed_cost()` provides the…
## Issue: When a lot has remaining quantity not included in the landed cost’s moves, the resulting `stock.valuation.layer` amounts are incorrect Even though `compute_landed_cost()` provides the correct base values ## Cause: The cost repartition used `lot_id.quantity_svl` that's the total quantity of the lot , which leads to an incorrect ratio when only part of the lot is impacted As a result, the landed cost amount can be overstated, depending on the difference between the lot's total remaining_qty and the move's remaining_qty This logic only works when all `stock.valuation.layer` of the lot are involved, which is not always the case https://github.com/odoo/odoo/blob/e72b25fffc8f07c51e9a72fe6310e8dd046da793/addons/stock_landed_costs/models/stock_landed_cost.py#L125-L142 ## Steps to reproduce: - Enable Lots & Serial Numbers in Settings - Create a product (Tracked by lot + Valuated by Lot + AVCO) - Create and validate two receipts for the same product and lot - Open Inventory > Products > Lots / Serial Numbers page of Inventory and select your lot (The cost should be 0) - Add Landed Costs for the first receipt - Add a line for a cost of 100$ and compute (You’ll see that one line with 100$ should be added) - Confirm the Landed Cost and click Valuation (The value of the line is doubled to 200$) - On the Lot/Serial Number page of your lot, the cost is also double that the expected value opw-5128570
The scheduled check for Mexican electronic invoice status now rotates through all eligible invoices instead of repeatedly checking the same first batch. This helps ensure cancellations or status changes from the SAT portal are detected across the full invoice set.
Original PR description
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return…
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.
Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.
This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.
This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.This fix ensures Argentine vendor bills for foreign suppliers consistently use the expected “Invoices and Receipts from Abroad” document type. It also aligns customer invoice defaults so foreign customers and suppliers receive the same suggested document type based on the selected journal, reducing manual corrections and compliance risk.
Original PR description
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del…
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively. In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners. With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers. Current behavior before PR: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers Desired behavior after PR is merged: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228635
7 changes
Resolved issues and error corrections
Event registrations now request the reCaptcha check only when the user submits the form. This prevents valid attendees from being blocked if they take more than two minutes to complete registration.
Original PR description
Steps to reproduce =============== 1. Enable reCaptcha in Settings and configure keys. 2. Go to an event and click Register. 3. Fill in the form but wait more than 2 minutes. 4. Submit the form ---> An error message is shown. When reCaptcha was enabled on event registrations, the token was being requested too early (during `willStart`). Since a token is only valid for 2 minutes, users who took longer to fill out the registration form encountered an error when submitting. After this commit, the reCaptcha token is requested only on submitting. This way, the token is always valid and the form can be submitted successfully, even after several minutes. Task-4982067 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
Portal users can no longer edit the customer field on shared project tasks, preventing accidental removal of the customer that they cannot restore themselves. The fix also restores reliable task creation for portal users by avoiding an access error when assigning the default customer.
Original PR description
Since the user can only set himself as customer for task in the portal view, we removed this option in order to avoid issues on the customer side. E.A. setting the customer to False, then save, and being unable to put back the original customer. 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
New field service tasks created from the portal now automatically use the current user as the customer when none is provided. This prevents task creation failures caused by a missing mandatory customer and makes field service workflows more reliable.
Original PR description
When creating a new FSM task in the portal view, the current user will now be set as default user instead of False. The fix is done to be more generic. The customer field is mandatory on fsm tasks, but there is no restriction on it in the backend side. So we might encounter a similar issue again. With assigning a default user for fsm tasks at the creation, we ensure that the field is always set.
Project and sales administrators can now open and manage SMS templates used for projects and tasks without running into access errors. This removes an incorrect permission restriction and ensures template rules apply to the right project-related records.
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
Portal users updating their account details will no longer accidentally overwrite custom bank account holder names when their name was not changed. This protects employee banking information from unintended edits during routine profile updates.
Original PR description
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a…
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a Bank Account with a custom Account Holder Name. 4. Log in to the Website using the Test User. 5. Navigate to My Account and click Edit Information. 6. Fill in the address details (without changing the Name) and click Save. 7. Go back to the Employee’s Bank Account and check the Account Holder Name. Observation: ------------------------- The Account Holder Name was overwritten to the partner's name. Issue: ------------------------- In `_compute_account_holder_name` method, https://github.com/odoo/odoo/blob/c3b543631bde96260082484a3baac19d942f6b9f/odoo/addons/base/models/res_bank.py#L104-L107 The Account Holder Name is always recomputed using the Partner’s name. When submitting the form from the frontend, the name field is included in the values sent to update the Partner, even if the user did not actually change the name. https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/portal/controllers/portal.py#L196-L205 which re-triggers this compute and as a result, the Partner’s name overwrites the Account Holder Name on the linked Bank Account Solution: ------------------------- Prevent the Account Holder Name compute method from being triggered when updating information from the frontend if the Partner’s name has not been changed. opw-5059247
The shop floor now shows the correct remaining quantity for each individual manufacturing operation when handling a backorder. This prevents workers from seeing the full backorder quantity in the edit popup when only a smaller amount is needed for that specific step, reducing production mistakes and confusion.
Original PR description
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total…
**PROBLEM** When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation. **STEP TO REPRODUCE** 1. create a BoM of product with 3 or more operations 2. Create a Manufacturing order for i.e. 10 unit 3. Open shop floor 4. Register the production in shopfloor: - Op1 – 10 units registered - Op2 – 7 units registered - Op3 – 5 units registered 5. At the end, a backorder is created for 5 units. 6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step. **CAUSE** When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order. **FIX** We should pass `qty_production` instead which is the quantity to produce for the specific step. opw-5011739
This fix ensures Argentine vendor bills for foreign suppliers consistently default to the expected “Invoices and Receipts from Abroad” document type. It helps businesses avoid incorrect invoice classifications and reduces manual corrections when processing foreign vendor transactions.
Original PR description
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del…
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively. In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners. With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers. Current behavior before PR: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers Desired behavior after PR is merged: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228635