Currently the top line of a combo product is always showing a 0$ price. Steps to reproduce: ------------------- * Open a POS Shop session * Add a combo product, confirm selection choices > Observation: The first order line representing the combo product will show a price of 0$ Why the fix: ------------ In saas-17.3 the price is not shown on the combo parent line anymore to avoid any confusion. Discussed with the PO and he asked to put this in 17.0 as well if possible. Here is the

Currently the top line of a combo product is always showing a 0$ price.

Steps to reproduce:
-------------------
* Open a POS Shop session
* Add a combo product, confirm selection choices
> Observation: The first order line representing the combo product will
show a price of 0$

Why the fix:
------------
In saas-17.3 the price is not shown on the combo parent line anymore to avoid any confusion. Discussed with the PO and he asked to put this in 17.0 as well if possible.

Here is the commit that did the change in saas-17.3: https://github.com/odoo/odoo/commit/72267340663e47581d42f46deded6830c72fbda3

Slight change as in saas-17.3 `combo_line_ids` is always a list, empty or not and in 17.0 if you have a simple product, `combo_line_ids` will be `undefined`.

opw-3942339

Forward-Port-Of: odoo/odoo#169587

Use case: - LOT A 20 units in stock - LOT B 20 units in stock - Do an outgoing picking for 10 units - Reserve - Remove the `stock.move.line` - Add a new line of B Current behavior: Line is prefilled for 20 units Expected: Line only takes the 10 units missing It's due to commit [1] enforcing the computation on the origin move and not the current situation [1] commit 383d4eb98ba4bfbcb384b3d1ee27393da00226e7 Description of the issue/feature this PR addresses: Current beha

Use case:
- LOT A 20 units in stock
- LOT B 20 units in stock
- Do an outgoing picking for 10 units
- Reserve
- Remove the `stock.move.line`
- Add a new line of B

Current behavior:
Line is prefilled for 20 units

Expected:
Line only takes the 10 units missing

It's due to commit [1] enforcing the computation
on the origin move and not the current situation

[1] commit 383d4eb98ba4bfbcb384b3d1ee27393da00226e7

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

reverts e6c55e1683d679efd12e7d1cfca85b736fcbea01 We notice too many usability issues as a result of this commit. As it was stated that the security concerns were not that bad we let users delete any mail attachment they may find necessary. task-3983664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169925 Forward-Port-Of: odoo/odoo#168832

reverts  e6c55e1683d679efd12e7d1cfca85b736fcbea01

We notice too many usability issues as a result of this commit.

As it was stated that the security concerns were not that bad we let users delete any mail attachment they may find necessary.

task-3983664

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

Forward-Port-Of: odoo/odoo#169925
Forward-Port-Of: odoo/odoo#168832

When an image is set to a cover from the website builder, this commit will automatically convert it to webp. task-3761728 Forward-Port-Of: odoo/odoo#169822 Forward-Port-Of: odoo/odoo#156554

When an image is set to a cover from the website builder, this commit will automatically convert it to webp.

task-3761728

Forward-Port-Of: odoo/odoo#169822
Forward-Port-Of: odoo/odoo#156554

**Current behavior:** Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures. **Expected behavior:** The lines generated in this manner should look like ones created when the valuation is generated for a product that was already valuated with the automated option. **Steps to reproduce:** 1. Create a product category with the default manual valuation method, create a storable

**Current behavior:**
Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures.

**Expected behavior:**
The lines generated in this manner should look like ones created when the valuation is generated for a product that was already valuated with the automated option.

**Steps to reproduce:**
1. Create a product category with the default manual valuation method, create a storable product that belongs to it

2. Sell some quantity of the new product without adding any on-hand quantity (so that the qty is negative), confirm the order and generate the invoice

3. Swap to automated valuation in the product category that was created in step 1

4. In the entries for the stock valuation journal, observe that:
     A) the stock valuation account is getting *debited* instead of credited, and

     B) the other entry generated is for the stock input account
          instead of stock output, and

     C) the debit/credit amounts should be swapped here as well

**Cause of the issue:**
The negative quantity case is not considered when we do the empty/replenish sequence on valuation method change.

**Fix:**
Add an explicit check for negative quantity in the replenish step of changing valuation method.

