Problem
---------
The account tour had some troublesome steps such the one waiting for the user to select a template. If this had already been done before, it meant that the tour would be on stand by. The Send & Print wizard steps were also quite heavy with extra steps being taken to add an email to the partner, this would stop the tour if the selected partner already had a email address.

Solution
---------
This commit removes
- the steps related to the template selection (for both the manual and automatic tours)
- the extra steps in the send and print, asking the user to select add an address for the partner without one and simply asks him to Send & Print directly (only for the manual tour, the automatic tour maintain those steps since the automatic tour creates a new partner without email address during the run).

This commit adds
- Steps to add a description of a product (for both manual and auto)

task-4309716
odoo/enterprise/pull/74092

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

The way we initially implemented CTA, it was using the current rate for all the balance sheet accounts. Instead, we actually want to consider the closing rate ; that is, the rate of each currency at the end of the fiscal year the operation was made in.

Current rate currency translation is still applied like before when CTA is not enabled on the report.

task-4270102

==========================================================================

[IMP] account_reports: currency table: add test case
If a period containing some res.currency.rate object starts by some sub-period without any range, the average rate computation considered this sub-period as having a rate of 0. It's wrong; it should be 1.

The fix itself is in the corresponding community commit ; this one adds a check ensuring this doesn't break again in the future.

Fixing this also revealed an issue in the Trial Balance, where the initial balance column group was computed with different rates than the rest of the report, which is not what we want for this instance. We fix that by properly setting the period_key on all of its column groups and ensuring the initial balance dates have no impact on the currency table.

Steps to reproduce:

- Open Firefox.
- Type a few characters.
- Add a space after the characters.
- Press backspace.
- Observe that both the space and the last visible character are removed.

Description of the issue/feature this PR addresses:

- In Chrome, pressing space inserts a `&nbsp` (non-breaking space, `U+00A0`), which is treated as a visible character by `isVisibleChar`. Thus, only the whitespace is removed when backspace is pressed.

- In Firefox, pressing space inserts a regular space (`U+0020`), which `isVisibleChar` identifies as invisible. As a result, the backspace action incorrectly calculates the range and removes both the space and the preceding character.

Character details:

- Chrome: `char.charCodeAt(0).toString(16)` → `U+00A0`
- Firefox: `char.charCodeAt(0).toString(16)` → `U+0020`

Desired behavior after PR is merged:

- In Firefox, pressing backspace after a whitespace removes only the invisible character without affecting the preceding visible character.

task-4363847

Problem
---------
1 - Open Odoo 18.0
2 - install l10n_hu_edi
3 - switch to "HU Company"
4 - create an outgoing normal invoice with other than HUF currency
5 - put items, taxes, select partner, etc.
6 - print the invoice
-> KeyError: 'formatted_total_vat_amount_in_huf'

The issue occurs because, in multi-currency, the method
`_l10n_hu_get_invoice_totals_for_report` is expected to add
`total_vat_amount_in_huf` to the tax dictionary as required by the 
invoice template.

However, currently, the said method only adds `total_vat_amount_in_huf`
for credit notes / refunds, in other cases, it stops early and does not
add the required key-value pair in the dictionary.

Solution
---------
Make sure the method always adds `total_vat_amount_in_huf` to the tax
dictionary, while making sure that it only reverses the tax values when
it is rendering a credit note / refund like before.

task-4391659

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

Versions
--------
- 18.0+

Steps
-----
1. Go to eCommerce;
2. go to a product with attributes;
3. open the editor;
4. set specification to display in accordion;
5. enable "Compare" option on Cart.

Issue
-----
> 500: Internal Server Error
> Error while render the template
> TypeError: tuple indices must be integers or slices, not product.public.category
> Template: website_sale_comparison.specifications_table

Cause
-----
The `categories` value set in this template contains an ordered dict with `product.attribute.category` records as keys, and `product.template.attribute.line` records as values.

When inserting its logic into the `website_sale` template, its variable name conlficts with the `categories` value returned by the `WebsiteSale` controller, which contains `product.public.category` records.

The issue occurs when it tries to use a `product.attribute.category` record to index a `product.public.category` recordset.

