Daily updates from Odoo
Thursday, March 12, 2026
29 changes · 18.0
New functionality added to Odoo
This update adds support for triangular taxes to the tax reporting system. This is necessary to accurately generate the EC Sales List report, ensuring compliance with Finnish tax regulations. The changes improve the accuracy of tax reporting for Finnish businesses using Odoo.
Original PR description
The aim of this commit is adding the triangular taxes into the tax report to use it in EC Sales List report. task-4010767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This change optimizes the process of generating GST reports by streamlining the database query. Specifically, it removes a complex domain filter that was causing performance issues with large datasets. This results in faster report generation times, improving efficiency.
Original PR description
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this ``` SELECT account_move.id FROM account_move WHERE (…
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this
```
SELECT
account_move.id
FROM
account_move
WHERE
(
account_move.l10n_in_gst_return_period_id = 23
OR (
account_move.move_type IN ('in_invoice', 'in_refund')
AND account_move.invoice_date >= '2025-11-01'
AND account_move.invoice_date <= '2025-11-30'
AND account_move.company_id IN (1)
AND account_move.state = 'posted'
AND (
account_move.l10n_in_gst_treatment NOT IN ('composition', 'unregistered', 'consumer')
OR account_move.l10n_in_gst_treatment IS NULL
)
AND account_move.id IN (
SELECT
account_move_line.move_id
FROM
account_move_line
WHERE
EXISTS (
SELECT 1
FROM account_move_line_account_tax_rel AS account_move_line__tax_ids
WHERE account_move_line__tax_ids.account_move_line_id = account_move_line.id
)
)
)
)
ORDER BY
account_move.date DESC,
account_move.name DESC,
account_move.invoice_date DESC,
account_move.id DESC
```
See this EXPLAIN for big database
```
Gather Merge (cost=165759176482.82..2983665158687.50 rows=36 width=30)
Workers Planned: 2
-> Incremental Sort (cost=165759175482.80..2983665157683.32 rows=18 width=30)
Sort Key: account_move.date DESC, account_move.name DESC, account_move.invoice_date DESC, account_move.id DESC
Presorted Key: account_move.date
-> Parallel Index Scan Backward using account_move__date_index on account_move (cost=59.28..2983665157682.51 rows=18 width=30)
Filter: ((l10n_in_gst_return_period_id = 23) OR (((move_type)::text = ANY ('{in_invoice,in_refund}'::text[])) AND (invoice_date >= '2025-11-01'::date) AND (invoice_date <= '2025-11-30'::date) AND (company_id = 1) AND ((state)::text = 'posted'::text) AND (((l10n_in_gst_treatment)::text <> ALL ('{composition,unregistered,consumer}'::text[])) OR (l10n_in_gst_treatment IS NULL)) AND (SubPlan 1)))
SubPlan 1
-> Materialize (cost=58.84..1601427.18 rows=4994548 width=4)
-> Merge Semi Join (cost=58.84..1556944.44 rows=4994548 width=4)
Merge Cond: (account_move_line.id = account_move_line__tax_ids.account_move_line_id)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.44..1339780.32 rows=26611459 width=8)
-> Index Only Scan using account_move_line_account_tax_rel_pkey on account_move_line_account_tax_rel account_move_line__tax_ids (cost=0.43..88678.65 rows=4994548 width=4)
```
So removing this from domain and put it as condition it's faster
Forward-Port-Of: odoo/enterprise#109795This update removes unnecessary code that subtracted the current production order from a list of related orders. The existing filtering logic already effectively achieved the same result, ensuring cleaner and more efficient code. This change improves code readability and maintainability without impacting functionality.
Original PR description
`- self` is redundant given there's already `.filtered(lambda p: p.origin !=self.origin)`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refines how analytic accounts are assigned within Odoo. Specifically, the order of fields related to analytic distribution has been adjusted for better organization and usability. This change improves the clarity and efficiency of managing analytic accounting data.
Original PR description
Reordering the analytic distribution field. task-5887978 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces support for the US ISO 20022 format for payments, aligning with evolving banking standards. Initially, it focuses on domestic ACH transfers, with plans for future expansion to include international and mixed-type transfers. This change is necessary to accommodate new payment methods being implemented by US banks.
Original PR description
Backport of #90378 US banks are starting to implement the ISO 20022 format for transfers between domestic and international accounts. However, the major banks (Bank of America and JP Morgan Chase) have slightly different implementations of the specification vs SEPA, as such a new payment method must be created. In this first step, the US ISO 20022 payment method supports only domestic ACH transfers; however, future work will support international and mixed-type transfers as the need arises. opw-5727613
This update aligns Odoo's Peppol EAS field selections with the latest Peppol codelist version 9.5. This ensures continued compliance with European e-billing regulations and standards, maintaining accurate data exchange for EDI transactions.
Original PR description
A new version of codelist (v9.5) has been released. This commit aligns the Peppol EAS field selection with the Peppol codelist v9.5 See the changelog here : https://docs.peppol.eu/edelivery/codelists/changelog.html Updates applied according to the official v9.5 changes. task-5461213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This PR allows users to inherit the group_by hook in the POS order report. Previously, this hook was ineffective because it wasn't called during the initial report generation. This change enables more flexible report customization for business users.
Original PR description
Description of the issue/feature this PR addresses: The pos order report has a group_by hook that can be inherited but the hook is not called in the init Current behavior before PR: inherit the group_by is useless because the init does not call it Desired behavior after PR is merged: the group_by hook can be inherited --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where fleet officers with specific user groups couldn't access vehicles without assigned employees. The fix modifies access rules to grant fleet officers the necessary permissions, ensuring they can view all vehicles within the system. This improves operational efficiency for fleet management.
Original PR description
This includes a back port of this commit: efc59084fbd3fe314a686699e42bfdcc4553ad85 ### Issue: The user group "Fleet / Officer: Manage all vehicles" don't see vehicles with no employee when he also…
This includes a back port of this commit: efc59084fbd3fe314a686699e42bfdcc4553ad85 ### Issue: The user group "Fleet / Officer: Manage all vehicles" don't see vehicles with no employee when he also have the ### Steps to reproduce: - Create a user having the group "Fleet / Officer: Manage all vehicles" and "Employees / Officer: Manage all employees" - Create a new vehicle - Switch to this user and go to the Fleet app - The vehicle doesn't appear ### Cause: 1. The user group "Fleet / Officer: Manage all vehicles" have no rule allowing them to read the vehicle model. Currently users access only vehicles with an employee defined because of the rule "Hr Officer read rights on vehicle with employees assigned" if they have the group "Officer: Manage all employees". 2. This rule was kept by the commit we are backporting. When it gets applied (when the user has the group "Officer: Manage all employees"), the user cannot see vehicles without employees. This is because the commit we are backporting didn't add any rule to give the access to "Fleet / Officer: Manage all vehicles" so the default access is overridden by this rule. ### Solution: 1. We backport the commit efc59084fbd3fe314a686699e42bfdcc4553ad85 2. We modify the rules giving rights to Administrators to give the same rights to Officers. As Administrator implies Officer we don't change anything for them. opw-5344528
This update resolves a technical issue that caused tracebacks when using the pivot table autofill feature. The fix corrects a misidentification of the function being called, ensuring consistent behavior with vertical autofills. While the core result isn't corrected, this resolves a reporting error.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266) Forward-Port-Of: odoo/enterprise#109620
This update corrects a warning message appearing during tax report adjustments in the French localization. The issue stemmed from an unnecessary reference to 'box_B1' within the report's calculations. Removing this element ensures the report functions correctly without displaying the misleading warning, improving the user experience for French accounting users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001
This update resolves an issue where clicking on 'reply' links within Odoo mailboxes didn't function correctly. Now, clicking on a reply link will automatically jump to the original thread of the message, improving the user experience and ensuring messages are easily accessible within conversations. This fix enhances the efficiency of email management within Odoo.
Original PR description
Before this change, clicking on a `message in reply` in mailboxes had no effect. The expected behavior is for it to jump to the message in its origin thread. To fix it, this commit ensures that `useMessageHighlight` hook receives the correct thread which in this case is the origin thread of the message in reply. task-5343804
This update resolves a technical issue that caused the bulk payments feature to crash when attempting to check the status of a batch without a linked bank account. A new user message will now alert users if the required bank journal is not connected, preventing the error and improving the user experience.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083
This update resolves an issue where tax calculations were incorrect during the reconciliation process, particularly when dealing with reverse charges. The fix ensures accurate tax amounts are applied to journal entries, improving financial reporting accuracy. This impacts users utilizing the reconciliation features within the Enterprise accounting module.
Original PR description
## ISSUE 1: **Steps to reproduce [l10n_be easier]:** - Create a journal entry: ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in…
## ISSUE 1: **Steps to reproduce [l10n_be easier]:** - Create a journal entry: ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in the wizard > account 600 tax 12% (purchase) - Validate - Check the last entry created **Issue:** There is no invert tag set on the tax line **Cause:** The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815 The line was never set to properly (same of is_refund) ## ISSUE2: **Steps to reproduce:** - create a journal entry ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in the wizard > account 600 tax 21% EU M (Purchases) - Validate - Check the last entry created **Issue:** No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0. opw-4976780 ## ISSUE3: **Steps to reproduce:** - Create a Statement line of 1000$ - In the Writeoff add 2.5% RC tax - Check created tax lines **Issue:** Adding a 2.5% RC tax gives 24.39 instead of 25.00 opw-5039386 Forward-Port-Of: odoo/enterprise#92556
This update fixes an issue where overtime calculations were inaccurate after a leave request was validated. Now, overtimes are automatically recalculated whenever a leave request is created, updated, or removed, ensuring accurate overtime reporting. This prevents overtimes from being miscalculated due to leave validation changes.
Original PR description
When we re-evaluate leaves we update overtimes after switching to draft but we do not update the overtimes again after the leave is switched back to validated. This causes the overtimes from attendances that overlap with the leave to be miscalculated as if the leave was not validated. To rectify this issue, we recalculate the overtimes for the affected employees after every create/write/unlink of `resource.calendar.leaves`. opw-4844447 Forward-Port-Of: odoo/odoo#229723
This update fixes an issue where returning products previously transferred to sub-locations wouldn't reserve them correctly. The fix adjusts the system's search strategy to properly account for sub-locations, ensuring returns can now be processed from any location within the stock hierarchy. This improves the efficiency of the returns process.
Original PR description
Issue ----- Returning products doesn't work if they were transferred to a sub location. Steps to reproduce ----- - Enable storage locations - Create a new sub location to WH/Stock (eg WH/Stock/Shelf) - Receive a product in WH/Stock & confirm - Transfer the product to WH/Stock/Shelf - Go to the reception transfer and return it > The return cannot reserve the product from WH/Stock/Shelf Cause ----- The problem was introduced by 13567aa. https://github.com/odoo/odoo/blob/f86baa6ba1c915145dbfe43b67de0eff13959e91/addons/stock/models/stock_move.py#L1966 The strategy used to find available quants is set as strict, so the domain contains an exact match for the location instead of `child_of` which would include sub locations. https://github.com/odoo/odoo/blob/f86baa6ba1c915145dbfe43b67de0eff13959e91/addons/stock/models/stock_quant.py#L770-L787 ----- Ticket: opw-5364331
This update addresses a critical security vulnerability by preventing users from canceling documents after they've been fully signed. This ensures the integrity of legal records and provides reliable proof of agreements. The system now automatically disables the cancellation button and blocks backend changes to finished documents, enhancing security and data protection.
Original PR description
Before this commit, users could cancel documents after everyone had signed. This weakened legal records and proof of agreement. After this commit, the cancel button disappears once signing is complete. We also blocked backend cancellations to keep finished documents permanent and secure. task-5980337
This update resolves a technical issue that prevented users from running the 'Polish eInvoice' download process when the KSeF system returned a 'Rate Limit' error. The fix ensures the system correctly handles these errors, preventing a traceback and allowing the download process to continue smoothly. This improves the reliability of the Polish e-invoicing functionality.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Run scheduled action "Polish eInvoice: Download vendor bills from KSeF" 3. If the customer gets 429 Too Many Requests => A traceback error is raised as message isn't an attribute in KSeFRateLimitError object `AttributeError: 'KSeFRateLimitError' object has no attribute 'message'` This happens because `KSeFRateLimitError` does not define a `message` attribute. The message is only passed to the base Exception and stored in `args`. After this commit: Use `str(e)` to properly retrieve the exception message and avoid the AttributeError. opw-6009380
This update resolves a restriction in the l10n_pl_edi module, allowing standard users to perform KSeF-related tasks. Previously, access to key settings and certificates was limited to administrators. This change expands user capabilities while maintaining security.
Original PR description
Fields on `res_company` related to KSeF are marked only for group `base.group_system`, as are the `certificate.certificate` and `certificate.key` models. Adding `compute_sudo` and `sudo()` calls where it's needed in actions that can be performed by non-admin users. task-6018713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a usability issue on mobile devices where a key button was hidden within a dropdown, requiring extra scrolling. The change ensures the loan creation process is smoother and more accessible on smaller screens, allowing users to easily calculate loan amounts. This improves the overall user experience for mobile users.
This update fixes an issue where equity reports were incorrectly using historical currency rates for certain accounts. The change reordered a key statement within the report generation process to ensure the most accurate and up-to-date currency conversion is applied, improving the reliability of financial reporting.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task
This update corrects a bug where resending invoices to MER would overwrite existing addendums, even if the invoice hadn't been sent. The fix ensures that existing addendums are updated instead of creating new ones, streamlining the invoice processing workflow and preventing data inconsistencies.
Original PR description
Issue: when resending an invoice already sent to MER, the existing addendum is overwritten even when the invoice is not sent to MER. Solution: updating values on the existing addendum rather than creating a new one, if it already exists. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing users from creating new journals when a previously archived default account was linked to a journal. Previously, the system blocked new journal creation due to a validation error. Now, users can create new journals seamlessly, even with archived accounts, improving usability and preventing workflow disruptions.
Original PR description
Backport of https://github.com/odoo/odoo/pull/249869 Description This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a…
Backport of https://github.com/odoo/odoo/pull/249869 Description This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived. Current Behavior Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error: "Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]" This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived. Desired Behavior After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts. video https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view 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 fixes an issue where closing a popup modal using the ESC key was not functioning correctly. The fix ensures that the modal closes reliably, regardless of whether the popup contains interactive elements. This improves the user experience and prevents unexpected modal persistence.
Original PR description
Steps to reproduce: =================== - Add a Popup snippet to a page - Remove all links/buttons inside the popup - Save and wait for the popup to appear - Press ESC -> Nothing happens. Cause:…
Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC
-> Nothing happens.
Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.
When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.
Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases
opw-5891054
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects a memory issue that was causing slowdowns when calculating depreciation for large customer records. The fix uses a more efficient method to process depreciation data, significantly improving performance and stability. This resolves a previously reported problem.
Original PR description
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the…
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.
Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version.
```
Traceback (most recent call last):
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
result = records.read(fields, **read_kwargs)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
return needle(*args)
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```
opw-5921410
upg-3891767
Forward-Port-Of: odoo/enterprise#109008This update fixes an issue where overpayments made via bank payment in Point of Sale didn't create the necessary accounting records. Now, when a customer pays more than the order amount with a bank payment, a corresponding accounting line is created, ensuring accurate financial reporting and preventing the system from incorrectly stating an outstanding balance.
Original PR description
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the order amount with bank pm * Validate * Close register * Check customer > Observation: It says we owe the customer money, although change was given. Why the fix: ------------ Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it. Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted. opw-5149700 Forward-Port-Of: odoo/odoo#247621
This update resolves an issue where quotation documents with lines having a zero subtotal amount were being discarded during upload. The fix ensures that these lines are now correctly processed, preventing data loss and maintaining accurate quotation records. This change was introduced to address a regression caused by a previous update targeting a different Odoo version.
Original PR description
Versions: --- Reproducible on 18.0+ Fix targets 16.0 to keep the code consistent across versions Issue: --- Due to this issue, a line with zero subtotal amount will be discarded in quotation document upload. Steps to reproduce: --- 1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket) 2- As you see, lines are discarded. Cause: --- This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0. Fix: --- Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself. opw-5977735 Forward-Port-Of: odoo/odoo#251463
This update clarifies potential errors (specifically code 9004) that users might encounter when using the Instagram integration within Odoo. It provides helpful guidance to troubleshoot issues directly, reducing the need for support tickets. This improves the user experience and streamlines problem resolution.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#109319
This update resolves an issue where adding attributes to archived product templates caused errors. The change ensures all variants (active and archived) are counted, preventing template deletion and maintaining archived variants when their template is archived. This improves the flexibility of managing product templates.
Original PR description
When adding attributes to an archived product template, an error was raised because the template was incorrectly deleted. This happened because variant counting only considered active variants. Now counts all variants (active and archived) to prevent template deletion, and filters variants before activation to keep them archived when their template is archived. @qrtl QT6449
This update resolves an issue where multiple files uploaded to WhatsApp Discuss channels were only partially delivered to recipients. The fix ensures that all files are sent by validating the total number of attachments before sending, aligning with WhatsApp's API limitations. This improves the reliability of file sharing within WhatsApp Discuss.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035