opw-3810779

Forward-Port-Of: odoo/odoo#169601
Forward-Port-Of: odoo/odoo#165179

When two pickings have a reservation date in the past the reservation give the priority to the move with the smallest reservation_date (reserve x days before date on picking type). However it's not very obvious for the end user and using the date of the move seems a better idea. ALso the forecast report doesn't respesct the reservation_date in its forecat. Reconcile correctly the move base on their reservation date. Task-3530930 closes odoo/odoo#146643 Description of the issue/featur

When two pickings have a reservation date in the past the reservation give the priority to the move with the smallest reservation_date (reserve x days before date on picking type). However it's not very obvious for the end user and using the date of the move seems a better idea.

ALso the forecast report doesn't respesct the reservation_date in its forecat. Reconcile correctly the move base on their reservation date.

Task-3530930

closes odoo/odoo#146643

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

Due to legal considerations, it is necessary to modify the template for certain fields. We also fix the display of differents values because it was not corretcly displayed. Additionally, rectifications have been made to accurately display various values that were previously incorrect. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148155

Due to legal considerations, it is necessary to modify the template for certain fields.

We also fix the display of differents values because it was not corretcly displayed. Additionally, rectifications have been made to accurately display various values that were previously incorrect.

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

Forward-Port-Of: odoo/odoo#148155

The tour is not actually ran in this version, and is blocked before in other versions. We should fix it in an other PR. This typo causes a check on available steps to fail in master. runbot-68355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169973 Forward-Port-Of: odoo/odoo#169646

The tour is not actually ran in this version, and is blocked before in other versions.
We should fix it in an other PR.
This typo causes a check on available steps to fail in master.

runbot-68355




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

Forward-Port-Of: odoo/odoo#169973
Forward-Port-Of: odoo/odoo#169646

Versions -------- - 15.0+ Steps ----- 1. Go to Sale / Configuration / Units of Measure Categories; 2. go to Working Time; 3. set rounding precision of Hours to 1.0; 4. create a SO, selling 10 hours of timesheeted service; 5. click confirm; 6. add 9.1 hours to a timesheet for the SO. Issue ----- The sale order line displays 9 hours delivered, while a smart button displays 10 hours recorded. Cause ----- The smart button displays the value of the `timesheet_total_duration` fie

Versions
--------
- 15.0+

Steps
-----
1. Go to Sale / Configuration / Units of Measure Categories;
2. go to Working Time;
3. set rounding precision of Hours to 1.0;
4. create a SO, selling 10 hours of timesheeted service;
5. click confirm;
6. add 9.1 hours to a timesheet for the SO.

Issue
-----
The sale order line displays 9 hours delivered, while a smart button displays 10 hours recorded.

Cause
-----
The smart button displays the value of the `timesheet_total_duration` field, this field gets computed with `_compute_quantity` method of `uom.uom`, which defaults to the `UP` rounding method:
https://github.com/odoo/odoo/blob/b724fbcf6f348ed7a9109a325d366be69c052d1c/addons/uom/models/uom_uom.py#L216

In contrast, the SOL displays the result of `_get_delivered_quantity_by_analytic`, which uses the same `uom.uom` method, but with the `HALF-UP` rounding method: https://github.com/odoo/odoo/blob/b724fbcf6f348ed7a9109a325d366be69c052d1c/addons/sale/models/sale_order_line.py#L387

Solution
--------
Modify the `_compute_timesheet_total_duration` methods of `account.move` and `sale.order` to use the same rounding method as the `_get_delivered_quantity_by_analytic` method.

opw-3949986

Forward-Port-Of: odoo/odoo#169900
Forward-Port-Of: odoo/odoo#167607

Current behavior: When the restaurant is opened and "Self Ordering" is set to "QR menu", the banner "We're currently closed." is shown. Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" module - Start a restaurant session and go to the backend - In the settings, set "Self Ordering" to "QR menu" and save - Click on "Preview Web interface" - Problem: The banner is shown Solutions: Display the banner if the session is not opened rather than when we have a token (in

Current behavior:
When the restaurant is opened and "Self Ordering" is set to "QR menu", the banner "We're currently closed." is shown.