Solution
--------
Rename the `categories` variable to `attrib_categories` in the `website_sale_comparison` template.

opw-4356669

In rare cases there can be more than one tax on the same line with the same taxName and rate. These taxes are different e.g.:

```
Charleston Co Educational Capital Improvements Tax (Special) at 1%
Charleston Co Tt (Special) at 1%
```

But `find_or_create_tax()` maps both of them to SC SPECIAL 1%.

This doesn't cause issues for invoice_line_ids, those amounts are correct. But the journal items are not because there's only one tax journal item for this tax and its summary total gets overwritten instead of added to. This leads to the total on the invoice not matching the sum of debits/credits in the journal items tab.

Fix it by adding to the summary total instead of overwriting it.

PS. An alternative solution is to create unique tax names by incorporating the jurisCode and possibly other relevant fields. This approach would enhance the accuracy of tax representation on invoices. However, historically, we have prioritized brevity over accuracy [1].

[1] https://github.com/odoo/enterprise/pull/68549

**Current behavior:**
When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page.

**Expected behavior:**
The total cost for the POS order should match the computed BOM price shown on the product page.

**Steps to reproduce:**

1. Create two products: Product 1 and Product 2.
2. Set both products to be tracked by "quantity" or make them "storable" and assign them to a product category with "average cost" as the costing method (instead of "standard price").
3. Create a Bill of Materials for each product, ensuring they share at least one component. Make sure BoM Type is 'kit'
   - Tip: For better visibility of the error, assign a quantity of 10 or more to the shared component in Product 2's BOM, and set the shared component’s `standard_price` (cost) to 5 or higher. This will make the discrepancy in the total cost more apparent.
4. Create the shared component as a new product and assign it a price.
5. Open a new POS order, add Product 1 and Product 2, and close the order.
6. Locate the order and observe that the "total cost" is incorrect.

**Cause of the issue:**
The stock move filter does not consider that stock moves for BOM lines need to belong to the current product. As a result, if two kit products share components, the stock moves for one product are mistakenly included in the calculation for the other, leading to an incorrect total cost.

**Fix:**
When filtering out the stock moves, ensure they are correctly associated with the current product by verifying that each stock move’s BOM line belongs specifically to the current product and does not include nested BOMs.

opw-4274532

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

Forward-Port-Of: odoo/odoo#190116
Forward-Port-Of: odoo/odoo#187130

**Steps to reproduce:**
- Create a new mailing
- Add a link with "Link" widget
- Enter a link with the same domain (e.g. a link to an event)
- Insert the link

**Issue:**
The link is automatically converted to a relative link. This may cause some issue in a multi-company environment where each company has a website (i.e. has its own domain url) and "web.base.url" is configured with the domain of the other company.

**Cause 1:**
The "Autoconvert to relative link" checkbox is never displayed and is always applied as it is checked by default. The display toggle is done in "_onURLInput" function of "Link" component, but it is never called by the override function in "LinkDialog".

**Cause 2:**
Even if the "Autoconvert to relative link" checkbox is displayed, the link will be stripped from its domain as soon as an URL is inputted and save in "this.state.url".
When the checkbox is unchecked, "this.state.url" stays unchanged because it is not possible to retrieve the stripped domain from "this.state.url".

**Solution 1:**
Call the super function in "_onURLInput" function of "LinkDialog".

**Solution 2:**
Retrieve the URL from the input when the domain should not be stripped and update "this.state.url" with it.

opw-4357095



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

Forward-Port-Of: odoo/odoo#190385
Forward-Port-Of: odoo/odoo#189351

Content of the IMP:
---

In the form picking view, it is possible to edit the move lines that are related to a given move by using the `SMLX2ManyField`. However, untill you save the record, available quantity of quants present in the  DB are not updated. This commit ensures that the quants proposed for your  move line creation have an available quantity (even if currenlty dirty) and that the quantity used for the next move line creation is both related to the demand of the move, and the real availability of the quant used to create it.

[FIX] stock: avoid move line reset when opening detailled ops
---

This reverts [1] commit b45e249f8f5f36cffdb1ff615953eac7bb45b995.

### Steps to reproduce:

