Non-image attachments in Discuss now display in a cleaner list layout instead of appearing broken due to an unsuitable grid view. This makes it easier for users to browse and identify attached documents in conversations.

The grid layout in attachment list makes the non attachment list view look broken. This commit removes the grid from this view.

Steps to reproduce:
- open a discuss channel
- add some non image attachments
- go to the attachments list

Backport of https://github.com/odoo/odoo/pull/186033

Steps to reproduce: - Install Project and sale_timesheet - Create a project with Timesheet option enabled - Go to that project's setting and allocate hours - Gear Icon > Duplicate The duplicated project has 0 allocated hours, this is odd since sale_timesheet forces that field to copy=False despite every other module allowing it (Even Timesheet). Additionally, copied tasks still have their allocated hours no matter what so it is strange to remove them from the project itself. opw-428495

Steps to reproduce:
- Install Project and sale_timesheet
- Create a project with Timesheet option enabled
- Go to that project's setting and allocate hours
- Gear Icon > Duplicate

The duplicated project has 0 allocated hours, this is odd since sale_timesheet forces that field to copy=False despite every other module allowing it (Even Timesheet). Additionally, copied tasks still have their allocated hours no matter what so it is strange to remove them from the project itself.

opw-4284950

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#186292
Forward-Port-Of: odoo/odoo#185890

This error occurs when we are creating a new operation type in transfer. Steps to reproduce: --- - Install ``l10n_it_stock_ddt`` module - Switch company to ``IT Company`` - Go to transfer and create any new operation type Traceback: --- ``KeyError: 'code'`` At [1], we are facing this error because we are attempting to retrieve ``code`` from the ``vals``, but when we create a new operation type, we only receive ``name`` in the ``vals``. [1]- https://github.com/odoo/odoo/blob/248

This error occurs when we are creating a new operation type in transfer.

Steps to reproduce:
---
- Install ``l10n_it_stock_ddt`` module
- Switch company to ``IT Company``
- Go to transfer and create any new operation type

Traceback:
---
``KeyError: 'code'``

At [1], we are facing this error because we are attempting to retrieve ``code`` from the ``vals``, but when we create a new operation type, we only receive ``name`` in the ``vals``.

[1]- https://github.com/odoo/odoo/blob/2489a4c4a5aae829bb7dafe24d93529767ce07db/addons/l10n_it_stock_ddt/models/stock_picking.py#L76

sentry-6037671568

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#186127

Steps: - Open Terminal and click on the burger combo - Select burger and click the cancel button - Select the burger again and click OK with the default selection - Select a drink Issue: - After selecting all components of the product, the `Add to Order` button remains disabled, preventing the combo from being added to the cart. Cause: - The combo state is not being reset when discarding or closing the product configuration popup. Fix: - Implemented a proper reset of the combo st

Steps:
- Open Terminal and click on the burger combo
- Select burger and click the cancel button
- Select the burger again and click OK with the default selection
- Select a drink

Issue:
- After selecting all components of the product, the `Add to Order` button remains disabled, preventing the combo from being added to the cart.

Cause:
- The combo state is not being reset when discarding or closing the product configuration popup.

Fix:
- Implemented a proper reset of the combo state upon closing the configuration popup.

task-4285981

Forward-Port-Of: odoo/odoo#185296

Ease adding voice metadata through message_post. Task- Forward-Port-Of: odoo/odoo#186244

Ease adding voice metadata through message_post.

Task-

Forward-Port-Of: odoo/odoo#186244

__Current behavior before commit:__ Events with products that use a pricelist with `discount_policy` set `without_discount` cause 403 for public users on event pages if website setting `show_line_subtotals_tax_selection` = `tax_included`. __Reason:__ This is because of access right issues on taxes for `price_incl` being displayed on the event page. __Fix:__ Added `compute_sudo=True` to the field `price_incl`. __Steps:__ 1. Create new product `detailed_type` `event` with a high pri

__Current behavior before commit:__

Events with products that use a pricelist with `discount_policy` set `without_discount` cause 403 for public users on event pages if website setting `show_line_subtotals_tax_selection` = `tax_included`.

__Reason:__
This is because of access right issues on taxes for `price_incl` being displayed on the event page.

__Fix:__
Added `compute_sudo=True` to the field `price_incl`.

__Steps:__
1. Create new product `detailed_type` `event` with a high price Ex:100.
2. Set the website pricelist entry for this price as lower price Ex:50.
3. Change pricelist `discount_policy` to `without_discount`.
4. Change website setting: (Display Product Price) to (Tax Included)
4. Create event with custom product.
5. Publish event and view the event page from a public user.

