Daily updates from Odoo
Wednesday, October 22, 2025
27 changes · saas-18.3
Resolved issues and error corrections
Shopee orders that are delivered but still awaiting buyer confirmation are now handled correctly. This prevents Odoo from incorrectly showing these delivery orders in an error state, reducing confusion for sales and operations teams.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
Point of Sale now correctly loads special products that are assigned to the same company as the PoS configuration. This prevents missing products during data reloads and helps ensure company-specific PoS setups work as expected.
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
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
Saudi e-invoices now keep negative amounts correctly for invoice lines that are not subject to VAT. This prevents unnecessary ZATCA validation warnings when sending invoices that include negative 0% tax lines, improving compliance feedback and reducing manual follow-up.
Original PR description
Adding a negative line with 0% tax on an invoice will make the validation succeed with a warning Steps to reproduce (with a SA company setup): - Create an invoice - Add a negative line with 0% tax - Confirm and send to Zatca Issue: The following warning can be observed in chatter [202] BR-O-08 : [BR-O-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject to VAT' the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not subject to VAT'. This occurs because in the e-invoice, the tax base is transmitted in absolute value opw-5072577 Forward-Port-Of: odoo/odoo#231737
Updating the UTM module could fail if users had created or edited tracking sources or media with duplicate names, such as LinkedIn. This change protects the default tracking records during module updates so upgrades complete without disrupting marketing link tracking data.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202567
Fiscal position tax mappings now ignore inactive taxes, preventing invoices from using taxes that should no longer be available. This helps keep invoice tax calculations aligned with current tax setup and avoids accidental use of obsolete tax rules.
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#230729
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
The event registration page now shows the date selection labels in the visitor's chosen language. This improves the experience for multilingual event attendees by avoiding untranslated English text during registration.
Original PR description
Scenario: - adds slots to an event - register to that event with another language Result: "Selected Date" or "Select a Date" is not translated or translatable. Fix: wrap those JS strings with _t function. opw-5167911
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
This update fixes and improves Odoo's internal unit testing tools, especially Hoot, so developers can diagnose failed tests and server errors more accurately. It also improves the test interface and documentation, reducing maintenance friction while keeping changes limited to the testing ecosystem.
Original PR description
## Pull Request HOOT 38 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/97851 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232474 Forward-Port-Of: odoo/odoo#231263
This pull request updates several automated tests so they work correctly with recent changes in Odoo's Hoot testing tools. The changes are limited to the test environment and help keep quality checks reliable without affecting customer-facing features.
Original PR description
## Pull Request HOOT 38 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/232536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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) ...
A typo in the Web Studio field list was corrected from “Multine” to “Multiline”. This makes the field name clearer and avoids confusion when users create or edit views in Studio.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
Invoice terms and conditions now refresh in the customer's selected language when that language is changed during invoice creation. This prevents invoices from showing terms in the wrong language and helps maintain clear communication with customers.
Original PR description
Issue: When changing the customer’s language during invoice creation, the terms & services were not retranslated, unlike when creating a new partner in a different language. Repro Steps: 1. Create an invoice with terms link or plain enabled. 2. Change the partner's language from the invoice creation view. 3. Terms is not translated. Cause: The translation compute was only triggered on partner change, not language change. Fix: Added dependency for partner_id.lang to the narration compute to ensure it updates when the language changes. opw-5031933 Forward-Port-Of: odoo/odoo#230800
Long mailing list names now remain inside their designated area instead of overlapping nearby fields. This keeps the Marketing mailing list view readable and easier to use when records have lengthy names.
Original PR description
Issue: When you create a long name for your maling list, the name overflows over the other fields in the view. Repro: Go to marketing -> mailing lists -> create a fairly long name -> notice name overflows in the view. Cause: Small bootstrap issue, name field not limited to it's container. Fix: Added a simple w-100 to limit the field to 100% of it's container. opw-5153270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232312
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