The system crashed because it expected the information from the card to be in `dictionary` format, but it came in the `list of dictionaries`. Usually, when there is only one contact on the card, the system retrieves the details as a `Dictionary`. But if the card has details of more than one person, it receives a `list of dictionaries`.

When the `extracted_data` comes as list of dictionaries, then at [1], it raises the `TypeError`.

[1]
https://github.com/odoo/enterprise/blob/e5b21d77b6dfff2b1371909c3c1e17cecee43a19/crm_enterprise/tools/business_card_scanner.py#L85

**Steps to produce:-**
1. Install `CRM` and make sure you have iap tokens for `Lead generation`.
2. Go to CRM and click on gear icon and click on Import Business Cards.
3. Then upload this [image](https://drive.google.com/file/d/1wKONdUEAMQptNU8cUeZsUY1xVJBpD8Dk/view?usp=sharing).

**Traceback:-**
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/http.py", line 2467, in __call__
    response = request._serve_db()
  File "/home/odoo/odoo18/community/odoo/http.py", line 1970, in _serve_db
    return self._transactioning(
  File "/home/odoo/odoo18/community/odoo/http.py", line 2034, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "/home/odoo/odoo18/community/odoo/service/model.py", line 164, in retrying
    result = func()
  File "/home/odoo/odoo18/community/odoo/http.py", line 2001, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/odoo18/community/odoo/http.py", line 2263, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/odoo18/community/odoo/addons/base/models/ir_http.py", line 349, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/odoo18/community/odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/odoo18/community/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/odoo18/community/odoo/service/model.py", line 84, in call_kw
    result = method(recs, *args, **kwargs)
  File "/home/odoo/odoo18/enterprise/crm_enterprise/models/crm_lead.py", line 34, in action_ocr_business_cards
    leads = card_scanner.business_cards_to_leads(attachments)
  File "/home/odoo/odoo18/enterprise/crm_enterprise/tools/business_card_scanner.py", line 82, in business_cards_to_leads
    lead_values = {
  File "/home/odoo/odoo18/enterprise/crm_enterprise/tools/business_card_scanner.py", line 85, in <dictcomp>
    if extracted_data.get(field)
AttributeError: 'list' object has no attribute 'get'
```

**Solution:-**
- We first checked whether the data returned from the OCR was a dictionary or a list of dictionaries (multiple contacts).
    - If it was just a dictionary, **we wrapped it in a list** so that we could handle everything the same way.
    - Then, we looped through each dictionary, picked out the allowed fields, and **created a lead for each one**.

**Sentry - 6658829547**

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

# 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