opw-4264353

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

Steps to reproduce: - Install Project and sale_timesheet and Accounting - Settings > Enable 'Analytic Accounting' - Create a service product generating a project and task - New Product > Set 'Re-invoice Expenses' to 'Cost' - (If you have hr_expense you need to tick 'Can be expensed') - Create a new quotation for your project generating product > Confirm - Accounting > Vendors > Bills > New > Add your expense product - Set the analytic distribution to your project's (S000... - Customer)

Steps to reproduce:
- Install Project and sale_timesheet and Accounting
- Settings > Enable 'Analytic Accounting'
- Create a service product generating a project and task
- New Product > Set 'Re-invoice Expenses' to 'Cost'
- (If you have hr_expense you need to tick 'Can be expensed')

- Create a new quotation for your project generating product > Confirm
- Accounting > Vendors > Bills > New > Add your expense product
- Set the analytic distribution to your project's (S000... - Customer)
- Fill in Vendor, Bill Date and Price with arbritrary values > Confirm
- Project > ':' Menu on your project's card > Project Updates

The analytic line created on vendor bill confirmation is also linked to the sale order line created by the re-invoiced product on the original SO. This error notably does not occur without the sale_timesheet module, and the same flow with hr_expense instead of a vendor bill works flawlessly.

Project Updates shows the expense twice under Costs because unlike with the hr_expense module, no expense_id is linked to the account_move_line (Since regular vendor bills do no handle that field). This means we fail to filter the analytic_line in `_get_profitability_aal_domain`, thus reading the same update analytic line and deducting the amount twice.

Given that the vendor bill was meant to be treated as an expense, and that the same flow using hr_expense instead of a vendor bill results in only 1 line of costs, we want to replicate that behavior here, but we don't have a clean way to filter for these types of analytic lines. As a workaround we use the property of `_get_costs_items_from_purchase` to label updates in the 'other_purchase_costs' category to single out vendor bill updates and skip processing them the second time they come up.

opw-4042729

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#180589

During `test_drag_and_drop_event_in_calendar`, an error occurs due to the target not being found in drag and drop steps. When the test is performed on the same week as the event, there is a likely chance for the drag and drop steps to be triggered before the rendering of the Monthly Calendar view. When we are changing from weekly to monthly view, we will wait for the latter to be rendered before calling the next steps. runbot-error-105708 runbot-error-105709 Forward-Port-Of: odoo/odoo#18

During `test_drag_and_drop_event_in_calendar`, an error occurs due to the target not being found in drag and drop steps.

When the test is performed on the same week as the event, there is a likely chance for the drag and drop steps to be triggered before the rendering of the Monthly Calendar view. When we are changing from weekly to monthly view, we will wait for the latter to be rendered before calling the next steps.

runbot-error-105708
runbot-error-105709

Forward-Port-Of: odoo/odoo#186142

Description of the issue/feature this PR addresses: Described in #184497 Current behavior before PR: Error when selecting a template that contains field you don't have access to Desired behavior after PR is merged: No error occurs --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184943

Description of the issue/feature this PR addresses:
Described in #184497 

Current behavior before PR:
Error when selecting a template that contains field you don't have access to

Desired behavior after PR is merged:
No error occurs



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#184943

Issue Summary: During the upgrade from Odoo version 16.0 to 17.0, a discrepancy has emerged in the product configuration, specifically with the "Buy" route. The problem arises when computing the available quantity using the _compute_quantities_dict function. see: https://github.com/odoo/odoo/commit/6d8f184f09c213be068f911dd327ffe84fde8bab Problem Description: In version 17.0, when fetching the domain_Quant using the _get_domain_locations function, the domain returned is ('location

Issue Summary:

During the upgrade from Odoo version 16.0 to 17.0, a discrepancy has emerged in the product configuration, specifically with the "Buy" route.
The problem arises when computing the available quantity using the _compute_quantities_dict function.

see:
 https://github.com/odoo/odoo/commit/6d8f184f09c213be068f911dd327ffe84fde8bab

Problem Description:

In version 17.0, when fetching the domain_Quant using the _get_domain_locations function, the domain returned is ('location_id', 'any', [(0, '=', 1)])
 if no locations are found.
In version 16.0, it returns an empty list [] if no locations are found. This change results in the domain_quant in version 17.0 being
 [('product_id', 'in', [2684, 5474, 5475, 5478, 5487, 5522]), ('location_id', 'any', [(0, '=', 1)])],
 which leads to {} values, whereas in version 16.0, the domain
 would be [('product_id', 'in', [2684, 5474, 5475, 5478, 5487, 5522])], which returns actual values.

