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.

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.

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

![image](https://github.com/user-attachments/assets/1624723d-6867-4e71-83bc-b26fec7a2009)

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.

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.

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

The employee folder access settings now open correctly instead of showing an error. This lets administrators manage document permissions for employee folders without interruption.

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.

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

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.

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

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

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

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.

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

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

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

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

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#85942

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

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

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

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

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

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

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

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

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 ------

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

…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 -----------------

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

…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

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

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

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

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

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

**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. 
![image](https://github.com/user-attachments/assets/df451bf2-ecce-4a46-88d1-b051349b99a7)
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

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

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

## 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.
![image](https://github.com/user-attachments/assets/da774829-9fac-4ae0-a91a-6381c2404471)




**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

**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

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

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

**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:

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