Daily updates from Odoo
Navigate
Branch
Saturday, November 1, 2025
30 changes
13 changes
Resolved issues and error corrections
The Help page's "Browse Articles" button now sends portal users directly to the knowledge article linked to their Helpdesk Team. This prevents users from landing on an empty knowledge page and makes support self-service easier to use.
Original PR description
To reproduce: ============= 1. Create a Helpdesk Team linked to a Knowledge Article 2. Access the Help page on website as a portal user 3. Click on "Browse Articles" button -> redirected to empty knowledge home portal view Problem: ======== before this commit, redirection was made through the method `redirect_to_article` which will later call `_redirect_to_portal_view` that doesn't use the `article` parameter anymore as there is a patch on the front side to handle the redirection to the articale through the router, but as the calls are server-side, the patch is not applied and the redirection fails. Solution: ========= instead of calling `redirect_to_article`, directly redirect to the article's `website_url`. opw-5114885 Forward-Port-Of: odoo/enterprise#98363
Users importing Indian IRN invoice files no longer need extra company record permissions for the import to work. This prevents an access error and lets the invoice import process complete successfully for affected users.
Original PR description
When importing an IRN JSON as an invoice, users without sufficient access rights to `res.company` fields encountered an access error on `l10n_in_edi_production_env`. This commit uses `sudo()` to safely read the company’s EDI environment configuration without requiring extra permissions. Before this PR: Import failed with error: `You do not have enough rights to access the field 'l10n_in_edi_production_env' on Companies (res.company)` After this PR: Import proceeds successfully for users without `res.company` read rights. Forward-Port-Of: odoo/enterprise#98528
This fix prevents Point of Sale session numbers from being skipped when cash detail posting fails. Session names now advance only after the operation succeeds, keeping records easier to track and audit.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/enterprise/pull/98157 opw-5180712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233784 Forward-Port-Of: odoo/odoo#233183
Belgian POS session names now stay continuous when cash posting fails. The session number is only used after a successful operation, helping keep point-of-sale records consistent and easier to audit.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. related: https://github.com/odoo/odoo/pull/233183 opw-5180712 Forward-Port-Of: odoo/enterprise#98468 Forward-Port-Of: odoo/enterprise#98157
Stripe card payments in Point of Sale and Restaurant could be left in the wrong state after a customer added a tip, preventing future tipping from working correctly. This fix ensures Stripe payments are properly adjusted and captured when tips are added after payment, improving checkout reliability for businesses using POS tipping.
Original PR description
Since [^1], tip after payment has been broken for stripe as `_update_payment_line_for_tip` is no longer called anywhere. This means that all payments were put in as uncaptured and no future tipping would work. This PR fixes it by using the "new" send_payment_adjust method like ayden to guarantee the payments are properly handled. Note that this is solved by wrapping `capturePayment` into a new method `capturePaymentStripe` to keep the stable policy. A followup PR will move the data back to `capturePayment` in master with the new parameters. opw-5121568 [^1]: 9c37f42ef4e23372f5e2bdbb956b625b3a47d8e1 Forward-Port-Of: odoo/odoo#232574
Point of Sale now detects when its local browser database is missing required data areas after a module change and refreshes the database setup automatically. This prevents sessions from failing when features such as restaurant mode add new local storage needs without a manual version update.
Original PR description
Currently, new IndexedDB object stores are only created during the 'onupgradeneeded' event. This event only fires if the database version is manually incremented in the code. If a new module (e.g.,…
Currently, new IndexedDB object stores are only created during the 'onupgradeneeded' event. This event only fires if the database version is manually incremented in the code. If a new module (e.g., restaurant) adds a new object store to the PoS database schema but the `dbVersion` is not bumped, the store is never created. This causes the PoS session to fail when it tries to access the missing store. This commit modifies the `databaseEventListener` to add a check inside the `onsuccess` handler. After the database opens, it compares the list of required stores (`this.dbStores`) with the list of existing stores (`this.db.objectStoreNames`). If a mismatch is detected: 1. The current database connection is closed. 2. The `dbVersion` is incremented. 3. The database connection process is re-run. This forces the `onupgradeneeded` event to trigger, which then correctly creates the missing object stores, ensuring the database schema is always up-to-date. opw-5166049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233268
Odoo’s Peppol integration now uses Odoo’s IAP service to handle participant lookups as the old DNS method is being phased out. This helps ensure electronic invoicing continues to work when Peppol stops supporting the previous lookup approach.
Original PR description
From November 1st, CNAME DNS will be deprecated for Peppol lookups. From February 1st CNAME lookups will no longer be supported. The replacement are NAPTR DNS records. Multiple solutions were available, such as using DoH (e.g. with cloudflare DNS), but we ended up choosing to proxy DNS requests through IAP to centralize the lookups and make such specs upgrades easier to handle in the future. IAP is now responsible of doing the DNS lookup and fetching the service groups of the found SMP. IAP-side: https://github.com/odoo/iap-apps/pull/1227 task-5179969 Forward-Port-Of: odoo/odoo#233766 Forward-Port-Of: odoo/odoo#232483
Saudi e-invoicing checks now also run when a company has no country configured. This helps catch setup issues earlier and prevents automated EDI processing jobs from failing for all pending documents.
Original PR description
ZATCA invoice misconfigurations are only checked for if the company has Saudi Arabia set as its country. However, ZATCA EDIs can be generated without Saudi Arabia set as the country. Thus, companies without a company set can create EDI documents for misconfigured invoices. This may cause traceback errors which prevent the "EDI : Perform web services operations" cron from running at all. This commit ensures that configuration checks are run on companies without countries set (and adds a relevant unit test). opw-5057792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233078 Forward-Port-Of: odoo/odoo#231255
This fixes an issue where purchase order tax calculations could fail when multiple currencies were involved. The system now uses the currency of the current purchase order, helping users complete tax totals without errors.
Original PR description
On the tax computation, when trying to compute the total tax, customer was having an error " Expected singleton: res.currency(1, 69) " As Odoo is trying to get the currency of all the records instead of the one in the current order opw-5177551 Forward-Port-Of: odoo/odoo#233471
The Planning app now shows the recurrence banner only after recurring shifts have actually been created. This avoids confusing users with a banner that appears too early and has no practical effect yet.
Original PR description
**Steps to reproduce:** --------- 1. Create a shift. 2. Save the shift. 3. Open the shift and enable the recurrence. 4. Observe that the recurrence banner is immediately displayed. **Issue:** ----- The recurrence banner is shown as soon as a shift is marked recurring, even though no recurring shifts have been generated yet. This is misleading since the banner has no effect until the actual recurrence slots exist. **Cause:** ------- The banner visibility was based on repeat and id, so it appeared too early, before any recurring shifts were actually created. **Fix:** -------- Update the banner visibility condition to check for both repeat and recurrency. Now, the recurrence banner only appears once the recurrence record exists and recurring shifts are generated: task-5163851 Forward-Port-Of: odoo/enterprise#97245
Downloading document folders now avoids creating unintended subfolders when document names contain slashes. Slashes in downloaded file names are replaced with underscores, making extracted zip files easier and more predictable to use.
Original PR description
Bug === If you download a folder that has documents in it, with `/` in their names, then after extracting the zip, it will create folders for the part on the left of `/`. To solve that issue, we replace the `/` with `_`. Task-5109681 Forward-Port-Of: odoo/enterprise#96087
Adding multiple contacts to a mailing list through the wizard now records the subscription date correctly. This ensures marketing teams see complete and consistent mailing list history regardless of how contacts are added.
Original PR description
Steps to reproduce: ------------------------- 1. Install Email Marketing Module 2. Create a new Mail List 3. Go to Mailing List Contacts 4. Select multiple contacts from list and click on Add to List…
Steps to reproduce: ------------------------- 1. Install Email Marketing Module 2. Create a new Mail List 3. Go to Mailing List Contacts 4. Select multiple contacts from list and click on Add to List button 5. From wizard select the newly created list and click on Add button 6. Open one of the contact added in step 4 Observation: ------------------------- In the Mailing Lists tab of the contact, the newly added list does not show a Subscription Date. However, if we add the same through Add a line, the subscription date is shown correctly. Issue: ------------------------- When adding contacts to a mailing list through the wizard, the code https://github.com/odoo/odoo/blob/1e6ba783fcd898875dadb47924147688685707cf/addons/mass_mailing/wizard/mailing_contact_to_list.py#L34-L39 adds the contact using a direct database operation. This bypasses the ORM record creation for `mailing.subscription`, so the `create_date` (subscription date) is never set. Solution: ------------------------- Use `Command.create` on the `subscription_ids` field to properly create the `mailing.subscription` records and ensure the Subscription Date is set. opw-5055372 Forward-Port-Of: odoo/odoo#230284
This fix prevents archived bank account records from being counted when checking whether multiple contacts share the same bank account. Users will no longer see misleading duplicate bank account warnings on contact pages when the only matching records have been archived.
Original PR description
If a res_partner_bank record shares an acc_number with other res_partner_bank records, even archived ones, the field duplicate_bank_partner_ids still includes partners from those archived records. As…
If a res_partner_bank record shares an acc_number with other res_partner_bank records, even archived ones, the field duplicate_bank_partner_ids still includes partners from those archived records. As a result, the contact page shows a banner indicating other partners use the same bank account, even though those res_partner_bank records have been archived. Steps to reproduce the issue: 1. Create a new bank account which has the same bank account number as another bank account already associated to a partner 2. Assign this new bank account to another partner 3. Archive this new bank account 4. Go to the contact page of the partner (from step 1) which has a bank account with the same bank account number as the new bank account just created 5. A banner will pop up at the top of the contact saying that this partner uses the same bank account as the partner you set on the bank account in step 2 Solution: Add a condition to the JOIN clause that checks “other.active = TRUE” to ensure that other res_partner_bank records to search for that have the same account number are active. Also add a condition to the WHERE clause that checks “this.active = TRUE” to ensure that the current res_partner_bank record doing the search is active itself. opw-4967083 Forward-Port-Of: odoo/odoo#232018 Forward-Port-Of: odoo/odoo#231585
6 changes
Resolved issues and error corrections
This fixes an error that could occur when calculating taxes on purchase orders involving multiple currencies. Odoo now uses the currency from the current purchase order, helping users complete tax calculations without interruption.
Original PR description
On the tax computation, when trying to compute the total tax, customer was having an error " Expected singleton: res.currency(1, 69) " As Odoo is trying to get the currency of all the records instead of the one in the current order opw-5177551 Forward-Port-Of: odoo/odoo#233471
The planning shift recurrence banner is no longer shown immediately after enabling recurrence. It now appears only after recurring shifts have actually been generated, reducing confusion for users managing schedules.
Original PR description
**Steps to reproduce:** --------- 1. Create a shift. 2. Save the shift. 3. Open the shift and enable the recurrence. 4. Observe that the recurrence banner is immediately displayed. **Issue:** ----- The recurrence banner is shown as soon as a shift is marked recurring, even though no recurring shifts have been generated yet. This is misleading since the banner has no effect until the actual recurrence slots exist. **Cause:** ------- The banner visibility was based on repeat and id, so it appeared too early, before any recurring shifts were actually created. **Fix:** -------- Update the banner visibility condition to check for both repeat and recurrency. Now, the recurrence banner only appears once the recurrence record exists and recurring shifts are generated: task-5163851 Forward-Port-Of: odoo/enterprise#97245
Company logos are no longer fetched directly in the browser during partner search. The system now uses the updated logo provider through Odoo's enrichment service, improving reliability while limiting logo retrieval to enrichment flows.
Original PR description
Before this commit- We used to rely on clearbit to fetch the logo of the company on the client side After this commit- We replace it with logo.dev and remove the fetching of logo from client side and move it to the IAP task-5126337 IAP PR- https://github.com/odoo/iap-apps/pull/1234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233925 Forward-Port-Of: odoo/odoo#231397
Downloading a folder now safely handles document names that contain slashes. Slashes are replaced with underscores so extracted ZIP files keep the intended file structure instead of creating unexpected subfolders.
Original PR description
Bug === If you download a folder that has documents in it, with `/` in their names, then after extracting the zip, it will create folders for the part on the left of `/`. To solve that issue, we replace the `/` with `_`. Task-5109681 Forward-Port-Of: odoo/enterprise#96087
Fixed an issue where contacts added to an email marketing mailing list through the bulk add wizard were missing their subscription date. This keeps contact records accurate and consistent regardless of how contacts are added to a list.
Original PR description
Steps to reproduce: ------------------------- 1. Install Email Marketing Module 2. Create a new Mail List 3. Go to Mailing List Contacts 4. Select multiple contacts from list and click on Add to List…
Steps to reproduce: ------------------------- 1. Install Email Marketing Module 2. Create a new Mail List 3. Go to Mailing List Contacts 4. Select multiple contacts from list and click on Add to List button 5. From wizard select the newly created list and click on Add button 6. Open one of the contact added in step 4 Observation: ------------------------- In the Mailing Lists tab of the contact, the newly added list does not show a Subscription Date. However, if we add the same through Add a line, the subscription date is shown correctly. Issue: ------------------------- When adding contacts to a mailing list through the wizard, the code https://github.com/odoo/odoo/blob/1e6ba783fcd898875dadb47924147688685707cf/addons/mass_mailing/wizard/mailing_contact_to_list.py#L34-L39 adds the contact using a direct database operation. This bypasses the ORM record creation for `mailing.subscription`, so the `create_date` (subscription date) is never set. Solution: ------------------------- Use `Command.create` on the `subscription_ids` field to properly create the `mailing.subscription` records and ensure the Subscription Date is set. opw-5055372 Forward-Port-Of: odoo/odoo#230284
This fixes Turkish Nilvera e-invoices so VAT percentages are included correctly for withholding invoices. As a result, the VAT amount now appears properly on the generated Nilvera PDF, reducing confusion in tax documents.
Original PR description
Before this commit: For withholding invoices, the VAT percentage was not included inside the <cac:TaxTotals> node, due to this, the VAT amount was not displayed in the PDF in Nilvera. After this commit: The VAT amount is shown correctly in the <cbc:Percent> node inside the <cac:TaxTotals> node and percent amount appears correctly in the PDF. task-5225600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233929
1 change
Resolved issues and error corrections
Document downloads now replace slashes in file names with underscores before creating ZIP files. This prevents extracted downloads from accidentally creating extra folders, making downloaded document folders easier to use and understand.
Original PR description
Bug === If you download a folder that has documents in it, with `/` in their names, then after extracting the zip, it will create folders for the part on the left of `/`. To solve that issue, we replace the `/` with `_`. Task-5109681 Forward-Port-Of: odoo/enterprise#96087
2 changes
Enhancements to existing features
The depreciation schedule report now defaults to the previous year instead of the previous month. This better matches how businesses typically use the report when preparing completed-year financial filings such as tax returns or BNB attachments.
Original PR description
The depreciation schedule report is usually is consulted to be attached to the BNB and/or tax return of a completed financial year. For an ongoing financial year, it has very little value. Therefore default opening of the depreciation schedule report is changed from previous month(default value) to previous year. task-5167082 Forward-Port-Of: odoo/enterprise#97327
Resolved issues and error corrections
Downloading folders from Documents now avoids creating unintended subfolders when document names contain a slash. Slashes in downloaded filenames are replaced with underscores, making extracted zip files match user expectations and preventing confusing folder structures.
Original PR description
Bug === If you download a folder that has documents in it, with `/` in their names, then after extracting the zip, it will create folders for the part on the left of `/`. To solve that issue, we replace the `/` with `_`. Task-5109681 Forward-Port-Of: odoo/enterprise#96087
6 changes
Resolved issues and error corrections
The Planning app now shows the recurrence banner only after recurring shifts have actually been generated. This prevents users from seeing a misleading message before the recurrence is active and actionable.
Original PR description
**Steps to reproduce:** --------- 1. Create a shift. 2. Save the shift. 3. Open the shift and enable the recurrence. 4. Observe that the recurrence banner is immediately displayed. **Issue:** ----- The recurrence banner is shown as soon as a shift is marked recurring, even though no recurring shifts have been generated yet. This is misleading since the banner has no effect until the actual recurrence slots exist. **Cause:** ------- The banner visibility was based on repeat and id, so it appeared too early, before any recurring shifts were actually created. **Fix:** -------- Update the banner visibility condition to check for both repeat and recurrency. Now, the recurrence banner only appears once the recurrence record exists and recurring shifts are generated: task-5163851 Forward-Port-Of: odoo/enterprise#97245
Downloading folders from Documents now handles file names containing slashes more safely. Slashes are replaced with underscores so extracted ZIP files keep the expected flat file structure instead of creating unintended folders.
Original PR description
Bug === If you download a folder that has documents in it, with `/` in their names, then after extracting the zip, it will create folders for the part on the left of `/`. To solve that issue, we replace the `/` with `_`. Task-5109681 Forward-Port-Of: odoo/enterprise#96087
Ingenico payment terminals no longer trigger an error caused by repeated status updates when nothing has changed. The fix reduces unnecessary database requests and keeps payment processing stable, while also updating a deprecated internal call.
Original PR description
Currently when paying with ingenco there is an error: "Uncaught (in promise) TypeError: can't access property "payment_method", line is undefined." This is due to the fact that Ingenco sends requests to the database every second even when the status of the driver didn't change since the last payment. This PR fixes the issue by only sending requests to the database if a) THe driver status has changed b) A payment is being processed It also fixes the deprecation warning for isSet() replaced by is_set(). opw-5166439 opw-5181429 opw-5164612 opw-5170658 Forward-Port-Of: odoo/enterprise#98059 Forward-Port-Of: odoo/enterprise#97945
Adding contacts to an email marketing list through the bulk wizard now records the subscription properly. This ensures users can see when each contact was added, improving list history accuracy and consistency with manual additions.
Original PR description
Steps to reproduce: ------------------------- 1. Install Email Marketing Module 2. Create a new Mail List 3. Go to Mailing List Contacts 4. Select multiple contacts from list and click on Add to List…
Steps to reproduce: ------------------------- 1. Install Email Marketing Module 2. Create a new Mail List 3. Go to Mailing List Contacts 4. Select multiple contacts from list and click on Add to List button 5. From wizard select the newly created list and click on Add button 6. Open one of the contact added in step 4 Observation: ------------------------- In the Mailing Lists tab of the contact, the newly added list does not show a Subscription Date. However, if we add the same through Add a line, the subscription date is shown correctly. Issue: ------------------------- When adding contacts to a mailing list through the wizard, the code https://github.com/odoo/odoo/blob/1e6ba783fcd898875dadb47924147688685707cf/addons/mass_mailing/wizard/mailing_contact_to_list.py#L34-L39 adds the contact using a direct database operation. This bypasses the ORM record creation for `mailing.subscription`, so the `create_date` (subscription date) is never set. Solution: ------------------------- Use `Command.create` on the `subscription_ids` field to properly create the `mailing.subscription` records and ensure the Subscription Date is set. opw-5055372 Forward-Port-Of: odoo/odoo#230284
This fixes an intermittent automated test failure by ensuring the test environment includes the required HR data models alongside messaging and live chat models. The change helps keep validation runs reliable without changing business features or user-facing behavior.
Original PR description
*: hr, web Follow-up of https://github.com/odoo/enterprise/pull/98481 PR above added a new HOOT test in test_discuss_full_enterprise that is duplicate of a livechat tests, to cover good working of…
*: hr, web Follow-up of https://github.com/odoo/enterprise/pull/98481 PR above added a new HOOT test in test_discuss_full_enterprise that is duplicate of a livechat tests, to cover good working of feature when overrides like `ai` module are applied in code. It replaced a `defineHrModels()` into a `defineTestDiscussFullEnterprise()`, which is shortcut for the test helper `defineWebsiteHelpdeskLivechatModels`. This is because the new test needs livechat models, and it's hard to combine defineModels for odoo modules that do not strictly patch on top of each other. While it doesn't look like it, the test "can handle command and disable mentions in AI composer" sometimes asks for hr models and can fail non-deterministically because of that. This commit fixes the issue by adding hr models in the helper of `test_discuss_full_enterprise`. To combine same models together with ease, instead of defining subclasses for extension, the models are instead patched. Since the patch is made in place, they combine nicely without puzzling with combining models in the right order, something that even the actual models in python don't have to care about. Fixes https://runbot.odoo.com/runbot/build/92414152
This fixes an intermittent failure in an automated test for Enterprise discussion and live chat features. The change improves test reliability by ensuring the needed HR-related test data is consistently available, reducing false failures in validation pipelines.
Original PR description
*: test_discuss_full_enterprise Follow-up of https://github.com/odoo/enterprise/pull/98481 PR above added a new HOOT test in test_discuss_full_enterprise that is duplicate of a livechat tests, to…
*: test_discuss_full_enterprise Follow-up of https://github.com/odoo/enterprise/pull/98481 PR above added a new HOOT test in test_discuss_full_enterprise that is duplicate of a livechat tests, to cover good working of feature when overrides like `ai` module are applied in code. It replaced a `defineHrModels()` into a `defineTestDiscussFullEnterprise()`, which is shortcut for the test helper `defineWebsiteHelpdeskLivechatModels`. This is because the new test needs livechat models, and it's hard to combine defineModels for odoo modules that do not strictly patch on top of each other. While it doesn't look like it, the test "can handle command and disable mentions in AI composer" sometimes asks for hr models and can fail non-deterministically because of that. This commit fixes the issue by adding hr models in the helper of `test_discuss_full_enterprise`. To combine same models together with ease, instead of defining subclasses for extension, the models are instead patched. Since the patch is made in place, they combine nicely without puzzling with combining models in the right order, something that even the actual models in python don't have to care about. Fixes https://runbot.odoo.com/runbot/build/92414152
1 change
Resolved issues and error corrections
The Planning app now shows the recurrence banner only after recurring shifts have actually been created. This prevents users from seeing a misleading message before the recurrence setup has taken effect.
Original PR description
**Steps to reproduce:** --------- 1. Create a shift. 2. Save the shift. 3. Open the shift and enable the recurrence. 4. Observe that the recurrence banner is immediately displayed. **Issue:** ----- The recurrence banner is shown as soon as a shift is marked recurring, even though no recurring shifts have been generated yet. This is misleading since the banner has no effect until the actual recurrence slots exist. **Cause:** ------- The banner visibility was based on repeat and id, so it appeared too early, before any recurring shifts were actually created. **Fix:** -------- Update the banner visibility condition to check for both repeat and recurrency. Now, the recurrence banner only appears once the recurrence record exists and recurring shifts are generated: task-5163851 Forward-Port-Of: odoo/enterprise#97245
1 change
Resolved issues and error corrections
Product forms now show the correct tax information when a branch company uses taxes shared from its parent company. This helps users see accurate sale prices and tax details that match invoices and sales orders.
Original PR description
Steps: - Install account app. - Create a branch company under the main company. - Create a tax for the branch company. - Add a main company tax on a product. - Switch to branch company. Issue: - Tax…
Steps: - Install account app. - Create a branch company under the main company. - Create a tax for the branch company. - Add a main company tax on a product. - Switch to branch company. Issue: - Tax string is not displaying on the product form even though its setting tax from parent company on invoice line and SO line so its displaying wrong sale price on product form. Cause: - After [PR] taxes are only consider from current company even though company is branch company but in [17.0 PR] we share taxed and other accounting related data b/w main and branch company so if branch does not it's specific tax applied on product then it should take tax from its parent company. Fix: - Compute tax_string in product the way we compute tax on invoice line, SOL etc using `_filter_taxes_by_company` method this way it'll give proper tax which will be applied on related documents. [PR]: https://github.com/odoo/odoo/pull/194881 [17.0 PR]: https://github.com/odoo/odoo/pull/125642 opw-5042833