Impact:

The inconsistency in the domain operation between versions results in incorrect or missing quantity data after the upgrade, affecting the accuracy of product availability.

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

After this commit 784f1511 , The `float_round()` functionality is changed. Before this commit, If the `qty_available` is 0.57: ``` In [2]: float_round(0.57,2) Out[2]: 0.5700000000000001 After this commit: In [2]: float_round(0.57,2) Out[2]: 0.57 ``` Now, while executing this line of code https://github.com/odoo/odoo/blob/baea953d248471e8aef60e02c1216f77941f1951/addons/mrp/models/product.py#L244 ``` Before: In [3]: 0.5700000000000001*100//1 Out[3]: 57.0 After: In [3]: 0.57*

After this commit 784f1511 , The `float_round()` functionality is changed. 
Before this commit, If the `qty_available` is 0.57:
```
In [2]: float_round(0.57,2)
Out[2]: 0.5700000000000001

After this commit:
In [2]: float_round(0.57,2)
Out[2]: 0.57
```

Now, while executing this line of code
https://github.com/odoo/odoo/blob/baea953d248471e8aef60e02c1216f77941f1951/addons/mrp/models/product.py#L244
```
Before:
In [3]: 0.5700000000000001*100//1
Out[3]: 57.0

After:
In [3]: 0.57*100//1
Out[3]: 56.0
```

These differences leads to blocking the upgrade process.
```
Traceback (most recent call last):
File "/tmp/tmpft9eq3rf/migrations/testing.py", line 212, in test_check
self.check(value)
File "/tmp/tmpft9eq3rf/migrations/stock/tests/test_on_hand_quantity.py", line 90, in check
self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[12,[7979 chars]6, '57'], [20249, '17.06'], [20250, '1705'], [[12354 chars]'1']] != [[12,[7979 chars]6, '56'], [20249, '17.06'], [20250, '1705'], [[12354 chars]'1']]

First differing element 529:
[20246, '57']
[20246, '56']
```

upg-2096343
opw-4224012

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

Since #138471, each time `create_or_update_sequences_and_picking_types` is called, the related sequences will be updated to their default values. This means that if a user changed the sequence_code of a standard picking type, whenever that method is called (which can happen at the update of a warehouse), it will erase their settings. Rather than that, if the picking type already exist, we use its sequence_code instead of the default one. Related to: opw-4245938 opw-4264520 --- I conf

Since #138471, each time `create_or_update_sequences_and_picking_types` is called, the related sequences will be updated to their default values. This means that if a user changed the sequence_code of a standard picking type, whenever that method is called (which can happen at the update of a warehouse), it will erase their settings.

Rather than that, if the picking type already exist, we use its sequence_code instead of the default one.

Related to:
opw-4245938
opw-4264520

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#186051
Forward-Port-Of: odoo/odoo#185966

When in daily and weekly calendar views, the start time of events are shown twice in the event card, poluting the user interface. This commit removes the isolated start time for making the event card cleaner. task-4161302 Forward-Port-Of: odoo/odoo#178984

When in daily and weekly calendar views, the start time of events are shown twice in the event card, poluting the user interface.

This commit removes the isolated start time for making the event card cleaner.

task-4161302

Forward-Port-Of: odoo/odoo#178984

Steps: - Create a loyalty program with reward_type product - add a tag in product_tag field which is linked to multiple products Issue: - Description is not updated Cause: - The compute_reward_description is not called when tag is updated Fix: - added product_tag in depends for the _compute_reward_description opw-4039914 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174135

Steps:

- Create a loyalty program with reward_type product
- add a tag in product_tag field which is linked to multiple products

Issue:

- Description is not updated

Cause:

- The compute_reward_description is not called when tag is updated

Fix:

- added product_tag in depends for the _compute_reward_description

opw-4039914

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#174135

When an exception occurred during a request to IAP, there was no way of knowing which one it was exactly. This log should help understand what went wrong. Related ticket for which this would have been helpful: #4276907 Forward-Port-Of: odoo/odoo#185535

When an exception occurred during a request to IAP, there was no way of knowing which one it was exactly. This log should help understand what went wrong.

Related ticket for which this would have been helpful: #4276907

Forward-Port-Of: odoo/odoo#185535

This PR updates l10n_uy by adding 22% and 10% VAT-included tax options for sales and purchases, supporting Uruguay’s practice of using both tax-included and tax-excluded amounts per document. The data aligns with XML requirements by specifying VAT inclusion at the document level, enabling accurate automatic vendor bill creation from XML imports. Task Adhoc side: 43467 Task latam side: 1282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa

This PR updates l10n_uy by adding 22% and 10% VAT-included tax options for sales and purchases, supporting Uruguay’s practice of using both tax-included and tax-excluded amounts per document. The data aligns with XML requirements by specifying VAT inclusion at the document level, enabling accurate automatic vendor bill creation from XML imports.
Task Adhoc side: 43467
Task latam side: 1282




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#184940

When using ship later with 3 steps delivery and receipt, all the steps would always be done again even when the product is already available Steps to reproduce: ------------------- * Create a product A with any vendor * Setup 3 steps receipt and delivery in your warehouse * Create a sale order for product A * Receiving steps and purchase order will be created * Validate the purchase order and all the receiving steps so that there is 1 quantity in the warehouse * Open PoS, settle the or

When using ship later with 3 steps delivery and receipt, all the steps would always be done again even when the product is already available

Steps to reproduce:
-------------------
* Create a product A with any vendor
* Setup 3 steps receipt and delivery in your warehouse
* Create a sale order for product A
* Receiving steps and purchase order will be created
* Validate the purchase order and all the receiving steps so that there is 1 quantity in the warehouse
* Open PoS, settle the order and ship it later
> Observation: In the PoS order you will see that all receiving steps
  have been created again, and a new purchase order has been created too

Why the fix:
------------
The error was happening because the quantity of the original sale order was still reserved. So when creating the new delivery order there was no quantity available and the whole receiving process was required again. We now make sure to free the quantity before creating the delivery order

opw-4092298
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#185469

Steps to reproduce: - Drag and drop any snippet with image in it. - Select image and crop image using transform option. - Click replace button. - Image selection popover won't open. After this commit: - The "preserveCursor" method has been used to maintain the cursor state because transform option was losing cursor selection. task-3930743 Forward-Port-Of: odoo/odoo#167338

Steps to reproduce:
- Drag and drop any snippet with image in it.
- Select image and crop image using transform option.
- Click replace button.
- Image selection popover won't open.

After this commit:
- The "preserveCursor" method has been used to maintain the cursor
state because transform option was losing cursor selection.

task-3930743

Forward-Port-Of: odoo/odoo#167338

Invoice extraction now supports the latest OCR response format, where invoice line details are returned more directly. This keeps automated invoice processing compatible with the updated OCR service and helps maintain accuracy for accounting and purchasing workflows.

The OCR now returns invoice lines as direct values, no longer using the `feature_result` construct. This commit updates the handling of invoice lines to reflect these changes.

The Helpdesk ticket card menu no longer shows an Edit option. This reduces menu clutter because users can already open and update a ticket by clicking the card itself.

Before this commit, the `Edit` button is displayed in the menu of the kanban card of helpdesk ticket. This button is not really useful since the user can easily go to the form view of ticket by clicking on the kanban card.

This commit removes `Edit` button in the kanban card menu of helpdesk ticket since that button is not really useful.

task-4262236

The project list now shows the regular project name when there is only one company, or when Field Service is not installed. This keeps the list easier to sort while still showing company details when they are useful in multi-company Field Service setups.

In the project list view, instead of displaying the name, we use the display_name so that we can show the company name for fsm projects.
However, since it is a computed field, it has the drawback of not being sortable.

To alleviate this, this PR will use the name instead if there is only one company in the context or if Field Service is not installed.

Task-3942760

WhatsApp message templates with the same priority are now shown with the most recently updated templates first. This makes it easier for users to find and work with the templates that were changed most recently.

The templates who has the same sequence number should be
sorted based on their most recent update date.

task-3794427

Planning users can now open the resource form while creating or editing resources, making it easier to choose the right resource type. This avoids automatically creating an employee for material resources and reduces cleanup work.

### Before this PR:
Before this change, creating a resource would automatically result in the creation of an associated employee, which users needed to delete if creating a material resource.

### After this PR:
Now, users can directly access the resource view to specify the resource type and make necessary adjustments, avoiding unnecessary steps and enhancing workflow efficiency.

task-4027561

The subscription stock forecast report now handles warehouse information in one consistent way, whether there is one warehouse or several. This simplifies the underlying logic and helps keep future maintenance easier without changing the user workflow.

In this PR
========================

1. For the forecast report, always pass warehouses as a list, regardless of whether it's one or more. This reduces unnecessary code and simplifies the logic.

The main goal is to clean this PR: https://github.com/odoo/enterprise/pull/69760

TaskId :4214109

This fix corrects a report generation method name for GSTR-1 and updates the GSTR-2B status spelling from "recived" to "received". It helps avoid confusion and potential errors when handling Indian GST return periods.