- Enable Multi-step routes
- Create a storable product: put 5 units on shelf 1 and 5 on shelf 2
- Create and "mark as todo" a delivery order for 3 units
- Click on the detailed operation and change the reservation from shelf 1 to shelf 2 > save (the subrecord not the record)
- Reopen the details operation
#### > The records get resets in front of you

### Cause of the issue:

One of the main problems of [1] is that it modifies dirrectly the data's of the props of the component used by the X2many dialog:
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L48
As such, as soon as you mount that component, you will reset the data's used by that same component. Worse, the component is doing this to itself. Hence, if you did not perform a save before opening the details operation you will reset the values to match the DB's data. Furthermore this data change modifying the props of the component we are looking at will force to reload the component with the newly hardcoded data (which explains that you see your last change resetting in front of you).

In addition, the `quant_id` field of the stock.move.line model is a very particular field as it is neither stored or computed but is used by the create and the write for the stock.move.line data's to match some of the quant informations:
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L85
https://github.com/odoo/odoo/blob/7e01d83ac08f9b076e0cd7d7e644679d5264ff7d/addons/stock/models/stock_move_line.py#L310-L311
Therefore this field will never be set on a move. line that was not  modified in JS and is not saved yet. In order to take into account  the offset between the DB Data and the data's we are setting on the form of stock move it is therefore necessary to perform an rpc to **guess**  what quant was used to create a given line. HOWEVER, as teached by the JS framework formation:
```
The first rule of customizing Odoo in JS is: do it in python
```
So that you should not do that matching in JS but rather where it belongs.

Finally, modifying the props of a component during the `onMounted` is a super hacky way to use OWL as it is the first Hook for which OWL does not destroy the component because of props inconsistency...

opw-4294650

Original issue of the reverted "FIX":
---

### Steps to reproduce

- In the setting enable Multi Step Routes
- Create a storable prodcut and put 5 units on shelf 1
- Create and Mark as Todo a delivery order for 3 units of your product
- Set the quantity of the move to 0 and save the record
- Click on the "burger list icon" of the stock move to edit the
  detailed operations and make the reservations for your 3 units
- We want to make the reservation in 2 lines targetting the same quant
- Add a new line selecting your shelf 1 quant and set the qty to 1
- Try to add a second one the quant is not proposed

### Cause of the issue:

When a quant has been selected at least once and the record is not yet saved the js data of the record contains the info of the quant used to create/update the move line because of the non stored not computed dummy field `quant_id` of the stock move. As such the quant will be considered to already having been used in this transaction and hence not available:
https://github.com/odoo/odoo/blame/54e06a1b25ed9e317e368e89979c7c77ddbffc08/addons/stock/static/src/fields/stock_move_line_x2_many_field.js#L52-L54

### Note:
The IMP fixes the original issue + more.
This reverted commit already required an other fix: Commit ea4fca8faa4ee84693e645514085a65b92364842

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

Forward-Port-Of: odoo/odoo#189173
Forward-Port-Of: odoo/odoo#186400

Issue:
------
Commit 749e0af3639d243f1d24e40f9c0d374c634eaf79 improves the performance of the `res.device` model in the case of a filtered search (for a given user or a given id).

However, when the search is not filtered it takes a long time. This scenario occurs when an administrator goes to the list view of this model.

Cause:
------
This is because, although the data in the view is already ordered, the ORM explicitly adds an order (by default, `ORDER BY 'res_device'.'id'`). The re-sort forces an exhaustive search (before satisfying the limit) which is very time-consuming given the amount of data.

Solution:
---------
Remove the sort in the non-materialised view and let the ORM add it, thus sorting the data just once.

Note:
Optimisations on this view only work if a limit is applied.

Appendices:
-----------
For the query: `SELECT * FROM res_device ORDER BY id LIMIT 80`