Steps to reproduce:
- Install "Point of Sale" app and "pos_restaurant" module
- Start a restaurant session and go to the backend
- In the settings, set "Self Ordering" to "QR menu" and save
- Click on "Preview Web interface"
- Problem: The banner is shown

Solutions:
Display the banner if the session is not opened rather than when we have a token (in mode "QR menu", there is no token)

opw-3854839


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

Forward-Port-Of: odoo/odoo#169618

During a fw-port, an error was made and the "or" became an "and". This fixes it, to hide the tab if the move is not from a polish company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168502

During a fw-port, an error was made and the "or" became an "and". 
This fixes it, to hide the tab if the move is not from a polish company.




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

Forward-Port-Of: odoo/odoo#168502

The certificate issuer name in the Factura-e XML needs to be formatted in a very specific way. Else it fails the validators of the Basque Region in Spain. This commit changes the format to be the same as in module l10n_es_edi_tbai . task-3990176 Forward-Port-Of: odoo/odoo#169609

The certificate issuer name in the Factura-e XML needs to be formatted in a very specific way. Else it fails the validators of the Basque Region in Spain.

This commit changes the format to be the same as in module l10n_es_edi_tbai .

task-3990176

Forward-Port-Of: odoo/odoo#169609

### Steps to reproduce: - Enable Batch Transfers in the settings - Go to Inventory > Config> Warehouse Management > Operation Types - On receipts, enable "Automatic Batches" group by contact - Create and confirm a purchase order for any contact with: - 1 X storable product P1 - Create and confirm a purchase order for the same contact with: - 1 X storable product P1 - 1 x storable product P2 - Go to the assocated stock picking > change the quantity of P1 to 0 - Validate and cre

### Steps to reproduce:

- Enable Batch Transfers in the settings
- Go to Inventory > Config> Warehouse Management > Operation Types
- On  receipts, enable "Automatic Batches" group by contact
- Create and confirm a purchase order for any contact with:
  - 1 X storable product P1
- Create and confirm a purchase order for the same contact with:
  - 1 X storable product P1
  - 1 x storable product P2
- Go to the assocated stock picking > change the quantity of P1 to 0
- Validate and create a backorder

#### > invalid operation: The following transfers cannot be added to batch

### Cause of the issue:

When the backorder is processed, the stock picking that currently belongs to our batch is validated and a backorder is created: https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock/models/stock_move.py#L1891-L1892 The picking associated to this backorder is then added to our batch https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking.py#L160-L162 But for this action to be performed, we need to pass the sanity check verifying that the pickings associated to our batch are allowed: https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking_batch.py#L282-L286 And here comes the problem, the picking that created the backorder was not yet removed from our batch but is not allowed anymore since it is now in 'done' state:
https://github.com/odoo/odoo/blob/f168c4ba9d64a05a4a55715c44016a15230fe706/addons/stock_picking_batch/models/stock_picking_batch.py#L76-L77

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

Forward-Port-Of: odoo/odoo#163935

Before this commit, the restricted editor would see the "Edit" button regardless of the current language. This led to unpredictable results: no editable content, editing the source, or editing the translation. Now, we display the correct buttons for translating and editing. Previously, if you edited a blog in French while your website's default language was English, it would overwrite the French source instead of translating it. Now, it correctly translates the content. Forward-Port-O

Before this commit, the restricted editor would see the "Edit" button
regardless of the current language. This led to unpredictable results:
no editable content, editing the source, or editing the translation.

Now, we display the correct buttons for translating and editing.

Previously, if you edited a blog in French while your website's default
language was English, it would overwrite the French source instead of
translating it. Now, it correctly translates the content.

Forward-Port-Of: odoo/odoo#169458

Before commit: When creating an expense through an email alias, it can sometimes have no product_id set. This usually causes a clean error message to pop up, but here there was a traceback due to the use of product_uom_id.rounding before we get to show the error message After commit: The traceback is solved and the correct error message is shown opw-3921278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165552

Before commit:
When creating an expense through an email alias, it can sometimes have no product_id set.  This usually causes a clean error message to pop up, but here there was a traceback due to the use of product_uom_id.rounding before we get to show the error message

After commit:
The traceback is solved and the correct error message is shown

opw-3921278

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