This **PR**, rectifies method name for GSTR-1 report generation and corrects GSTR-2B status spelling from 'recived' to 'received'.

**task**-4306959

**Upgrade PR** - https://github.com/odoo/upgrade/pull/6717

This update cleans up internal import and export usage across several Odoo apps to align with newer core standards. It should not change day-to-day workflows, but it improves maintainability and reduces future upgrade risk across accounting, payroll, appointments, delivery, documents, helpdesk, field service, IoT, and localization areas.

odoo/odoo#184928

The Point of Sale codebase has been reorganized so service-related files are grouped into clearer dedicated folders. This is an internal cleanup that should make future maintenance easier without changing day-to-day user workflows.

Reorganization of all `services` files into a specific folder.

task-id: 4290514

This update cleans up and modernizes automated tests across several Odoo Enterprise areas, including messaging, VoIP, and grid views. It helps make internal quality checks more reliable and easier to maintain, with no direct change expected for day-to-day users.

## Pull Request HOOT (PRHOOT) - part 26

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328
Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657
Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767
Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895
Part 21: https://github.com/odoo/odoo/pull/174337
Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721
Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728
Part 24: https://github.com/odoo/odoo/pull/181971
Part 25: https://github.com/odoo/odoo/pull/183358

Community: https://github.com/odoo/odoo/pull/183921

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This commit adds voice information to attachments while creating attachments received from meta side. This will let the users play voice messages directly from the discuss channel. Task-3839838 Forward-Port-Of: odoo/enterprise#73364 Forward-Port-Of: odoo/enterprise#73291

This commit adds voice information to attachments
while creating attachments received from meta
side. This will let the users play voice messages
directly from the discuss channel.

Task-3839838

Forward-Port-Of: odoo/enterprise#73364
Forward-Port-Of: odoo/enterprise#73291

Issue: A traceback occurs when attempting to create an invoice or sales order for a customer whose fiscal position is set to Automatic Tax Mapping in Brazilian accounting. ```python File "/home/odoo/src/enterprise/account_external_tax/models/account_move.py", line 18, in _compute_tax_totals subtotal = tax_totals['subtotals'][0] ~~~~~~~~~~~~~~~~~~~~~~~^^^ IndexError: list index out of range ``` Steps to reproduce: - Have Brazilian localization (including EDI modules) with Avatax config

Issue: A traceback occurs when attempting to create an invoice or sales order for a customer whose fiscal position is set to Automatic Tax Mapping in Brazilian accounting.

```python
File "/home/odoo/src/enterprise/account_external_tax/models/account_move.py", line 18, in _compute_tax_totals subtotal = tax_totals['subtotals'][0]
~~~~~~~~~~~~~~~~~~~~~~~^^^
IndexError: list index out of range
```

Steps to reproduce:
- Have Brazilian localization (including EDI modules) with Avatax configuration.
- Create a new Sales Order or Invoice and:
  - Use a contact with a fiscal position set to "Automatic Tax Mapping (Avalara Brazil)", or
  - Set the fiscal position to that on the SO or invoice itself.
- Observe the traceback as described in the ticket.

Explanation: In account_move/sale_order from the modules account_external_tax/sale_external_tax, the method _compute_tax_totals attempted to compute the tax totals when there were no account move lines (tax_totals['subtotals'] is empty), which results in an "out of range" traceback. The Brazilian Automatic Tax Mapping is computed externally, which is why it triggered this issue.

opw-4256191

Forward-Port-Of: odoo/enterprise#72611

Before this commit, if a user didn't remove the prepared orders from the preparation display, all orders would be displayed even after closing and opening a new session. This could cause rendering issues due to the large number of orders. opw-4295258 Forward-Port-Of: odoo/enterprise#73235

Before this commit, if a user didn't remove the prepared orders from the preparation display, all orders would be displayed even after closing and opening a new session. This could cause rendering issues due to the large number of orders.

opw-4295258

Forward-Port-Of: odoo/enterprise#73235

As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/enterprise#73014 Forward-Port-Of: odoo/enterprise#71676

As Debian wants to remove pypdf2 and keep only pypdf (4.3) in
trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian.

Forward-Port-Of: odoo/enterprise#73014
Forward-Port-Of: odoo/enterprise#71676

The issue: The child of the server action "Ask for Validation, Add Tag Draft" should be named "Remove Tag Draft." How to reproduce the issue: - Go to Server Actions: Search for “Ask for validation”. - Open “Add tag draft” child action opw-4281732 Forward-Port-Of: odoo/enterprise#73142

