Tuesday, November 25, 2025
20 changes · 18.0
Enhancements to existing features
This update enhances how Odoo calculates taxes, specifically addressing scenarios where taxes are based on volume (e.g., per unit). This change, requested during Odoo Exp 2025, ensures more accurate tax calculations for products sold by volume, improving financial reporting. It impacts the account and point of sale modules.
Original PR description
The use case to cover is when you have a volume based tax. Requested during Odoo Exp 2025. --- 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 resolves a memory issue that occurred when processing sales documents for the Romanian EDI (RS) system. By proactively retrieving country codes, the system now avoids running out of memory, leading to smoother and faster processing of these documents. This improves the overall efficiency of the RS EDI functionality.
Original PR description
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in…
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory records ``` sagu_3267671=> select count(id) from account_move; count --------- 1034179 (1 row) ``` ``` File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine return needle(*args) File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed') File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__ self.compute_value(recs) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value records._compute_field_value(self) File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine return needle(records, *args) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp> values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__ return self._fields[key].__get__(self, self.env.registry[self._name]) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__ return super().__get__(records, owner) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__ recs._fetch_field(self) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field self.fetch(fnames) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch fetched = self._fetch_query(query, fields_to_fetch) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query self.env.cache.insert_missing(fetched, field, values) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing field_cache.setdefault(id_, val) MemoryError ``` upg-3267671 opw-5246681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235919
This update resolves an error that prevented the Accounts Coverage Report in the Spanish localization (l10n_es_reports) from generating correctly. The issue stemmed from incorrect data formatting within the report's database queries. By correcting the data file and adjusting its loading order, the report now functions as intended, ensuring accurate account coverage reporting for Spanish businesses.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#98745This update automatically flags stock moves resulting from returns as 'refunds,' streamlining the accounting process. Previously, only returns initiated through the return wizard were correctly marked for refund. This change ensures accurate tracking and reconciliation of returned goods, simplifying inventory management and financial reporting.
Original PR description
This commit makes the `to_refund` field `True` by default for stock move in case of return. The value is True for product coming from the return wizard but not for extra product added later in the picking. In `stock_barcode` there is even not return wizard. Task: 4680813 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 corrects an issue where credit notes' XML files weren't properly validated by the FACe system, a Spanish tax authority. The fix ensures compliance by standardizing the 'ReasonDescription' field, aligning with Spanish requirements. Additionally, the reversal wizard has been streamlined for clarity.
Original PR description
In cases of credit notes, the xml would not be validated by the FACe. This was caused by the field 'ReasonDescription', which can only be one of the proposed field. We used to provide it in English when the available reasons are only in Spanish. Also fixed CorrectionMethodDescription. See https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx for more documentation. ticket-5184181 Took the opportunity to improve the reversal wizard : In the reversal wizard, two fields 'Reason' would be displayed. Only kept the mandatory one and used it in place of the non-mandatory one. Forward-Port-Of: odoo/odoo#236684
This update optimizes how sales orders are accessed, specifically when filtering by sales team. By adding an index to the `sale.order.team_id` field, the system now searches more efficiently, reducing delays and improving the speed of reports and data views related to sales teams. This enhances the overall performance of our sales tracking processes.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237116
This update resolves issues with concurrent database writes impacting Viva Wallet notifications, preventing duplicate or delayed messages to the POS. The change streamlines data transmission via websocket and adds safeguards to handle failed payment requests and unexpected webhook events, ensuring smoother operation across multiple Viva terminals.
Original PR description
When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the…
When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the `viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late. This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message. In addition, there are two other minor fixes: - In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error). - The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva. opw-5226966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where increasing stock quantities didn't accurately reflect the reservation process, leading to incorrect move line creation. Now, the system first checks available quantities before creating the move line, ensuring quantity increases align with the standard stock reservation logic. This improves the reliability of stock adjustments.
Original PR description
Increasing the quantity of a stock move will create a move line with the same data as the stock move (location and product), no lot, nor package. This commit make the increase of quantity mimic the reservation process by getting first the available quants. The move line are then created accordingly. Backport of odoo/odoo#230344 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 optimizes how Odoo matches bank transactions with sale orders, resulting in a significant speed improvement. By removing an inefficient query and leveraging an index, the process is now much faster, leading to quicker reporting and improved system performance. This change addresses a performance bottleneck.
Original PR description
Before this commit, finding a match between the bank transactions and sale orders was done via an unoptimized query that is preventing postgres from using any index. This commit removes the unnecessary CTE by simply doing the query directly on the sale_order table. This way we can also use a trigram index on the regex used for matching and postgres will be able to utilize it for faster search. Benchmarks: | Num sale_order | Before | After | | -------------- | ------ | ------ | | 1391909 | 3.88 s | 0.27 s | opw-5139457
This update fixes a potential issue where changes to related records weren't consistently reflected across multiple linked data fields. The update ensures that all relevant data is synchronized during updates, preventing data inconsistencies and improving data accuracy. This primarily impacts how data is updated within certain Odoo modules.
Original PR description
Some models have several One2many (some with a domain and another without by example) targeting the same Many2one. In this case, when we create a new record, add new line in one of this One2many and modifying any else that triggers onchange. The onchange will contains the line in one of the sibling one2many but not the other, and then during the `modified`, the ORM may used the one2many that doesn't contains any lines, and that's miss some compute to recompute.... To avoid this situation, we patch the sibling one2many when one of them contains the line during the all onchange process.
This update resolves an issue where the 'Select All' button in the document control panel only selected the first 40 files. Now, all files selected through any method (including 'Select All') are correctly included when performing actions like duplication or moving to the trash. This ensures consistent and reliable functionality for managing large document sets.
Original PR description
Steps to Reproduce =================== 1. Upload more than 40+ files in a folder. (One page displays upto 40 docs) 2. Use the checkbox to select all files on the page (this selects only 40 files) 3.…
Steps to Reproduce =================== 1. Upload more than 40+ files in a folder. (One page displays upto 40 docs) 2. Use the checkbox to select all files on the page (this selects only 40 files) 3. Click the 'Select All' button in the control panel to select all 40+ files. 4. Now, try duplicating or moving them to the trash. => Only the first 40 selected files (on the single page) are considered for action, not all the selected files. Technical ========== For documents control panel action we have custom handling for selecting records and executing action. We use `model.root.selection` which only consider records in current page, case of select all records from other pages is missed here. After this PR ================== - All selected records are considered for the actions - Added custom `getResIds` method to get filtered `resIds` as per domain. Note: `getResIds` in DynamicList doesn't have custom domain feature so create our own as per use case Task-4700841
This update resolves an issue where helpdesk ticket assignments were failing due to incorrect resource selection. The fix ensures that only resources within the same company as the helpdesk team are considered, preventing access errors and improving ticket assignment functionality. This improves the reliability of the helpdesk module.
Original PR description
To reproduce: ============= - with `hr_contract` and `helpdesk` installed - create a user with 2 resources in 2 different companies - add the user as member of a helpdesk team of company A - enable…
To reproduce: ============= - with `hr_contract` and `helpdesk` installed - create a user with 2 resources in 2 different companies - add the user as member of a helpdesk team of company A - enable auto assignment on the team - try to create a ticket on that team -> error Problem: ======== When computing working intervals for resources of the team members, we were considering all resources of the user, even those not in the same company as the helpdesk team. Which lead to access errors when trying to read data from the other company. This issue was not caught before as we were never reading data from the resources, until this [commit](https://github.com/odoo/odoo/commit/79a559c9741410ad861c107e395b2fc486da95e8) where we try reading `employee_id` of the resource. Solution: ========= Filter resources to keep only those in the same company as the helpdesk team. P.S: ==== the removed test was trying to test assigning ticket to user that is not in the same company as the helpdesk team, which is not correct so the test was removed. opw-[2749232](https://www.odoo.com/web#id=2749232&view_type=form&model=project.task)
This update resolves an issue where the Gantt view incorrectly grayed out days when flexible working hours were enabled. The fix ensures that all days are treated as working days, accurately reflecting employee availability and improving the view's reliability. This change impacts project scheduling accuracy.
Original PR description
To reproduce: ============= 1. Activate flexible working hours on the company calendar 2. Go to Project app -> all tasks 3. Switch to Gantt view notice that on the unassigned tasks row, two days are grayed out randomly Problem: ======== When flexible working hours is activated, the unavailability intervals are computed with an estimation: we take the total of working hours per week and we divide it by number of hours per day to get `N` days, so we estimate that from `now` to `now + N` days are working days, and the rest are non-working days. This is wrong because the working hours may not be evenly distributed over the week, and between today and tomorrow we get different unavailability intervals. Solution: ========= When flexible working hours is activated, we consider that all days are working days, so there is no unavailability interval to consider. opw-5257081
This update corrects a bug where tasks created from service products didn't automatically reflect the quantity of the corresponding sales order line. Now, when a service product with 'manual' service type is used to create a task from a sales order, the task's allocated hours will accurately match the order line quantity. This ensures accurate time tracking for service projects.
Original PR description
To reproduce: ============= - Create service product with `service_tracking = task_in_project` and `service_type = manual` - Create a SO with this product and set quantity on the line - Confirm the SO - check the created task, allocated hours is 0.0 instead of the quantity of the SO line Problem: ======== When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'. Solution: ========= Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity. opw-5153467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue in Odoo 18.0 to 18.4 where changing a product's cost in a multi-company environment caused tax access errors. The problem stemmed from fetching taxes using a privileged (sudo) environment, leading to incorrect data and manual save failures. This fix, removing the privileged environment, ensures accurate tax calculations and prevents these errors.
Original PR description
from v18.0 to v18.4, in a multi-company environment, when a product with no income/expense account had its cost changed, all the taxes for other companies were being fetched which caused access errors when trying to view it after a manual save. This happens because the fetch is happening in a sudo environment because the stock valuation layer was being created as sudo, so all taxes were being fetched and probably because of cache pollution they were not being filtered properly, this is not happening in v19.0 because the stock valuation layer was removed, so everything is being called in a normal user environment, refer to this commit-08b62a4 task-5117882
This update fixes an issue where vendor bill payment statuses remained incorrect after deleting or resetting payments. The change ensures that the bill's status accurately reflects the payment's state, resolving a discrepancy observed compared to customer invoices. This improves data consistency and reporting accuracy.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment…
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment using the smart button. 5. Delete the payment or click on Reset to Draft. Observation: ------------------------- 1. On deleting the payment: The Vendor Bill still shows the "In Payment" status even after the payment is deleted. 2. On resetting the payment to draft: The Vendor Bill also remains in the "In Payment" status instead of reverting to "Not Paid". This behavior is not observed for customer invoices, where the payment state updates correctly in both cases. Issue: ------------------------- 1. Delete case: In the `unlink` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945 the `linked_invoices` variable only includes invoices that are reconciled (i.e., their journal items are matched). Since the Vendor Bill is not yet reconciled, it is excluded from recomputation. Hence, its `payment_state` remains unchanged. 2. Reset to draft case: In the `_compute_payment_state` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163 the compute depends on the state of reconciled payments. However, since these payments are not reconciled, the compute method is not triggered, and the payment state remains outdated. Solution: ------------------------- Added `matched_payment_ids.state` in the depends of the `_compute_reconciled_payment_ids` method to ensure it recomputes correctly when payment state changes on setting payment to draft or deleting payment Ticket [link](https://www.odoo.com/odoo/project.task/5208772) opw-5208772
This update resolves an issue where adding content to the website header caused unexpected scrolling behavior. The fix removed a problematic variable that wasn't consistently updating, leading to a jumpy scroll. This ensures a smoother and more reliable user experience when adding or modifying content on the website.
Original PR description
Before this commit, the header height was stored in a global variable. This variable wasn't always updated, which led to issues regarding the scroll. When adding elements in the header that increased its height, the scroll would jump and showing / hiding the header. This commit removes the need of the headerHeight variable. Steps to reproduce the bug: - Add a "Text Highlight" inner content above the ContactUs button - Add multiple Title snippets below one another (When adding the third one, the page scroll indefinitely) (The number of snippets to drop may vary depending on the viewport) task-4267249 Forward-Port-Of: odoo/odoo#185812
This update fixes an error in the Peru tax report (RVIE Sales 14.4) export that incorrectly included credit note amounts in the report. The fix ensures the report accurately reflects SUNAT regulations for credit note reporting, improving compliance and data accuracy for Peruvian businesses.
Original PR description
How to reproduce the issue: -With l10n_pe localization - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466
This update resolves an issue where invoices using specific document types within the l10n_ar localization pack couldn't be printed correctly. The fix ensures that the invoice template supports multiple Spanish languages, allowing printing regardless of whether es_AR is installed. This improves usability for customers using the Arabic localization.
Original PR description
#The issue: - With l10n_ar company - Make sure that the language es_AR is not installed. - Create an invoice where the Document type (l10n_latam_document_type_id) code is in 201, 202, 203, 206, 207, 208, 211, 212 or 213 - Try to print the invoice, the following error occurs: odoo.addons.base.models.ir_qweb.QWebException: Error while render the template UserError: Invalid language code: es_AR In the report_invoice template used in l10n_ar, if the document type is 201, 202, 203, 206, 207, 208, 211, 212, or 213, the amount in letters is mandatory. Currently, the template is hard-coded to use es_AR. As a result, if the customer does not have the es_AR language installed, the invoice cannot be printed, even if another Spanish language is available. opw-5079885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where changes to the 'analytic.project_plan' system parameter didn't properly update related fields in the analytic accounting system. Now, when this parameter is modified, the system dynamically adjusts the associated fields on analytic lines, ensuring data consistency. This prevents errors and ensures accurate reporting.
Original PR description
A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan`…
A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan` parameter does not get a dynamic field, it uses `account_id`. If you change the system parameter for analytic.project_plan, the plan with the corresponding value will now use `account_id,` and the plan that corresponds to the previous default value will have no corresponding field on `account.analytic.line`.
So, when the project plan system parameter changes, the dynamic fields that are created for each analytic plan (apart from the project one) do not get updated.
Steps:
1. Set the `analytic.project_plan` system parameter to a value other than `1`
2. Enable `Analytic Accounting` setting under `Accounting > Analytic`
3. Create a sales order with a service product that creates a project.
4. Confirm sales order
5. Traceback: `ValueError: Invalid field account.analytic.line.x_plan1_id in leaf 'x_plan1_id', 'in', [23])`
We now extend the write method on `ir.config_parameter` so that when the value of the analytic.project_plan is changed the dynamic fields on `account.analytic.line` are properly added and removed. This solution always creates a field for the previous value and deletes a field for the new value so that no plan ever has two fields referencing it.
Ticket [link](https://www.odoo.com/odoo/project.task/5069381)
opw-5069381
Forward-Port-Of: odoo/odoo#231981