Forward-Port-Of: odoo/odoo#165552

This commit import payment_token file in __init__ which was missed by [1] PR to properly execute it's code and do not return any token for express checkout. [1]: https://github.com/odoo/odoo/pull/107788 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#169942

This commit import payment_token file in __init__
which was missed by [1] PR to properly execute
it's code and do not return any token for express
checkout.

[1]: https://github.com/odoo/odoo/pull/107788

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

Previous implementation checked if a folder was empty before removing it. However, it didn't take into account cases where one folder is empty but there are non-empty subfolders inside. Removing the parent folder triggered an error. The new implementation recursively checks the subfolders to ensure their emptiness before trying to remove the parent folder. Forward-Port-Of: odoo/enterprise#62184 Forward-Port-Of: odoo/enterprise#61649

Previous implementation checked if a folder was empty before removing it. However, it didn't take into account cases where one folder is empty but there are non-empty subfolders inside. Removing the parent folder triggered an error.

The new implementation recursively checks the subfolders to ensure their emptiness before trying to remove the parent folder.

Forward-Port-Of: odoo/enterprise#62184
Forward-Port-Of: odoo/enterprise#61649

Before this commit only admin can add pivot in dashbord. <img width="680" alt="image" src="https://github.com/odoo/enterprise/assets/16716992/a301451f-1bf1-42f7-81fa-d93ab9223d05"> Forward-Port-Of: odoo/enterprise#65048

Before this commit only admin can add pivot in dashbord.

<img width="680" alt="image" src="https://github.com/odoo/enterprise/assets/16716992/a301451f-1bf1-42f7-81fa-d93ab9223d05">

Forward-Port-Of: odoo/enterprise#65048

reverts [1] as [2] was reverted and it is no longer needed. As some side effects were noticed and there may be more too subtle to find during manual tour testing. task-3983664 1: a187b096ceca1e0335f86f23469894c11f9b983b 2: e6c55e1683d679efd12e7d1cfca85b736fcbea01 Forward-Port-Of: odoo/enterprise#64937 Forward-Port-Of: odoo/enterprise#64478

reverts [1] as [2] was reverted and it is no longer needed. As some side effects were noticed and there may be more too subtle to find during manual tour testing.

task-3983664

1: a187b096ceca1e0335f86f23469894c11f9b983b

2: e6c55e1683d679efd12e7d1cfca85b736fcbea01

Forward-Port-Of: odoo/enterprise#64937
Forward-Port-Of: odoo/enterprise#64478

Current behavior in gstr1 report: - For invoices and credit notes, if there are nil rated tax grid journal items then these tax lines are considered in both GSTR summary tables i.e self category (b2b/b2c) table and nil category table. After fix: - Now, the journal items are considered for their respective GSTR summary tables only. - For, `special economic zone` the nil-rated journal items are considered in their category i.e b2b/b2cs/b2cl, not in the nil summary table. task-3866787 Fo

Current behavior in gstr1 report:
- For invoices and credit notes, if there are  nil rated tax grid journal items then these tax lines are considered in both GSTR summary tables i.e self category (b2b/b2c) table and nil category table.

After fix:
- Now, the journal items are considered for their respective GSTR summary tables only.
- For, `special economic zone` the nil-rated journal items are considered in their category i.e b2b/b2cs/b2cl, not in the nil summary table.

task-3866787

Forward-Port-Of: odoo/enterprise#61433

…ter its parent web_enterprise modifies the js template for the list_renderer by introducing an upsell point for Studio in the optional columns dropdown. That inheritance spec was not at any particular place in the inheritance hierarchy. On some views (e.g. account invoices) this feature was not available. This commit fixes the issue by manually forcing the extension in web_enterprise to go just after list_renderer.xml from the web module. After this commit, the upsell feature is ava

…ter its parent

web_enterprise modifies the js template for the list_renderer by introducing an upsell point for Studio in the optional columns dropdown.

That inheritance spec was not at any particular place in the inheritance hierarchy. On some views (e.g. account invoices) this feature was not available.

This commit fixes the issue by manually forcing the extension in web_enterprise to go just after list_renderer.xml from the web module.

After this commit, the upsell feature is available on the views that did not have it before.