The issue:
The child of the server action "Ask for Validation, Add Tag Draft" should be named "Remove Tag Draft."

How to reproduce the issue:
- Go to Server Actions: Search for “Ask for validation”.
- Open “Add tag draft” child action

opw-4281732

Forward-Port-Of: odoo/enterprise#73142

Problem: When rental dates are changed in the cart, the update occurs via an API call, which doesn't trigger the `_onchange_rental_start_date` and `_onchange_rental_return_date` methods. Additionally, we cannot add `rental_return_date` and `rental_start_date` as dependencies for `_compute_name` as outlined in this [commit](https://github.com/odoo/enterprise/commit/de5f3c7521d839e7549f5d44c7832e610fad7f29). Solution: Recompute the description after changing the dates in `_cart_update_renting

Problem:
When rental dates are changed in the cart, the update occurs via an API call, which doesn't trigger the `_onchange_rental_start_date` and `_onchange_rental_return_date` methods. Additionally, we cannot add `rental_return_date` and `rental_start_date` as dependencies for `_compute_name` as outlined in this [commit](https://github.com/odoo/enterprise/commit/de5f3c7521d839e7549f5d44c7832e610fad7f29).

Solution:
Recompute the description after changing the dates in `_cart_update_renting_period`


Steps to reproduce:
- Add any rental product to the cart.
- On the cart page, modify the rental start and end dates.
- The order description does not update to reflect the new dates.

opw-4259443

Forward-Port-Of: odoo/enterprise#72201

When an onboarding error occurred, the error page failed to render and the user would see "Internal Server Error" instead of a more helpful error message. The server error had two causes: - The original onboarding error not being properly cast to a string. - The onboarding return route not passing the lang code to the QWeb context. Forward-Port-Of: odoo/enterprise#71987

When an onboarding error occurred, the error page failed to render and the user would see "Internal Server Error" instead of a more helpful error message.

The server error had two causes:
- The original onboarding error not being properly cast to a string.
- The onboarding return route not passing the lang code to the QWeb context.

Forward-Port-Of: odoo/enterprise#71987

With a BR Company Setup: Settings > Website, assign 'My Website' to BR Company Configure Avatax Brazil in General Settings > Taxes > Avatax Publish the Product "Regular Consumable Product" to be available in the website. Open the web shop as Public User Add "Regular Consumable Product" to cart Go to checkout Fill valid Brazilian customer info Pay Issue: Error will popup ``` odoo.http: Odoo could not fetch the taxes related to S00040. It is not possible identify the CFOP ``` Thi

With a BR Company Setup:
Settings > Website, assign 'My Website' to BR Company
Configure Avatax Brazil in General Settings > Taxes > Avatax
Publish the Product "Regular Consumable Product" to be available in the website.
Open the web shop as Public User
Add "Regular Consumable Product" to cart
Go to checkout
Fill valid Brazilian customer info
Pay

Issue: Error will popup
```
odoo.http: Odoo could not fetch the taxes related to S00040.
It is not possible identify the CFOP
```

This occurs because the sales order is missing the "Goods Operation Type"
and the call to Avatax is not done

opw-4239483

Forward-Port-Of: odoo/enterprise#72966

