Daily updates from Odoo
Thursday, November 6, 2025
181 changes
12 changes
Resolved issues and error corrections
Users can now search for a message and jump directly to it in mailboxes. This fixes a previous limitation that prevented opening the right message from search results in mailbox threads, making message lookup faster and more reliable.
Original PR description
Before this commit, we could not jump to messages in mailboxes. This happens because the `useMessageHighlight()` hook prevented jumping to messages in thread that were not their origin thread. This commit fixes the issue by removing this limitation specifically for mailboxes. opw-4948798 opw-5087102 Forward-Port-Of: odoo/odoo#234526
This change prevents portal users from accidentally overwriting a bank account’s custom account holder name when they update their profile details online. It keeps existing banking information intact unless the user actually changes their name, avoiding unexpected data loss.
Original PR description
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a…
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a Bank Account with a custom Account Holder Name. 4. Log in to the Website using the Test User. 5. Navigate to My Account and click Edit Information. 6. Fill in the address details (without changing the Name) and click Save. 7. Go back to the Employee’s Bank Account and check the Account Holder Name. Observation: ------------------------- The Account Holder Name was overwritten to the partner's name. Issue: ------------------------- In `_compute_account_holder_name` method, https://github.com/odoo/odoo/blob/c3b543631bde96260082484a3baac19d942f6b9f/odoo/addons/base/models/res_bank.py#L104-L107 The Account Holder Name is always recomputed using the Partner’s name. When submitting the form from the frontend, the name field is included in the values sent to update the Partner, even if the user did not actually change the name. https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/portal/controllers/portal.py#L196-L205 which re-triggers this compute and as a result, the Partner’s name overwrites the Account Holder Name on the linked Bank Account Solution: ------------------------- Prevent the Account Holder Name compute method from being triggered when updating information from the frontend if the Partner’s name has not been changed. opw-5059247 Forward-Port-Of: odoo/odoo#232723 Forward-Port-Of: odoo/odoo#229210
The Australian TPAR report now exports correctly in both text and PDF formats. This fixes an error caused by country names being pulled in the wrong format and ensures report lines include the information needed for PDF generation.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990This update corrects the invoice data sent to ECPay when a sales downpayment is billed. It ensures negative quantities are converted into valid values, preventing rejected invoices and incorrect pricing in the transmitted JSON data.
Original PR description
When an invoice is created from a sale order with a downpayment, the invoice line for the downpayment typically has a negative quantity and a positive unit price. However, ECPay does not accept negative quantities, and this also leads to incorrect price values being sent in the JSON payload. To address this, when an invoice line has a negative quantity, it is inverted to ensure the data sent to ECPay is valid and consistent. **task**-5211264 Forward-Port-Of: odoo/odoo#233359
When a project is shared with another user, the Kanban view now prevents editing stages in that shared context. This avoids an error that could appear when users tried to search for more projects, making shared project navigation more reliable.
Original PR description
Steps to reproduce: - 1. Install the Project module. 2. Create a new project and share it with a user. 3. Log in as that user. 4. Open the shared project Kanban view and try to edit a stage. 5. Try to search for more projects. Issue: - A traceback occurs when clicking on 'Search More'. Fix: - Prevent stage editing in shared project Kanban view. task-5176630 Forward-Port-Of: odoo/odoo#233557
This update stops the same customer invoice from being settled more than once from the Point of Sale flow. It also keeps the selected customer in place if a second settlement attempt triggers an error, making the process clearer and avoiding duplicate accounting actions.
Original PR description
Steps to reproduce: ------------------------- - Install POS. - Create an invoiced order and pay with customer account. - Settle the created invoices from customers list. - Try to settle the invoice again from the same order. Issue: ------- - The system allows settling the same invoice multiple times. Cause: --------- - There is no check in place to verify whether the invoice has already been under settlement process before settling it again. Fix: ----- - Add a validation step to ensure that if the same invoice is selected again, the system prevents duplication and it will show that already being settled. - Also if error occured due to second try of settlment will not lose the selected partner. task: 5028009 related PR: [227971](https://github.com/odoo/odoo/pull/227971) Forward-Port-Of: odoo/enterprise#95156
Event ticket prices now display the currency symbol in the event form view. This makes pricing clearer at a glance and helps avoid confusion when working with tickets in different currencies.
Original PR description
Add missing currency symbol next to the event ticket price in the event form view. Task-5114075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233470
The VIES summary report now shows invoice amounts in the company’s currency when invoices are issued in a different currency. This prevents incorrect totals and helps ensure the report is accurate for tax and compliance review.
Original PR description
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in…
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report. **Steps to Reproduce:** 1. Install the Accounting app and the l10n_cz_reports_2025 module. 2. Go to Accounting > Customers > Invoices. 3. Create a new invoice using a currency other than CZK. 4. Add a product with Code Supply set to Gold and Transaction Code set to 0 Goods. Confirm the invoice. 5. Navigate to Accounting > Reporting > VIES Summary Report. 6. Observe that the total value is not correctly converted to the company currency. **Expected Behavior:** The total amounts in the VIES summary report should be correctly converted to the company currency if the invoice was created in a foreign currency. **Actual Behavior:** Amounts are displayed in the invoice currency without conversion, leading to incorrect totals when the invoice currency differs from the company currency. **Root Cause** The report fetches raw invoice data without handling currency conversion. Specifically, it retrieves the unconverted total value, even when the invoice currency differs from the company’s. **Fix** To solve the issue the balance field is used, which correctly reflects the value in the company currency. opw-4688638 Forward-Port-Of: odoo/enterprise#97894 Forward-Port-Of: odoo/enterprise#82978
The system now prevents customers from saving Boleto as a reusable payment method. This avoids failed or inconsistent payment setups because Boleto is a one-time offline payment method in most providers.
Original PR description
## Versions 17.0+ ## Issue Boleto is an offline, one-time-use payment method and cannot be tokenized with most payment providers (e.g., Adyen: https://docs.adyen.com/payment-methods/boleto-bancario/, Nuvei: https://www.nuvei.com/apm/boleto). ## Exception Stripe allows a form of tokenization by storing the customer's billing information and regenerating a new Boleto for each payment (cf. https://docs.stripe.com/payments/boleto). Technically, the Boleto itself is not reusable — Stripe simulates tokenization by associating customer info with new Boleto transactions. ## Fix To maintain consistent behavior and avoid provider-specific edge cases, tokenization is disabled for Boleto payments globally. opw-5156718 Forward-Port-Of: odoo/odoo#234373
When a graph view search returns no matching records, Odoo now shows the custom no-content message configured for that action instead of the generic default message. This makes the empty-state message more relevant and consistent with the setup chosen by the user.
Original PR description
Before this commit: In the graph view, when performing a search that yields no matching data, the default no content helper is shown even if a custom no content helper has been provided for that action window. After this commit: The provided no content helper for the action window is displayed instead. task-5136801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes the text color in the account reports debug popover when dark mode is enabled. The formula is now easier to read, improving usability for users who inspect report details.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
The setting formerly called a “reminder” has been renamed to “deadline” to better match how it is actually used. This makes the tax return settings clearer and helps avoid confusion when configuring default filing deadlines.
Original PR description
This field is not a reminder anymore and is used to compute the default deadline from the end of the tax return. task-5153900 Forward-Port-Of: odoo/enterprise#96651
18 changes
Resolved issues and error corrections
This update fixes tax report returns so they no longer repeat the same closing entry content across different reports in the same country. It also adjusts some reports to use a review step instead of generating a closing entry when that is the correct business flow, helping avoid incorrect return outputs.
Original PR description
It's possible for different tax reports to exist in the same country, each with its own return type. However, this is an issue when they aren't configured to generate closing entries with distinct contents, since each of them will then repeat the content of the other. To fix this, when it's legitimate to make multiple closing entries, we make sure the closing entry only considers the tax move lines linked to the report's tax tags. If multiple reports must generate the same closing entry (typically because one of them is a simplified version of the other), we disable the generation of the return for one of them. Some reports also didn't need to generate a closing entry and were switched to a 'review_submit' state. task-5123564
Users can now search for a message in mailboxes and jump directly to it. This fixes a limitation that previously blocked navigation to messages when they were not in their original conversation, making mailbox search more reliable and easier to use.
Original PR description
Before this commit, we could not jump to messages in mailboxes. This happens because the `useMessageHighlight()` hook prevented jumping to messages in thread that were not their origin thread. This commit fixes the issue by removing this limitation specifically for mailboxes. opw-4948798 opw-5087102 Forward-Port-Of: odoo/odoo#234526
This fix prevents a customer’s bank account holder name from being overwritten when they update their profile on the website. It ensures that saving address details does not unintentionally replace a manually set account holder name with the partner’s name.
Original PR description
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a…
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a Bank Account with a custom Account Holder Name. 4. Log in to the Website using the Test User. 5. Navigate to My Account and click Edit Information. 6. Fill in the address details (without changing the Name) and click Save. 7. Go back to the Employee’s Bank Account and check the Account Holder Name. Observation: ------------------------- The Account Holder Name was overwritten to the partner's name. Issue: ------------------------- In `_compute_account_holder_name` method, https://github.com/odoo/odoo/blob/c3b543631bde96260082484a3baac19d942f6b9f/odoo/addons/base/models/res_bank.py#L104-L107 The Account Holder Name is always recomputed using the Partner’s name. When submitting the form from the frontend, the name field is included in the values sent to update the Partner, even if the user did not actually change the name. https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/portal/controllers/portal.py#L196-L205 which re-triggers this compute and as a result, the Partner’s name overwrites the Account Holder Name on the linked Bank Account Solution: ------------------------- Prevent the Account Holder Name compute method from being triggered when updating information from the frontend if the Partner’s name has not been changed. opw-5059247 Forward-Port-Of: odoo/odoo#232723 Forward-Port-Of: odoo/odoo#229210
This update prevents users from editing stages in the Kanban view of shared projects. It avoids a crash that could happen when they tried to search for more projects, improving stability and making shared project access behave as expected.
Original PR description
Steps to reproduce: - 1. Install the Project module. 2. Create a new project and share it with a user. 3. Log in as that user. 4. Open the shared project Kanban view and try to edit a stage. 5. Try to search for more projects. Issue: - A traceback occurs when clicking on 'Search More'. Fix: - Prevent stage editing in shared project Kanban view. task-5176630 Forward-Port-Of: odoo/odoo#233557
This update corrects how downpayment invoice lines are sent to ECPay by converting negative quantities into valid values. It prevents incorrect invoice data from being transmitted and helps ensure Taiwan electronic invoicing works reliably for sales with down payments.
Original PR description
When an invoice is created from a sale order with a downpayment, the invoice line for the downpayment typically has a negative quantity and a positive unit price. However, ECPay does not accept negative quantities, and this also leads to incorrect price values being sent in the JSON payload. To address this, when an invoice line has a negative quantity, it is inverted to ensure the data sent to ECPay is valid and consistent. **task**-5211264 Forward-Port-Of: odoo/odoo#233359
The Australian TPAR report now exports correctly by using the proper country name text instead of a stored data structure. It also fixes PDF generation so reports can be downloaded without errors, improving reliability for businesses using this filing format.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990The VIES summary report now correctly converts invoice amounts into the company currency when invoices are issued in another currency. This ensures the reported totals are accurate and match accounting expectations.
Original PR description
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in…
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report. **Steps to Reproduce:** 1. Install the Accounting app and the l10n_cz_reports_2025 module. 2. Go to Accounting > Customers > Invoices. 3. Create a new invoice using a currency other than CZK. 4. Add a product with Code Supply set to Gold and Transaction Code set to 0 Goods. Confirm the invoice. 5. Navigate to Accounting > Reporting > VIES Summary Report. 6. Observe that the total value is not correctly converted to the company currency. **Expected Behavior:** The total amounts in the VIES summary report should be correctly converted to the company currency if the invoice was created in a foreign currency. **Actual Behavior:** Amounts are displayed in the invoice currency without conversion, leading to incorrect totals when the invoice currency differs from the company currency. **Root Cause** The report fetches raw invoice data without handling currency conversion. Specifically, it retrieves the unconverted total value, even when the invoice currency differs from the company’s. **Fix** To solve the issue the balance field is used, which correctly reflects the value in the company currency. opw-4688638 Forward-Port-Of: odoo/enterprise#97894 Forward-Port-Of: odoo/enterprise#82978
This fix prevents a frontend crash when a Point of Sale is switched from a setup without employee login to one that uses it. If the local POS data is outdated, the system now clears it and reloads so the correct employee data can be loaded safely.
Original PR description
Before this fix, a traceback occurred on the frontend when switching from a POS configuration without the “Log in with employees” option enabled to one that had it enabled. Steps to reproduce : 1. Open a PoS without "Log In With Employees" option activated 2. Close Register and go to the backend 3. Enable the "Log in with employees option" for this PoS and set some users 4. Re-open the PoS with a user and close it 5. A TB occured This traceback occurred because the IndexedDB did not include the "hr.employee" module required by the "Log in with employees" option. The fix was to delete the IndexedDB when the error is caught and refresh the page to trigger the IndexedDB upgrade process. task: 5223393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where a one-day time off request could appear as spanning multiple days in the Calendar app for some time zones. This makes the calendar view match the actual leave dates, reducing confusion for managers and employees.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817 Forward-Port-Of: odoo/odoo#230079 Forward-Port-Of: odoo/odoo#224298
Boleto payments are now treated as one-time payment methods and can no longer be stored for reuse. This avoids inconsistent behavior across payment providers and prevents checkout issues for customers using Boleto.
Original PR description
## Versions 17.0+ ## Issue Boleto is an offline, one-time-use payment method and cannot be tokenized with most payment providers (e.g., Adyen: https://docs.adyen.com/payment-methods/boleto-bancario/, Nuvei: https://www.nuvei.com/apm/boleto). ## Exception Stripe allows a form of tokenization by storing the customer's billing information and regenerating a new Boleto for each payment (cf. https://docs.stripe.com/payments/boleto). Technically, the Boleto itself is not reusable — Stripe simulates tokenization by associating customer info with new Boleto transactions. ## Fix To maintain consistent behavior and avoid provider-specific edge cases, tokenization is disabled for Boleto payments globally. opw-5156718 Forward-Port-Of: odoo/odoo#234373
The event form now displays the currency symbol next to ticket prices. This makes pricing clearer for users and reduces the risk of confusion when setting up event tickets.
Original PR description
Add missing currency symbol next to the event ticket price in the event form view. Task-5114075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233470
Fixed an issue in Barcode operations where available stock was not refreshed after changing the product or source location. This ensures users see the correct stock quantities when creating or editing internal transfers.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#98850 Forward-Port-Of: odoo/enterprise#95906
In dark mode, the debug popup in account reports now shows formulas with a readable text color. This makes it easier for users to inspect report details without straining to read the content.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
The appointment booking flow no longer uses a hard-coded limit for resource capacity. Businesses can now set a global maximum allowed capacity, so customers can book resources with higher capacities when needed.
Original PR description
**Steps to reproduce:** - Install Appointment and Website apps - Create a resource with capacity above 12 - Create an appointment_type on `Resources` - Check `Manage Capacities` - Set its assignment method to `Select Time then auto-assign` - Go to the website and select the new resource - The maximum capacity you can book in the drop-down list is stuck to 12 **Issue:** Arbitrary maximum value (12) seemed to be used in the appointment website and controllers, for the resource capacity which can be booked by someone. **Fix:** Added `resource_max_capacity_allowed` setting to configure the maximum allowed value globally. related: https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc related: https://github.com/odoo/enterprise/commit/db36b59c80b45c6df1da3ac9dc876e79121e5e5e opw-5059177 Forward-Port-Of: odoo/enterprise#94935
This change prevents an error when a purchase warning is shown for a contact that does not have a name. Users can now create purchase orders and related invoices for these contacts without the process crashing.
Original PR description
When creating a purchase order for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install purchase with demo data - Enable purchase warning from settings - Open `Azure…
When creating a purchase order for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install purchase with demo data - Enable purchase warning from settings - Open `Azure Interior` Contact > In Contact, Add Contact > Type: invoice > Save & close - Add warning in newly created contact - Create a purchase order with the newly created partner and create an invoice with the newly created partner Traceback: `TypeError: unsupported operand type(s) for +: 'bool' and 'str'` https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/purchase_order.py#L298 https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/account_invoice.py#L131 Here, `partner_id.name` is `False`, which leads to string concatenation with a boolean in purchase warning messages and results in the above traceback. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes issues that could leave the system in an inconsistent state after uninstalling a module. It ensures affected models and fields are refreshed correctly so database rules and field settings are restored properly, avoiding uninstall errors and stale configuration data.
Original PR description
When we uninstall a module, we never reflect impacted models or fields on ir.model or ir.model.fields. That can lead to an inconsistent state after uninstallation: For example, the…
When we uninstall a module, we never reflect impacted models or fields on ir.model or ir.model.fields. That can lead to an inconsistent state after uninstallation:
For example, the 'appointment_account_payment' module that makes `calendar_event_id` not required anymore. After uninstalling it, the ORM will complain that the not-null constraint doesn't exist ("Missing not-null constraint on appointment.answer.input.calendar_event_id"). Also, if we look at the `ir.model.fields` record for `calendar_event_id`, it shows that the field isn't required, but it should be required again (with the correct constraints too).
Add the information of impacted models for the 'to remove' modules, and force the new registry to call `init_models` on them. This will handle constraints and reflection on `ir.model`/`ir.model.fields`. We can then remove the call to `check_tables_exist` (see 3058ca4121048796c38aad78e3e4f5ffde3530f5) since `init_models` will do the job correctly for impacted models.
Also remove a part of the uninstall hook of website because it forces reloading the registry too soon (warning of missing not-null constraint) and the uninstallation manages the case genericly (remove correctly `ir.model.fields` record of `res.config.settings.website_id`)
runbot-error-233770This update restores menu mode in the self-ordering flow so customers can browse and order as expected. It helps prevent ordering interruptions and improves the reliability of the self-service experience.
Original PR description
Menu mode was broken in self ordering. This commit fix it. Forward-Port-Of: odoo/odoo#234019 Forward-Port-Of: odoo/odoo#232503
This update fixes floating-point rounding issues that could cause DHL shipment validation to fail for otherwise valid orders. It helps ensure prices and weights are sent in a format DHL accepts, reducing delivery errors at confirmation time.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#98819 Forward-Port-Of: odoo/enterprise#96012
7 changes
Resolved issues and error corrections
This update fixes two issues in the Australian TPAR report. Exported country names now use the correct plain text value, and PDF reports now include the information needed to render properly, preventing export failures.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990This change corrects how prices and weights are rounded before sending shipment data to DHL. It prevents validation failures caused by tiny floating-point precision errors, helping deliveries go through without unexpected errors.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#98819 Forward-Port-Of: odoo/enterprise#96012
The appointment booking flow no longer stops at a hardcoded limit of 12 for resource capacity. A new global setting lets businesses define the maximum capacity available in the website booking options, so larger resources can be handled correctly.
Original PR description
**Steps to reproduce:** - Install Appointment and Website apps - Create a resource with capacity above 12 - Create an appointment_type on `Resources` - Check `Manage Capacities` - Set its assignment method to `Select Time then auto-assign` - Go to the website and select the new resource - The maximum capacity you can book in the drop-down list is stuck to 12 **Issue:** Arbitrary maximum value (12) seemed to be used in the appointment website and controllers, for the resource capacity which can be booked by someone. **Fix:** Added `resource_max_capacity_allowed` setting to configure the maximum allowed value globally. related: https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc related: https://github.com/odoo/enterprise/commit/db36b59c80b45c6df1da3ac9dc876e79121e5e5e opw-5059177 Forward-Port-Of: odoo/enterprise#94935
The account reports info popover now uses a lighter text color in dark mode. This makes the displayed formula easier to read for users working in the dark theme, especially in debug mode.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
This fix stops signing request emails from being sent again when a contact’s email address is changed only in letter case, such as from lowercase to uppercase. It prevents duplicate emails and avoids confusing recipients with repeated signing requests for the same document.
Original PR description
Before this commit, when changing the partner email to uppercase or lowercase, it would resend sign requests emails for each previously sent signed request to that email. After this commit, we don't resend anymore the sign requests emails after a case sensitive email change of a partner. task-4844230 Forward-Port-Of: odoo/enterprise#87112
The POS floor plan will only show new table bookings that match the appointment type configured for that POS setup. This prevents bookings from appearing and then disappearing after refresh, and avoids sending notifications when no booking type is set. When Table Booking is turned off, the related appointment type is now cleared automatically to keep settings consistent.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/my-tasks/5005216) Enterprise v17.0: [#93714](https://github.com/odoo/enterprise/pull/93714) --- **Before:** If no appointment type is specified in the POS config and a table is booked via the website, the floor plan is notified of a new booking because the resource used is one of the POS config resources. However, if the page is refreshed, the booking disappears since no appointment type is defined in the POS config **After:** The floor plan is notified of a new booking only if the appointment type of the booking matches the one specified in the POS config. If no appointment type is set in the POS config, no booking notifications are sent. Additionally, when the "Table Booking" field is unchecked in the POS config, the appointment type is automatically unset. Forward-Port-Of: odoo/enterprise#93636
This update corrects automated tests for the accounting reports module after a previous change caused them to fail. It helps keep the reporting feature reliable and ensures future updates can be validated correctly.
Original PR description
See https://github.com/odoo/enterprise/commit/5291d0249ba925182fb9e670f9b46b9e57bda00c Forward-Port-Of: odoo/enterprise#98891
24 changes
Resolved issues and error corrections
This fix prevents a server crash when sending Uruguayan electronic credit or debit notes linked to an original document that is not a valid electronic tax document. Users now receive a clear message explaining what needs to be corrected, helping them resolve the issue without technical support.
Original PR description
### Description of the issue/feature this PR addresses: When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document…
### Description of the issue/feature this PR addresses:
When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document is not a real CFE then will raise a traceback error
### Steps to reproduce:
1. Create an e-invoice and confirm in Odoo (without sending to DGI)
2. Create an e-credit note from the e-invoice created in (1) and confirm
3. Try to send the credit note to DGI
The result is a traceback:
```
RPC_ERROR
Odoo Server Error
Occured on 18.core.odoo.localhost on model account.move.send.wizard on 2025-10-21 20:47:48 GMT
Traceback (most recent call last):
File "/home/odoo/custom/odoo/odoo/http.py", line 2144, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2111, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2359, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/wizard/account_move_send_wizard.py", line 294, in action_send_and_print
attachments = self._generate_and_send_invoices(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 719, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 620, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move_send.py", line 88, in _call_web_service_before_invoice_pdf_render
invoice._l10n_uy_edi_send()
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 813, in _l10n_uy_edi_send
request_data = move._l10n_uy_edi_prepare_req_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 787, in _l10n_uy_edi_prepare_req_data
xml_content = self._l10n_uy_edi_get_xml_content()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 773, in _l10n_uy_edi_get_xml_content
"referencia_lines": self._l10n_uy_edi_cfe_F_reference(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 381, in _l10n_uy_edi_cfe_F_reference
cfe_serie, cfe_number = self.l10n_uy_edi_document_id._get_doc_parts(related_cfe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/l10n_uy_edi_document.py", line 215, in _get_doc_parts
return re.findall(r"([A-Z]{1,2})[-]*([0-9]{1,8})", record.l10n_latam_document_number)[-1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3162:163)
at XMLHttpRequest.<anonymous> (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3167:13)
```
### Desired behavior after PR is merged:
Now we ensure to show a proper message to the user to fix the problem: the original document should be a electronic one
<img width="1203" height="664" alt="after" src="https://github.com/user-attachments/assets/bb7b105e-12f0-4935-b6bc-37edb3bc3aca" />
References LATAM 1301 / ADHOC Task 54770
Forward-Port-Of: odoo/enterprise#90281This update adjusts automated tests in Knowledge and Studio to match the current editor behavior around table endings and selection placeholders. It helps keep quality checks accurate without changing how business users work in the product.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/225576 task-4129699 Forward-Port-Of: odoo/enterprise#96484
A manufacturing planning test now uses a consistent timezone so demo data does not cause duplicate purchase order lines during replenishment. This reduces false test failures and helps keep quality checks reliable across environments.
Original PR description
The `test_replenish` test was failing with demo data because replenishment created an extra Purchase Order line. The `_run_buy` search domain included `date_planned_mps` with an equality check on a datetime stored in `UTC`. With demo data loaded in a non-UTC timezone (e.g. Europe/Brussels), the forecast date was converted to `2025-07-31 22:00:00 UTC`, which did not match the existing PO at `2025-08-01 00:00:00 UTC`. As a result, no PO was found and a duplicate was created. Changes: Set the test user timezone to `UTC` so that `date_planned_mps` comparisons are stable when using demo data. This ensures replenishment reuses the existing PO instead of creating a duplicate. [runbot-230425](https://runbot.odoo.com/odoo/error/230425) Forward-Port-Of: odoo/enterprise#98268
Customers can no longer cancel self-order orders from “My orders” once they have been sent to the kitchen display. This prevents mismatches where an order is cancelled in the system but still appears active for kitchen staff, reducing operational confusion.
Original PR description
Currently, it is possible to cancel orders that have been sent to the kitchen display. However when doing so, the kitchen displayd does not receive any information about the cancellation. Steps to reproduce: ------------------- - Modify restaurant and enable self ordering - Open self an place an order (not paid but sent to kitchen) - Go back to "My orders" and cancel it > Order is cancelled in backend but not in the kitchen display Why the fix: ------------ When an order is sent to the kitchen the only way to cancel it should be by going to the register. Therefore now, if an order is present on the kitchen display we will not show the cancel button. opw-5030223 Community: https://github.com/odoo/odoo/pull/229039 Forward-Port-Of: odoo/enterprise#98035 Forward-Port-Of: odoo/enterprise#95770
Manufacturing work orders marked as done directly from the status widget now correctly add the related work center cost to the project analytics. This keeps project gross margin calculations accurate even when users skip the start/stop workflow.
Original PR description
This PR fixes the problem of adding the hourly cost of the work center when marking an operation as done from the status widget. To reproduce the bug: 1- Create a work center with an hourly cost > 0. 2- Create an MO with 1 operation in that work center, expected time > 0. 3- Create and set a project on the MO. 4- Make sure that project has an analytic account. 5- Mark the operation as done from the status widget. (click on it and choose done, don't use the start button) 6- Go to the analytic account of the project and check the gross margin. = No cost of the workorder was added. Now, this PR takes into account the duration of the WO first when marking it as done directly from the status widget. Task-5156286 Forward-Port-Of: odoo/enterprise#97253
This fix ensures Australian TPAR reports export correctly by using the proper country name format and adding missing report structure information. Businesses can now generate both TPAR files and PDFs without errors caused by incorrect country data or missing report line details.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990The Czech VIES summary report now uses invoice amounts converted into the company currency, rather than treating foreign-currency values as already converted. This prevents overstated or understated report totals when invoices are issued in a different currency.
Original PR description
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in…
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report. **Steps to Reproduce:** 1. Install the Accounting app and the l10n_cz_reports_2025 module. 2. Go to Accounting > Customers > Invoices. 3. Create a new invoice using a currency other than CZK. 4. Add a product with Code Supply set to Gold and Transaction Code set to 0 Goods. Confirm the invoice. 5. Navigate to Accounting > Reporting > VIES Summary Report. 6. Observe that the total value is not correctly converted to the company currency. **Expected Behavior:** The total amounts in the VIES summary report should be correctly converted to the company currency if the invoice was created in a foreign currency. **Actual Behavior:** Amounts are displayed in the invoice currency without conversion, leading to incorrect totals when the invoice currency differs from the company currency. **Root Cause** The report fetches raw invoice data without handling currency conversion. Specifically, it retrieves the unconverted total value, even when the invoice currency differs from the company’s. **Fix** To solve the issue the balance field is used, which correctly reflects the value in the company currency. opw-4688638 Forward-Port-Of: odoo/enterprise#97894 Forward-Port-Of: odoo/enterprise#82978
Payslip exports now use the fields selected by the user instead of falling back to incorrect defaults. This ensures payroll teams get the expected information in exported files, reducing manual corrections and confusion.
Original PR description
Since the introduction of payslip issues, the optional active fields were not correctly given back to the controller. This resulted in having the wrong default fields inside the export (not the ones selected). This commit fixes the issue by avoid using a proxy. task-5129681 Forward-Port-Of: odoo/enterprise#96707
This fix makes the formula text in accounting report info popovers readable when dark mode is enabled. It improves usability for users reviewing report details in debug mode without changing report data or workflows.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
The Chilean point of sale flow now handles contacts with missing required information properly during order validation. Instead of crashing, the system shows the expected notification and opens the contact edit form so staff can correct the details and continue the sale.
Original PR description
Before this commit, when validating an order, if the selected contact was missing a required field, the PoS would crash instead of displaying the correct notification and opening the partner edit form. opw-5222040 Forward-Port-Of: odoo/enterprise#98757
The tax report settings now refer to this timing field as a deadline instead of a reminder. This makes the label match its actual purpose: calculating the default deadline from the end of a tax return period.
Original PR description
This field is not a reminder anymore and is used to compute the default deadline from the end of the tax return. task-5153900 Forward-Port-Of: odoo/enterprise#96651
This fix corrects uneven vertical spacing on the return type form by using the appropriate inline text element. Users will see a more consistent and polished layout when viewing or editing return types.
Original PR description
The return type form view had an inconsistent vertical spacing due to the use of a paragraph instead of a span. task-5153900 Forward-Port-Of: odoo/enterprise#96711
When someone signs a document while logged in as another user, Odoo no longer automatically uses the other user's saved signature. The signing certificate now clearly notes that the document was signed via another user's account, improving transparency and preventing accidental misuse of stored signatures.
Original PR description
Before this commit, we allow to sign on behalf on another user but we should not fetch his saved signature. We want that when a user is signing from the account of another user: - we don't load the signature of the user (saved in the user profile) - we have a mention in the certificate that the document was signed via another user. task-5223975 Forward-Port-Of: odoo/enterprise#98533
When customers book a table from the website, the phone number field is now filled from the customer record linked to the appointment. This helps staff see the correct contact number while keeping the booking’s phone field as a separate copied value.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/project/1737/tasks/5005216) --- The phone number field was not being populated correctly when booking a table from the website. It is now properly filled using the phone number of the `res.partner` associated with the appointment. The field remains unlinked to the partner, as it is just a copy. Forward-Port-Of: odoo/enterprise#98041 Forward-Port-Of: odoo/enterprise#92836
Rental-related automated tests were adjusted so they no longer depend on optional demo accounting or stock setup. This helps ensure the rental sales module can be validated consistently across clean test environments, reducing false failures in the release process.
Original PR description
The test was failing in no-demo environments because it relied on accounting and stock configurations that were not present. When the test attempted to set property_valuation = 'real_time' on the product category, it triggered a ValidationError because the related stock accounts had not been properly set up for the test's transaction context. runbot-error-230417 Forward-Port-Of: odoo/enterprise#98798 Forward-Port-Of: odoo/enterprise#92292
Live chat conversations now show the correct channel name when a new member joins, even when some current participant details are unavailable. This helps support teams and visitors keep the right context in the helpdesk live chat sidebar.
Original PR description
…mber join This change introduces the `im_livechat.channel.member.history` model on the client side to properly display the Livechat channel name. In the case of lacking data for current agents or visitors, we use the history records to display the channel name. task-4966319
Subscription invoices that are aligned to the calendar will now keep delivery charges at their full fixed amount instead of reducing them like service fees. This prevents undercharging customers for shipping when prorated invoices are created.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a subscription with delivery product. 2. Select align to calendar in the recurring plan 2. Add shipping method by assigning a delivery product with recurring_invoice. 3. Create an invoice with prorated Issue: - Delivery products are considered service-type products and their price was prorated in invoice. Cause: - The proration logic treated delivery lines like normal recurring service products, instead of keeping their fixed charge. Solution: - Exclude delivery products from proration by setting their period ratio to 1. Co-authored-by: Darshan Patel dvpa@odoo.com Co-authored-by: Federico Braidi brfe@odoo.com task-4662188 Forward-Port-Of: odoo/enterprise#98909 Forward-Port-Of: odoo/enterprise#91133
This fix places a manufacturing work order quality view in the correct module and updates its dependency setup. It helps ensure the related quality features load reliably when manufacturing work orders are installed.
Original PR description
view `quality_point_routing_view_form_inherit_quality_mrp` was supposed to be in the module `quality_mrp_workorder` as it has `quality` and `mrp_workorder` as dependency. And also `quality_mrp_workorder` was supposed to depend on `quality_mrp` not `quality_control`. Forward-Port-Of: odoo/enterprise#97147
The point of sale settlement flow now prevents the same customer invoice from being settled more than once. This avoids duplicate payments or accounting entries and keeps the selected customer in place if a repeat settlement attempt triggers an error.
Original PR description
Steps to reproduce: ------------------------- - Install POS. - Create an invoiced order and pay with customer account. - Settle the created invoices from customers list. - Try to settle the invoice again from the same order. Issue: ------- - The system allows settling the same invoice multiple times. Cause: --------- - There is no check in place to verify whether the invoice has already been under settlement process before settling it again. Fix: ----- - Add a validation step to ensure that if the same invoice is selected again, the system prevents duplication and it will show that already being settled. - Also if error occured due to second try of settlment will not lose the selected partner. task: 5028009 related PR: [227971](https://github.com/odoo/odoo/pull/227971) Forward-Port-Of: odoo/enterprise#98927 Forward-Port-Of: odoo/enterprise#95156
This fix ensures Web Studio saves changes only once when a browser tab is hidden or switched away from. It reduces unnecessary background save activity and helps keep editor behavior consistent without changing how users work.
Original PR description
This commit is the counter part of odoo/odoo#232523. A form editor test had to be adapted as we no longer go through _save in the tested scenario. task~5184626
The appraisal feedback wizard now only considers appraisal survey templates the current user is allowed to access. This prevents users from hitting an access error when asking for feedback if another restricted survey exists in the system.
Original PR description
To reproduce (on runbot): - As 'admin' user: * Create a survey of type 'Appraisals' and name it 'Test No Access' * Set `Restricted to' to 'admin' user only. - As 'demo' user: * Create an appraisal for another employee * Click on "Confirm" button * Click on "Ask Feedback" button * Try to choose an Employee. An exception is raised saying we don't have 'read' access to the survey 'Test No Access'. This commit force computing `survey_template_id` as non-superuser only get survey that the user has access to. Forward-Port-Of: odoo/enterprise#98348
Monthly minimum rental periods now use real calendar months instead of assuming every month has 30 days. This prevents valid rentals in shorter months, such as February, from being incorrectly rejected on the website.
Original PR description
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting,…
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting, set `Minimum Rental Duration` to 1 month. 3- Create a rental product and from website, choose the date: - 01/02/2026 - 28/02/2026 4- This fails. The earliest end date it accepts is 03/03/2026. Cause: This is due to hardcoded 30 days: https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L7-L12 https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L47-L53 We can use luxon plus method instead. ```diff + const minEndDate = startDate.plus(Object.fromEntries([[unit, duration]])); ``` In all usages of `msecPerUnit` we can do the same. Also we can keep remove `msecPerUnit` from master. opw-5094534 Forward-Port-Of: odoo/enterprise#98967 Forward-Port-Of: odoo/enterprise#98168
Barcode internal transfers now refresh available stock quantities when the selected product or source location changes. This helps warehouse staff see accurate stock availability while preparing transfers, reducing confusion and operational errors.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#98900 Forward-Port-Of: odoo/enterprise#95906
This change prevents certain payment-related tests from running when the required accounting component is not installed. It helps avoid false test failures and keeps validation results reliable without changing customer-facing functionality.
Original PR description
We have tests for payment wihtout journal entries. But these payments can only be generated if accountant in installed. It makes these tests fail if the module is not installed. To avoid making a bridge module only to test these, we add a class that will be skipped if the module is not installed. runbot-232728 Forward-Port-Of: odoo/enterprise#97764
26 changes
Resolved issues and error corrections
Users can now search for messages in mailboxes and jump directly to the matching message. This fixes a navigation issue that previously prevented message links from working in mailboxes, making it easier to find and review conversations.
Original PR description
Before this commit, we could not jump to messages in mailboxes. This happens because the `useMessageHighlight()` hook prevented jumping to messages in thread that were not their origin thread. This commit fixes the issue by removing this limitation specifically for mailboxes. opw-4948798 opw-5087102 Forward-Port-Of: odoo/odoo#234526
Fixed an issue where the image toolbar would not open if the editable area had lost focus. The update makes toolbar behavior more reliable when users click between content and other parts of the page.
Original PR description
Description of the issue: - The image toolbar failed to open when the editable had lost focus. - Previously, `focusEditable()` exited early if the active element was inside the editable, even when the actual document selection wasn’t. Solution: - Updated the condition in `focusEditable()` to also check whether the document selection is inside the editable. - Now it only returns early when both the active element and the selection are within the editable. task-5117272 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234338 Forward-Port-Of: odoo/odoo#230549
When a portal user updates their profile details, Odoo will now avoid overwriting any custom bank account holder name if the user did not actually change their name. This prevents an unexpected data change in employee bank details and preserves manually entered account information.
Original PR description
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a…
Steps to Reproduce: ------------------------- 1. Install the Website and Employees modules. 2. Create a Test User and It's Employee. 3. On the Employee record, go to Private Information, create a Bank Account with a custom Account Holder Name. 4. Log in to the Website using the Test User. 5. Navigate to My Account and click Edit Information. 6. Fill in the address details (without changing the Name) and click Save. 7. Go back to the Employee’s Bank Account and check the Account Holder Name. Observation: ------------------------- The Account Holder Name was overwritten to the partner's name. Issue: ------------------------- In `_compute_account_holder_name` method, https://github.com/odoo/odoo/blob/c3b543631bde96260082484a3baac19d942f6b9f/odoo/addons/base/models/res_bank.py#L104-L107 The Account Holder Name is always recomputed using the Partner’s name. When submitting the form from the frontend, the name field is included in the values sent to update the Partner, even if the user did not actually change the name. https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/portal/controllers/portal.py#L196-L205 which re-triggers this compute and as a result, the Partner’s name overwrites the Account Holder Name on the linked Bank Account Solution: ------------------------- Prevent the Account Holder Name compute method from being triggered when updating information from the frontend if the Partner’s name has not been changed. opw-5059247 Forward-Port-Of: odoo/odoo#232723 Forward-Port-Of: odoo/odoo#229210
This update prevents users from editing stages in a shared project kanban board. It avoids an error that could appear when they try to search for more projects, improving stability for shared project users.
Original PR description
Steps to reproduce: - 1. Install the Project module. 2. Create a new project and share it with a user. 3. Log in as that user. 4. Open the shared project Kanban view and try to edit a stage. 5. Try to search for more projects. Issue: - A traceback occurs when clicking on 'Search More'. Fix: - Prevent stage editing in shared project Kanban view. task-5176630 Forward-Port-Of: odoo/odoo#233557
This update corrects the data sent to ECPay for invoices created from down payments. It ensures negative quantities are handled properly so the invoice information remains valid and the payment record can be processed without errors.
Original PR description
When an invoice is created from a sale order with a downpayment, the invoice line for the downpayment typically has a negative quantity and a positive unit price. However, ECPay does not accept negative quantities, and this also leads to incorrect price values being sent in the JSON payload. To address this, when an invoice line has a negative quantity, it is inverted to ensure the data sent to ECPay is valid and consistent. **task**-5211264 Forward-Port-Of: odoo/odoo#233359
This update fixes two issues in the Australian TPAR report: exported file lines now use the correct country name format, and PDF generation no longer fails when rendering report lines. As a result, users can export and print the report reliably without errors.
Original PR description
Behavior before: Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'})…
Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.
Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.
Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.
Ticket [link](https://www.odoo.com/odoo/project.task/5148697)
opw-5148697
Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990The purchase agreement view now shows the start and end dates in the same date format. This makes the information easier to read and avoids confusion when comparing contract dates.
Original PR description
Issue: In the purchase agreement view the start and end date have different date formatting where start date is writting as such (Nov 12) and end date is written as (02/01/2027). Fix: Simply added the widget date alongside the optio numeric true for the start date opw-5187358 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a small issue in the Belgian black box POS module when receiving orders from Urban Piper. It helps ensure these orders are accepted and processed correctly, reducing the risk of ordering disruptions for affected businesses.
Original PR description
Fix small issue in `pos_blackbox_be` module when accepting orders from Urban Piper. Forward-Port-Of: odoo/enterprise#98563
The event form now displays the currency symbol next to ticket prices. This makes pricing clearer for users and helps avoid confusion when managing event tickets.
Original PR description
Add missing currency symbol next to the event ticket price in the event form view. Task-5114075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233470
This change moves the accrual menu’s parent to a menu that is always available in the main accounting module. It prevents a setup issue that could break menu access when related accounting add-ons are installed and then removed.
Original PR description
The PR odoo/enterprise#97151 introduces a miss-match between module dependency (new modules depend of `account_accountant`) and by records used as parent menu (defined in `account_report`.) `account_report` depends of `account_accountant` and is in auto-install which means by installing modules there is no issue, but in config where `account_accountant` is installed and then `account_report` is uninstalled, it causes issue. To fix that, a new menu item is created in `account` and will be used by accrual menu item as parent menu. **Enterprise PR:** https://github.com/odoo/enterprise/pull/98914
Boleto payment methods are now marked as non-tokenizable, so customers can no longer save them for future reuse. This avoids inconsistent behavior across payment providers and prevents issues with providers that do not support reusable Boleto payments.
Original PR description
## Versions 17.0+ ## Issue Boleto is an offline, one-time-use payment method and cannot be tokenized with most payment providers (e.g., Adyen: https://docs.adyen.com/payment-methods/boleto-bancario/, Nuvei: https://www.nuvei.com/apm/boleto). ## Exception Stripe allows a form of tokenization by storing the customer's billing information and regenerating a new Boleto for each payment (cf. https://docs.stripe.com/payments/boleto). Technically, the Boleto itself is not reusable — Stripe simulates tokenization by associating customer info with new Boleto transactions. ## Fix To maintain consistent behavior and avoid provider-specific edge cases, tokenization is disabled for Boleto payments globally. opw-5156718 Forward-Port-Of: odoo/odoo#234373
This update prevents inventory reservation cleanup from running on kit-type products, which could trigger errors when users open the stock quant list. It helps avoid blocking users from adjusting stock quantities when a product was changed to a kit after being used in inventory operations.
Original PR description
Since this commit: 766ec99 We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on…
Since this commit: 766ec99 We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on “stock.quant”. However, there are cases where a user creates a storable product, updates its quantity, and then uses it in a “stock.move.line”, confirms it, and later changes the product type to a kit. So, when trying to clean the reservations for these “stock.move.line”, a user error occurs because the system attempts to create a quant for a kit-type product: https://github.com/odoo/odoo/blob/c07778bbce4311c142bd8e2ce3013998d4f126ae/addons/mrp/models/stock_quant.py#L6-L11 As a result, each time users try to access the quant list, clean_reservation is triggered, causing a user error that prevents them from modifying the quantity of any quant. Solution: For kits, we can skip cleaning their quant to avoid unnecessary errors. This is a manual forward-port of #200595 opw-4625002 opw-4624008 opw-4621175 opw-4625465 opw-4621504 opw-4623523 opw-4621508 opw-4623329 opw-4629386 opw-5179369 Forward-Port-Of: odoo/odoo#234417 Forward-Port-Of: odoo/odoo#232646
This update ensures delivery fees in subscription invoices are kept as fixed charges instead of being reduced when invoices are prorated. It prevents shipping costs from being undercharged when subscriptions are billed according to a calendar or partial period.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a subscription with delivery product. 2. Select align to calendar in the recurring plan 2. Add shipping method by assigning a delivery product with recurring_invoice. 3. Create an invoice with prorated Issue: - Delivery products are considered service-type products and their price was prorated in invoice. Cause: - The proration logic treated delivery lines like normal recurring service products, instead of keeping their fixed charge. Solution: - Exclude delivery products from proration by setting their period ratio to 1. Co-authored-by: Darshan Patel dvpa@odoo.com Co-authored-by: Federico Braidi brfe@odoo.com task-4662188 Forward-Port-Of: odoo/enterprise#98784 Forward-Port-Of: odoo/enterprise#91133
The VIES summary report now uses the amount converted into the company currency when invoices are issued in another currency. This ensures the reported totals are accurate and prevents mismatches in tax reporting.
Original PR description
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in…
**Issue** When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report. **Steps to Reproduce:** 1. Install the Accounting app and the l10n_cz_reports_2025 module. 2. Go to Accounting > Customers > Invoices. 3. Create a new invoice using a currency other than CZK. 4. Add a product with Code Supply set to Gold and Transaction Code set to 0 Goods. Confirm the invoice. 5. Navigate to Accounting > Reporting > VIES Summary Report. 6. Observe that the total value is not correctly converted to the company currency. **Expected Behavior:** The total amounts in the VIES summary report should be correctly converted to the company currency if the invoice was created in a foreign currency. **Actual Behavior:** Amounts are displayed in the invoice currency without conversion, leading to incorrect totals when the invoice currency differs from the company currency. **Root Cause** The report fetches raw invoice data without handling currency conversion. Specifically, it retrieves the unconverted total value, even when the invoice currency differs from the company’s. **Fix** To solve the issue the balance field is used, which correctly reflects the value in the company currency. opw-4688638 Forward-Port-Of: odoo/enterprise#97894 Forward-Port-Of: odoo/enterprise#82978
This update blocks duplicate invoice settlements in Point of Sale. If a customer invoice is already being settled, the system now prevents it from being selected again and keeps the customer selection in place if an error occurs.
Original PR description
Steps to reproduce: ------------------------- - Install POS. - Create an invoiced order and pay with customer account. - Settle the created invoices from customers list. - Try to settle the invoice again from the same order. Issue: ------- - The system allows settling the same invoice multiple times. Cause: --------- - There is no check in place to verify whether the invoice has already been under settlement process before settling it again. Fix: ----- - Add a validation step to ensure that if the same invoice is selected again, the system prevents duplication and it will show that already being settled. - Also if error occured due to second try of settlment will not lose the selected partner. task: 5028009 related PR: [227971](https://github.com/odoo/odoo/pull/227971) Forward-Port-Of: odoo/enterprise#95156
This update fixes an issue in Point of Sale where selecting different variants of a lot-tracked product could accidentally change the prices of all variants. Pricing now stays correct for each variant, helping prevent billing mistakes at checkout.
Original PR description
Before this commit, when a product had multiple variants with different prices and was tracked by lot, adding different variants in the PoS would incorrectly update all product prices. opw-5228830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234332 Forward-Port-Of: odoo/odoo#234171
In dark mode, the informational popover in Account Reports now uses a lighter text color so formulas are easier to read. This makes the debug information clearer and improves usability for users working in low-light themes.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
The configuration field has been renamed so it better reflects its actual purpose: calculating the default tax return deadline. This reduces confusion for users and makes the setting easier to understand when preparing tax reports.
Original PR description
This field is not a reminder anymore and is used to compute the default deadline from the end of the tax return. task-5153900 Forward-Port-Of: odoo/enterprise#96651
This change prevents a rare database error when a unit of measure has an extremely large relative value. It caps the automatically assigned sequence number so records can still be saved without failing.
Original PR description
The default value of uom.sequence is calculated as uom.relative_factor * 100. If the value of relative_factor is big enough, it can be bigger than what the int column can handle and trigger ``` ERROR: integer out of range ``` So we just cap it at an arbitrary value. To reproduce: - Create an uom with relative factor bigger than 2147483647.
The commercial state field is now only shown on accounting entries for Colombian companies. This prevents users working in other countries from seeing a field that does not apply to their company and reduces confusion when creating moves.
Original PR description
The commercial state field should only be visible on moves part of Colombian companies. Steps to reproduce: load the `l10n_co_dian` module and switch a non-Colombian company, then create a move -> the commercial event is visible. task: 5232473
The inventory valuation report will no longer fail if the company’s valuation account is missing. This lets users generate the report first and only see a warning later if they try to create an accounting entry without the required account.
Original PR description
****Behavior:**** **Current:** When generating the inventory valuation report, if the default stock valuation account is removed in the company settings, the system assumes that there will be an…
****Behavior:**** **Current:** When generating the inventory valuation report, if the default stock valuation account is removed in the company settings, the system assumes that there will be an account linked to the debit/credit and will attempt to access it without any other check which will lead to an IndexError. **Expected:** We want to avoid blocking users as much as we can, so we will allow users to generate the report without the account and later fallback to stopping them with a warning if they try to generate an accounting entry from the valuation. Since we are now checking that there is an account before trying to access it, it doesn't matter if it is empty. **Steps to reproduce:** - Enable warehouse locations - Make sure the Production location has a 'Cost of Production' account. - Create two products with costs and prices - Create a bom and manufacture one of the products. - Go to Settings/Inventory Valuation and remove the Valuation Account - When trying to generate the Inventory Valuation, you should get an error opw-5184300
This change prevents a crash that could happen when users add a new line to a bank statement linked to a copied or non-default journal. It makes bank statement entry more reliable and avoids interrupting accounting work.
Original PR description
The system will crash when user tries to create new bank statement line. **Steps to produce:** - Install `Invoicing` module without demo data. - Go to `Configuration > Journals` and duplicate the…
The system will crash when user tries to create new bank statement line. **Steps to produce:** - Install `Invoicing` module without demo data. - Go to `Configuration > Journals` and duplicate the default Bank journal to create Bank (Copy). - `Dashboard` and Click on 3 dots of Bank(Copy) and click on `Transactions`. - Create a new transaction and set the Statement also(Create new and assign it). - Go to that statements and Add a line and set the foreign currency as `USD`. **Error:** `ValueError: Wrong value for account.bank.statement.journal_id: account.journal(7, 6)` **Cause:** - During an onchange on a new, unsaved `statement line`, our code tried to read the `statement_id.journal_id` ([1]). This forced to compute the journal on the unsaved parent statement, which failed with a error. **Solution:** - We use `self.statement_line_id.statement_id._origin.journal_id` to read the journal's stored value [1] https://github.com/odoo/odoo/blob/ec2d8d026d9f13c8fb869ad1f7b8026a144e85ec/addons/account/models/account_move.py#L887 **sentry-6928858335** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects how accrual menu items are connected so they no longer depend on a menu that can disappear in certain setup changes. It helps ensure users can reliably access accrual-related options after installing or removing accounting-related components.
Original PR description
The PR odoo/enterprise#97151 introduces a miss-match between module dependency (new modules depend of `account_accountant`) and by records used as parent menu (defined in `account_report`.) `account_report` depends of `account_accountant` and is in auto-install which means by installing modules there is no issue, but in config where `account_accountant` is installed and then `account_report` is uninstalled, it causes issue. To fix that, a new menu item is created in `account` and will be used by accrual menu item as parent menu. **Community PR:** https://github.com/odoo/odoo/pull/234577
This update restores the bank statement view that was previously removed and adjusts the button action so it opens the correct screen again. It fixes a broken workflow in bank reconciliation, helping users review and process statements without errors.
Original PR description
This commit: 935b25f change the view of the bank statement but by doing so they broke the use of the statement button on the bank rec widget. This commit will add the old view back and change the view used in the action of the statement button. (This view has already been added in 19.1 so it's kind of a backport of https://github.com/odoo/enterprise/commit/2ea690bb5b08ac014f89cc05813c557ccb8832bb) no task id
This fix ensures the minimum rental period is calculated correctly for calendar months, so a one-month rental works as expected in shorter months like February. It prevents customers from being blocked by an incorrect extra-long minimum end date when selecting rental dates on the website.
Original PR description
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting,…
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting, set `Minimum Rental Duration` to 1 month. 3- Create a rental product and from website, choose the date: - 01/02/2026 - 28/02/2026 4- This fails. The earliest end date it accepts is 03/03/2026. Cause: This is due to hardcoded 30 days: https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L7-L12 https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L47-L53 We can use luxon plus method instead. ```diff + const minEndDate = startDate.plus(Object.fromEntries([[unit, duration]])); ``` In all usages of `msecPerUnit` we can do the same. Also we can keep remove `msecPerUnit` from master. opw-5094534 Forward-Port-Of: odoo/enterprise#98899 Forward-Port-Of: odoo/enterprise#98168
This update fixes an issue where the attendance camera could fail to start correctly in some cases. It helps ensure employees can reliably use camera-based attendance without getting blocked by a blank or broken camera view.
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
6 changes
Resolved issues and error corrections
Boleto payment methods are now treated as one-time payments and cannot be tokenized for later reuse. This avoids inconsistent behavior across payment providers and reduces the chance of payment failures or confusing customer experiences.
Original PR description
## Versions 17.0+ ## Issue Boleto is an offline, one-time-use payment method and cannot be tokenized with most payment providers (e.g., Adyen: https://docs.adyen.com/payment-methods/boleto-bancario/, Nuvei: https://www.nuvei.com/apm/boleto). ## Exception Stripe allows a form of tokenization by storing the customer's billing information and regenerating a new Boleto for each payment (cf. https://docs.stripe.com/payments/boleto). Technically, the Boleto itself is not reusable — Stripe simulates tokenization by associating customer info with new Boleto transactions. ## Fix To maintain consistent behavior and avoid provider-specific edge cases, tokenization is disabled for Boleto payments globally. opw-5156718 Forward-Port-Of: odoo/odoo#234373
The account reports info popover now uses a lighter text color in dark mode, making the formula easier to read. This improves usability for users who inspect report details in debug mode.
Original PR description
When using the dark mode, the popover available only in debug mode on the account reports (when pressing the info button on the right of each line) used to display the formula with a dark color, making it hard to read. Forward-Port-Of: odoo/enterprise#98905
This update fixes an issue in Shiprocket delivery label generation when taxes without GST tags are used. It also makes the related test more reliable by forcing a consistent tax rate, reducing the risk of intermittent failures.
Original PR description
Some other test adds a fiscal position with tax mapping. This creates 2 problems 1. The new taxes have a tag, which means we evaluate the right hand of…
Some other test adds a fiscal position with tax mapping. This creates 2 problems
1. The new taxes have a tag, which means we evaluate the right hand of
https://github.com/odoo/enterprise/blob/8d3fe30c627eada1186c15480876fb2e8f7ddb59/delivery_shiprocket/models/shiprocket_request.py#L239
However, since l10n_in is not installed,
`tax.env.ref(f"l10n_in.tax_tag_{gst}gst", False)`
does not return anything (False is not a fallback)
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/api.py#L588
So we end up looking for `None` in `tax_tag_ids`, which leads us to compare the `_name` properties, see
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/models.py#L6545-L6558
2. The test added in 4d5df93 was assuming the default company 15% tax, which was not always true
Solution
-----
1. Provide a fallback for the `ref` lookup
2. Force a 15% tax in the test
-----
runbot-232692
Forward-Port-Of: odoo/enterprise#97998Quality checks now keep the correct company when they are created from stock movements. This prevents confirmation errors when a user switches to another company, making intercompany receipt handling more reliable.
Original PR description
When creating quality checks per quantity, a multi-company error occurs if the active company differs from the one defined on the control point. Steps to reproduce: - Create a Quality Control Point for Company B and Product Table for the receipt operation with a per-quantity control. - Create a receipt in Company B for this product but leave it in draft. - Switch to Company A and try to confirm → error. Root cause: The company_id was not set when creating the quality check, causing it to default to `env.company` (A) instead of the stock move line’s company (B). opw-86993 Forward-Port-Of: odoo/enterprise#98655
This change adjusts how Swiss ISO20022 payment files are generated so they only include SEPA-specific XML details when explicitly enabled. It helps avoid files being rejected by banks that still expect the older Swiss format, while keeping the earlier fix available for cases that need it.
Original PR description
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after…
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt. The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix. ticket-4535542 ======================= [FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard. Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file. ticket-4535542
This update prevents an access error in Documents when a company is archived and users open the app. It ensures folders are only loaded for companies the user can still access, so the Documents workspace opens normally.
Original PR description
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it…
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it **Issue:** The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`: `folders = accessible_records.filtered(lambda d: d.type == 'folder')` This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched. **Fix:** Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere. For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows. opw-4931278
7 changes
Resolved issues and error corrections
This change corrects how reversal documents identify the original vendor bill when sending Malaysian e-invoices. It now uses the stored invoice reference so credit notes validate properly even if the bill reference was changed later.
Original PR description
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference document UUID [...] does not exist. The internal ID for DocumentUUID [...] does not match. ``` Steps to reproduce: - With an MY company setup - Create a bill and add a custom reference - Send Bill to MyInvois - Create credit note for the Bill - Send Credit note to MyInvoice Issue: Validation will fail because the reference does not match. In the reverse bill we always send the original bill name as original bill id, but also the reference could have been used. Analysis: A solution would be to send always the reference of the original vendor bill if present. However, the bill reference may be altered after submitting the e-invoice. A safer way is to retrieve the reference from the stored e-invoice. opw-5057050
This fix stops temporary loading elements and disabled states added by Cloudflare Turnstile from being saved into website forms. As a result, forms keep working normally even if the Turnstile module is later removed or turned off.
Original PR description
Steps to reproduce: 1. Install the `website_cf_turnstile` module. 2. Enter valid Cloudflare Turnstile credentials in the configuration. 3. Go to the Website Editor. 4. Add or edit a form (e.g. contact form) and save the page. 5. Notice that the form’s submit button temporarily shows a spinner and gets a 'disabled' class while Turnstile is initializing. 6. After saving the page, these temporary elements and classes (e.g. .turnstile-spinner and 'disabled') are incorrectly saved into the form’s HTML. 7. If you later remove or uninstall the website_cf_turnstile module, the submit button remains disabled and the spinner icon still appears, even though Turnstile is no longer active. After this commit: Now, when you save a website form in the editor, any temporary classes or elements added by Cloudflare Turnstile are removed. This prevents unwanted changes from being saved to forms. task-4951470
This update fixes a crash and slow loading when opening the chat tab in the messaging menu, especially on iOS and in accounts with many chats. It improves how chat threads are loaded and sorted so the menu opens more smoothly and reliably.
Original PR description
Before this commit, a maximum call stack traceback occurred when accessing the chat tab of the messaging menu on iOS when many chats were present. On chrome and firefox, no traceback occurred, but…
Before this commit, a maximum call stack traceback occurred when accessing the chat tab of the messaging menu on iOS when many chats were present. On chrome and firefox, no traceback occurred, but the menu took a long time to open. Threads shown in the messaging menu rely on the `menuThreads` store property, which had two issues: - It was a computed field done on the many side of the relation, while relying on the inverse (thread) side would be much faster. - The sort function was triggered for each thread inserted or removed from the relation. The sort function is not trivial, and accessing sort fields through the reactive proxy is very slow. This commit fixes the issue by: - Updating the `menuThreads` property to use an inverse instead of a complex compute. - Debouncing the array sort to ensure it is executed only once when the relation is properly filled. task-4794325 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 change removes blank spaces that appeared in Deliveries and Batch Transfers screens. It improves the layout so users see cleaner tables with the correct columns shown only when needed.
Original PR description
Issue: Blank, unused columns showed in Deliveries and Batch Transfers. Repro Steps: Open Deliveries and see a right-side gap . Open Batch Transfers list and see a right-side gap. Open a Batch Transfer details shows left-side gap. Cause: Rows were hidden, but their table columns stayed visible, so space was still reserved. Fix: Deliveries: hide the rescheduling popover column and the activity indicator column at the column level. Batch Transfers list: hide the activity indicator column at the column level. Batch Transfer Detailed: hide the three quality-check button columns at the column level when the batch has no checks to do (keep row-level visibility when shown). opw-5167229 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where repeated IoT screen actions left background requests running instead of stopping them. As a result, the IoT interface is more reliable and no longer runs into browser request limits that could cause actions to fail or time out.
Original PR description
Steps to reproduce: 1. Pair an IoT box 2. In the IoT form view, click on any device, then click back to return to the IoT form view. 3. Repeat this step multiple times. If you have devtools open, you…
Steps to reproduce: 1. Pair an IoT box 2. In the IoT form view, click on any device, then click back to return to the IoT form view. 3. Repeat this step multiple times. If you have devtools open, you can see a `/event` fetch request every time you open the device form. Expected behaviour: - When a new request is made, the previous request is cancelled. Actual behaviour: - The previous requests remain active, and eventually no further requests are possible due to browser limits, causing action calls to timeout. This behaviour was broken when the longpolling was changed to use the `fetch` method instead of jquery. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called. Before the fix (action times out due to many stuck event calls): <img width="545" height="249" alt="image" src="https://github.com/user-attachments/assets/f18b8a5d-c27c-47a3-ab58-428a78ef5383" /> After the fix (action succeeds): <img width="538" height="228" alt="image" src="https://github.com/user-attachments/assets/30f2863e-9df9-4a6e-b715-135ece4224ed" />
This fixes an issue in the Italian tax XML export where quarterly tax returns could be incorrectly blocked when there was no closing in the previous month. With this correction, businesses using quarterly tax periods can post their tax closing entries normally, while the monthly validation still remains in place where needed.
Original PR description
A [previous PR](https://github.com/odoo/enterprise/pull/86642) improved the XML export of tax returns with Italian localization. This introduced a bug if the tax period is set quarterly. Currently, it prevents a tax return move from being posted if it detects previous tax closings, but there are none in the previous month. This should only be the case if the tax period is set monthly. Steps to reproduce on runbot: - Install the l10n_it_xml_export module - Switch to an Italian company and set the tax period to `quarterly` - Create a closing entry for the previous quarter - Try to create a closing entry for the current quarter Related ticket: opw-5156791
The color picker interface now refreshes properly when users choose grayscale, transparent grayscale, or theme colors. This makes it easier to fine-tune background colors without the UI showing outdated color information.
Original PR description
Before this commit, the colorpicker UI would not update when switching to some colors (grayscale, transparent grayscale, theme colors). It would therefore be difficult to make small changes to those colors. This commit make the colorpicker update correctly. Step to reproduce the bug (example with grayscale colors): - Add a snippet - Change the background color to a custom color (the colorpicker interface was updated to match the color) - Change the background color to a grayscale color (the colorpicker interface was not updated to match the color) task-3806989