If customers migrate to version 18 from a lower version, 'Create Bill' record newly introduced so it just create but not translated.

**Before fix:**
```
test_18=# select id,name from account_reconcile_model;
 id |                                                            name                                                            
----+----------------------------------------------------------------------------------------------------------------------------
  3 | {"en_US": "Line with Bank Fees", "es_AR": "Línea con comisiones bancarias"}
  1 | {"en_US": "Invoices/Bills Perfect Match", "es_AR": "Coincidencia perfecta de facturas"}
  2 | {"en_US": "Invoices/Bills Partial Match if Underpaid", "es_AR": "Coincidencia parcial si hay pagos parciales en facturas"}
  4 | {"en_US": "Create Bill"}
  5 | {"en_US": "Internal Transfers", "es_AR": "Transferencias internas"}
```

**After Fix:**
```
test_18=# select id,name from account_reconcile_model;
 id |                                                            name                                                            
----+----------------------------------------------------------------------------------------------------------------------------
  1 | {"en_US": "Invoices/Bills Perfect Match", "es_AR": "Coincidencia perfecta de facturas"}
  2 | {"en_US": "Invoices/Bills Partial Match if Underpaid", "es_AR": "Coincidencia parcial si hay pagos parciales en facturas"}
  5 | {"en_US": "Internal Transfers", "es_AR": "Transferencias internas"}
  3 | {"en_US": "Line with Bank Fees", "es_AR": "Línea con comisiones bancarias"}
  4 | {"en_US": "Create Bill", "es_AR": "Crear factura"}
```
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

## Version:
saas-18.0+

## Issue:
Importing eCommerce translations for products erase all existing translations and set the new one as default value, whatever the user's current language is.
The `website_description` acts the same.

## Steps to reproduce:
- From the user's `Preferences`:
  - Add a second language you understand;
  - Translate all websites and close without switching;
- Access `Sales / Products / Products`:
  - Set a product as favorite and open it:
    - Under the `Sales` tab, write something in the `ECOMMERCE DESCRIPTION` field;
    - Open the translation wizard by clicking the `EN` link appearing when hovering the input:
      - Write anything else in the second language's input field and save;
- Come back to the general products view (*`Sales / Products / Products`*):
  - Change view to list and select the favorite item (*check the case of the record line*);
  - Via the `Actions` button, click on `Export`:
    - Check `I want to update data (import-compatible export)`;
    - From the `Available fields` list, add `eCommerce Description`;
- Open the exported file:
  - Change the `description_ecommerce` content and save;
- From the general products view (*`Sales / Products / Products`*):
  - Ensure no product is selected;
  - Click the gear next to `Products` then `Import records`
    - Click `Upload Data File` and select the exported and modified file;
    - Ensure the fields are well mapped;
    - Test then import data;

## Cause:
Translation method refactoring via this PR: https://github.com/odoo/odoo/pull/170779, especially `update_field_translations(field_name, {"fr_FR": {"en2": "fr2"}})`, requiring a key (`en2`) and a value (`fr2`) for a given language as a `field_name` translation. Before the fix, giving only one value erases value and key for a given `field_name`

opw-4600662

Steps to reproduce the bug:
- Create a storable product “P1”:
    - Update the quantity to 1 in "WH/Stock"
    - Create a putaway rule:
        - From "WH/Stock" to "WH/Stock/Shelf1"

- Create a manufacturing order:
    - Select any product to produce
    - Add a component:
        - 1 unit of P1

- Confirm and validate the MO
- Unbuild the order

Problem:
A stock move for P1 is created from "Virtual Location/Production" to "WH/Stock/Shelf1" instead of "WH/Stock".
This happens because the `_apply_putaway_strategy` method is not called on the `stock.move.line` linked to the move.

In previous versions (e.g., v17), this issue didn't occur because the quantity was directly set on the move. This triggered a write on the `stock.move` model, which in turn called `_set_quantity`. Since no `stock.move.line` was linked at that point, a new one was created, and its quantity was set via `_set_quantity_done`, which itself called `_apply_putaway_strategy`:

- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L202
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L399
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L384
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L2133

This scenario used to work only when the product was untracked:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L186

However, starting from v18, some code was refactored to clean up unnecessary conditions. The `else` block was removed, and now, regardless of the product type, the quantity is not set directly on the move anymore. Instead, a `stock.move.line` is created using `_prepare_move_line_vals`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L197

But `_apply_putaway_strategy` is not called in this flow.

Bug introduced in v18.0, commit:
https://github.com/odoo/odoo/commit/79d9dd7f15371aa7293a4af0b0ebd193aa80e2be

opw-4830952

Steps:
------
- Install `l10n_fr_pos_cert`
- Open a PoS session, and add a combo product, orderlines corresponding to the combo procuts will be added
- Hide the numpad by clicking on the selected orderline.
- Choose a random orderline, and click on the text "Old unit price"

-> Observe that the numpad will appear and then disappear immediately.

Reason:
-------
When clicking the text "Old unit price", two click events are dispatched, those running the click handler twice, the first time it selects the orderline and hence show the numpad, and the second time, it unselects that same orderline, hiding the numpad.

Fix:
----
We disable the pointer-events on the "Old unit price" text, making it unclickable, more precisely, preventing it from being a `target` of a click event. With that change, the click handler (aka `clickLink` [1]) will only run once.

[1]: https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/point_of_sale/static/src/app/screens/product_screen/order_summary/order_summary.xml#L9

opw-4636261

# Issue:
When sending an email with an attachment to an incoming alias, if the target folder in Documents is explicitly owned by a specific company, an error occurs during alias creation: "We could not create alias Inactive Alias because domain company1.com belongs to company YourCompany while the owner document belongs to company Company2."

This issue arises because the `mail.alias.mixin.optional` model, when determining the `company_id` for the alias associated with the new document, might default to the system's company or another incorrect company, leading to a mismatch with the actual company of the explicitly-owned document folder.

# Proposed solution:
This commit modifies the `create` method of `mail.alias.mixin.optional` to prioritize the `company_id` of the document's target folder when setting the `company_id` for the associated alias.

Specifically, within the loop where alias values are prepared:
- It first attempts to retrieve the `company_id` directly from the `vals` dictionary for the current record.
- If no `company_id` is explicitly provided in `vals` but a `folder_id` is present, it then checks the `company_id` of that `documents.folder`.
- If the folder has an explicit `company_id`, this company is used as the effective `company_id` for the alias.
- Otherwise, it falls back to the previously determined `company_id_default`.

This ensures that the `company_id` used for alias domain validation aligns with the `company_id` of the document's folder, resolving the domain/owner company mismatch error.

opw-4727873


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

_Description of the issue/feature this PR addresses:_

When setting up a new activity template on a new activity plan, HR specific values for 'Assignment' such as Coach or Manager are not available.

_Current behavior before PR:_

As an HR manager, go to menu HR -> Configuration -> Activity Plan. Click 'New'. Under Activities To Create, click 'Add a line'. Under 'Assignment', the only options available are Ask at launch and Default user.

<img src="https://github.com/user-attachments/assets/97be6790-b450-42c6-910a-07483c30e175" width=50% height=50%>

Cancel the 'Create Activities' popup. Give the plan a name and save it. Again, under Activities To Create, click 'Add a line'. Only now are HR specific options (Coach, Manager etc) available under 'Assignment'.

_Desired behavior after PR is merged:_

HR specific values for 'Assignment' are immediately availalbe when setting up a new plan for the Employee model.

![image](https://github.com/user-attachments/assets/391da1c1-c1ed-495a-a25f-48941554791a)

_Technical solution:_

Pass the plan's model as the default model for new templates so that the related field is populated with a value that unlocks the HR specific values before first saving the plan.

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