Daily updates from Odoo
Monday, September 22, 2025
162 changes
12 changes
Resolved issues and error corrections
This fix stops customers from editing rental dates after a rental product has already been added to the cart. It prevents checkout-disrupting errors when invalid date ranges are entered and keeps rental orders consistent.
Original PR description
An error currently occurs when an user attempts to change the rental start date to a value later than the end date while a product is already in the cart. **Steps to replicate:** * Install…
An error currently occurs when an user attempts to change the rental start date to a value later than the end date while a product is already in the cart. **Steps to replicate:** * Install `website_sale`, `stock` , `sale_renting` with demo data * Rental > Products > Printer > Sales > Turn `Out of stock: continue selling` off * Website > Shop > Printer > Select dates when printer is available * Add printer to cart > Set start date greater than end date by typing `ValueError: min() iterable argument is empty` **Cause:** This error occurs because [1] causes the `availabilities` list to be empty at [2] when retrieving combination information. This issue occurs in version `18.4` and later because the date picker remains editable after the product is added to the cart. The changes in [3] remove the `disabled` attribute after the product is added, allowing users to modify the date. **Solution:** * Prevent users from editing dates after a product is added to the cart, as done in version `18.3`, since all products must share the same dates as the one already in the cart, as specified in [4]. [1]: https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_stock_renting/models/product_product.py#L79 [2]: https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_stock_renting/models/website.py#L14-L19 [3]: https://github.com/odoo/odoo/commit/bbb2d98d9ab97ce729d59b9858b63daccf5434e2#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R230 [4]: https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_renting/views/templates.xml#L100 **Sentry-6803401968**
Fixed an issue where Saudi Arabia invoice PDFs could omit the company logo when another localization module was installed. This ensures printed invoices keep the correct branding and presentation for customers.
Original PR description
steps to reproduce: ------------------- 1. Install `l10n_sa_edi` and `l10n_latam_invoice_document` 2. Create and confirm an invoice. 3. Print the invoice PDF issue: ------ The company logo is not…
steps to reproduce:
-------------------
1. Install `l10n_sa_edi` and `l10n_latam_invoice_document`
2. Create and confirm an invoice.
3. Print the invoice PDF
issue:
------
The company logo is not printed on the invoice PDF.
cause of the issue:
-------------------
The `l10n_latam_invoice_document` hides the standard company logo if
`company_header` is set to true:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_latam_invoice_document/views/report_templates.xml#L6-L8
In the case of `l10n_sa`, the custom_header value is set because of this condition:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_sa/views/report_invoice.xml#L23
However, the condition in `l10n_latam_invoice_documnet` expects
a callable record instead of static XML data, which is incorrect:
https://github.com/odoo/odoo/blob/022fcbcf40a28afa56010f6130c26bb0503d5467/addons/l10n_latam_invoice_document/views/report_templates.xml#L9-L14
solution:
---------
Renaming the variable to `custom_header_sa` resolves the issue.
<details>
<summary>Click here to see:</summary>
Before:
<img src="https://github.com/user-attachments/assets/f4606a44-10ce-4038-92a3-2c8ec2a69edf"/>
After:
<img src="https://github.com/user-attachments/assets/70055155-63f2-4fec-aaf6-3bf5587f5591"/>
</details>
opw-4977422
Forward-Port-Of: odoo/odoo#225476Spanish translations for Peruvian tariff fractions and withholding codes were corrected so users see the right wording in localization workflows. This helps reduce confusion and supports more accurate Peruvian electronic document handling.
Original PR description
## Issue: The latest `tariff_fraction` entries were not properly translated into Spanish There were also inconsistencies in the translation of some `withhold codes` ## Cause: The `.po` and `.pot` files were not correctly populated In addition, the translation of "Others" in `l10n_pe_withhold_code` conflicted with `l10n_pe_edi_reason_for_transfer__13`, because the `msgid` is the same but not the `msgstr` should be different opw-4741731 Forward-Port-Of: odoo/enterprise#95019 Forward-Port-Of: odoo/enterprise#92758
This update ensures invoices for foreign customers use an alphanumeric Other Buyer ID in Saudi e-invoicing XML. This helps avoid ZATCA acceptance warnings and supports smoother invoice compliance checks.
Original PR description
When an invoice is being issued to a Foreign Customer, the Other Buyer ID (Other Buyer ID (BT-46) <cac:AccountingCustomerParty / cac:Party / cac:PartyIdentification / cbc:ID>) should be OTH and filled accordingly to avoid an acceptance warning from ZATCA. According to ZATCA, the value needs to be in alphanumeric format, even if the value does not follow the specific country's VAT format Task-id: 5075005 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#227294 Forward-Port-Of: odoo/odoo#226593
This fixes bus notifications so users receive updates for both their direct groups and any groups they inherit through roles. It prevents cases where administrators or other users with implied permissions missed automatic Discuss channel updates until manually reloading.
Original PR description
To target users of a group, bus notifications are sent on group records. To do so, user groups are added to its bus subscription. However, since odoo/odoo#179354, only explicit groups are added, not every implied group. It's incorrect. For example, sending on the user channel doesn't notify administrators while it should. Steps to reproduce (note that the steps are only working for admin): - Click the gear button on the sidebar in discuss page to navigate to the channel kanban view as admin - Click the `New` button and create a channel with an internal users group as `Auto Subscribe Groups` - Go back to the discuss main page. The new channel will not be pinned unless you reload the page See: https://github.com/odoo/odoo/pull/179354/files#r1954163704 Forward-Port-Of: odoo/odoo#217543
The website editor now correctly hides the image width setting when an image is placed inside a card. This restores expected behavior and helps prevent users from applying layout options that do not make sense in that context.
Original PR description
When converting the options to Owl, the behavior from commit [1], which hid the image width option for images inside cards, was lost. We are reintroducing it here. [1]: https://github.com/odoo/odoo/commit/4dcd1f9607ecc1ea932e02128a3e6f01d652cba6
Event track emails now use embedded image-based icons instead of relying on external icon fonts that many email systems do not support. This ensures recipients see the intended visual elements consistently in their invitations or notifications.
Original PR description
Font awesome classes must no be inserted into email as external servers do not use them so icons are not displayed. This commit replaces i tags with font awesome classes in mail by images. Task-5082165 Forward-Port-Of: odoo/odoo#226331
The automation rule trigger dropdown now uses the correct background color when dark mode is enabled. This removes a visual inconsistency, making the interface easier to read and more polished for users working in dark mode.
Original PR description
Steps: - Install `base_automation` - Enable dark mode - Open Automation rules - Create a new rule - open trigger dropdown - the dropdown background is still in light mode This commit apply $dropdown-bg on `o_field_base_automation_trigger_selection` opw-5064357 Forward-Port-Of: odoo/odoo#226666 Forward-Port-Of: odoo/odoo#226116
This fix prevents an error when a Chilean electronic tax document is imported more than once. Users now receive the intended message instead of encountering a system traceback, improving reliability for Chilean accounting workflows.
Original PR description
### Steps to reproduce: - Install 'l10n_cl_edi' and switch to a Chilean company - Import twice the same DTE XML file. ### Cause: This [commit](https://github.com/odoo/enterprise/commit/42744fcecdbd36ea0101070c68299227a9f204a6) forgot to add the `_()` method to format the message. As `append()` only needs one argument but two are given, there is a traceback. opw-5080094
This fix ensures contracts with no amount due are no longer incorrectly marked as needing an invoice. It helps teams avoid unnecessary invoice follow-up work and keeps subscription billing status accurate.
Original PR description
Forward-Port-Of: odoo/enterprise#94626
This fixes an error that could occur when point-of-sale orders calculated external taxes through AvaTax. Removing the outdated reference helps ensure tax data can be prepared without interrupting checkout or order processing.
Original PR description
Since [this PR](https://github.com/odoo/enterprise/pull/82623), defination of `_get_lines_eligible_for_external_taxes` was removed but a reference to it still remained, causing the following error when calling the `_get_line_data_for_external_taxes` method:. `AttributeError: 'pos.order' object has no attribute '_get_lines_eligible_for_external_taxes'` Fix: Removed reference to `_get_lines_eligible_for_external_taxes` from `_get_line_data_for_external_taxes` at [1]. [1]- https://github.com/odoo/enterprise/blob/9a1544d19c1f5f3546c04022a11601df43199d10/pos_avatax/models/pos_order.py#L15-L18 sentry-6843827499
Approval demo data no longer adds the same administrator approver twice. This prevents duplicate approval entries when users open their approval requests, keeping demo approval workflows cleaner and less confusing.
Original PR description
steps to reproduce: - install approvals with demo data - click on My approvals > My requests Issue: - approval category sets approver `user_admin` and demo data also sets `user_admin` as approver so it creates double entry for `user_admin` in DB Fix: - removed `user_admin` in approval request because it will be added directly through approval category task-4677549
8 changes
Resolved issues and error corrections
Survey invitation emails now correctly update their subject line when a different email template is selected. This prevents outdated or incorrect subjects from being sent and helps keep survey communications consistent with configured templates.
Original PR description
Description of the issue/feature this PR addresses: Fixed [previous commit] where the subject doesn't update when the template was updated. This was due to a filter in place preventing this from happening. Steps to reproduce on runbot: 1. Go to mail templates and search for Survey 2. Open the Survey: Invite template 3. Update the subject on this template 4. Open the Surveys app and select any survey 5. Click on Share and then enable send by email 6. Change the template being used 6. The subject will stay the same [previous commit]: https://github.com/odoo/odoo/commit/16a2c28c9aec307f7ce9dbed0a660b512db31f3a opw-4654411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227460 Forward-Port-Of: odoo/odoo#221049
Odoo now blocks invalid custom view changes before they can be saved. This prevents Web Studio from failing to open when a malformed customization is entered through technical settings, reducing disruption for users managing forms.
Original PR description
This error occurs when a user modifies a Studio-generated custom form view by updating it through the technical settings and adds an invalid XPath expression. As a result, Web Studio fails to open and load the view. **Steps to replicate:** * Install `contacts` and `web_studio` * Open form view for any contact and Add/remove any field using studio. * Go to technical>User Interface>Views> `Odoo Studio:res.partner.form customization` * Add the following line:`<xpath expr='/form[1]/field[6]'/>` inside data and save. * Go to contact form view and open studio. `ValueError:The element <xpath expr='/form[1]/field[6]'/> cannot be located in the main view` **Solution** * Prevent users from saving changes to a view by raising a validation error when an invalid XPath expression is detected. **Sentry-6678221213**
This fixes an issue where Saudi Arabia invoice PDFs could print without the company logo when certain localization modules were installed together. Businesses using Saudi invoicing get properly branded customer invoices again, improving document presentation and consistency.
Original PR description
steps to reproduce: ------------------- 1. Install `l10n_sa_edi` and `l10n_latam_invoice_document` 2. Create and confirm an invoice. 3. Print the invoice PDF issue: ------ The company logo is not…
steps to reproduce:
-------------------
1. Install `l10n_sa_edi` and `l10n_latam_invoice_document`
2. Create and confirm an invoice.
3. Print the invoice PDF
issue:
------
The company logo is not printed on the invoice PDF.
cause of the issue:
-------------------
The `l10n_latam_invoice_document` hides the standard company logo if
`company_header` is set to true:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_latam_invoice_document/views/report_templates.xml#L6-L8
In the case of `l10n_sa`, the custom_header value is set because of this condition:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_sa/views/report_invoice.xml#L23
However, the condition in `l10n_latam_invoice_documnet` expects
a callable record instead of static XML data, which is incorrect:
https://github.com/odoo/odoo/blob/022fcbcf40a28afa56010f6130c26bb0503d5467/addons/l10n_latam_invoice_document/views/report_templates.xml#L9-L14
solution:
---------
Renaming the variable to `custom_header_sa` resolves the issue.
<details>
<summary>Click here to see:</summary>
Before:
<img src="https://github.com/user-attachments/assets/f4606a44-10ce-4038-92a3-2c8ec2a69edf"/>
After:
<img src="https://github.com/user-attachments/assets/70055155-63f2-4fec-aaf6-3bf5587f5591"/>
</details>
opw-4977422
Forward-Port-Of: odoo/odoo#225476This fix updates Spanish translations used in Peruvian electronic invoicing and stock documents, including tariff fraction labels and withholding code names. It helps businesses avoid confusing or inconsistent wording in localized tax and logistics records.
Original PR description
## Issue: The latest `tariff_fraction` entries were not properly translated into Spanish There were also inconsistencies in the translation of some `withhold codes` ## Cause: The `.po` and `.pot` files were not correctly populated In addition, the translation of "Others" in `l10n_pe_withhold_code` conflicted with `l10n_pe_edi_reason_for_transfer__13`, because the `msgid` is the same but not the `msgstr` should be different opw-4741731 Forward-Port-Of: odoo/enterprise#95019 Forward-Port-Of: odoo/enterprise#92758
Bus notifications now include both direct and inherited user groups when deciding who should receive real-time updates. This ensures administrators and other users with implied group access see new auto-subscribed Discuss channels immediately without needing to reload.
Original PR description
To target users of a group, bus notifications are sent on group records. To do so, user groups are added to its bus subscription. However, since odoo/odoo#179354, only explicit groups are added, not every implied group. It's incorrect. For example, sending on the user channel doesn't notify administrators while it should. Steps to reproduce (note that the steps are only working for admin): - Click the gear button on the sidebar in discuss page to navigate to the channel kanban view as admin - Click the `New` button and create a channel with an internal users group as `Auto Subscribe Groups` - Go back to the discuss main page. The new channel will not be pinned unless you reload the page See: https://github.com/odoo/odoo/pull/179354/files#r1954163704 Forward-Port-Of: odoo/odoo#217543
This fixes unstable automated checks around live chat call status and agent assignment. It helps ensure live chat quality checks are consistent, reducing false failures during releases without changing customer-facing behavior.
Original PR description
Since [1], rtc sessions are garbage collected when creating new live chat sessions. Rtc sessions that didn't receive any update during the last minute are considered as inactive. This can interfere with agent assignation tests: operators in a call are not prioritized. If the session is garbage collected, they are not in a call, and tests can fail. fixes runbot-232705 [1]: https://github.com/odoo/odoo/pull/211359 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#227648
Duplicate detection now ignores company differences when a database only has one company. This lets users find and merge duplicate records that were previously missed, improving data cleanup accuracy.
Original PR description
**Issue** In single company databases, it wasn't possible to find duplicate records with different `company_id` values to merge them (in multi company databases, it is possible to enable the "Cross-Company" option on the deduplication rule). **Change** Always ignore the company field in single company databases. opw-4794408 Forward-Port-Of: odoo/enterprise#94797 Forward-Port-Of: odoo/enterprise#93184
The website editor now shows newsletter mailing list names without extra numbers when adding checkbox options. This makes the form setup clearer for users and avoids confusing labels in the editor.
Original PR description
In the "Subscribe to newsletter" form, "Add new Checkbox" on the web editor for "Subscribe to" field lists mailing list with number. This commit removes the number by fetching the records from mailing list via "name" and not "display_name". Steps to Reproduce: 1. Add a form 2. Change action to "Subscribe to Newsletter" 3. Click on "Subscribe to" field 4. Click on "Add new Checkbox" and you see the numbers on the list. opw-4730089 Forward-Port-Of: odoo/odoo#210891
4 changes
Resolved issues and error corrections
The trial balance period comparison now calculates end balance columns correctly for Profit and Loss accounts, using only the latest displayed year instead of adding prior years together. This prevents misleading balances and keeps previous years' amounts in the appropriate unaffected earnings account, improving financial report accuracy.
Original PR description
When activating the period comparison with the trial balance, the end balance columns used to sum the values of the displayed periods, which should not be the case for Profit and Loss accounts. Indeed, only the last displayed year should be used in the end balance, while the previous years' amount must be displayed in the unaffected earnings account. We used to optimize the query by computing in python the end balance on some conditions (for example analytic groupby filter). This wasn't actually totally working, for example the end balance columns used to display amounts in both debit and credit columns. This optimization is no longer possible since the P&L accounts of the previous fiscal years need to be displayed in the unaffected earnings account. task-4728887 Forward-Port-Of: odoo/enterprise#94600
This fixes incorrect Spanish translations for Peruvian electronic invoicing and stock-related tax/shipping codes. Users working in Spanish will see clearer, more accurate tariff and withholding labels, reducing confusion in local compliance workflows.
Original PR description
## Issue: The latest `tariff_fraction` entries were not properly translated into Spanish There were also inconsistencies in the translation of some `withhold codes` ## Cause: The `.po` and `.pot` files were not correctly populated In addition, the translation of "Others" in `l10n_pe_withhold_code` conflicted with `l10n_pe_edi_reason_for_transfer__13`, because the `msgid` is the same but not the `msgstr` should be different opw-4741731 Forward-Port-Of: odoo/enterprise#95019 Forward-Port-Of: odoo/enterprise#92758
This fixes errors in Danish minimal financial reports where extra signs caused incorrect values to be processed. Report labels and translations were also cleaned up so the reports are clearer and more consistent for users.
Original PR description
In the minimal reports of l10n_dk, it appears that some expression ended with a sign and the report engine was given wrong value. This commit will remove the extra sign to correct the report and also remove the letter or number before the name. This commit will remove the extra sign to correct the report and also remove the letter or number before the name. This commit will change the translation accordingly to the other commits task-4949062 Forward-Port-Of: odoo/enterprise#91135
A mislabeled language code in the Dutch balance sheet report has been corrected. This helps ensure the right translated term appears in financial reporting, reducing confusion for users viewing localized reports.
Original PR description
One term in the Dutch balance sheet was having the `nl` language code instead of `de`. This commit corrects that.
13 changes
Resolved issues and error corrections
Several help and documentation links across Odoo Enterprise were corrected to open the 19.0 documentation instead of the older 18.0 pages. This helps users reach the right guidance for their current version and avoids confusion from outdated instructions.
Original PR description
Community PR https://github.com/odoo/odoo/pull/227546. Forward-Port-Of: odoo/enterprise#95009
This fixes an issue that prevented Ecuadorian POS orders from being completed during payment validation. The update aligns the Ecuador e-invoicing POS logic with recent changes in the core payment flow, restoring normal checkout operations.
Original PR description
After the commit https://github.com/odoo/enterprise/commit/343efe41bc74e612c867d5109c196a11680866db, the `currentOrder` reference in the payment validation flow was replaced with `order`. However, this change was not reflected in `l10n_ec_edi_pos`, which still relied on `currentOrder`. As a result, attempting to validate a POS order raised an error, making it impossible to complete the order. This commit updates the logic to use `order` instead of `currentOrder`, aligning with the upstream changes and restoring proper functionality. opw-5099083 Forward-Port-Of: odoo/enterprise#95105
Odoo now recognizes Ecuadorian supplier invoice XML files downloaded from the SRI even when the invoice is wrapped inside a CDATA section. This allows vendor bills to be populated automatically from those files, avoiding manual entry for affected Ecuadorian companies.
Original PR description
### Issue: Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill…
### Issue: Ecuadorian customer can download their invoice's XML from the SRI, but the file contains the invoice in a wrapper tag (`<![CDATA[ ... ]]>`) that prevent the extraction of the data to fill the vendor bill form view. #### Steps to reproduce: - Install "l10n_ec_edi" and switch to an Ecuadorian company - Have a file downloaded from the SRI. - Go to Accounting > Vendor > Bills - Click "Upload" and select the file - The generated move is not populated with the data ### Cause: We are expecting the XML to not be in the tag `CDATA` and it gets ignored. ### Solution: The change is in `_get_import_file_type` to detect the new type of file as `'l10n_ec.factura'`. The CDATA content can be fetched by getting the content of the tag `comprobante`. We then try to convert the content of `comprobante` to XML. If it's possible, we have an XML on which we can do the same check as before to know if it's an Ecuadorian invoice. We then replace the `file_data['xml_tree']` by the content of `CDATA` to have the correct XML for the data extraction. opw-5004636 Forward-Port-Of: odoo/enterprise#94184
Updated automated tests for the Stock Barcode app to match a related platform change in how pack-adding actions are called. This helps keep barcode picking workflows reliable and prevents test failures during ongoing maintenance.
Original PR description
Following the change in the community counterpart in [#226043](https://github.com/odoo/odoo/pull/226043), `action_add_entire_packs` now uses ids instead of recordsets (as it's meant to be called directly through JS code). Adapt tests to reflect this change. Task-5065793 Forward-Port-Of: odoo/enterprise#94562
Free subscription contracts are now correctly cleared from the invoicing queue when there is nothing to bill. This prevents users from seeing or processing unnecessary invoice prompts for zero-value contracts.
Original PR description
Forward-Port-Of: odoo/enterprise#94626
Field service tasks created from a template now correctly keep the template's Under Warranty setting. This prevents warranty-covered work from being missed or treated incorrectly after task creation.
Original PR description
**Steps to reproduce:**
- Install industry_fsm_sale
- Create a task template with "Under Warranty" enabled
- Create a task from that template
**Issue:**
The created task does not carry over the "Under Warranty" value from the task template.
**Cause:**
The `under_warranty` field has `copy=False`, so the value is not transferred.
**Fix:**
Updated the copy method to check for `copy_from_template` in the context. If the task template has "Under Warranty" enabled, the field is explicitly set on the new task.
task: 5083386
Forward-Port-Of: odoo/enterprise#95114
Forward-Port-Of: odoo/enterprise#94924Spanish Mod347 tax reports now include withholding tax lines, so reported totals match invoices that use retentions. This prevents underreported sales or purchase amounts in affected Spanish tax declarations.
Original PR description
Withholding taxes should be taken into account in mod347 tax report. Steps: - Create a bill for a spanish customer - Set the amount of 40000, tax 21% and 15% withholding tax - Go to mod347 tax report -> Line "B - Sales of goods and services greater than 3.005,06 €" is showing 42,400.00 instead of 48,400.00 (same goes for other lines with similar configuration) Before this commit, custom engines domains were only including aml with payable or receivable account. With this commit, we include tax lines that are of type 'retencion' in the custom engines domains. opw-4448662 Forward-Port-Of: odoo/enterprise#95066 Forward-Port-Of: odoo/enterprise#94338
Odoo now ignores the company field when looking for duplicate records in databases that only use one company. This helps users find and merge duplicates that were previously missed because they had different company values.
Original PR description
**Issue** In single company databases, it wasn't possible to find duplicate records with different `company_id` values to merge them (in multi company databases, it is possible to enable the "Cross-Company" option on the deduplication rule). **Change** Always ignore the company field in single company databases. opw-4794408 Forward-Port-Of: odoo/enterprise#94797 Forward-Port-Of: odoo/enterprise#93184
Bookkeeper and related accounting users can now access the document summary section of Indian tax returns without being blocked by a permissions error. This removes an interruption in tax return review and helps finance teams navigate permitted records smoothly.
Original PR description
Before: - Bookkeeper users (`group_account_user`) encountered an access error of gstr document summary line when opening tax returns. - The error occurred because access rights were missing for the given model. Fix: - Added access rights for readonly, basic and accounting users. - Bookkeeper users can now view and navigate their permitted tax return records without errors. Impact: - Ensures smooth access to tax returns for Bookkeeper role. Forward-Port-Of: odoo/enterprise#94580
This update fixes an error that could occur when point-of-sale orders used Avatax external tax calculations. By removing an outdated internal reference, POS tax processing can continue reliably without triggering a system error.
Original PR description
Since [this PR](https://github.com/odoo/enterprise/pull/82623), defination of `_get_lines_eligible_for_external_taxes` was removed but a reference to it still remained, causing the following error when calling the `_get_line_data_for_external_taxes` method:. `AttributeError: 'pos.order' object has no attribute '_get_lines_eligible_for_external_taxes'` Fix: Removed reference to `_get_lines_eligible_for_external_taxes` from `_get_line_data_for_external_taxes` at [1]. [1]- https://github.com/odoo/enterprise/blob/9a1544d19c1f5f3546c04022a11601df43199d10/pos_avatax/models/pos_order.py#L15-L18 sentry-6843827499 Forward-Port-Of: odoo/enterprise#93490
Fixes Danish minimal financial reports so report lines use the correct names and calculation values. This helps prevent incorrect report output and keeps translations aligned with the corrected labels.
Original PR description
In the minimal reports of l10n_dk, it appears that some expression ended with a sign and the report engine was given wrong value. This commit will remove the extra sign to correct the report and also remove the letter or number before the name. This commit will remove the extra sign to correct the report and also remove the letter or number before the name. This commit will change the translation accordingly to the other commits task-4949062 Forward-Port-Of: odoo/enterprise#94350 Forward-Port-Of: odoo/enterprise#91135
The project budget demo data has been updated to remove sample purchase order content that is no longer relevant. This prevents demo environments from referencing purchasing features that are no longer required by the budgeting app.
Original PR description
Since 5cf91390dd7c320c3348d509d3f33a499e760259, `account_budget` doesn't depend on `purchase` anymore. Remove `purchase` related demo data. Forward-Port-Of: odoo/enterprise#95091
A mislabeled language code in the Dutch balance sheet report was corrected so the affected term appears under the right language. This helps ensure financial report labels are displayed consistently for users working with localized reports.
Original PR description
One term in the Dutch balance sheet was having the `nl` language code instead of `de`. This commit corrects that. Forward-Port-Of: odoo/enterprise#95118
26 changes
Resolved issues and error corrections
Fixed an issue where Saudi Arabia invoice PDFs could omit the company logo when another localization module was installed. This ensures printed invoices display the correct company branding for customers and compliance documents.
Original PR description
steps to reproduce: ------------------- 1. Install `l10n_sa_edi` and `l10n_latam_invoice_document` 2. Create and confirm an invoice. 3. Print the invoice PDF issue: ------ The company logo is not…
steps to reproduce:
-------------------
1. Install `l10n_sa_edi` and `l10n_latam_invoice_document`
2. Create and confirm an invoice.
3. Print the invoice PDF
issue:
------
The company logo is not printed on the invoice PDF.
cause of the issue:
-------------------
The `l10n_latam_invoice_document` hides the standard company logo if
`company_header` is set to true:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_latam_invoice_document/views/report_templates.xml#L6-L8
In the case of `l10n_sa`, the custom_header value is set because of this condition:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_sa/views/report_invoice.xml#L23
However, the condition in `l10n_latam_invoice_documnet` expects
a callable record instead of static XML data, which is incorrect:
https://github.com/odoo/odoo/blob/022fcbcf40a28afa56010f6130c26bb0503d5467/addons/l10n_latam_invoice_document/views/report_templates.xml#L9-L14
solution:
---------
Renaming the variable to `custom_header_sa` resolves the issue.
<details>
<summary>Click here to see:</summary>
Before:
<img src="https://github.com/user-attachments/assets/f4606a44-10ce-4038-92a3-2c8ec2a69edf"/>
After:
<img src="https://github.com/user-attachments/assets/70055155-63f2-4fec-aaf6-3bf5587f5591"/>
</details>
opw-4977422
Forward-Port-Of: odoo/odoo#225476Creating a field service task from a template now correctly keeps the template’s “Under Warranty” setting. This prevents service teams from losing warranty information when using task templates, helping avoid incorrect billing or follow-up handling.
Original PR description
**Steps to reproduce:**
- Install industry_fsm_sale
- Create a task template with "Under Warranty" enabled
- Create a task from that template
**Issue:**
The created task does not carry over the "Under Warranty" value from the task template.
**Cause:**
The `under_warranty` field has `copy=False`, so the value is not transferred.
**Fix:**
Updated the copy method to check for `copy_from_template` in the context. If the task template has "Under Warranty" enabled, the field is explicitly set on the new task.
task: 5083386
Forward-Port-Of: odoo/enterprise#95112
Forward-Port-Of: odoo/enterprise#94924This fixes bus notifications so users receive updates through both their direct groups and any groups they inherit. Administrators and other users with implied group membership will now see relevant Discuss channel updates immediately without needing to reload.
Original PR description
To target users of a group, bus notifications are sent on group records. To do so, user groups are added to its bus subscription. However, since odoo/odoo#179354, only explicit groups are added, not every implied group. It's incorrect. For example, sending on the user channel doesn't notify administrators while it should. Steps to reproduce (note that the steps are only working for admin): - Click the gear button on the sidebar in discuss page to navigate to the channel kanban view as admin - Click the `New` button and create a channel with an internal users group as `Auto Subscribe Groups` - Go back to the discuss main page. The new channel will not be pinned unless you reload the page See: https://github.com/odoo/odoo/pull/179354/files#r1954163704 Forward-Port-Of: odoo/odoo#217543
Spanish translations for Peruvian tariff fraction entries and withholding codes were corrected so users see clearer, consistent labels. This reduces confusion when working with Peruvian electronic invoicing and stock localization data.
Original PR description
## Issue: The latest `tariff_fraction` entries were not properly translated into Spanish There were also inconsistencies in the translation of some `withhold codes` ## Cause: The `.po` and `.pot` files were not correctly populated In addition, the translation of "Others" in `l10n_pe_withhold_code` conflicted with `l10n_pe_edi_reason_for_transfer__13`, because the `msgid` is the same but not the `msgstr` should be different opw-4741731 Forward-Port-Of: odoo/enterprise#95019 Forward-Port-Of: odoo/enterprise#92758
Bookkeeper and related accounting users can now open India tax returns without access errors on document summary lines. This keeps tax return review and navigation smooth for permitted users.
Original PR description
Before: - Bookkeeper users (`group_account_user`) encountered an access error of gstr document summary line when opening tax returns. - The error occurred because access rights were missing for the given model. Fix: - Added access rights for readonly, basic and accounting users. - Bookkeeper users can now view and navigate their permitted tax return records without errors. Impact: - Ensures smooth access to tax returns for Bookkeeper role.
Event-related emails now use embedded image icons instead of website-only icon styling. This helps recipients see the intended visual elements consistently across email clients and external mail servers.
Original PR description
Font awesome classes must no be inserted into email as external servers do not use them so icons are not displayed. This commit replaces i tags with font awesome classes in mail by images. Task-5082165 Forward-Port-Of: odoo/odoo#226331
Website sitemaps now avoid listing the same page more than once when website controllers are customized or extended. This helps keep sitemap files cleaner for search engines without changing which pages are included.
Original PR description
When extending controllers (e.g. `WebsiteSale.shop`), sitemap entries were duplicated because deduplication relied on the endpoint function object. Overridden methods result in different function objects but identical sitemap URLs, leading to duplicates. This commit fixes the issue by deduplicating on the generated sitemap location (`loc['loc']`) instead of the function object, ensuring unique URLs in the sitemap even when controllers are extended. Fixes #224193 Forward-Port-Of: odoo/odoo#226810 Forward-Port-Of: odoo/odoo#224406
This fixes an issue where changing an employee's check-in or check-out time could incorrectly reset approved extra hours to zero. Extra hours now recalculate when attendance times change, unless the user has intentionally edited the extra-hours value themselves.
Original PR description
**Steps to reproduce** - Automatically approved attendances. - Create an attendance and save it. - Note the "Extra hours" displayed. - From the form view, change the check in or check out and save…
**Steps to reproduce** - Automatically approved attendances. - Create an attendance and save it. - Note the "Extra hours" displayed. - From the form view, change the check in or check out and save it. - Issue: "Extra hours" are 0. Expected: they should be the same as "Worked extra hours", as the user has not manually modified the field. **Cause** Issue since cc81bb59f87540cf4dd8da65510417d8023ef65b The problem is that a 0 value for `overtime_hours` was computed for the `NewId` record used during edition in the interface. This meant `validated_overtime_hours` was also set to this value https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L171 and sent on save, which meant the value was not further recomputed in `_update_overtime`. https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L408 **Change** We avoid a recomputation of `validated_overtime_hours` in the interface (which wasn't useful anyway, it was set to 0) to avoid it being interpreted as a manual change by the user. opw-5003488 Forward-Port-Of: odoo/odoo#226393 Forward-Port-Of: odoo/odoo#222689
This fix corrects Philippine localization tax setup so VAT-exempt fiscal positions and taxes are classified properly. It helps businesses avoid incorrect tax labels or country restrictions when configuring Filipino company accounting.
Original PR description
### Steps to reproduce: - Install "l10n_ph" and switch to a Filipino company - Check the tax "0% Exempt", it has both "VAT Exempt" and "VAT Registered" ### Cause: The CSV was badly generated because of the fiscal position tax mapping before 18.3. ### Solution: Fix the CSV. Also delete the country for the fiscal position "VAT Exempt". This is a [recommendation from AYH on discord](https://discord.com/channels/678381219515465750/687337689988726949/1410930795329097880). opw-5044305 Forward-Port-Of: odoo/odoo#227261
The product comparison page layout has been adjusted so desktop visitors no longer see unnecessary horizontal scrollbars. This keeps the comparison table aligned with the page header and footer, improving the browsing experience without changing functionality.
Original PR description
This PR fixes an issue about the `website_sale_comparison` page showing an unwanted scrollbar on desktop. Since each `.o_wsale_compare_table_column` element comes with a padding on the left and right side, it was creating a misalignment between the page content and the page header and footer. With this commit, we fix the issue by assigning a new `width` to the container, based on those padding values. task-5076730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Automation Rules trigger dropdown now uses the correct background color when dark mode is enabled. This fixes a visual inconsistency so users get a cleaner, more consistent experience while creating automation rules.
Original PR description
Steps: - Install `base_automation` - Enable dark mode - Open Automation rules - Create a new rule - open trigger dropdown - the dropdown background is still in light mode This commit apply $dropdown-bg on `o_field_base_automation_trigger_selection` opw-5064357 Forward-Port-Of: odoo/odoo#226666 Forward-Port-Of: odoo/odoo#226116
This fixes an automated test so it works correctly when demo data is present. It helps keep quality checks reliable and prevents false failures during development and release validation.
This update corrects a typo in internal documentation for a core Odoo operation. It does not change how the system works, but helps keep developer-facing guidance accurate and easier to understand.
Original PR description
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
This fix updates an automated barcode inventory test so it waits for the correct step before continuing. It helps reduce false build failures and improves confidence in the stock barcode workflow validation.
Original PR description
The `test_put_packs_in_existing_pack` tour was using an erroneous trigger causing race condition. This commit replaces this trigger by another one to be sure previous step is completed before going forward. Runbot build error: [232638](https://runbot.odoo.com/odoo/runbot.build.error/232638)
A timing issue in an accounting guided test was fixed so product selection is properly recognized before the next check runs. This improves reliability of automated validation, especially when localization features take slightly longer to load.
Original PR description
Issue: The tour was failing because the product was not being selected in time. As a result, the subsequent step that checks whether the product is selected was consistently failing. Cause: In the Romanian localization, the `FetchInvoicesCogMenu` component uses an `isDisplayed` argument with async/await. This introduces a delay before the component is fully rendered. Meanwhile, the tour step was executing too early, before the product was actually selected. Fix: Increase the wait time to 1000ms to ensure the product is properly selected before the following step is executed.
This fixes an issue where subscription contracts with no amount due could still appear as needing an invoice. It helps keep billing queues cleaner and prevents staff from spending time reviewing contracts that should not generate invoices.
Original PR description
Forward-Port-Of: odoo/enterprise#94626
This update makes Malaysia electronic invoicing tests more consistent by using fixed tax settings in additional scenarios. It reduces the chance of test failures caused by unrelated default tax or product tax changes, helping maintain confidence in future updates.
Original PR description
follow-up on https://github.com/odoo/odoo/pull/227111 The fixes helped improve the stability of the tests, but a few using different ways of setting up their invoices (or SO) went through without the change. This adds the fixed tax to these as well, so that they should no longer fail if a side effect changes the default tax/product tax. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the website builder by delaying tooltip checks until they are actually needed. This reduces unnecessary work during page editing and should make builder rows render more quickly, especially on complex pages.
Original PR description
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#223945
The salary offer screen now uses theme-aware background colors instead of a fixed color. This improves readability and visual consistency for users working in dark mode.
Original PR description
With this commit the background-color is not hardcoded anymore; the background color is calculated with the bootstrap variable text-bg-secondary task-5089515
An unnecessary background log message was removed from the spreadsheet chart configuration area. This keeps browser tools cleaner for support and development without changing how users work with spreadsheets.
Original PR description
Task: 0
The account merge wizard now uses the full available space to show its list view. This fixes a display issue where the list became progressively narrower during repeated rendering, making the wizard harder to use.
Original PR description
Use the full width of the wizard to display the list view. It was even worse because the width of the view was being reduced in multiple renders with a few frames per second.
The website shop checkout test was made more reliable by waiting for page elements before continuing. This helps reduce false test failures and keeps quality checks aligned with the current "Add to Cart" button wording.
Original PR description
The add_to_cart_snippet_tour was unstable due to race conditions. some steps executed before their target elements were actually present, causing failures in subsequent steps. This commit ensures the tour runs reliably by adding explicit wait conditions between the affected steps, so the elements are guaranteed to exist before moving on. In addition, the tour is updated to reflect the recent change where the button label was renamed from "Continue Shopping" to "Add to Cart" [1]. [1] https://github.com/odoo/odoo/commit/786c6c00701bcc30c1f2aa04d7fd9ee7bd4c511b#diff-5ac64dbfc12558f048e995a7d75f91d915161063741ddf36281062b273598a51 runbot-231474
Duplicate records can now be found and merged in single-company databases even when their company value differs. This helps teams clean up data more reliably without needing multi-company settings or workarounds.
Original PR description
**Issue** In single company databases, it wasn't possible to find duplicate records with different `company_id` values to merge them (in multi company databases, it is possible to enable the "Cross-Company" option on the deduplication rule). **Change** Always ignore the company field in single company databases. opw-4794408 Forward-Port-Of: odoo/enterprise#94797 Forward-Port-Of: odoo/enterprise#93184
This fixes a crash in the website editor when resizing the title area of a newly added Floating Cards item. Users can now add and adjust these cards without encountering an error, improving reliability while editing website pages.
Original PR description
*: html_builder In the "Floating Cards" snippet, after adding a new card, when trying to resize its title column vertically, a traceback appears. It happens because this grid item does not have the `g-col-*` class, which is needed for the resize in grid mode to work. This commit adds this class. Steps to reproduce: - Drop a "Floating Cards" snippet. - Add a card. - Click on the new card title and resize the column vertically. => Traceback The issue was previously addressed in [1], but a refactor of the Floating Cards snippet in master introduced a duplicate template, and the fix was applied to the incorrect one. [1]: https://github.com/odoo/odoo/commit/78f6e70e0777f5b063524ead73ddaae93ba55f22 Forward-Port-Of: odoo/odoo#226260
The Spanish Mod347 tax report now includes withholding tax lines when calculating report amounts. This prevents understated totals for affected customer or vendor transactions, helping businesses file more accurate Spanish tax reports.
Original PR description
Withholding taxes should be taken into account in mod347 tax report. Steps: - Create a bill for a spanish customer - Set the amount of 40000, tax 21% and 15% withholding tax - Go to mod347 tax report -> Line "B - Sales of goods and services greater than 3.005,06 €" is showing 42,400.00 instead of 48,400.00 (same goes for other lines with similar configuration) Before this commit, custom engines domains were only including aml with payable or receivable account. With this commit, we include tax lines that are of type 'retencion' in the custom engines domains. opw-4448662 Forward-Port-Of: odoo/enterprise#95066 Forward-Port-Of: odoo/enterprise#94338
Users can now open the debug Data view on records that include field properties without encountering an error. This helps administrators and support teams inspect record data reliably, including custom property fields.
Original PR description
Example Steps: - Install `crm` - Add a random field properties in a random form view - Enable debug mode - Open debug menu - Select Data - Traceback ```py raise ValueError(f"Invalid field…
Example Steps:
- Install `crm`
- Add a random field properties in a random form view
- Enable debug mode
- Open debug menu
- Select Data
- Traceback
```py
raise ValueError(f"Invalid field {field_name!r} on model {self._name!r}")
ValueError: Invalid field 'properties.xyz' on model 'x.y'
```
There are two causes for this problem.
First, we use orm.read to retrieve data from records, which does not directly handle sub-field properties. We only need to use `definition_property` (which contains the overall schema of the JSON field).
Second, when displaying the data, we use JSON.stringify with `replacer`:
```js
get content() {
const record = this.props.record;
return JSON.stringify(record, Object.keys(record).sort(), 2);
}
```
In this case, replace contains all the keys present in record, sorted. The problem is that the properties fields are themselves objects that contain the keys: `name`, `string`, `type`, `default`, `value`.
And giving an array to replace in `JSON.stringify` will filter the keys and keep only those that are whitelisted in it.
```js
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
const foo = {
foundation: “Mozilla”,
model: “box”,
week: 45,
transport: “car”,
month: 7,
};
JSON.stringify(foo, [“week”, “month”]);
// ‘{“week”:45,“month”:7}’, only keep ‘week’ and “month” properties
```
This will ignore the keys of the properties fields.
The fix is therefore to sort the object before stringifying it, without using replace.
Thanks to these two fixes, the data is displayed as expected, regardless of whether there are field properties or not.
opw-5017425
Forward-Port-Of: odoo/odoo#225572
Forward-Port-Of: odoo/odoo#22408422 changes
Resolved issues and error corrections
This fix prevents an error that could occur when editing replenishment rules linked to confirmed manufacturing orders. Users can update min/max replenishment values without the page crashing in this specific manufacturing planning scenario.
Original PR description
When modifying fields in a replenishment rule with an associated Manufacturing Order (MO) in a confirmed state and a lead_timedate between date_start and date_finished, the orderpoint.id sometimes…
When modifying fields in a replenishment rule with an associated Manufacturing
Order (MO) in a confirmed state and a lead_timedate between
date_start and date_finished, the orderpoint.id
sometimes contained <NewId>. This resulted in a KeyError when attempting to
index res[orderpoint.id] in _quantity_in_progress.
Steps to reproduce:
Install MRP
Go to Inventory > Operations > Replenishment
1. Click new > select product `[[D_0045_GR] Stool (Grey)]` and set min and max as 1
2. Press 'Order' button of selected product
3. Open Bill of material of product `[D_0045] Stool`
4. Go to the Miscellaneous Page and make Manuf. Lead Time it 10 days and save it.
5. Open manufacturing order of product `[[D_0045_GR] Stool (Grey)]`
6. Select Scheduled Date Field and put it 2 days into the future if date is 2
future date should be 4.
7. Go back to Inventory App Operations>Replenishment.
8. Remove default filters To Reorder and Not Snoozed.
9. Stool Grey should now be visible make the `Min = 2` and then only click on Max
Value (Not anywhere else, do not save it).
KeyError: 8
Solution:
1.Check if the orderpoint exist in res
2.If the key does not exist we initialize it.
3.This ensures there are no key errors.
Sentry - 6135193468This fixes an error that could occur when the appointment calendar processed multiple events at the same time. It helps ensure video call redirection links are generated reliably for bookings, reducing failed appointment flows.
Original PR description
In the event of calendar.event() having multiple id's such as `calendar.event(1,2)` within `_compute_videocall_redirection` it is possible that the `models.py` returns the following: `ValueError: Expected singleton or no record: calendar.event(2, 1)` Solution: Replacing 'self.get_base_url()' and 'self.access_token' with 'event.get_base_url' and 'event.access_token' allowing only single event record instead of multiple at once. Sentry - 6491567020
This fix prevents an error when preparing a manufacturing order after the component separator is left blank during batch production with serial-numbered products. Users can continue the preparation process without being interrupted by a system traceback.
Original PR description
When user unsets the Component separator in Batch Production of serial number,
A traceback will appear.
Steps to reproduce the error:
- Create two Product A and B
- Tracked by Unique Serial Number
- Create a MO > Product: Product A > Quantity: 2
- Components > Product: Product B > To Consume: 2
- Confirm > Produce All
- Unset Component separator > Prepare MO
Traceback:
```
File "/home/odoo/src/odoo/addons/mrp/wizard/mrp_batch_produce.py", line 52, in _compute_production_text_help
text += wizard.component_separator + move_raw.product_id.display_name
TypeError: unsupported operand type(s) for +: 'bool' and 'str'
```
https://github.com/odoo/odoo/blob/47992d61a1ffa96287099be7dee8f9f244d835d4/addons/mrp/wizard/mrp_batch_produce.py#L52
Here, When ``component_separator`` is False.
It will lead to the above traceback.
sentry-6625936682
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents the Inventory replenishment screen from crashing when all warehouses have been removed. It helps users continue working safely in unusual stock configurations instead of seeing an error message.
Original PR description
When there is no warehouse and user clicks on the replenishment, A traceback will appear. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings >…
When there is no warehouse and user clicks on the replenishment, A traceback will appear. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings > Enable Multi-Step Routes - Create new product > Click on ``On Hand`` smart button > Add Negative On Hand Quantity (e.g. -10) - Go to Inventory > Configuration > Rules > Delete all Rules - Go to Inventory > Configuration > Warehouses > Delete Warehouse - Go to Inventory > Operations > Replenishment Traceback: ``` NotNullViolation: null value in column 'warehouse_id' of relation 'stock_warehouse_orderpoint' violates not-null constraint ``` https://github.com/odoo/odoo/blob/54204e664ed1924f512ba4626be010e39c2d17a3/addons/stock/models/stock_orderpoint.py#L538-L545 When there is no warehouse available, the ``warehouse_id`` is set to False. when the method tries to create orderpoints using this ``False`` value for ``warehouse_id``. So, It will raise the above traceback. sentry-6682818532 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could stop users from planning a manufacturing order after recording actual time on one of its work orders. The plan action now handles work orders without scheduling data correctly, helping production teams continue planning without interruption.
Original PR description
When user clicks the plan button in the mo, A traceback will appear. Steps to reproduce the error: - Create a new MO > Select any product > Add 2 workorders - Confirm - Set Real duration in any…
When user clicks the plan button in the mo,
A traceback will appear.
Steps to reproduce the error:
- Create a new MO > Select any product > Add 2 workorders
- Confirm
- Set Real duration in any workorder
- Click on Plan button
Traceback:
```
File "/home/odoo/src/odoo/addons/mrp/models/mrp_production.py", line 1583, in _plan_workorders
'date_start': min([workorder.leave_id.date_from for workorder in workorders]),
TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'
```
The error occurs due to changes introduced in the following commit: https://github.com/odoo/odoo/commit/e587fecca81081a1861b353b85f1d8ed68503973
After this commit, modifying the real duration of a work order sets its status to ``In Progress``.
As a result, the resource calendar leave is no longer created for that workorder. https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/mrp/models/mrp_workorder.py#L529-L530
So, here ``leave_id.date_from`` becomes False.
https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/mrp/models/mrp_production.py#L1575-L1576
So, It will lead to the above traceback.
sentry-6595147036
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents Colombian electronic invoices from failing unexpectedly when no signing certificate is configured. Users will avoid a system error during invoice sending in this setup, making the missing configuration easier to handle.
Original PR description
The variable `cert_sudo` was being used outside of the for loop If no certificate is present, the loop is skipped, and `cert_sudo` remains undefined, resulting in the UnboundLocalError. **Steps to…
The variable `cert_sudo` was being used outside of the for loop If no certificate is present, the loop is skipped, and `cert_sudo` remains undefined, resulting in the UnboundLocalError. **Steps to replicate** Install the Sales,Accounting apps and l10n_co_dian module. * Go to Settings Open `Users and Companies` > `Companies` and create a New Company. * Enter the name: YourCompany (Colombia) and in the `Country field`, select `Colombia`. * Enter arbitrary values for the `Company ID` fields and save. * Switch to `YourCompany (Colombia)` from dashboard. * Go to Settings>Accounting section>Colombian Electronic Invoicing section. * In Operation Modes, add a line. * Set Software Mode to `DIAN 2.1: Electronic Invoices` and set `Software PIN` and `Testing ID` randomly and save. * Go to Contacts app and search for `Deco Addict`. * Open the Sales and Purchase page. * In the `Obligaciones y Responsabilidades` field, select `0-47`. * Enter an arbitrary value for Company ID and save. * Go back to contacts and now search for `YourCompany (Colombia)`. * Enter arbitrary letters in the Identification field and select any option in the `City` field. * Go to the Sales and Purchase page and Fill in `Obligaciones y Responsabilidades` and save. * Open Accounting and Select Configuration > Journals>Customer Invoices. * Go to the Advanced Settings page. * Fill all fields under the `Resolución DIAN section` with arbitrary values and save. * Create a new Customer Invoice by pressing the New button under Customer Invoices from accounting dashboard. * Set the customer to `Deco Addict`. * Add a random product in the product lines then save and press confirm. * Press Send, then in the template preview, press Continue > Send. **Error:** `UnboundLocalError: local variable 'cert_sudo' referenced before assignment` **Solution:** Added a check to ensure that certificates_sudo is not empty before entering the block where cert_sudo is used. Sentry-6515616912
This fixes an error that could prevent the Partner Ledger report from opening when users selected a custom horizontal group containing multiple journals. Accounting teams can now use this reporting configuration without hitting a system error.
Original PR description
When creating a custom horizontal group in accounting module with multiple journals, query with wrong syntax will be fired from `_get_query_sums` method **Steps to reproduce:** Install accounting…
When creating a custom horizontal group in accounting module with multiple journals, query with wrong syntax will be fired from `_get_query_sums` method
**Steps to reproduce:**
Install accounting module
* `Configuration>Accounting>Horizontal Groups`
* Create new group and put arbitrary `group name`
* On `Reports` field add `Partner Ledger` then add a line and on `field` select `Journal` hit Save and close.
* Go to `Reporting>Partner Reports>Partner Ledger`
* Select `Horizontal Group > The name of the group you created`
**Error:**
`psycopg2.errors.SyntaxError: syntax error at or near 'WITH'
LINE 27: WITH partner_sums AS (`
**Solution:**
Modify the `WITH partner_sums AS( .....) `
with `SELECT * FROM ( WITH partner_sums AS(...) as sub` this prevents invalid syntax of
```sql
WITH partner_sums AS (...)
SELECT * FROM partner_sums
...
UNION ALL
WITH partner_sums AS (...)
SELECT * FROM partner_sums
...
```
and now instead it does which is a valid syntax
```sql
SELECT * FROM (
WITH partner_sums AS (...) SELECT * FROM partner_sums
) AS sub
UNION ALL
SELECT * FROM (
WITH partner_sums AS (...) SELECT * FROM partner_sums
) AS sub
...
```
Sentry-6529855325Creating a new user no longer fails if a specific mail notification setting has been removed or renamed. The system now checks whether the setting exists before applying it, helping administrators avoid an unexpected error during user setup.
Original PR description
When the reference to external ID `mail.group_mail_notification_type_inbox` is not found while creating a user a value error is thrown. **Steps to reproduce:** * Install the module mail. * Delete/rename id `mail.group_mail_notification_type_inbox` from External Identifiers. * Create a new User and save. `Value Error:External ID not found in the system: mail.group_mail_notification_type_inbox` **Solution:** * Make `raise_if_not_found=False` and add an if statement to check for `inbox_group` and only proceed if it exists. **Sentry-6564294068** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users now receive a clear validation message when an asset depreciation period is set beyond supported date limits. This prevents confusing system errors during asset confirmation and helps users correct unrealistic depreciation settings.
Original PR description
Currently, creating an asset with an excessively long depreciation duration (e.g., 50,000 years) causes an error during depreciation computation. **Steps to Reproduce:** 1. Go to Accounting > Assets & Liabilities > Assets. 2. Create new assets with a duration of 50,000 years for depreciation method. 3. Click on the "Confirm/Compute Depreciation" button. **Error:** `ValueError - year 502025 is out of range` **Cause:** The computation of the last depreciation date relies on `relativedelta`. When the duration is too long, it produces a year value far beyond python’s supported datetime range, which raises an error during computation. **Fix:** This commit wraps the computation in a `try/except` block and raises a user-friendly Validation Error instead of a traceback. sentry-6832993432
Bank synchronization now starts after the company's accounting lock date, preventing transactions from being imported into periods that should no longer change. Opening balances are also dated consistently with the first synced transaction, reducing the risk of incorrect or confusing bank statement entries.
Original PR description
If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing…
If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing should be created in a period covered by a lock date. As a result, these transactions would be created at a wrong date (if the current month is the first after the lock date or if the sequence has a monthly reset, then they would be appended to the current month, else if the sequence reset annually, then they would be created at the current date). Additionally, the potential opening balance would be created at a wrong date too, since it would try to create it one day prior to the oldest transaction. The date which the opening balance is created would not be the same as the transactions above, which adds a layer to the mess created. To prevent this, at initialization, we set the last sync date one day after the lock date, not the same day. As for the opening balance, we do not try to set it one day prior to the oldest transaction, but the same day. The `internal_index` computed will ensure it is displayed as the first transaction of that journal. Finally, the test related to statement creation were adapted to this new behavior. Some ordering based on `date` in other tests were changed to `internal_index` to unify the test file with these changes. opw-4890538 Forward-Port-Of: odoo/enterprise#93543
Fixes an issue where edited time entries in the Timesheet list view could appear to revert when users moved focus with Shift+Tab. This helps employees keep confidence that their entered time is retained accurately while creating or updating timesheets.
Original PR description
Steps to reproduce: ----------------- 1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time. 2. Change time in the Time Spent field. 3. Press Shift + Tab. Observation:…
Steps to reproduce: ----------------- 1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time. 2. Change time in the Time Spent field. 3. Press Shift + Tab. Observation: ----------------- The focus changes, but the Time Spent field reverts to its old value instead of keeping the newly entered one. Issue: ----------------- - For new records, the component retrieves the value only from the state, which is updated in the `onWillUpdateProps` lifecycle. This lifecycle triggers only on saving or editing, not when simply changing focus. https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L123-L128 - The same behavior occurs when editing existing records, leading to incorrect value display. https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L31-L33 Solution: ----------------- - For new records, since the default value is 0, the fix makes the component fall back to the updated record value if the state value is not yet available. - For existing records, if the timer is running, the timer’s value is displayed. otherwise, the component falls back to the updated record value. opw-4922847
Timesheet reports printed from a sales order now show the related helpdesk ticket name when time was logged on a ticket. This makes billed support work easier to identify and avoids reports showing only the helpdesk team name.
Original PR description
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report from the sale order -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name" Problem: ======== on the report template, the task name is fetched from line.task_id only, but helpdesk timesheets are linked to a ticket through line.helpdesk_ticket_id Solution: ========= use conidtionally line.task_id or line.helpdesk_ticket_id to display the task name opw-5002650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the Project view from failing when two independent modules use the same ordering value for project statistic buttons. It makes the view more reliable for businesses using multiple project-related customizations or add-ons.
Original PR description
Description of the issue/feature this PR addresses: If a sequence in function _get_stat_buttons in project.project is repeated, the view view fail because we are using the sequence as key Current behavior before PR: If we repeat a sequence in two independent modules, the view fails. Desired behavior after PR is merged: The view works as expected --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where orders could keep using the Click and Collect warehouse even after the customer switched to standard delivery. This helps ensure quotations and fulfilled orders use the correct warehouse, reducing fulfillment errors.
Original PR description
Steps: - Activate Click and Collect, then create a new warehouse. - For the product, add quantities in both locations. - Assign the second warehouse to Click and Collect. - Go to the website, add the product to the cart, choose Click and Collect as the delivery method, then switch it to Delivery and confirm payment. Issue: - When checking the quotation, it still uses the warehouse linked to Click and Collect. Cause: - Warehouse recomputation logic is called after _remove_delivery_line which resets the delivery_type of sale order. Since delivery_type is reset the sale order filter for warehouse recomputation does not work as intended. Fix: - Moved warehouse recomputation logic to _set_delivery_method which will filter the sale order before _remove_delivery_line. opw - 4965726, 5004170 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The timesheet and attendance timesheet filters for Today, This Week, and Last Week now use the user’s local date instead of a UTC-based date. This prevents entries from appearing under the wrong day or week for users in time zones where the previous logic caused off-by-one errors.
Original PR description
This commit fixes issues with the timesheet Date filters, in which the `date` field of account.analytic.line records, which is stored as the local timezone's date, is being compared to a UTC DateTime value. This leads to off-by-one errors. For example, if you are in Berlin and try to filter for all timesheet entries from "Today", you will only find entries from the previous day. Similarly, for the "This Week" and "Last Week" filters, which would be shifted by one day. The filter domains have been changed to compare the `date` to the local timezone's "today". opw-5003310
This fix ensures date filters in timesheet forecasting return the correct records regardless of a user’s time zone. It prevents off-by-one-day errors that could cause forecasts or timesheet data to appear missing or incorrectly included.
Original PR description
This commit fixes the timezone issues with the Date filters, in which we were comparing a UTC DateTime value to a local timezone's Date. In certain timezones, this leads to off-by-one errors in the records fetched from the DB, depending on how far ahead or behind UTC that timezone is. Specifically, we remove the UTC conversion within the filter domains. opw-5068870
This fix stops users from repeatedly validating an online POS payment while the order is still syncing. It prevents checkout errors on slow connections and makes online payments more reliable for cashiers and customers.
Original PR description
Currently, an error occurs when validating an online payment if the network is slow. **Steps to Reproduce:** 1) Install POS (with demo data) and the Demo Payment module. 2) Go to Payment Methods and…
Currently, an error occurs when validating an online payment if the network is slow.
**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module.
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.
Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')
**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.
**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.
[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17
[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87
[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26
**sentry-6849786792**This fixes Saudi e-invoicing so that a duplicate submission response is treated as a successful send instead of an error. It helps prevent invoices that were already received by the authority from being incorrectly shown as failed, reducing manual follow-up for accounting teams.
Original PR description
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
Duplicating multiple Point of Sale configurations at once no longer causes an error. The update also ensures each duplicated shop gets its own cash payment method, preventing payment setup conflicts.
Original PR description
This issue occurs due to changes introduced in commit [4ac2702](https://github.com/odoo/odoo/commit/4ac2702c31f0e95f33f9ad554e7350bef9dab8bd), which added the `copy_data` method. The technique…
This issue occurs due to changes introduced in commit [4ac2702](https://github.com/odoo/odoo/commit/4ac2702c31f0e95f33f9ad554e7350bef9dab8bd),
which added the `copy_data` method. The technique allowed
duplicating multiple POS configs at once.
When performing a `search_count` on `pos.config` to check for existing records
with matching `payment_method_ids`, the domain was incorrectly using
('id', '!=', self.id).
This works fine if self is a `singleton record`, but `fails` if self contains
`multiple records`.
**Steps to Produce:-**
- Install the `Point of sale`.
- `Point of sale > Configuration > Payment methods`.
- Select `Card` and `Customer Account`, and delete them.
- Now, go to `Dashboard` and then open the `list view` of `Point of Sale`.
- Select `Furniture Shop` and `Clothes Shop` and then try to duplicate them.
**Error:-**
`ValueError: Expected singleton: pos.config(6, 7)`
**Solution:-**
- This commit fixes the above issues by:-
- Replacing `('id', '!=', self.id)` with `('id', 'not in', self.ids)` to
safely handle multi-record sets.
- Also found another issue, like when we duplicate pos in batch, then it assign
the same `cash payment method` to `multiple pos`.
- This commit also fixes the above issue by overriding the `copy_data()`
method.
- Assign a unique name to each duplicate (e.g., "Shop (copy)").
- Assign an `unused cash payment method` to each config, or `create` one if
none are available.
**Sentry - 6673398556**Cancelling a sales order after multiple nested product returns no longer causes the system to crash. This improves reliability for sales and warehouse teams handling complex return flows.
Original PR description
The system crashes with a `RecursionError` during the `Sale Order` cancellation with nested `returns`. **Steps to produce:-** - Install the `Purchase Stock` and `Sales` modules. - Create a new `Sales Order` (SO) with `Product A`. - Confirm the `Sales Order` and click on the `Delivery` button. - Click on `Return > Return all`. - In the new window, also click on `Return > Return all`. - Return to the `Sales Order` and attempt to `Cancel` it. **Error:-** `RecursionError: maximum recursion depth exceeded` **Solution:-** - Added a check for the self not already visited in the method `_get_upstream_documents_and_responsibles` to prevent revisiting the same move multiple times and `avoid infinite recursion`. **Sentry - 6693197358** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Planning now shows progress for flexible employee shifts based only on the hours that fall within the selected week. This prevents shifts spanning multiple weeks from making the current week look over-allocated.
Original PR description
### Steps to reproduce: - Install Planning app - Create a shift for a flexible employee that starts on Friday and end on the following Tuesday for example - Go to the gantt view for the week that the shift should start at - Notice the progress bar is showing the whole allocated hours not just the week's hours ### Cause: This mainly happening because when the employee is flexible we are getting the value by multiplying the hours_per_day of his schedule by the period.days and the period is the shift period ### Fix: We use the interval we are just checking as the period now so if the shift is extended to the next week we are just going to use the end of the week as the interval end not the shift's end_datetime opw-5022800
Field Service sales orders now use the product's currency when calculating prices, instead of incorrectly reusing the sales order currency. This ensures prices are converted correctly when products and orders use different currencies, preventing incorrect invoice amounts.
Original PR description
### Steps to reproduce: - Open Field Service module. - Create a new task. In the Customer field, select “Bloem GmbH”. - Open the task’s project. - In the Invoicing tab, create a new line for any…
### Steps to reproduce: - Open Field Service module. - Create a new task. In the Customer field, select “Bloem GmbH”. - Open the task’s project. - In the Invoicing tab, create a new line for any employee and any service. - Return to the task and in the Timesheets tab, add a new timesheet. - Click the Mark as done button. - Click the Sales order button. ### Cause: When creating the sale order out of the fsm task we use _get_tax_included_unit_price to get the price of the SO line but we are passing the order currency twice to this method so it doesn't convert the price as when it checks the currency and the product_currency it found they are the same so no need to convert https://github.com/odoo/odoo/blob/6653355b8bc063ceadf08af17fbf2c4a250553e6/addons/account/models/product.py#L239-L240 ### Fix: We pass the product currency instead of the order currency in order to be able to convert the price according to the currencies opw-5045071 Forward-Port-Of: odoo/enterprise#94947
15 changes
Resolved issues and error corrections
Fixed an issue where the website donation button could fail if a pre-filled donation option had no amount entered. This prevents an error page and keeps the donation flow usable for visitors and website editors.
Original PR description
When the user clicks the ``Donate Now`` button and one of the pre-filled options
has a null amount, A traceback will appear.
Steps to reproduce the error:
- Go to Website > drag and drop donation button > Edit > Click on Donate Now button
- Add new pre-filled option with Null amount > Save
- Click on Donate Now button
Traceback:
```
ValueError: could not convert string to float: ''
```
https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/website_payment/views/payment_form_templates.xml#L86
Here, ``donation_amount`` will be an ``empty string('')``.
So, It will lead to the above traceback.
This commit will add a fallback value for a null amount.
sentry-6703335051
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMarketing automation campaigns with invalid filter rules no longer trigger a system error when users add a new activity. Instead, the campaign now warns users about the invalid condition so they can correct it and continue working.
Original PR description
An error occurs when a user enters a `malformed domain` in a campaign and then creates a new activity, due to an unhandled `literal_eval` exception. **In the following code:**…
An error occurs when a user enters a `malformed domain` in a campaign and then creates a new activity, due to an unhandled `literal_eval` exception. **In the following code:** https://github.com/odoo/enterprise/blob/0a34ac7363b8270bb745a9e9bebba836af52d63f/marketing_automation/models/marketing_activity.py#L142-L143 **Steps to reproduce:** * Install `marketing_automation` and turn on developer mode. * `Marketing automation > New>Start from Scratch > Create Campaign` * Add condition> paste [this domain](https://drive.google.com/file/d/1HKWlgsQt-oGN7SGdgtfghYOMGNslDSag/view?usp=sharing) in the code editor. * After `Created on` is added click on it and select the `Created on` field again from dropdown menu this will allow you to save. * Press `Add new activity`. `ValueError:malformed node or string on line 1: <ast.Call object at 0x7af0f19a1210>` **Solution** * Add `eval_domain` helper to handle errors from malformed domain strings. * Trigger a validation error for invalid domains on the campaign page and during activity creation. Sentry-6688190469
Testing the AvaTax Brazil production connection no longer crashes when the account has insufficient credits. Instead, users receive a controlled error message, making setup issues easier to understand and preventing disruptive traceback screens.
Original PR description
If there are insufficient credits and the user attempts to test the connection for AvaTax Brazil in the production environment, a traceback will be raised. Steps to reproduce the error: - Install ``l10n_br_avatax`` module and switch to BR company - Go to Invoicing > Configuration > Settings > AvaTax Brazil > Environment: Production > Set Avatax Portal Email, API ID and API Key > Save - Click on Test Connection Traceback: ``` InsufficientCreditError: null ``` https://github.com/odoo/odoo/blob/b10303a136f87e17f621f1294f1e197c3ed67c98/addons/iap/tools/iap_tools.py#L138 When the user clicks the Test Connection button, the ``_l10n_br_iap_request`` method is called, which then calls the ``iap_jsonrpc`` method. This call raises an ``InsufficientCreditError`` if there are not enough credits. sentry-6721351360
This fix stops users from removing every website from the system, even if the default website reference was deleted. It prevents website pages from crashing and ensures the Website app always has at least one site available.
Original PR description
Currently, an error occurs when the user deletes all the websites and tries to open the website. Steps to Reproduce: - Install website - Navigate to Settings>Technical>External Identifier and Search `default_website`, delete that record - Navigate to website>configuration>websites - Delete all available website. - Tries to access or open the website Error: ValueError: Expected singleton: website() Root Cause: Since https://github.com/odoo/odoo/commit/60adaf5632ddfe3f68da369a2e9642ad639da37e , the check preventing the deletion of the last website was changed. The new constraint only prevents the deletion of the default website via the external identifier website.default_website. But if the user deleted the external identifier of the default website and deleted all the websites it leads to a traceback. Solution: This commit ensures that at least one website exists. sentry-5900356108
Odoo now handles invalid or non-image files more gracefully when users try to set a Discuss channel profile image. This prevents an error from interrupting channel setup and improves reliability for users who accidentally upload the wrong file type.
Original PR description
Currently, an error is encountered on uploading non-image files(e.g .txt, .csv) rather than image file, in the discuss channel. **Steps to reproduce:** - Install Discuss module - Navigate to Discuss channels. - Create new Channel and upload [this](https://docs.google.com/spreadsheets/d/1k_s_V7Q-zA9uQUaQblsJtBHC4VlEFM-w/edit?usp=drive_link&ouid=101212513075316114369&rtpof=true&sd=true) file as group's profile image. **Error:** `ValueError: Compute method failed to assign discuss.channel(<NewId origin=4>,).avatar_128` **Root Cause:** On uploading a file compute method expects a `Id` and here we are receiving `temporary id` as `<NewId origin=4>`, on using this id at [1] raising an error. [1]- https://github.com/odoo/odoo/blob/44a9831f125800743504a5cc55b395980ddc9ce7/addons/mail/models/discuss/discuss_channel.py#L126 **Solution:** This commit handles error on uploading a corrupt image in the discuss channel. Sentry- **6690968543**
This fix helps Odoo handle Twilio connection problems more cleanly when network issues or request timeouts occur. It reduces unexpected failures in mail-related services by identifying the type of connectivity problem more accurately.
Original PR description
The error occurs when the Twilio API call fails due to network issues. This commit ensures that a ConnectionError is raised when a connection issue occurs with the Twilio API, and a TimeoutError is raised in case of a request timeout. sentry-6541206983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website contact forms no longer show an unnecessary blank space before the reCAPTCHA privacy line when labels are positioned at the top. This makes forms look cleaner and more professional for visitors without changing how reCAPTCHA works.
Original PR description
Steps to Reproduce: 1. Go to _Settings_ and search for reCAPTCHA. 2. Add the required keys. 3. Go to _Website_ and enter edit mode. 4. Drop any _Contact Form_ snippet. 5. Make the labels to top. 6. Enable the _Show reCAPTCHA_ option. 7. Notice an unnecessary blank space before the privacy policy line. Issue: The reCAPTCHA line created unnecessary blank space when aligned to the left. Reason: The line was placed inside the form block, which reserves space for a label. Since reCAPTCHA has no label, an empty placeholder space appeared. Fix: Hide the unused label by setting its visibility to `none` for the reCAPTCHA line, removing the extra blank space. Before: <img width="1464" height="406" alt="image" src="https://github.com/user-attachments/assets/b5fc0fc2-104d-4a3e-a6c9-fab34992ee0d" /> After: <img width="936" height="772" alt="image" src="https://github.com/user-attachments/assets/8d721d90-b7fa-45a5-8d0c-a750ec504a12" /> task-4756289
Maintenance equipment pages no longer fail when imported maintenance requests have no request date. The system now fills in a sensible default and handles missing dates safely, improving reliability for teams importing maintenance data.
Original PR description
Currently, an error occurs when accessing equipment if the maintenance request data is imported with an empty request date. **Steps to reproduce:** - Install Maintenance app. - Create new equipment…
Currently, an error occurs when accessing equipment if the maintenance request data is imported with an empty request date. **Steps to reproduce:** - Install Maintenance app. - Create new equipment (e.g; laptop) - Import [this](https://docs.google.com/spreadsheets/d/1QDwpRtbHemXJLpZRf0eLM2mN_58tfsTA/edit?usp=drive_link&ouid=113889705772170635141&rtpof=true&sd=true) file in Maintenance Requests. - Open the newly created equipment form view. **Error:** `TypeError - unsupported operand type(s) for -: 'datetime.date' and 'bool'` **Cause:** Here at [1], it tries to subtract a `False` value (i.e., no `request_date`) from a `datetime.date`, which causes a traceback. [1] - https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/maintenance/models/maintenance.py#L109 **Fix:** This commit ensures a default `request_date` (today's date) is assigned during maintenance request creation if none is provided and ensures proper computation when the request date is not set. sentry-6734276358
Field service tasks now use the product's currency when creating related sales order lines. This ensures prices are converted correctly when the product and sales order use different currencies, avoiding incorrect invoicing amounts.
Original PR description
### Steps to reproduce: - Open Field Service module. - Create a new task. In the Customer field, select “Bloem GmbH”. - Open the task’s project. - In the Invoicing tab, create a new line for any employee and any service. - Return to the task and in the Timesheets tab, add a new timesheet. - Click the Mark as done button. - Click the Sales order button. ### Cause: When creating the sale order out of the fsm task we use _get_tax_included_unit_price to get the price of the SO line but we are passing the order currency twice to this method so it doesn't convert the price as when it checks the currency and the product_currency it found they are the same so no need to convert https://github.com/odoo/odoo/blob/6653355b8bc063ceadf08af17fbf2c4a250553e6/addons/account/models/product.py#L239-L240 ### Fix: We pass the product currency instead of the order currency in order to be able to convert the price according to the currencies opw-5045071
This fix prevents users from hitting an error when drilling into graph or pivot report data that points to a form view that is not available. It keeps reporting navigation stable by only including form views when they actually exist, while still showing records in list view.
Original PR description
This error occurs in 18.2 when a user creates a course record for any attendee. Steps to Reproduce: - Install the website_slide module. - Go to Reporting > Attendees. - Go to either the Graph or…
This error occurs in 18.2 when a user creates a course record for any attendee.
Steps to Reproduce:
- Install the website_slide module.
- Go to Reporting > Attendees.
- Go to either the Graph or Pivot View and click on any count value.
- Open any attendee record and click on New.
SyntaxError: syntax error at or near ")"
LINE 18: WHERE SCP.id IN ()
^
This error occurs because when the user clicks on New to create the attendee's course record, the system triggers the compute method before saving the record. Since the record has not been saved yet, the self.id is empty, which causes the error.
In the list and kanban views, clicking on any attendee record does not open any form view. However, in the graph and pivot views, clicking on an attendee record opens a form view that does not exist, resulting in an error.
This commit ensures that if the form view is present, it will be included in the graph and pivot views. The list view is always included to display the records. The form view may contain computed methods, which can lead to errors if the view is not properly defined.
Sentry-6465821899
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents the command palette from crashing when a status field has no available choices, such as in certain Field Service task flows. Users can continue working normally; the unavailable command is simply hidden instead of causing an error.
Original PR description
**Steps to reproduce:** - Installed industry_fsm (Field Service) module - Navigate the menu Field Service -> Configuration -> Project - Create a new project - Then Navigate the menu My Tasks -> Tasks…
**Steps to reproduce:** - Installed industry_fsm (Field Service) module - Navigate the menu Field Service -> Configuration -> Project - Create a new project - Then Navigate the menu My Tasks -> Tasks - Create a new task with the new created project - Then using the keyboard shortcut ctrl + k for command search, an error occurs **Cause:** - When the `stage_id` statusbar had no possible values, `this.getAllItems()` returned an empty array. - The command `isAvailable` unconditionally accessed `this.getAllItems().at(-1).isSelected`, which is undefined, causing a crash.[see](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L147-L148) **Fix** - Add safe check in the command action so it does not attempt to select a non-existent "next" item. **Result** - The command palette no longer crashes when the `stage_id` field has no available items. Instead, the command is simply unavailable. opw-5084130 upg-3130405 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 website editor now handles font size and text style changes more cleanly, reducing unwanted formatting artifacts and extra undo steps. It also prevents style changes in header areas where they could accidentally damage the page structure.
Original PR description
This PR is a follow-up of https://github.com/odoo/odoo/pull/129791 It permits to: - prevent unnecessary elements on text option change - remove font size classes / style on text style change - set font size class in a single command - remove dead code to delete empty class attribute - clean dom after text style change in `<li>` - unwrap sub text style element on text style change - hide text style dropdown for text element in the header task-1958098
When a purchase bill is reset to Draft, its GSTR-2B reconciliation information is now returned to the starting state. This prevents outdated return period links or exception flags from carrying over, helping teams reconcile GST data more reliably.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582
This fix prevents Firefox from keeping the wrong hidden product value when a website editor switches product variant display modes. It helps ensure shoppers and editors can continue selecting variants and adding products to the cart without needing to refresh the page.
Original PR description
### Problem: Switching the variants view from "Options" to "Product List" using the web editor, in Firefox, causes an error stating that the `product_template_id` doesn't exist. Add to cart and switching variants won't work until refreshing the page. This issue occurs only in Firefox because it incorrectly preserves hidden input values during DOM replacement. It assigns the value of the first hidden input (`product_id`) to the new `product_template_id` input, based on its position in the DOM. ### How to reproduce: * Create a product with variants. * Go to the product page in website shop using Firefox. * Open website editor on Customize. * Switch the variants view from Options to Product List. ### Solution: Disable autocomplete on the `product_template_id` input to prevent Firefox from preserving and reusing the previous value during DOM updates. opw-4901316
This fixes an issue where the Cloudflare Turnstile verification code could be added more than once on website forms. The change helps avoid duplicate checks and potential form behavior problems for visitors.