Before:
```
 Limit  (cost=723566.00..723566.20 rows=80 width=154) (actual time=18565.185..18565.198 rows=80 loops=1)
   ->  Sort  (cost=723566.00..728832.00 rows=2106398 width=154) (actual time=18453.028..18453.036 rows=80 loops=1)
         Sort Key: d.id
         Sort Method: top-N heapsort  Memory: 66kB
         ->  Sort  (cost=641185.54..646451.53 rows=2106398 width=154) (actual time=17845.533..18159.999 rows=2355457 loops=1)
               Sort Key: d.last_activity DESC
               Sort Method: external merge  Disk: 348000kB
               ->  Merge Anti Join  (cost=1.11..419946.90 rows=2106398 width=154) (actual time=0.043..15869.920 rows=2355457 loops=1)
                     Merge Cond: ((d.user_id = d2.user_id) AND ((d.session_identifier)::text = (d2.session_identifier)::text))
                     Join Filter: ((NOT ((d2.platform)::text IS DISTINCT FROM (d.platform)::text)) AND (NOT ((d2.browser)::text IS DISTINCT FROM (d.browser)::text)) AND ((d2.last_activity > d.last_activity) OR ((d2.last_activity = d.last_activity) AND (d2.id > d.id))))
                     Rows Removed by Join Filter: 64036293
                     ->  Index Scan using res_device_log__composite_idx on res_device_log d  (cost=0.56..230733.16 rows=4674167 width=154) (actual time=0.018..3639.566 rows=4679317 loops=1)
                     ->  Index Only Scan using res_device_log__composite_idx on res_device_log d2  (cost=0.56..142436.83 rows=4674167 width=73) (actual time=0.005..6216.295 rows=64036294 loops=1)
                           Heap Fetches: 4284155
 Planning Time: 0.402 ms
 Execution Time: 18588.272 ms
```

After:
```
 Limit  (cost=0.99..117.94 rows=80 width=154) (actual time=0.028..0.974 rows=80 loops=1)
   ->  Nested Loop Anti Join  (cost=0.99..3079343.32 rows=2106398 width=154) (actual time=0.027..0.968 rows=80 loops=1)
         ->  Index Scan using res_device_log_pkey on res_device_log d  (cost=0.43..202459.12 rows=4674167 width=154) (actual time=0.012..0.118 rows=138 loops=1)
               Filter: (NOT revoked)
               Rows Removed by Filter: 3
         ->  Index Only Scan using res_device_log__composite_idx on res_device_log d2  (cost=0.56..0.61 rows=1 width=73) (actual time=0.006..0.006 rows=0 loops=138)
               Index Cond: ((user_id = d.user_id) AND (session_identifier = (d.session_identifier)::text))
               Filter: ((NOT ((platform)::text IS DISTINCT FROM (d.platform)::text)) AND (NOT ((browser)::text IS DISTINCT FROM (d.browser)::text)) AND ((last_activity > d.last_activity) OR ((last_activity = d.last_activity) AND (id > d.id))))
               Rows Removed by Filter: 6
               Heap Fetches: 9
 Planning Time: 0.368 ms
 Execution Time: 0.996 ms
```

Forward-Port-Of: odoo/odoo#189576

### Steps to reproduce:

- Enable Multi-Steps Routes in the settings
- Inventory > Configuration > Warehouse Management > Locations
- Pick any location
- With studio add the one2Many field `Store to sublocation` (`location_out_id` of `stock.putaway.rule`) > Close studio
- Try to add a line on the associated list
#### > Traceback

### Cause of the issue:

Adding a line will trigger an onchange of the`stock.putaway.rule` model in order to compute the default data of the new subrecord. However, the code will crash during the `_search_count` of the `_onchange_location_in` because of an invalid domain: https://github.com/odoo/odoo/blob/29939aa5fb1455af89a37293d2f76541ff1645ef/addons/stock/models/product_strategy.py#L80-L88 THis crashed since in our case the `location_out_id` will be a new record created during the onchange to represent the 'stock.location' and from which we are looking at the form. As such, a NewId will be given and treated as an integer in the domain leading to a traceback when the db is served.

### Fix:

Onchange method should be robust with respect to the usage of New records and hence the records used here should be replace by their origin if it even exists.

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

Forward-Port-Of: odoo/odoo#189878
Forward-Port-Of: odoo/odoo#188053