"Title Suggested features for your new model" pop-up is not well aligned. After the upgrade to bootstrap 5.3, the variable is declared in the .model ( https://github.com/odoo/odoo/blame/63e09a452d7724b6e844c5b0229c95e36f39ea61/addons/web/static/lib/bootstrap/scss/_modal.scss#L25-L27 ) while in web_studio we're only using 'model-header' Task-4072763 Forward-Port-Of: odoo/enterprise#73252 Forward-Port-Of: odoo/enterprise#72196

"Title Suggested features for your new model" pop-up is not well aligned. After the upgrade to bootstrap 5.3, the variable is declared in the .model ( https://github.com/odoo/odoo/blame/63e09a452d7724b6e844c5b0229c95e36f39ea61/addons/web/static/lib/bootstrap/scss/_modal.scss#L25-L27 ) while in web_studio we're only using 'model-header'

Task-4072763

Forward-Port-Of: odoo/enterprise#73252
Forward-Port-Of: odoo/enterprise#72196

Collection of small shop floor fixes for v17. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#73095 Forward-Port-Of: odoo/enterprise#70704

Collection of small shop floor fixes for v17.
Please refer to the individual feature commits for details.

Forward-Port-Of: odoo/enterprise#73095
Forward-Port-Of: odoo/enterprise#70704

…anys Have a ir.default that sets one line into a one2many on some models. In studio, edit the form view of the main model, then navigate to edit the one2many, with the ir.default having been triggered (there is one virual line in the one2many). Before this commit there was a crash because "false" is not a valid id for the staticlist. After this commit, there is no crash, and the virtual record doesn't appear. opw-4289233 Forward-Port-Of: odoo/enterprise#73260 Forward-Port-Of: odoo/

…anys

Have a ir.default that sets one line into a one2many on some models. In studio, edit the form view of the main model, then navigate to edit the one2many, with the ir.default having been triggered (there is one virual line in the one2many).

Before this commit there was a crash because "false" is not a valid id for the staticlist.

After this commit, there is no crash, and the virtual record doesn't appear.

opw-4289233

Forward-Port-Of: odoo/enterprise#73260
Forward-Port-Of: odoo/enterprise#73220

**Steps to reproduce:** - Install l10n_pk_reports - Switch to a Pakistani company (e.g. PK Company) - Create a Journal entry crediting an account of "Other Income" type (e.g. 3112003 Misc Income) - Post the journal entry - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Select "Profit and Loss (PK)" report **Issue:** The created journal entry is negative in the "Other Income" section and its value is subtracted from "Gross Profit" section, reducing "Profit of the

**Steps to reproduce:**
- Install l10n_pk_reports
- Switch to a Pakistani company (e.g. PK Company)
- Create a Journal entry crediting an account of "Other Income" type (e.g. 3112003 Misc Income)
- Post the journal entry
- Go to "Accounting / Reporting / Statement Reports / Profit and Loss"
- Select "Profit and Loss (PK)" report

**Issue:**
The created journal entry is negative in the "Other Income" section and its value is subtracted from "Gross Profit" section, reducing "Profit of the Year" section, which is not correct. On the other hand, if the normal "Profit and Loss" report is selected, the created journal entry is positive and its value is added to "Gross Profit" section, increasing "Net Profit" section, which is correct.

opw-4185212

Forward-Port-Of: odoo/enterprise#73272
Forward-Port-Of: odoo/enterprise#72378

*l10n_fr_fec_import,l10n_fr_reports Related to https://github.com/odoo/odoo/pull/185817 Forward-Port-Of: odoo/enterprise#73167 Forward-Port-Of: odoo/enterprise#73048

*l10n_fr_fec_import,l10n_fr_reports

Related to https://github.com/odoo/odoo/pull/185817

Forward-Port-Of: odoo/enterprise#73167
Forward-Port-Of: odoo/enterprise#73048

To reproduce the bug: 1. Install the subscription feature on your website. 2. Create a second company and link it to the website. 3. Create a recurring product with the service type. 4. In the subscription app, create a quotation with the specified product. 5. Preview the invoice for the quotation. 6. Copy the link for the portal invoice and open it in an incognito window. 7. Pay the invoice. You will encounter a TraceBack error depending on the modules installed. This is due to the

To reproduce the bug:

1. Install the subscription feature on your website.
2. Create a second company and link it to the website.
3. Create a recurring product with the service type.
4. In the subscription app, create a quotation with the specified product.
5. Preview the invoice for the quotation.
6. Copy the link for the portal invoice and open it in an incognito window.
7. Pay the invoice.

You will encounter a TraceBack error depending on the modules installed. This is due to the `company_id` being set to an empty record as a result of how it is computed here:

https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_move.py#L696-L698

In our case, `move.journal_id.company_id` (the invoice company) exists, so `self.env.company` (the website company) gets ignored. However, since the public user of the website doesn't have access to the invoice company, the `company_id` is set to an empty record after checking the access rights with `._accessible_branches()[:1]`.

opw-3999546

Forward-Port-Of: odoo/enterprise#71404
Forward-Port-Of: odoo/enterprise#68034

In this commit: === - Removed the XML data file for creating the discount product. - Added logic to create the discount product in Python, directly where the existing discount product is searched. - Implemented a check to first search for the discount product, and only create it if it does not already exist. Forward-Port-Of: odoo/enterprise#72981

In this commit:
===
- Removed the XML data file for creating the discount product.
- Added logic to create the discount product in Python, directly where the existing discount product is searched.
- Implemented a check to first search for the discount product, and only create it if it does not already exist.

Forward-Port-Of: odoo/enterprise#72981

In this commit: === - Discounts for online delivery orders are now handled. - Tax is now applied to charges (e.g., packaging charges). - The rider_status_updated payload has been updated. task-4075113 Forward-Port-Of: odoo/enterprise#72458

In this commit:
===
- Discounts for online delivery orders are now handled.
- Tax is now applied to charges (e.g., packaging charges).
- The rider_status_updated payload has been updated.


task-4075113

Forward-Port-Of: odoo/enterprise#72458

This update addresses a security vulnerability by preventing the ‘knowledge’ module from directly accessing localStorage and sessionStorage within the browser. This change reduces the risk of unauthorized data access and improves the overall security posture of the Odoo Enterprise platform. It’s a routine maintenance update focused on security best practices.

…directly

Forward-Port-Of: odoo/enterprise#73113

This update resolves an issue where Helpdesk teams weren't displaying all relevant non-billable projects in their dropdown menus. The fix ensures that projects are correctly identified regardless of billing settings, and also corrects a bug where disabling Time Billing kept projects in an unexpected state. This improves team efficiency and data accuracy.

### Current behavior before PR:
When creating a Helpdesk team and the Timesheets option enabled and Time Billing disabled you will not get all non-billed projects in the dropdown menu. This is happening because the domain for project_id is checking the company_id to be the same as the company_id of the team.
https://github.com/odoo/enterprise/blob/18.0/helpdesk_sale_timesheet/models/helpdesk_team.py#L10 Though since this commit https://github.com/odoo-dev/odoo/commit/16a07ed1bfd33a193b363f3e87aab3f9bd6f8bd0 company_id is not required for projects. Since the domain of the project_id field was introduced here https://github.com/odoo/enterprise/pull/4956/commits/c82b1b019cebd1f78749b9563e717fae88d7fae5 and the reason why we check the company_id is not the same anymore since the commit I mentioned above we should not use the same domain.

Also in this PR we are solving another issue which is where you enable both Timesheets and Time Billing options and choose a project that has both options enabled too then you disable the Time Billing option for the team the project that we chose before will be kept and have both options enabled and you can save it.

### Desired behavior after PR is merged:
We are now checking for the project of the team if the company_id is False or equal to the team's company_id.

Also when disbaling the Time Billing option we set the project_id to False.

opw-4275647
opw-4148207

This update fixes an issue where duplicated shifts didn't correctly calculate allocated hours for different employees. Previously, duplicated shifts would incorrectly show 8 hours instead of the expected hours based on the employee's working schedule. This ensures accurate shift planning and time tracking.

Steps to reproduce:
-------------------
1. Install Planning app
2. Have an employee A with 40h/week working schedule and an employee B with 35h/week working schedule
3. Create a shift and assign it to employee A, the default allocated hours should be 8h
4. From the Gantt view, duplicate this shift and assign it to employee B (use drag and drop)
5. Problem: The allocated hours of the duplicated shift are not recomputed, they are equal to 8h instead of 7h

Fix:
-------------------
When duplicating a shift and assigning it to another resource, the copy() method is called with the resource_id of the target resource (an employee in this case). But _compute_allocated_hours() is not called so we have to call it explicitly in this case.

version-17.0
task-3978590

This update resolves a bug where the 'release_to_pay' field in invoices was incorrectly reverting to 'Yes' after saving, even when set to 'No'. This issue prevented accurate payment processing. The fix ensures the field's value is correctly saved based on user selections.

**Steps to reproduce:**
- Install account_3way_match
- Go to "Invoicing / Vendors / Bills"
- Create a bill
- (Edit the view in order to display "release_to_pay" field)
- (Make sure that "Force Status" (force_release_to_pay) is always checked)
- Set "Should Be Paid" (release_to_pay_manual) to "Yes" => "release_to_pay" becomes "Yes"
- Save the bill => "release_to_pay" stays "Yes"
- Change "Should Be Paid" to "No" => "release_to_pay" becomes "No"
- Save the bill => "release_to_pay" reverts to "Yes"

**Issue:**
Upon save, "release_to_pay" reverts to "Yes", even if it has been correctly computed to "No" before saving.

opw-4181752

Forward-Port-Of: odoo/enterprise#72190

This update resolves an issue where the 'Requests to switch' filter incorrectly identified future shifts as past, due to timezone discrepancies. The fix ensures shifts are accurately displayed based on their actual time, regardless of the user's location, improving scheduling accuracy.

The 'Requests to switch' filter is supposed to show slots that are unwanted and that are not in the past.

Prior to this commit, some shifts that were in the future were not shown by the filter.

That was because the planning.slot field end_datetime was encoded in UTC while the datetime.datetime.now() function in the filter's domain was returning the datetime in the client's timezone. Shifts in the time difference between the user's timezone and UTC would be mistakenly marked as "past shifts" while they might still be in the future.

We fix this by using the 'to_utc()' function which should make the filter domain's comparisson between 2 UTC datetimes.

Fix done in 17.0

task-4286161