Daily updates from Odoo
Friday, May 23, 2025
70 changes
10 changes
Miscellaneous changes
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the
Original PR description
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the context preparation the preparation_display doesn't process the order. Fix: Make the call to syncAllOrders from preparation_display await. Move the call for sendOrderInPreparationUpdateLastChange after addPendingOrder since addPendingOrder adds the order again to the pending orders that causes the syncAllOrders from the floor_plan to make the sync_from_ui call again. Task-4812830 Forward-Port-Of: odoo/enterprise#86119
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB. In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting ind
Original PR description
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the…
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB.
In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting indexes. The timing goes from minutes to seconds. The frontend is usable again.
Example of the data stored in the temp table:
```
=> select count(*) from analytic_temp_account_move_line
+----------+
| count |
|----------|
| 60669759 |
+----------+
```
The example DB has 31 "plan columns". In other words we are duplicating 31 times 1957089 rows. That's too much data. It's also a waste of space and time. Especially if we later issue more filtering commands as the report is refined in the frontend. This leads to current approach being unusable for some clients. In the example DB the timing is bigger than the standard timeout for frontend requests.
Planning and execution of for the insert in the temporary table:
```
Insert on analytic_temp_account_move_line (cost=0.86..6659742.75 rows=0 width=0) (actual time=209651.484..209651.487 rows=0 loops=1)
-> Subquery Scan on "*SELECT*" (cost=0.86..6659742.75 rows=157594266 width=548) (actual time=644.693..92507.579 rows=60669759 loops=1)
-> Result (cost=0.86..5083800.09 rows=157594266 width=548) (actual time=644.689..85762.552 rows=60669759 loops=1)
-> ProjectSet (cost=0.86..1143943.44 rows=157594266 width=366) (actual time=644.657..72959.699 rows=60669759 loops=1)
-> Merge Left Join (cost=0.86..317844.46 rows=5083686 width=486) (actual time=644.562..22711.962 rows=1957089 loops=1)
Merge Cond: (account_analytic_line.move_line_id = account_move_line.id)
-> Index Scan using account_analytic_line__move_line_id_index on account_analytic_line (cost=0.43..97499.67 rows=1957619 width=150) (actual time=641.529..7738.521 rows=1957089 loops=1)
Filter: (general_account_id IS NOT NULL)
Rows Removed by Filter: 136994
-> Materialize (cost=0.43..144877.29 rows=2272735 width=344) (actual time=3.014..13564.293 rows=3022715 loops=1)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.43..139195.45 rows=2272735 width=344) (actual time=3.005..11312.577 rows=2274827 loops=1)
Planning Time: 132.775 ms
JIT:
Functions: 78
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 4.236 ms (Deform 2.533 ms), Inlining 64.617 ms, Optimization 351.121 ms, Emission 222.715 ms, Total 642.690 ms
Execution Time: 209672.536 ms
```
Planning and execution of a query based on the new view (note the usage of indexes from the actual tables):
```
Hash Join (cost=72813.40..294958.00 rows=7724 width=4) (actual time=1760.970..3493.933 rows=61 loops=1)
Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
-> Subquery Scan on account_move_line (cost=72794.39..294349.71 rows=223360 width=8) (actual time=1725.998..3477.187 rows=246 loops=1)
Filter: (account_move_line.analytic_distribution = ANY ('{1703,898,896,890,648,670,673,685,818,899,828,837,846,849,848,891,901,904,905,906,907,942,952,1039,980,985,1049,1050,1051,1093,1107,1114,1233,1126,1129,1133,1151,1152,1153,1222,1272,1218,1230,1243,1282,1249,1369,1271,1286,1328,1371,1396,1432,1403,1404,1406,1409,1430,1431,1437,1449,1473,1498,1515,1516,1517,1524,1525,1527,1528,1543,1549,1588,1592,1604,1605,1784,1641,1650,1652,1676,1677,1678,1679,1680,1702,1751,1759,1760,1767,1964,1796,1826,1832,1838,1926,1866,1883,1916,1922,1923,1954,1963,2144,1977,1974,2005,2011,2013,2015,2016,2032,2035,2037,2038,2064,2142,2097,2106,2110,2111,2112,2115,2121,2122,2130,2131,2141,2157,2311,2251,2252,2263,2269,2270,2271,2272,2274,2275,2279,2280,2287,2300,2307,2312,2316,2330,2339,2720,2370,2372,2423,2439,2462,2494,2477,2478,2480,2483,2491,2492,2493,2537,2533,2534,2535,2536,2546,2550,2551,2573,2574,2575,2576,2587,2598,2658,2691,2710,2721,2763}'::jsonb[]))
Rows Removed by Filter: 2617642
-> Gather (cost=72793.94..290647.16 rows=246807 width=910) (actual time=1720.216..3369.512 rows=2617888 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Result (cost=71793.94..264966.46 rows=4500611 width=910) (actual time=1706.592..2884.302 rows=1308944 loops=2)
-> ProjectSet (cost=71793.94..197457.29 rows=4500611 width=12) (actual time=1706.573..2654.189 rows=1308944 loops=2)
-> Parallel Hash Join (cost=71793.94..173865.38 rows=145181 width=132) (actual time=1706.560..2554.799 rows=42224 loops=2)
Hash Cond: (account_move_line_1.id = account_analytic_line.move_line_id)
-> Parallel Index Scan using account_move_line__journal_id_index on account_move_line account_move_line_1 (cost=0.43..100906.82 rows=149368 width=4) (actual time=2.633..788.321 rows=126675 loops=2)
Index Cond: (journal_id = ANY ('{23,21,17}'::integer[]))
-> Parallel Hash (cost=67363.05..67363.05 rows=354437 width=136) (actual time=1699.502..1699.503 rows=421304 loops=2)
Buckets: 1048576 Batches: 1 Memory Usage: 54880kB
-> Parallel Index Scan using account_analytic_line__date_index on account_analytic_line (cost=0.43..67363.05 rows=354437 width=136) (actual time=9.963..1507.693 rows=421304 loops=2)
Index Cond: ((date <= '2024-12-31'::date) AND (date >= '2024-01-01'::date))
Filter: ((general_account_id IS NOT NULL) AND (company_id = 3))
Rows Removed by Filter: 57954
-> Hash (cost=18.65..18.65 rows=29 width=4) (actual time=16.619..16.620 rows=29 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 10kB
-> Index Scan using account_account__account_type_index on account_account account_move_line__account_id (cost=0.15..18.65 rows=29 width=4) (actual time=16.513..16.592 rows=29 loops=1)
Index Cond: ((account_type)::text = 'income'::text)
Planning Time: 75.050 ms
JIT:
Functions: 51
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 4.433 ms (Deform 2.707 ms), Inlining 0.000 ms, Optimization 2.501 ms, Emission 30.127 ms, Total 37.061 ms
Execution Time: 3496.425 ms
```
OPW-4782916
Forward-Port-Of: odoo/enterprise#85942Because the customer statement buttons took too much space, the breadcrumb becomes invisible. This commit fixes always show the breadcrumb, and the buttons move instead. task-4583817 Forward-Port-Of: odoo/enterprise#81253
Original PR description
Because the customer statement buttons took too much space, the breadcrumb becomes invisible. This commit fixes always show the breadcrumb, and the buttons move instead. task-4583817 Forward-Port-Of: odoo/enterprise#81253
This commit adds translations for Luxembourg Annual VAT Declaration in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 Forward-Port-Of: odoo/enterprise#86139 Forward-Port-Of: odoo/enterprise#85898
Original PR description
This commit adds translations for Luxembourg Annual VAT Declaration in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 Forward-Port-Of: odoo/enterprise#86139 Forward-Port-Of: odoo/enterprise#85898
…atch Batch generation currently takes contract templates, which it should not Forward-Port-Of: odoo/enterprise#86120
Original PR description
…atch Batch generation currently takes contract templates, which it should not Forward-Port-Of: odoo/enterprise#86120
Before this commit, the code checks if `this.connectorDragState.draging` if truly before using the split tool because we don't want to execute that if the user is currently dragging a planning slot. The problem is `draging` attribute does not exist in `connectorDragState`, it should be `dragging` instead. This commit fixes the typo to correctly check if the slot is dragging before doing the split tool or not. Forward-Port-Of: odoo/enterprise#85946
Original PR description
Before this commit, the code checks if `this.connectorDragState.draging` if truly before using the split tool because we don't want to execute that if the user is currently dragging a planning slot. The problem is `draging` attribute does not exist in `connectorDragState`, it should be `dragging` instead. This commit fixes the typo to correctly check if the slot is dragging before doing the split tool or not. Forward-Port-Of: odoo/enterprise#85946
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the new quote -> it's filled with default values instead of the one from the other quote you dpulicated one could expect after duplication (and so if you save without changing anything in the spreadsheet, you 'reset' the quote even though it's probably not what you wanted to do), Expected behaviour
Original PR description
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the…
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the new quote -> it's filled with default values instead of the one from the other quote you dpulicated one could expect after duplication (and so if you save without changing anything in the spreadsheet, you 'reset' the quote even though it's probably not what you wanted to do), Expected behaviour: the quote calculator spreadsheet is duplicated for the new quote with the same values. Implementation note: Why not just `copy=True` on field `spreadsheet_ids`? Because the spreadsheet should be copied, but not only! The `spreadsheet.revision` linked to the spreadsheet also need to be copied. If they are not copied, revisions which are not part of the last snapshot will be lost on the new spreadsheet record and it won't lead to the same spreadsheet data. Task: 4801418 Forward-Port-Of: odoo/enterprise#86017 Forward-Port-Of: odoo/enterprise#85746
When the status is married and no spouse name is provided, it raises a traceback. So we check that there is a spouse name before trying to upercase it, because the field is not required. Forward-Port-Of: odoo/enterprise#85980
Original PR description
When the status is married and no spouse name is provided, it raises a traceback. So we check that there is a spouse name before trying to upercase it, because the field is not required. Forward-Port-Of: odoo/enterprise#85980
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference ------
Original PR description
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference --------- opw-4743742 Forward-Port-Of: odoo/enterprise#86099 Forward-Port-Of: odoo/enterprise#85974
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checke
Original PR description
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checked in the _generate_lot() which is called on adding product tracked by lot. opw-4648542 opw-4646960 Forward-Port-Of: odoo/enterprise#85867 Forward-Port-Of: odoo/enterprise#82341
40 changes
Enhancements to existing features
The AI Fields feature now shows a clearer error message when the language model does not provide an answer. This helps users better understand what happened and reduces confusion when an AI-generated response is empty.
Original PR description
Task-4794401
The IoT app demo data now includes examples for a Fiscal Data Module and an Unsupported Device, along with a matching icon. This helps users and sales teams better demonstrate how the app represents different device types, including unsupported hardware.
Original PR description
This PR adds a "Fiscal Data Module" and an "Unsupported Device" to the demo data in the IoT app + it adds a new svg icon file for the unsupported device  Related task: 4770381
Server actions now use simpler automatic names, making them easier for users to recognize and manage. The related kanban view was also adjusted so these actions remain clear and consistent in day-to-day workflows.
Original PR description
Task id: opw-4736084
Search operator wording has been updated in spreadsheet document and Studio test coverage to match recent platform changes. This helps keep automated checks aligned with the current user interface and reduces the risk of false test failures.
Original PR description
We adapt some tests in documents_spreadsheet and web_studio to the changes brought by https://github.com/odoo/odoo/pull/210131 Task ID: 4798097
Resolved issues and error corrections
The employee folder access settings now open correctly instead of showing an error. This lets administrators manage document permissions for employee folders without interruption.
Original PR description
Steps to reproduce: 1. Go to the configuration, then settings. 2. Click the ' Manage Employee Access to employee folder' link. 3. In hr section, it throws a traceback. Technical Reason: Invalid prop structure passed to DocumentsPermissionPanel. After this commit: No traceback will occur, and the permission panel will appear. Task-4781134
Fixed an issue where the appointment type could appear blank in the scheduling Gantt popover. This helps users quickly identify appointment details without missing information.
Original PR description
Introduced in odoo/odoo@f79b2edb614fd08b19b18beeb16be38743f637b2 , the value of m2o is now changed to an object. Therefore, we cannot use appointment_type_id[1] to access the display_name as we did before, but access it directly as read from the object. Task-4816434
Features or functions removed from Odoo
The manual “Run Now” action was removed from reconciliation model settings because it is no longer useful after a previous change. This simplifies the accounting interface and avoids presenting users with an action that no longer adds value.
Original PR description
Since this commit: https://github.com/odoo/enterprise/pull/84751/commits/fb86103eda8ee87a41a7b1fff152719e671ae300 The run now button is not useful so we decided to removed it and the view associated to it. task-4749376
Miscellaneous changes
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-462
Original PR description
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-4628577 Forward-Port-Of: odoo/enterprise#85996 Forward-Port-Of: odoo/enterprise#84613
When an expense is manually created, the document is sent to the OCR, and the ocr modifies the values of the document. The issue is that the user cannot see that values have been modified and submit the expense with the wrong values (the ones returned by OCR which are not displayed on the form during submission). So to avoid such behaviour, we've made different fixes: - We display the banner that it has been sent to the OCR immediatly (not after a refresh) - We make work the refres
Original PR description
When an expense is manually created, the document is sent to the OCR, and the ocr modifies the values of the document. The issue is that the user cannot see that values have been modified and submit…
When an expense is manually created, the document is sent to the OCR, and the ocr modifies the values of the document. The issue is that the user cannot see that values have been modified and submit the expense with the wrong values (the ones returned by OCR which are not displayed on the form during submission). So to avoid such behaviour, we've made different fixes: - We display the banner that it has been sent to the OCR immediatly (not after a refresh) - We make work the refresh button diplayed in the banner - We don't change the name and/or product of the expense if the name of the expense has been entered manually (to know that we check if the name is the generated one when we create from attachment or not) - We don't modify the status of the expense to draft (if it has been submited before the response of the OCR we don't want modifications) The test have been modified the use case, because to correctly work if the expense is sent to the OCR, it means that there is an attachment linked to this PR. Also when we want to check the completion of the OCR, the attachment name is set as expense name (expense name is required) The issue comes from an internal feedback Forward-Port-Of: odoo/enterprise#84897
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.
Original PR description
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.facebook_no_business_management`. This parameter blocks the addition of the permission to the scope if set to any value, if not set it adds the permission to the scope. task-4719790 Forward-Port-Of: odoo/enterprise#86137 Forward-Port-Of: odoo/enterprise#84032
Currently if you make a mistake in the name of your employee and create a payslip, it's name will never be corrected since there is no direct dependency on the field. Forward-Port-Of: odoo/enterprise#86201
Original PR description
Currently if you make a mistake in the name of your employee and create a payslip, it's name will never be corrected since there is no direct dependency on the field. Forward-Port-Of: odoo/enterprise#86201
Summary ----- When you generate an entry via the deferred revenue report, if the original journal item has an analytic distribution at x%, then the lines of the deferred entries have an analytic distribution at -x%. Steps to reproduce ----- 1. In Accounting > Settings, enable the analytic accounting and set the "Generate Revenue Entries" as "Manually & Grouped". 2. Create an invoice with an analytic distribution, a start date and an end date. 3. Generate an entry with the deferred reven
Original PR description
Summary ----- When you generate an entry via the deferred revenue report, if the original journal item has an analytic distribution at x%, then the lines of the deferred entries have an analytic distribution at -x%. Steps to reproduce ----- 1. In Accounting > Settings, enable the analytic accounting and set the "Generate Revenue Entries" as "Manually & Grouped". 2. Create an invoice with an analytic distribution, a start date and an end date. 3. Generate an entry with the deferred revenue report by selecting a period including the created invoice. 4. Observe the negative analytic distribution in the generated entries. opw-4502556 Forward-Port-Of: odoo/enterprise#85039 Forward-Port-Of: odoo/enterprise#82594
pain.001.001.09 is a newer version of the ISO20022 format. Before this commit, we only supported it for SEPA Credit Transfer, using the same selection field as the one allowing to choose national variants of SEPA. This fix only intends to solve the issue for existing customers by using a system parameter that needs to be switched from "False" to "True". A cleaner solution will come in the future, after a refactoring of the payment methods. task-4647016 Forward-Port-Of: odoo/enterprise#86094
Original PR description
pain.001.001.09 is a newer version of the ISO20022 format. Before this commit, we only supported it for SEPA Credit Transfer, using the same selection field as the one allowing to choose national variants of SEPA. This fix only intends to solve the issue for existing customers by using a system parameter that needs to be switched from "False" to "True". A cleaner solution will come in the future, after a refactoring of the payment methods. task-4647016 Forward-Port-Of: odoo/enterprise#86094 Forward-Port-Of: odoo/enterprise#85597
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB. In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting ind
Original PR description
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the…
Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB.
In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting indexes. The timing goes from minutes to seconds. The frontend is usable again.
Example of the data stored in the temp table:
```
=> select count(*) from analytic_temp_account_move_line
+----------+
| count |
|----------|
| 60669759 |
+----------+
```
The example DB has 31 "plan columns". In other words we are duplicating 31 times 1957089 rows. That's too much data. It's also a waste of space and time. Especially if we later issue more filtering commands as the report is refined in the frontend. This leads to current approach being unusable for some clients. In the example DB the timing is bigger than the standard timeout for frontend requests.
Planning and execution of for the insert in the temporary table:
```
Insert on analytic_temp_account_move_line (cost=0.86..6659742.75 rows=0 width=0) (actual time=209651.484..209651.487 rows=0 loops=1)
-> Subquery Scan on "*SELECT*" (cost=0.86..6659742.75 rows=157594266 width=548) (actual time=644.693..92507.579 rows=60669759 loops=1)
-> Result (cost=0.86..5083800.09 rows=157594266 width=548) (actual time=644.689..85762.552 rows=60669759 loops=1)
-> ProjectSet (cost=0.86..1143943.44 rows=157594266 width=366) (actual time=644.657..72959.699 rows=60669759 loops=1)
-> Merge Left Join (cost=0.86..317844.46 rows=5083686 width=486) (actual time=644.562..22711.962 rows=1957089 loops=1)
Merge Cond: (account_analytic_line.move_line_id = account_move_line.id)
-> Index Scan using account_analytic_line__move_line_id_index on account_analytic_line (cost=0.43..97499.67 rows=1957619 width=150) (actual time=641.529..7738.521 rows=1957089 loops=1)
Filter: (general_account_id IS NOT NULL)
Rows Removed by Filter: 136994
-> Materialize (cost=0.43..144877.29 rows=2272735 width=344) (actual time=3.014..13564.293 rows=3022715 loops=1)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.43..139195.45 rows=2272735 width=344) (actual time=3.005..11312.577 rows=2274827 loops=1)
Planning Time: 132.775 ms
JIT:
Functions: 78
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 4.236 ms (Deform 2.533 ms), Inlining 64.617 ms, Optimization 351.121 ms, Emission 222.715 ms, Total 642.690 ms
Execution Time: 209672.536 ms
```
Planning and execution of a query based on the new view (note the usage of indexes from the actual tables):
```
Hash Join (cost=72813.40..294958.00 rows=7724 width=4) (actual time=1760.970..3493.933 rows=61 loops=1)
Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
-> Subquery Scan on account_move_line (cost=72794.39..294349.71 rows=223360 width=8) (actual time=1725.998..3477.187 rows=246 loops=1)
Filter: (account_move_line.analytic_distribution = ANY ('{1703,898,896,890,648,670,673,685,818,899,828,837,846,849,848,891,901,904,905,906,907,942,952,1039,980,985,1049,1050,1051,1093,1107,1114,1233,1126,1129,1133,1151,1152,1153,1222,1272,1218,1230,1243,1282,1249,1369,1271,1286,1328,1371,1396,1432,1403,1404,1406,1409,1430,1431,1437,1449,1473,1498,1515,1516,1517,1524,1525,1527,1528,1543,1549,1588,1592,1604,1605,1784,1641,1650,1652,1676,1677,1678,1679,1680,1702,1751,1759,1760,1767,1964,1796,1826,1832,1838,1926,1866,1883,1916,1922,1923,1954,1963,2144,1977,1974,2005,2011,2013,2015,2016,2032,2035,2037,2038,2064,2142,2097,2106,2110,2111,2112,2115,2121,2122,2130,2131,2141,2157,2311,2251,2252,2263,2269,2270,2271,2272,2274,2275,2279,2280,2287,2300,2307,2312,2316,2330,2339,2720,2370,2372,2423,2439,2462,2494,2477,2478,2480,2483,2491,2492,2493,2537,2533,2534,2535,2536,2546,2550,2551,2573,2574,2575,2576,2587,2598,2658,2691,2710,2721,2763}'::jsonb[]))
Rows Removed by Filter: 2617642
-> Gather (cost=72793.94..290647.16 rows=246807 width=910) (actual time=1720.216..3369.512 rows=2617888 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Result (cost=71793.94..264966.46 rows=4500611 width=910) (actual time=1706.592..2884.302 rows=1308944 loops=2)
-> ProjectSet (cost=71793.94..197457.29 rows=4500611 width=12) (actual time=1706.573..2654.189 rows=1308944 loops=2)
-> Parallel Hash Join (cost=71793.94..173865.38 rows=145181 width=132) (actual time=1706.560..2554.799 rows=42224 loops=2)
Hash Cond: (account_move_line_1.id = account_analytic_line.move_line_id)
-> Parallel Index Scan using account_move_line__journal_id_index on account_move_line account_move_line_1 (cost=0.43..100906.82 rows=149368 width=4) (actual time=2.633..788.321 rows=126675 loops=2)
Index Cond: (journal_id = ANY ('{23,21,17}'::integer[]))
-> Parallel Hash (cost=67363.05..67363.05 rows=354437 width=136) (actual time=1699.502..1699.503 rows=421304 loops=2)
Buckets: 1048576 Batches: 1 Memory Usage: 54880kB
-> Parallel Index Scan using account_analytic_line__date_index on account_analytic_line (cost=0.43..67363.05 rows=354437 width=136) (actual time=9.963..1507.693 rows=421304 loops=2)
Index Cond: ((date <= '2024-12-31'::date) AND (date >= '2024-01-01'::date))
Filter: ((general_account_id IS NOT NULL) AND (company_id = 3))
Rows Removed by Filter: 57954
-> Hash (cost=18.65..18.65 rows=29 width=4) (actual time=16.619..16.620 rows=29 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 10kB
-> Index Scan using account_account__account_type_index on account_account account_move_line__account_id (cost=0.15..18.65 rows=29 width=4) (actual time=16.513..16.592 rows=29 loops=1)
Index Cond: ((account_type)::text = 'income'::text)
Planning Time: 75.050 ms
JIT:
Functions: 51
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 4.433 ms (Deform 2.707 ms), Inlining 0.000 ms, Optimization 2.501 ms, Emission 30.127 ms, Total 37.061 ms
Execution Time: 3496.425 ms
```
OPW-4782916
Forward-Port-Of: odoo/enterprise#85942Before this **PR**: The same button could appear in both the primary and secondary button groups on a bank statement line, leading to unnecessary duplication. After this **PR**: If a button is already shown as a primary action, it is excluded from the list of secondary buttons to avoid redundancy. **task**-4780841 Forward-Port-Of: odoo/enterprise#85452
Original PR description
Before this **PR**: The same button could appear in both the primary and secondary button groups on a bank statement line, leading to unnecessary duplication. After this **PR**: If a button is already shown as a primary action, it is excluded from the list of secondary buttons to avoid redundancy. **task**-4780841 Forward-Port-Of: odoo/enterprise#85452
Because the customer statement buttons took too much space, the breadcrumb becomes invisible. This commit fixes always show the breadcrumb, and the buttons move instead. task-4583817 Forward-Port-Of: odoo/enterprise#81253
Original PR description
Because the customer statement buttons took too much space, the breadcrumb becomes invisible. This commit fixes always show the breadcrumb, and the buttons move instead. task-4583817 Forward-Port-Of: odoo/enterprise#81253
Change on a reco model should reset buttons for all unmatched statement lines. task-4749376 Forward-Port-Of: odoo/enterprise#84751
Original PR description
Change on a reco model should reset buttons for all unmatched statement lines. task-4749376 Forward-Port-Of: odoo/enterprise#84751
This commit adds translations for Luxembourg Annual VAT Declaration in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 Forward-Port-Of: odoo/enterprise#86139 Forward-Port-Of: odoo/enterprise#85898
Original PR description
This commit adds translations for Luxembourg Annual VAT Declaration in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 Forward-Port-Of: odoo/enterprise#86139 Forward-Port-Of: odoo/enterprise#85898
This commit adapts the ReferralKanbanMany2OneAvatarUserField to cope with changes made in https://github.com/odoo/odoo/pull/205922 task-4707431 Forward-Port-Of: odoo/enterprise#83397
Original PR description
This commit adapts the ReferralKanbanMany2OneAvatarUserField to cope with changes made in https://github.com/odoo/odoo/pull/205922 task-4707431 Forward-Port-Of: odoo/enterprise#83397
Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This happens because in this specific case of change of call activity deadline date, the VOIP softphone code is fetching activity data of today faster than odoo views, thanks to relying on bus notification, whereas odoo views and chatter rely on mostly
Original PR description
Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl')…
Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This happens because in this specific case of change of call activity deadline date, the VOIP softphone code is fetching activity data of today faster than odoo views, thanks to relying on bus notification, whereas odoo views and chatter rely on mostly on returned RPCs. The code of VOIP returns activity data with a custom formatter, which omits `persona` that is important for the good templating of an activity in Chatter otherwise there's the crash above. A recent PR [1] attempted to fix this issue, but the syntax for Store was wrong: it used the syntax for an item in field list (e.g. in `_to_store_defaults`) instead of pure store data from a specific record. This bad use of Store.One() resulted in actually returning `False`. [1]: https://github.com/odoo/enterprise/pull/84970 opw-4586756 Forward-Port-Of: odoo/enterprise#86037 Forward-Port-Of: odoo/enterprise#85907
Version: - saas-17.4 Steps to reproduce: - Create a sign request activity from sales or any other app. - Try to send document from activity from kanban view. Issue: - The sign request is created, but it is not linked to the related record. Cause: - The res_model and res_id were being read from the 'props' but it is available inside 'props.activity'. Solution: - Corrected the code to read res_model and res_id from 'props.activity'. task-4788037 Forward-Port-Of: odoo/enterpri
Original PR description
Version: - saas-17.4 Steps to reproduce: - Create a sign request activity from sales or any other app. - Try to send document from activity from kanban view. Issue: - The sign request is created, but it is not linked to the related record. Cause: - The res_model and res_id were being read from the 'props' but it is available inside 'props.activity'. Solution: - Corrected the code to read res_model and res_id from 'props.activity'. task-4788037 Forward-Port-Of: odoo/enterprise#86026 Forward-Port-Of: odoo/enterprise#85285
When the status is married and no spouse name is provided, it raises a traceback. So we check that there is a spouse name before trying to upercase it, because the field is not required. Forward-Port-Of: odoo/enterprise#85980
Original PR description
When the status is married and no spouse name is provided, it raises a traceback. So we check that there is a spouse name before trying to upercase it, because the field is not required. Forward-Port-Of: odoo/enterprise#85980
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference ------
Original PR description
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference --------- opw-4743742 Forward-Port-Of: odoo/enterprise#86099 Forward-Port-Of: odoo/enterprise#85974
…atch Batch generation currently takes contract templates, which it should not Forward-Port-Of: odoo/enterprise#86120
Original PR description
…atch Batch generation currently takes contract templates, which it should not Forward-Port-Of: odoo/enterprise#86120
Before this commit, when the user tries to delete a project in project app, a traceback is occurred because of recursion loop in the code during the deletion of the record. This commit removes the recursion in the code to correctly delete the project without any issue. Steps to reproduce the issue ---------------------------- 0. Install `esg_project` module 1. Create a project 2. Go to Projects list view 3. Delete the project created in step 1 Expected behavior -----------------
Original PR description
Before this commit, when the user tries to delete a project in project app, a traceback is occurred because of recursion loop in the code during the deletion of the record. This commit removes the recursion in the code to correctly delete the project without any issue. Steps to reproduce the issue ---------------------------- 0. Install `esg_project` module 1. Create a project 2. Go to Projects list view 3. Delete the project created in step 1 Expected behavior ----------------- The project should be deleted without any issue Current behavior ---------------- A recursion error is occurred during the deletion of the project task-4788173 Forward-Port-Of: odoo/enterprise#85277
…t with round per line opw-4685953 Forward-Port-Of: odoo/enterprise#85469
Original PR description
…t with round per line opw-4685953 Forward-Port-Of: odoo/enterprise#85469
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the new quote -> it's filled with default values instead of the one from the other quote you dpulicated one could expect after duplication (and so if you save without changing anything in the spreadsheet, you 'reset' the quote even though it's probably not what you wanted to do), Expected behaviour
Original PR description
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the…
1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine), 2. Modify it using the quote calculator, 3. Duplicate it, 4. Open the quote calculator in the new quote -> it's filled with default values instead of the one from the other quote you dpulicated one could expect after duplication (and so if you save without changing anything in the spreadsheet, you 'reset' the quote even though it's probably not what you wanted to do), Expected behaviour: the quote calculator spreadsheet is duplicated for the new quote with the same values. Implementation note: Why not just `copy=True` on field `spreadsheet_ids`? Because the spreadsheet should be copied, but not only! The `spreadsheet.revision` linked to the spreadsheet also need to be copied. If they are not copied, revisions which are not part of the last snapshot will be lost on the new spreadsheet record and it won't lead to the same spreadsheet data. Task: 4801418 Forward-Port-Of: odoo/enterprise#86017 Forward-Port-Of: odoo/enterprise#85746
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checke
Original PR description
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checked in the _generate_lot() which is called on adding product tracked by lot. opw-4648542 opw-4646960 Forward-Port-Of: odoo/enterprise#85867 Forward-Port-Of: odoo/enterprise#82341
Before this commit, when a shift has an allocated hours set, the allocated hours is displayed in the gantt pill even if the allocated percentage is at 100%. This commit adds the allocated_percentage field in the gantt view to make sure the allocated percentage is fetched to be able to know if the slot has an allocated percentage set to 100% if yes then the allocated hours will not be displayed in the display name of the gantt pill. This commit also reviews a bit the code to display or not the
Original PR description
Before this commit, when a shift has an allocated hours set, the allocated hours is displayed in the gantt pill even if the allocated percentage is at 100%. This commit adds the allocated_percentage field in the gantt view to make sure the allocated percentage is fetched to be able to know if the slot has an allocated percentage set to 100% if yes then the allocated hours will not be displayed in the display name of the gantt pill. This commit also reviews a bit the code to display or not the allocated hours to only call the parent method when it is really needed. task-4801407 Forward-Port-Of: odoo/enterprise#85944
compute imp & assert deduplicate Forward-Port-Of: odoo/enterprise#84867 Forward-Port-Of: odoo/enterprise#84842
Original PR description
compute imp & assert deduplicate Forward-Port-Of: odoo/enterprise#84867 Forward-Port-Of: odoo/enterprise#84842
There is a missing ``s`` in the translation in ``pt_BR`` language. Traceback: ``` ValueError: incomplete format File "/home/odoo/src/odoo/odoo/tools/translate.py", line 422, in get_translation return translation % args ``` This issue was introduced in this commit:https://github.com/odoo/enterprise/commit/12c9eee514868f627c581e367e566458520ae122 https://github.com/odoo/enterprise/blob/9d51f5171b3c2478599dde1ce991c90fa6fed32b/l10n_br_avatax/i18n/pt_BR.po#L1156 Here, the ``s`` i
Original PR description
There is a missing ``s`` in the translation in ``pt_BR`` language.
Traceback:
```
ValueError: incomplete format
File "/home/odoo/src/odoo/odoo/tools/translate.py", line 422, in get_translation
return translation % args
```
This issue was introduced in this commit:https://github.com/odoo/enterprise/commit/12c9eee514868f627c581e367e566458520ae122
https://github.com/odoo/enterprise/blob/9d51f5171b3c2478599dde1ce991c90fa6fed32b/l10n_br_avatax/i18n/pt_BR.po#L1156 Here, the ``s`` is missing at the end of ``%(errors)``
It should be ``%(errors)s``.
sentry-6616622354
Forward-Port-Of: odoo/enterprise#85983**Steps to reproduce:** Leave at least one field empty on the invoicing info page of the website checkout flow. For that page to appear, the customer country must be Chile, and the setting "Automatic Invoice" must be checked on the Website settings. **Issue:** Error 500 when rendering the template of the navigation buttons. The button values are not set.  Bug introduced in commit odoo/enterprise
Original PR description
**Steps to reproduce:** Leave at least one field empty on the invoicing info page of the website checkout flow. For that page to appear, the customer country must be Chile, and the setting "Automatic Invoice" must be checked on the Website settings. **Issue:** Error 500 when rendering the template of the navigation buttons. The button values are not set.  Bug introduced in commit odoo/enterprise@ba260e8 Fixed by calling the method that sets the values before rendering the template. Forward-Port-Of: odoo/enterprise#86097
Since odoo/enterprise#81180 removed the `ip_url` field from the IoT box form view, these buttons have not been working since their JS widgets relied on that field. This commit fixes the issue by making them use the new `formatEndpoint` helper instead. task-4813431 Forward-Port-Of: odoo/enterprise#86092
Original PR description
Since odoo/enterprise#81180 removed the `ip_url` field from the IoT box form view, these buttons have not been working since their JS widgets relied on that field. This commit fixes the issue by making them use the new `formatEndpoint` helper instead. task-4813431 Forward-Port-Of: odoo/enterprise#86092
With the introduction of signing communication between the IoT box and the DB, a `sign_communication` method is called on the `iot.box` model for every IoT request. This works fine when there is a logged in user, however in the case when there is no user it fails. This is due to the `call_kw` route used by ORM calls requiring a user. In the Kiosk environment, there is no logged in user, so the request fails. To fix this, a new route has been added to proxy the request, which verifies the sess
Original PR description
With the introduction of signing communication between the IoT box and the DB, a `sign_communication` method is called on the `iot.box` model for every IoT request. This works fine when there is a logged in user, however in the case when there is no user it fails. This is due to the `call_kw` route used by ORM calls requiring a user. In the Kiosk environment, there is no logged in user, so the request fails. To fix this, a new route has been added to proxy the request, which verifies the session ID and then returns the authorisation hash as usual. task-4809897 Forward-Port-Of: odoo/enterprise#86058
## Description This PR fixes several issues related to comments in spreadsheet cells: - **Dark Mode Styling** The comment styles were broken in dark mode because the dark SCSS file was in the wrong asset bundle. It's now removed from `assets_backend` and added to `assets_web_dark` to fix the issue. - **Focus Issue When Using Keyboard** When using the keyboard to move around the spreadsheet, opening a comment popup would focus the composer, stopping navigation. The composer now
Original PR description
## Description This PR fixes several issues related to comments in spreadsheet cells: - **Dark Mode Styling** The comment styles were broken in dark mode because the dark SCSS file was in the wrong…
## Description This PR fixes several issues related to comments in spreadsheet cells: - **Dark Mode Styling** The comment styles were broken in dark mode because the dark SCSS file was in the wrong asset bundle. It's now removed from `assets_backend` and added to `assets_web_dark` to fix the issue. - **Focus Issue When Using Keyboard** When using the keyboard to move around the spreadsheet, opening a comment popup would focus the composer, stopping navigation. The composer now doesn’t take focus, so keyboard navigation keeps working smoothly. - **Upload Button & Error Fixes** - The upload button was showing for spreadsheet cell comments but didn’t work. It’s now hidden. - There was also an error when editing a comment because `this.thread` wasn’t always available. Now it falls back to `this.message?.thread` when editing the message. - **Popover Visibility Fix** When posting the first comment and hovering over it, the action buttons (edit, favorite, delete) were partly cut off. This is now fixed by adding some padding to the thread style.  **Task**: [4708400](https://www.odoo.com/odoo/project/2328/tasks/4708400) Forward-Port-Of: odoo/enterprise#86032 Forward-Port-Of: odoo/enterprise#83410
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change the attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded a
Original PR description
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format…
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change the attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded attachment, but the computation of the 'raw' field on the attachment returns the value "b'56.00 bytes'", leaving the attachment_uuid field empty because the XML is assumed to be in the wrong format. The issue doesn't exist for shorter XML files in the Payment-10 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd) **Solution:** Before computing the attachment_uuid from the attachment, we set the bin_size to False in the context. opw-4641487 Forward-Port-Of: odoo/enterprise#83538
If the subject serial number is not set in the certificate and the user clicks the ``Send now to SII`` button on the invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_cl_edi`` module and switch to CL company - Go to Invoicing > Configuration > Settings > SII Web Services: SII - Test - Create a new invoice > customer: CL company > add a line > Confirm > ``Send now to SII`` Traceback: ``` TypeError: 'bool' object is not subscriptable ``` https://git
Original PR description
If the subject serial number is not set in the certificate and the user clicks the ``Send now to SII`` button on the invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_cl_edi`` module and switch to CL company - Go to Invoicing > Configuration > Settings > SII Web Services: SII - Test - Create a new invoice > customer: CL company > add a line > Confirm > ``Send now to SII`` Traceback: ``` TypeError: 'bool' object is not subscriptable ``` https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/account_move.py#L290 Here, If ``subject_serial_number`` of certificate is False. It will lead to the above traceback. ``subject_serial_number`` can be False because Some certificates do not provide this number. ref-https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/certificate.py#L19-L20 sentry-6591311577 Forward-Port-Of: odoo/enterprise#84980
Otherwise, there's no other way for users to verify if the charged taxes are correct. task-4688950 Forward-Port-Of: odoo/enterprise#85100 Forward-Port-Of: odoo/enterprise#83464
Original PR description
Otherwise, there's no other way for users to verify if the charged taxes are correct. task-4688950 Forward-Port-Of: odoo/enterprise#85100 Forward-Port-Of: odoo/enterprise#83464
**Steps to reproduce:** 1) Open a GST return period. 2) Click Fetch GSTR-2B Summary. 3) Go to Vendor Refunds. 4) Open the vendor credit note created by OdooBot. 5) Click the Fetch button. -> Traceback occurs. **Cause:** The translation function (_()) was incorrectly used with two arguments instead of one in this commit https://github.com/odoo/enterprise/commit/14bfe78b034563637e43fd2795c9498c736d0dbc **Fix:** Change the arguments that are applicable for translation. **Task**-48
Original PR description
**Steps to reproduce:** 1) Open a GST return period. 2) Click Fetch GSTR-2B Summary. 3) Go to Vendor Refunds. 4) Open the vendor credit note created by OdooBot. 5) Click the Fetch button. -> Traceback occurs. **Cause:** The translation function (_()) was incorrectly used with two arguments instead of one in this commit https://github.com/odoo/enterprise/commit/14bfe78b034563637e43fd2795c9498c736d0dbc **Fix:** Change the arguments that are applicable for translation. **Task**-4808874 Forward-Port-Of: odoo/enterprise#85971
This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval. Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:
Original PR description
This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry…
This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval. Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:00 and 05:00 respecively, up to a 1-hour difference for daylight savings time. Now suppose that the paysliip for this work entry only goes up to that following morning. Instead of using the local times of 18:00 and 01:00, the payslip would use the UTC times of 22:00 and 05:00, which would only count 2 of those hours instead of 6. This is resolved by converting the UTC times to local before using them to clamp the work entries to the payslip interval. opw-4790119 Forward-Port-Of: odoo/enterprise#85967 Forward-Port-Of: odoo/enterprise#85548
20 changes
Enhancements to existing features
The Belgian chart of accounts now classifies selected payable and receivable accounts as current liabilities or current assets where that better matches their purpose. This improves the accuracy of financial reporting and helps businesses see these balances in the right accounting categories.
Original PR description
In this PR: - Changed the account types of some accounts from 'payable' to 'current liabilities' and from 'receivable' to 'current assets' to better reflect their nature task-4813704
Historical inventory valuation reports now show Quantity and Total Value by default instead of remaining quantities and values. This makes past valuation views more relevant and easier for users to interpret.
Original PR description
When viewing the valuation in the past, the default measures 'Remaining Qty' and 'Remaining Value' are irrelevant. Instead, display the 'Quantity' and 'Total Value' measures by default. opw-4517548
A new automated test checks that changes made to existing Point of Sale records are saved locally and still available after refreshing the system. This helps reduce the risk of losing recent POS updates during everyday use.
Original PR description
This commit adds a test case which ensures that updates in existing records are properly saved in local database and are available after refresh opw-4778516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes how list view column widths are calculated when date or time formats include quoted text. Users should see more consistent column sizing in lists, avoiding layout issues caused by misread formatting rules.
Original PR description
This commit is a followup of odoo/odoo#210300 where we didn't correctly detect escaped parts (wrapped in single quotes) in date and time formats. This commit ensures that we first remove from the formats all escaped parts, before analysing those formats to detect patterns. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes restaurant loyalty reward checks wait for the needed information before continuing, preventing false test failures in automated validation. It helps keep the point of sale loyalty flow stable without changing normal business behavior for users.
Original PR description
Steps are triggered too quick on the runbot. 1- It was trying to render the reward button while computation was still ocurring, thus `coupon_id` wasn't set. > Use of the ? to avoid the traceback 2- It was trying to check for the price while the reward hadn't loaded yet. > Instead we check that the reward is there, we'll check the price at the end. runbot: 163072
This update improves Odoo's internal web testing tools so automated tests handle animations more reliably and produce clearer, less duplicated failure information. It helps teams diagnose test failures faster and reduces unnecessary noise in continuous integration logs.
Original PR description
This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures batch payments can include payments in all valid statuses, including paid payments when only the Invoicing app is installed. It also updates related tests so validation behaves correctly across different app setups.
Original PR description
* Previously, the domain only included payments in the "in_process" state, which is incorrect when only the Invoicing app is installed -paid payments should also be allowed-. * Test was failing with single app installed when accountant module was not installed. When only Invoicing, we can validate a batch payment even when payments are in paid state, so the Warning was not raised causing tests to fail.
This fix adjusts how employee legal names are calculated for Swiss payroll ELM transmissions. It helps ensure payroll submissions use the correct name format required in Switzerland, reducing the risk of reporting errors.
Original PR description
…o switzerland
Miscellaneous changes
Previously the `state name` of partner is validating, but as per government API json schema `state tin number` is required. After this commit: - The validation now checks the state tin number instead of the state name, ensuring it is a valid and min 1 and max-2 digit number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211276 Forward-Port-Of: odoo/odoo#204495
Original PR description
Previously the `state name` of partner is validating, but as per government API json schema `state tin number` is required. After this commit: - The validation now checks the state tin number instead of the state name, ensuring it is a valid and min 1 and max-2 digit number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211276 Forward-Port-Of: odoo/odoo#204495
Account 461411, set by default on the sales taxes in LU localization does not need to be reconcilable as only payables and receivables defined in tax groups have to be opw-4749885 Forward-Port-Of: odoo/odoo#211244 Forward-Port-Of: odoo/odoo#210613
Original PR description
Account 461411, set by default on the sales taxes in LU localization does not need to be reconcilable as only payables and receivables defined in tax groups have to be opw-4749885 Forward-Port-Of: odoo/odoo#211244 Forward-Port-Of: odoo/odoo#210613
Before fix, when a user manually added a narration (e.g. terms and conditions) on an invoice, changing the journal or other dependent fields (partner) would trigger a recompute of the narration field, which cleared the user-provided content. Steps to reproduce: ---- 1. Create a customer invoice. 2. Add custom narration (terms and conditions). 3. Change the journal or partner. → The narration field is reset and the manually-entered content is lost. After this commit: ---- The compute
Original PR description
Before fix, when a user manually added a narration (e.g. terms and conditions) on an invoice, changing the journal or other dependent fields (partner) would trigger a recompute of the narration field, which cleared the user-provided content. Steps to reproduce: ---- 1. Create a customer invoice. 2. Add custom narration (terms and conditions). 3. Change the journal or partner. → The narration field is reset and the manually-entered content is lost. After this commit: ---- The compute method for the narration field checks if narration already exists and preserves it, preventing loss of user input. ---- opw-4757119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210852
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Processing the backorder wizard will create and confirm moves for the backorder picking: https://github.com/odoo/odoo/blob/a7
Original PR description
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of…
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Processing the backorder wizard will create and confirm moves for the backorder picking: https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1916-L1919 However, as these moves are `make_to_order` they are planned to create and run procurements in their respective `_action_confirm`'s: https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1379-L1388 opw-4633920 opw-4713650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209924 Forward-Port-Of: odoo/odoo#209442
The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not support `SUM(timestamp)` — `SUM` can only be used with numeric types such as integer, float, or monetary. Steps to reproduce: --- - Install `Gamification` and `hr_appraisal` modules - Create a Gamification Challenge, and also create a Goal Definition and set `Computation Mode` -> `Sum`, `Model` -> `A
Original PR description
The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not…
The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not support `SUM(timestamp)` — `SUM` can only be used with numeric types such as integer, float, or monetary.
Steps to reproduce:
---
- Install `Gamification` and `hr_appraisal` modules
- Create a Gamification Challenge, and also create a Goal Definition and set `Computation Mode` -> `Sum`, `Model` -> `Appraisal Goal`, `Field to Sum` -> `Created on (Appraisal Goal)`, `Filter Domain` -> `[]`
- `Start Challenge` in Gamification Challenge
Traceback:
---
```
UndefinedFunction
function sum(timestamp without time zone) does not exist LINE 1: SELECT SUM("hr_appraisal_goal"."create_date") FROM "hr_appra...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
```
To fix this, we now check the field type before applying aggregation. If the computation mode is set to `sum` but the field is not numeric, we gracefully fallback to using `count` instead. This prevents SQL errors and ensures that goal computations remain reliable even with misconfigured definitions.
sentry-6575130734
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#208077The failing step is creating a new website, which could take a long time. Increasing the timeout for the next step should prevent the error. runbot-error-104332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210935 Forward-Port-Of: odoo/odoo#210121
Original PR description
The failing step is creating a new website, which could take a long time. Increasing the timeout for the next step should prevent the error. runbot-error-104332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210935 Forward-Port-Of: odoo/odoo#210121
### Steps to reproduce: - Navigate to Recruitment > Job Position > Any job position > Job applications (smart button) - Create an applicant - Set a Recruiter for the applicant - Move the stage to 'Contract Signed' - Click on 'Create Employee' - Notice a validation error that the opertion cannot be completed ### Cause: This is happening as the 'Job applications' smart button has default value for the user_id in context https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95
Original PR description
### Steps to reproduce: - Navigate to Recruitment > Job Position > Any job position > Job applications (smart button) - Create an applicant - Set a Recruiter for the applicant - Move the stage to…
### Steps to reproduce: - Navigate to Recruitment > Job Position > Any job position > Job applications (smart button) - Create an applicant - Set a Recruiter for the applicant - Move the stage to 'Contract Signed' - Click on 'Create Employee' - Notice a validation error that the opertion cannot be completed ### Cause: This is happening as the 'Job applications' smart button has default value for the user_id in context https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr_recruitment/views/hr_job_views.xml#L207-L211 so when creating an employee it will add the missing fields from defaults and it will get the default value in the context which for an existing user so when creating the employee with this user_id it will trigger the sql constraint https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr/models/hr_employee.py#L145-L148 ### Fix: clean the context before creating the partner and the employee corresponding to this applicant opw-4629219 Forward-Port-Of: odoo/odoo#210806 Forward-Port-Of: odoo/odoo#204997
**Steps to reproduce:** 1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` . 2. install website module. **Issue:** Users are incorrectly redirected to the configurator screen instead of the website page. However, refreshing the page correctly redirects to the home screen as the server-side route is triggered on reload. **Reason:** The issue started in Odoo 16. Until Odoo 15, redirection to the configurator route is handled using ir.actions.ac
Original PR description
**Steps to reproduce:** 1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` . 2. install website module. **Issue:** Users are incorrectly redirected to the…
**Steps to reproduce:** 1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` . 2. install website module. **Issue:** Users are incorrectly redirected to the configurator screen instead of the website page. However, refreshing the page correctly redirects to the home screen as the server-side route is triggered on reload. **Reason:** The issue started in Odoo 16. Until Odoo 15, redirection to the configurator route is handled using ir.actions.act_url, which triggered a full page reload, ensuring the server route executed. From Odoo 16 onwards, this action is removed, and a direct client action is attached. Within `configurator.js`, navigation is now handled using the `history.pushState` method which replace the current url and does not trigger a reload. As a result, even when navigating to the configurator route, the server route is not executed, leading to incorrect redirection. **Fix:** Added a check in configurator.js to verify the configurator status. If it is true, the user is redirected to the website page instead of the configurator. Otherwise, the normal configurator flow continues. **Key Changes:** 1. In configurator_init, added a check: if configurator_done is True, set the default theme using button_choose_theme and store its result (a dict containing the next action to execute) as redirect_url. 2. In the Configurator component, added redirect_url to the store, and inside the onWillStart method, checked if redirect_url exists. If it does, redirect to the home screen using doAction. This PR ensures the correct redirection behavior when users follow the Industries installation flow. task-4555467 Forward-Port-Of: odoo/odoo#197593
Speed up queries like in _check_uom_not_in_invoice Before: https://explain.dalibo.com/plan/dh442bag02518830 After: https://explain.dalibo.com/plan/db2ef078c8dd4ac0 From 12 seconds to .3ms 10 Millions account_ move_ line in the database Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#2
Original PR description
Speed up queries like in _check_uom_not_in_invoice Before: https://explain.dalibo.com/plan/dh442bag02518830 After: https://explain.dalibo.com/plan/db2ef078c8dd4ac0 From 12 seconds to .3ms 10 Millions account_ move_ line in the database Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210981 Forward-Port-Of: odoo/odoo#208992
Scenario: - create an object_write (Update the Record) action - update a field with equation evaluation (Python expression) with an expression like "record.id" - click on "Create contextual action" - go to a list view of the model, execute the action for several records Result: the value of the field of all records are computed based on the first selected record. Issue: we don't change the "record" in the evaluation context and just keep the first record. Fix: changing the reco
Original PR description
Scenario: - create an object_write (Update the Record) action - update a field with equation evaluation (Python expression) with an expression like "record.id" - click on "Create contextual action" -…
Scenario:
- create an object_write (Update the Record) action
- update a field with equation evaluation (Python expression) with an
expression like "record.id"
- click on "Create contextual action"
- go to a list view of the model, execute the action for several records
Result: the value of the field of all records are computed based on the
first selected record.
Issue: we don't change the "record" in the evaluation context and just
keep the first record.
Fix: changing the record.
Note: without the fix, the added test fails because the city of the
second record is set to the value of the ID of the first record.
opw-4491099
__PR code note__:
I did the change in "run" but this could be done in `_run_action_object_write`, I chose run because we are already changing the action_id in it.
The "`if eval_context.get('record') is not None`" is to not change an hypothetical case where `self.model_id` doesn't match the `context.action_model`.
__PR note__:
If it was too risky, we could probably merge in an higher version, the ticket is in 17.0 and this is still happening in master.
I've not heard of this issue before so this must not be very frequent or urgent, but I guess this is because people either use a python constant or they just use a python action with a for loop in general.
Forward-Port-Of: odoo/odoo#211122
Forward-Port-Of: odoo/odoo#210855Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand. ### Steps to reproduce: - Create a storable product. Put 5 units in stock. - Create a delivery order for 5 units and mark as to do. - Go to the barcode app and edit your delivery order. - Click on the pencil and set a qty of 1 > Confirm - Click back on the pencil and reset the quantity to 0 > confirm #### > On the picking, the demand of the line was edited from 5 to 1. ### Cause
Original PR description
Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand. ### Steps to reproduce: - Create a storable product. Put 5 units in stock. - Create a delivery…
Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand. ### Steps to reproduce: - Create a storable product. Put 5 units in stock. - Create a delivery order for 5 units and mark as to do. - Go to the barcode app and edit your delivery order. - Click on the pencil and set a qty of 1 > Confirm - Click back on the pencil and reset the quantity to 0 > confirm #### > On the picking, the demand of the line was edited from 5 to 1. ### Cause of the issue: Editing the quantity of a move line from the barcode actually updates the qty_done of the move line which updates both the quantity and the picked status of the move line in the backend via the `_inverse_qty_done`: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/models/stock_move_line.py#L58-L62 Initially, the quantity of the move line was 5 and hence the demand of the line in the barcode was displayed as 5: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L119-L121 The first time you edit the line, you will actually change its quantity to 1 and set it as picked. Once the line state refreshes in the barcode it will then keep the same demand of 5 as it will then be based on the previous demand of the line (since the qty of the move line is set and the qty done is positive): https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045 However, the next time you update the line the `_inverse_qty_done` will leave the quantity of the move line at 1 but will also unpick it. Then, and since the `qty_done` was set to 0, it will update the demand of the barcode line because of these same lines: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045 ### Fix: Prior to Commit 3af3e00aabecde8b811ac2cbab397f982721f164 the quantity was updated as well as the picked state even when the qty_done was set to 0, so that this issue would not occur as the null quantity would make us keep the demand of barcode line after edition. However, the problem was that this would update the reserved quantity of the move and hence the barcode app demand once you leave the barcode app because of the `split_uncompleted_moves`. However, in the present use case, that same method can save us because if the move is picked and its quantity is null when you exit the barcode app, it will be rereversed. opw-4700996 Forward-Port-Of: odoo/enterprise#85003 Forward-Port-Of: odoo/enterprise#83623
- Create a sub company from the main company. - On only the sub-company create a new followup level. - While being in both the main company and the sub-company at the same time, try to access the newly created followup level in the followup report view. The following traceback appears: File "/home/odoo/src/odoo/addons/web/models/models.py", line 128, in web_read vals = many2one_data[values[field_name]] KeyError: 9 This commit hide the statusbar for the child company if there is followu
Original PR description
- Create a sub company from the main company. - On only the sub-company create a new followup level. - While being in both the main company and the sub-company at the same time, try to access the newly created followup level in the followup report view. The following traceback appears: File "/home/odoo/src/odoo/addons/web/models/models.py", line 128, in web_read vals = many2one_data[values[field_name]] KeyError: 9 This commit hide the statusbar for the child company if there is followup level in the parent as per the specification of https://github.com/odoo/enterprise/commit/bbcd54519706539d7e2e313118c956200ea70c91 and the implementation of https://github.com/odoo/enterprise/commit/f82ef250560957046be0590f8c2a08039bcc34ca#diff-c502b098cfa2c57bc70c144ae4f0e1fbe1c0116f392ed1a63743f12a51b82084 opw-4669397 Forward-Port-Of: odoo/enterprise#85348 Forward-Port-Of: odoo/enterprise#82324