**Current behavior:**
Having a manufactured product with components, all with
'average' costing, a series of receiptions for the components at
difference price points, followed by an MO, followed by another
reception at (again) a new price point will result in an
imbalanced "Cost of Production" journal if the aforementioned MO
is unbuilt.

**Expected behavior:**
The unbuild operation doesn't leave the journal imbalanced.

**Steps to reproduce:**
1. Create a stored product with average, real_time costing

2. Create a BoM for this product, with 2 stored components (also
with average, real_time costing)

3. Create a PO for the components (price is arbitrary), confirm
and receive the product

4. Create another PO for the components with a different price
from the previous PO, confirm and receive

5. Create an MO for the final product, confirm and
consume/produce all

6. Create a final PO for the components with prices different
from the previous two orders, confirm and receive

7. Create a second MO for the final product and
confirm/consume/produce-all

8. Unbuild the MO from step 5 -> in the "Cost of Production"
journal, observe that there is an outstanding balance

**Cause of the issue:**
When the unbuild operation happens, the current price of the
final product informs the SVL's `value` and `unit_price` fields-
which of course is not the same as when the MO was completed.

We end up with a `unit_price` on the SVL for the final product
which is not equal to the sum of the component SVLs'
`unit_price` which leads to the generation of account move lines
that won't be balanced.

**Fix:**
During an ubuild operation, stock moves for finished products
which may have this issue (i.e., have non-standard costing) with
linked SVL records will use that SVL's unit cost for the unbuild
SVL (and ensuing journal entries) as opposed to taking the
current cost.

opw-4062415

Forward-Port-Of: odoo/odoo#189908
Forward-Port-Of: odoo/odoo#188016

**Issue:**
If a user changes a salary rule to the default Python Code for computation, an error occurs when trying to `Compute Sheet` on an employee's payslip.
![Capture d’écran 2024-12-12 à 09 37 09](https://github.com/user-attachments/assets/22fca0a9-0eaf-40e6-97ed-201b1fd08066)

**Expected:**
The computation should be feasible.

**Steps to reproduce:**
- Activate Payroll app;
- Move to `Configuration/Salary:Rules`;
- Select any rule having its `Computation` `Amount Type` field not set to `Python Code` (e.g. `Regular Pay > House Rent Allowance`);

![Capture d’écran 2024-12-12 à 09 38 06](https://github.com/user-attachments/assets/8d635b79-5d0e-4ab1-bf4a-6097031b7043)

- Change the `Amount Type` to `Python Code`;

![Capture d’écran 2024-12-12 à 09 38 56](https://github.com/user-attachments/assets/bd543395-93e1-44bf-82bb-e78247b57843)

- Create a new payslip entry for any employee and change the structure for the one you changed the rule in (e.g. `Regular Pay`);
- Click `Compute Sheet`;

**Cause:**
The Python code displayed in the computation rule contains an uncommented comment line that.

**Fix:**
Comment the blocking line.


opw-4377712

Forward-Port-Of: odoo/enterprise#75525

### Steps to reproduce the issue:

1. Create two Companies, one in EUR, the other in USD
2. In EUR Company, create two Invoices with the following settings:
    - Total price of 1000
    - Invoice date: today and one month ago
    - You must be able to isolate them using Partner Ledger filters (not date)
3. In USD Company, add EUR Rates as follows:
    - Today: 1USD = 1EUR
    - One month ago: 1USD = 0.9EUR
4. In USD Company, open General Ledger and isolate the Invoices
5. First, set the timeframe from beginning last month to end of this month
6. The Invoice of last month is using the current rate, with an amount of 1000$
7. Second, set the timeframe to the current month only
8. The Initial Balance is using the previous rate, with an amount of 1111.11$

### Explanation:

The initial balance is the balance of the company before the start of the currently reviewed timeframe. To calculate it, we must update the options to target the time before the current timeframe. Since we retrieve the rate used for this calculation using the updated options, we use the last rate before the current timeframe instead of the rate used in the current timeframe.

### Fix reasoning:

Since every amount must be calculated using the current rate, we will retrieve it using the main options and not the updated ones.

opw-4299153

Forward-Port-Of: odoo/enterprise#75517
Forward-Port-Of: odoo/enterprise#75441