Have a node that goes: ```xml <div groups="!module.some_group" /> ``` Before this commit, this case was not handled and that not-group was just ignored. This created confusion as the node, when the user was part of the group, would be invisible, the checkbox invisible would be ticked, and uniticking it had no effect. After this commit, we handle the case, with a second selector in the studio sidebar. opw-4273853 Forward-Port-Of: odoo/enterprise#73233

Have a node that goes:
```xml
<div groups="!module.some_group" />

```

Before this commit, this case was not handled and that not-group was just ignored.

This created confusion as the node, when the user was part of the group, would be invisible, the checkbox invisible would be ticked, and uniticking it had no effect.

After this commit, we handle the case, with a second selector in the studio sidebar.

opw-4273853

Forward-Port-Of: odoo/enterprise#73233

Steps to reproduce: - New product > Storable; Recurring; Edit 'On Hand Quantity' to 10 - New subscription > Add your product > Confirm - Create Invoice > Confirm > Back to sub - View forecast on order line > 1 reserved; 1 forecasted for next period (This is correct, the subscription is ongoing) - Renew > Confirm > View forecast - 1 reserved for original sub (OK); 2 forecasted for next period This is wrong because renewed subscriptions should no longer have recurring invoices, meaning th

Steps to reproduce:
- New product > Storable; Recurring; Edit 'On Hand Quantity' to 10
- New subscription > Add your product > Confirm
- Create Invoice > Confirm > Back to sub
- View forecast on order line > 1 reserved; 1 forecasted for next period (This is correct, the subscription is ongoing)
- Renew > Confirm > View forecast
- 1 reserved for original sub (OK); 2 forecasted for next period

This is wrong because renewed subscriptions should no longer have recurring invoices, meaning there is no reason to forecast a stock decrease for them. i.e here it should only forecast 1 unit for the next period corresponding to our new subscription (Created by renew).

Prior to 17.0 a storable product cannot also be recurring, so this issue is irrelevant there.

opw-4239989

Forward-Port-Of: odoo/enterprise#72397

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

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