Forward-Port-Of: odoo/enterprise#64875
Forward-Port-Of: odoo/enterprise#64776

In anticipation of Version 17 certification, multiple adjustments were required. The option to reprint tickets has been eliminated from the tip screen. Furthermore, the functionality on this screen has been rectified to enable the invoicing of previously non-invoiced orders. Previously, this action was not feasible when an order was placed using a blackbox. This commit also involves alterations to values within the sale details template. Moreover, steps have been taken to guarantee the precis

In anticipation of Version 17 certification, multiple adjustments were required. The option to reprint tickets has been eliminated from the tip screen. Furthermore, the functionality on this screen has been rectified to enable the invoicing of previously non-invoiced orders. Previously, this action was not feasible when an order was placed using a blackbox.

This commit also involves alterations to values within the sale details template. Moreover, steps have been taken to guarantee the precision of sequences for both pro forma and standard sales.

We've now enabled the option to cancel orders that were previously restricted.

Forward-Port-Of: odoo/enterprise#53654

When timezone of user is empty and the user clicks on Add a Leave button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save - Install 'Appointments' - Go to Appointments > Schedule > Resource Bookings > Add a Leave Traceback: ``` AttributeError: 'bool' object has no attribute 'upper' File "odoo/http.py", line 2254, in __call__ response = request._serve_db() File "odoo/http.py", line 1829, in _serve_db

When timezone of user is empty and the user clicks on Add a Leave button,
a traceback will appear.

Steps to reproduce the error:
- Open Profile > Preferences > Select empty in timezone > Save
- Install 'Appointments'
- Go to Appointments > Schedule > Resource Bookings > Add a Leave

Traceback:
```
AttributeError: 'bool' object has no attribute 'upper'
  File "odoo/http.py", line 2254, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1829, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1849, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1827, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1834, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2059, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 871, in onchange
    defaults = self.default_get(missing_names)
  File "odoo/models.py", line 1524, in default_get
    defaults[name] = field.default(self)
  File "home/odoo/src/enterprise/saas-17.2/appointment/wizard/appointment_manage_leaves.py", line 20, in <lambda>
    leave_start_dt = fields.Datetime('Start Date', required=True, default=lambda self: self._default_time(0, 0))
  File "home/odoo/src/enterprise/saas-17.2/appointment/wizard/appointment_manage_leaves.py", line 14, in _default_time
    user_timezone = pytz.timezone(self.env.user.tz or self.env.context.get('tz', 'utc'))
  File "odoo/tools/_monkeypatches_pytz.py", line 129, in timezone
    return original_pytz_timezone(name)
  File "__init__.py", line 183, in timezone
    if zone.upper() == 'UTC':
```

https://github.com/odoo/enterprise/blob/7640860f415028d2d516a2df5e4bc26d9d6dd3b4/appointment/wizard/appointment_manage_leaves.py#L14 When the user selects an empty timezone, tz will be False.
So, It will lead to the above traceback.

sentry-5443573507

Forward-Port-Of: odoo/enterprise#63858

## Issue: - For an inventory operation, if a product quantity is less than 1 (eg. 0.5), the "+" button in the Barcode app will display "+1" instead of "+ 0.5". ## Steps To Reproduce: - In Inventory, create a transfer (Receipts) with a product where the quantity is 0.5 and "Mark As Todo". - In the Barcode app, go to that operation and notice that the "Add Quantity" button shows "+1" instead of "+0.5". ## Solution: - I modified the `getIncrementQuantity` function to change the minimum qu

## Issue:
- For an inventory operation, if a product quantity is less than 1 (eg. 0.5), the "+" button in the Barcode app will display "+1" instead of "+ 0.5".

## Steps To Reproduce:
- In Inventory, create a transfer (Receipts) with a product where the quantity is 0.5 and "Mark As Todo".
- In the Barcode app, go to that operation and notice that the "Add Quantity" button shows "+1" instead of "+0.5".

## Solution:
- I modified the `getIncrementQuantity` function to change the minimum quantity from 1 to 0. This ensures that for product quantities less than 1, the "+" button in the Barcode app will display the correct increment.

OPW-3880380

Forward-Port-Of: odoo/enterprise#64812
Forward-Port-Of: odoo/enterprise#62770