Daily updates from Odoo
Navigate
Branch
Thursday, November 6, 2025
208 changes
13 changes
Enhancements to existing features
Odoo now uses a shared flow for settling customer accounts in point of sale test tours. This makes the tests more consistent and helps prevent cases where customer selection could be lost when dialogs are closed or reopened during the process.
Original PR description
In this commit: --------------- - We have introduced a common function for settlement of customer accounts and replaced it in existing tours. task: 5028009 related PR: [95156](https://github.com/odoo/enterprise/pull/95156) Forward-Port-Of: odoo/odoo#227971
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
16 changes
Enhancements to existing features
The Live Chat report now groups days of the week using the first day configured in each user’s language settings. This makes report views more consistent with local expectations and avoids confusing weekly breakdowns.
Original PR description
**Current behavior before PR**: The "Day of Week" group by in the Live Chat report always treats Sunday as the start of the week, ignoring the "First Day of Week" configured in the user's language settings. **Desired behavior after PR is merged**: "Day of Week" group by now correctly takes into account the user's configured "First Day of Week", as set in their language settings. **task**-[4808640](https://www.odoo.com/odoo/project.task/4808640) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
4 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
32 changes
Enhancements to existing features
Users can now manually choose the period covered by a Mexican global invoice instead of relying on automatic selection. This helps businesses invoice after month-end while still assigning the invoice to the correct reporting period.
Original PR description
Users need a way to select the period for which they're invoicing. Currently, the period is automatically selected, but it happends that users invoice the following month and then have no way of setting the period to the current month. opw-4732490
POS category synchronization with UrbanPiper now includes each category’s parent category, helping menus keep the intended structure on the Atlas platform. This improves consistency between Odoo and UrbanPiper while respecting UrbanPiper’s one-level sub-category limit.
Original PR description
In this commit: --- - The parent category of a POS category is now included during synchronization with the Atlas platform. - Added `parent_ref_id` in the category payload to maintain hierarchy. Note: The UrbanPiper platform only supports a single level of sub-categories. task-5169337 Forward-Port-Of: odoo/enterprise#98839 Forward-Port-Of: odoo/enterprise#97213
This change updates part of Web Studio’s field property editor, specifically the area used to configure type-specific and computed field settings. Because the pull request is still marked as work in progress and has limited detail, the business impact appears minor and focused on improving the Studio editing experience.
Chilean POS pre-tickets now show a suggested 10% tip when early receipt printing is enabled, helping restaurants comply with local tipping rules before payment. The pre-ticket also avoids showing fiscal data that is not required or reliable at that stage.
Original PR description
**PURPOSE** - Comply with Chilean [law](https://blog.nubox.com/contadores/ley-de-propinas-en-chile) requiring restaurants to print a 'suggested tip' on the pre-ticket (before payment). - Ensure the LATAM tip flow behaves correctly in POS. - Prevent fiscal data from being printed in the pre-ticket since it’s not required and cannot be generated accurately at that stage. **SPECIFICATION** - When Early Receipt Printing is enabled: - Exclude fiscal elements from pre-ticket in l10n_cl_edi_pos. - Add a 'Suggested Tip' line showing 10% of the order subtotal (before taxes) task-5060967 Forward-Port-Of: odoo/enterprise#94185
Users can now define custom notification subtypes based on tracked field changes, selected values, and business conditions. This gives teams more control over which notifications are sent and helps route relevant updates to the right people.
Original PR description
Before this commit, the user had no choice on the notification types available. Now, it is possible to create a custom notification subtype. Those subtypes are mainly defined by 3 characteristics…
Before this commit, the user had no choice on the notification types available. Now, it is possible to create a custom notification subtype. Those subtypes are mainly defined by 3 characteristics that should be respected to create the notification: - The tracked field: a field change (with `tracking=True`) has been detected. - The value update: the notification is created only if the value of the tracked field is the one of this field (or not set) - The domain: the end state after the change should match the given domain. The `tracked_field` and `value_update` are applied at the source of the change since they are static. The `domain` is applied when checking the recipients of the notification message and is filtering to ensure that the domain is respected by user. The solution creates new messages (if matching the 3 conditions) after the initial notification or message log of tracked fields, with the initial notification being their parent. The main reason being that we want to keep at most one subtype by message. task-5147099
Financial reporting queries were updated so currency conversion data can be added more consistently across reports. This is mainly an internal improvement that makes report generation logic cleaner and easier to maintain, with no expected change to day-to-day user workflows.
Original PR description
This is a syntaxic change. The first change is to allow the currency table to be joined on a `Query` object. This was not possible because `_currency_table_aml_join` returned raw sql. This is a…
This is a syntaxic change.
The first change is to allow the currency table to be joined on a
`Query` object. This was not possible because
`_currency_table_aml_join` returned raw sql.
This is a syntax improvement, as it then allows to fully exploit
the `Query` class methods, notably `select`, which generates the SQL
directly from the object. Without having to write
`SQL("SELECT %s FROM %s WHERE %s GROUP BY %s", ...)`.
In order to do this change, `_get_monocurrency_currency_table_sql` had
to be modified, as the sql returned by this method could not be
understood by the `Query` object. Not possible to join a table that is
created on the fly. That is because it expects an alias to be an
identifier, and not something of the form
`account_currency_table(company_id, ...)`.
Because of this change, it is possible to do a second syntax
improvement, which is to directly join the currency table on the `Query`
object created in `_get_report_query`. This is done by setting the new
kwarg `join_currency_table` to `True`.
Community PR: https://github.com/odoo/odoo/pull/227398Bank statement lines now clearly warn users when analytic distribution is required by a mandatory plan. This helps accounting teams complete reconciliation correctly and avoid missing required analytic information.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351
The payroll interface now uses the clearer label "Validate" instead of "Create Draft Entry" on related payslip and pay run actions. This makes the next step in payroll processing easier for users to understand, including in the Mexico payroll accounting flow.
Original PR description
Task-ID: 5226530
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
28 changes
New functionality added to Odoo
This change adds a basic accounting localization package for Sri Lanka. It includes the chart of accounts, tax groups, taxes, fiscal positions, and local tax reports needed to support VAT and withholding tax filing.
Original PR description
Implement a basic accounting package for Sri Lanka including: - COA - Tax groups - Taxes - Fiscal Positions - Tax reports (VAT001, WHT001) task-4352802
A new reporting module has been added for Sri Lanka, providing basic balance sheet and profit and loss reports. It also includes VAT and withholding tax return data to support local accounting and reporting needs.
Original PR description
Adds basic reporting module for Sri Lanka, including: - Balance sheet - Profit & loss Also adds the account_return_data for VAT and WHT account_reports task-4352802 CE-https://github.com/odoo/odoo/pull/224917
Enhancements to existing features
The POS pre-ticket now shows a suggested tip for Chilean restaurants when early receipt printing is enabled. It also removes fiscal details from this pre-payment receipt so the printed information matches what is available at that stage and stays compliant with local requirements.
Original PR description
**PURPOSE** - Comply with Chilean [law](https://blog.nubox.com/contadores/ley-de-propinas-en-chile) requiring restaurants to print a 'suggested tip' on the pre-ticket (before payment). - Ensure the LATAM tip flow behaves correctly in POS. - Prevent fiscal data from being printed in the pre-ticket since it’s not required and cannot be generated accurately at that stage. **SPECIFICATION** - When Early Receipt Printing is enabled: - Exclude fiscal elements from pre-ticket in l10n_cl_edi_pos. - Add a 'Suggested Tip' line showing 10% of the order subtotal (before taxes) task-5060967
This pull request mainly updates accounting and localization content, including new tax report codes for Finland and translation refreshes. It also fixes several smaller issues in accounting-related flows, point of sale, online payments, email templates, and website donations to improve reliability and avoid errors in everyday use.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces a shared way to handle customer account settlement in Point of Sale test tours. It also makes the process more reliable when dialogs are closed or switched, helping avoid cases where the wrong customer could be set during the flow.
Original PR description
In this commit: --------------- - We have introduced a common function for settlement of customer accounts and replaced it in existing tours. task: 5028009 related PR: [95156](https://github.com/odoo/enterprise/pull/95156) Forward-Port-Of: odoo/odoo#227971
This update improves the way return-related reporting items are displayed and checked, making the workflow clearer for users. It also updates several country-specific reporting modules so return handling stays consistent across localized reports.
Original PR description
task-5155703
The employee form view was adjusted so the details panel uses the available space more intelligently across screen sizes. On mobile, the panel now stretches to full width, while on larger screens it leaves room for the employee avatar, making the page easier to read and use.
Original PR description
Replace the generic col class with explicit col-12 col-sm-6 col-md-7 col-lg-8 so the right-hand panel spans full width on mobile but leaves room for the avatar on bigger screens task-5238383
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
3 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#979984 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