### Steps to reproduce:

1. Create a product tracked by lot
2. Put 10 units in WH/Stock without lot
3. Inventory > Operations > Adjustments > Physical Inventory
4. Select the line referring to your product and request an inventory count + Show Expected Quantity
5. Open the barcode app > Count Inventory
6. Scan your product
#### > The line is not selected, in particular, next scans will be re-interpreted as product scans rather than new serial creation for your product.

### Cause of the issue:

Scanning your product search a line to select if any: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1432-L1435 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1630-L1632
However, the `findLine` will fail since this method calls the `_canOverrideTrackingNumber` to determine if the lot of the barcodData matches the one of the line:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1859-L1863
But, the override of the `_canOverrideTrackingNumber` method for the `BarcodeQuantModel` does not handle the absence of lotName in the barcodeData correctly as it does not consider that a line without lot can be overridden by an empty lotName:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_quant_model.js#L729-L731
Note however that the super call does:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L795-L798

### Issue 2:

### Steps to reproduce:

- Steps 1 -> 5
- Click on your product line to select it
- Scan a new lot to add one new unit referring to that lot
- Confirm (1)
- Apply Now
#### > User Error: Quant's editing is restricted, you can't do this operation

Since the line is selected, you have a currentLine during the `processBarcode` and hence the existing line will be updated using the `lotName``:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L1560-L1584 However, writing on the line will then try to write on the related quant during the validation process which will be forbiden since we are not allowed to change the lot of an existing quant:
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/stock/models/stock_quant.py#L351-L360 Now, the issue is that actually due to the nature of the line and of the barcode data, the line lot is not expected to be updated but rather a new line is expected to be created:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L795-L798

Additional issue:

Fixing issue 1 and 2 highlight and other issue of the validation process:

- Steps 1 -> 6
> The line gets selected
- Scan a newlot
> a new subline is added referring to 1 unit of your new quant
- Confirm (1) > Some serials where not counted, set them as missing
#### > Check your quants: the 10 unit lotless quant was not updated but a new quant for 1 units was created for your newlot

### Cause of the issue:

Applying all quantities is expecting to toggle them as counted before applying to update the existing quants:
https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L72-L82 https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L287-L296 However, only line tracked by serial numbers are set as counted: https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L60-L63

opw-6212923

Forward-Port-Of: odoo/enterprise#118373

**Steps to Reproduce**

1. Create a database on v19.3.
2. Install `hr` and `hr_payroll`.
3. Create or log in as a user who only has access rights for the Employee app (`hr`) and no Payroll access.
4. Go to **Employees → Configuration → Employee → Employee Types**. Opening the Employee Types menu raises the following error:

```python
You do not have enough rights to access the field "employee_type_id" on
Employee Contract (hr.version). Please contact your system administrator.

Operation: read
User: 2
Groups: allowed for groups 'Payroll / Assistant'
```

**Issue Description:**

The field `employee_type_id` is defined in both modules with different group restrictions:

* In `hr/models/hr_version.py`, the field is restricted to **HR Managers**. [field](https://github.com/odoo/odoo/blob/f7e87637d5c47047ebffda0f3c929c25022c3f27/addons/hr/models/hr_version.py#L184)
* In `hr_payroll/models/hr_version.py`, the field is extended with the **Payroll / Assistant** group.
[field](https://github.com/odoo/enterprise/blob/acd831acd0f59f7b8c15bccfb6da0c3969fc3f6d/hr_payroll/models/hr_version.py#L41) When both modules are installed, access to `hr.version.employee_type_id` requires Payroll permissions.

In v19.3, PR #241780 introduced the `employee_count` [computation](https://github.com/odoo/odoo/blob/f7e87637d5c47047ebffda0f3c929c25022c3f27/addons/hr/models/hr_employee_type.py#L25) on `hr.employee.type`. During this computation, `_read_group()` is executed on `hr.employee` using the domain.

[pr] : https://github.com/odoo/odoo/pull/241780/changes

HR-only users (without hr_payroll.group_hr_payroll_user) cannot read the field, causing below traceback.

**Solution**

added `group_hr_manager` group to the field `employee_type_id` so both groups can view employee_type.

**Traceback**

```python
File "/home/odoo/src/odoo/saas-19.3/addons/hr/models/hr_employee_type.py"
 line 25, in _compute_employee_count
    employee_count_by_employee_type = dict(self.env['hr.employee']._read_group(
...
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 2732, in
check_field_access
    raise AccessError(error_msg)

odoo.exceptions.AccessError: You do not have enough rights to access the field
"employee_type_id" on Employee Contract (hr.version).

Operation: read
User: 8
Groups: allowed for groups 'Payroll / Assistant'
```

opw-6246367
upg- 4302826
tgb- 2751

Steps to Reproduce:
1. Install Accounting module (without Point of Sale).
2. Create a customer.
3. Create a journal entry with that customer set only at line level.
4. Post the journal entry.
5. Open the customer form.

Issue:
The Due smart button is not visible on the partner form even though an outstanding balance exists for the customer.

Note: This issue does not reproduce when Point of Sale is installed, as the POS module overrides `_compute_has_moves` with its own implementation that checks the outstanding balance directly.

Root Cause:
The `_compute_has_moves` method queries only `account.move `for partner matching. When a partner is referenced only at the account.move.line level, the partner is never picked up by this query, resulting in `has_moves = False` and the Due button remaining hidden.

Fix:
Replaced the EXISTS-based implementation with a UNION-based approach as the EXISTS implementation evaluated the query per partner row, whereas UNION processes all partners in a single batch query. Additionally extended the UNION to also include account.move.line partner matching, ensuring partners referenced only at the line level, are correctly detected and has_moves is set to True.

Result:
The Due smart button is now correctly visible for all partners with an outstanding balance, regardless of whether the partner is set at the journal entry level or only at the line level.

owp = 6243562

Forward-Port-Of: odoo/enterprise#120294
Forward-Port-Of: odoo/enterprise#119084

Steps to reproduce
---
1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56").
2. Map the columns to Debit and Credit and import.

The imported amounts are multiplied by 100: "1.234,56" is imported as 123,456.00.

Issue
---
This only happens when both `account_bank_statement_import_csv` and `account_bank_statement_extract` are installed, which is the default in any Accounting database since both modules are auto-installed.

`account_bank_statement_extract` turns debit and credit into real Monetary fields on `account.bank.statement.line`:

https://github.com/odoo/enterprise/blob/af863c5a53d0ab50fe67cb9ea910391d4a1979dd/account_bank_statement_extract/models/account_bank_statement_line.py#L7-L8

Because they are now real fields, the generic importer already converts those columns to floats:

https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/base_import/models/base_import.py#L1281-L1285

The CSV statement wizard then parses the same columns a second time:

https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L92-L93

The first pass correctly reads "1.234,56" as "1234.56", but the second pass sees a lone dot, mistakes it for the thousands separator, strips it, and produces 123456. The wizard now parses debit and credit only when they are virtual fields, so when they are real fields the values parsed by the generic importer are reused instead of being parsed twice.

Without `account_bank_statement_extract`, debit and credit exist only as virtual import fields, so the generic importer skips them and the wizard parses them once. That is why the regression stays hidden until the extract module is present.

opw-6227083
---

Forward-Port-Of: odoo/enterprise#118979

**Problem:**
On the shop, moving one of a product's extra images to the first position through the website editor raises a server error.

**Steps to reproduce:**
1. Have a product whose TEMPLATE has a main image set and at least one template-level extra image with different content.
2. Open the shop, open that product, and enter edit mode.
3. Move the extra image to the first position.
4. Observe the error.

**Current behavior:**
The reorder fails with "Attachment modified when accessing it from a Binary field".

**Expected behavior:**
The extra image becomes the product's main image and the others keep their order.

**Cause of the issue:**
Moving an additional image to the first position promotes it to the main image, so `resequence_product_image` swaps the `image_1920` value of the main record and the additional image. The swap was done with a single tuple assignment, where both right-hand reads are lazy values still bound to their attachments. Writing the first field rewrites its attachment in place, which changes that attachment's checksum; the second value is then read from the same attachment and its cached checksum no longer matches, tripping the binary field's concurrent modification assertion.
https://github.com/odoo/odoo/blob/55c7c8be9a7a78d683f5b8b6e1703fb051dddd2f/odoo/orm/fields_binary.py#L345-L346
This only surfaces for a narrow combination, which is why it is easy to miss (e.g. on runbot demo data and in the existing tests):
The main image being swapped must be a `product.template` record, i.e. the moved image is a template-level extra image. For variant extra images the main image is `product.product.image_1920`, a computed field whose inverse writes elsewhere, so no attachment is mutated in place and no error occurs.
https://github.com/odoo/odoo/blob/55c7c8be9a7a78d683f5b8b6e1703fb051dddd2f/addons/product/models/product_product.py#L132
https://github.com/odoo/odoo/blob/55c7c8be9a7a78d683f5b8b6e1703fb051dddd2f/addons/product/models/product_product.py#L249-L255
The product's main image must be set and its content must differ from the moved image (identical content keeps the same checksum).
The values must be read from their attachments (the case on a real request; in-memory tests cached them as plain bytes and passed).

**Fix:**
Reading both image contents into memory before writing decouples each write from the other's attachment, so mutating one attachment can no longer invalidate the value being written to the other.

opw-6249950

### Issue
When importing an electronic bill (such as a German XRechnung) that uses the Peppol EAS 'EM' (Email) with an email address as the endpoint, the import fails during the automatic partner creation

An error is logged in the chatter stating that the Peppol endpoint is not valid and should contain only letters and digits

Since 'EM' stands for Email, the system should allow the '@' character and validate the endpoint format

### Cause
While the export logic supported the 'EM' EAS, the validation flow triggered during automatic partner creation on import was too restrictive

The global regex `PEPPOL_ENDPOINT_INVALIDCHARS_RE` did not include the '@' character, causing the
validation to fail for any email address

Additionally, there was no specific format check implemented for the 'EM' EAS type to ensure the endpoint is a valid email string

### Steps to reproduce
- Install `account_edi_ubl_cii`
- Go to Accounting / Vendors / Bills
- Upload an electronic invoice containing an EM EAS and an email endpoint (you can use the added test file or the one from the ticket)

Before the fix, an error is raised in the chatter and the partner cannot be created automatically

opw-6205745

Forward-Port-Of: odoo/odoo#266894

Steps to reproduce:
- Start from a database where the eCommerce app is not installed.
- Open the website configurator.
- In the first step, choose "I want an eCommerce".
- In the Pages and Features step, select all Pages.
- Select a theme that adds an eCommerce category snippet, for example "Treehouse".
- Build the website. => During the first `configurator_apply`, `website_sale` is installed
   after the theme and the configured menu items are already created.
=> The homepage rendering then needs a `website_sale` configurator
   snippet template requested by the theme, but it was not generated
   during that first call.
=> The client retries `configurator_apply`. It now succeeds because
   `website_sale` is fully installed, but page and menu creation runs
   again and duplicates the menu items.

Before this commit, primary snippet template generation only read the manifest of the module being generated. When `website_sale` was installed from the first `configurator_apply`, it did not see addon snippets declared by the already installed theme. The first call could therefore fail while rendering the homepage after pages and menus were created.

After this commit, generation also reads installed theme addon snippets that target the module being generated. The `website_sale` configurator templates requested by the selected theme are created before the first homepage rendering, so `configurator_apply` does not retry after creating menu items.

task-5973739

Forward-Port-Of: odoo/odoo#261022

[FIX] hr_appraisal: fix auto-fill of employee in appraisal

Bug production:
    1 - employee app -> department -> select employees -> select any employee -> use appraisal smart button in top -> employee_id is not coming

Bug cause:
    1 - When we press smart button of appraisal action_send_appraisal_request in hr_employee is called.
    2 - It send the self.env.context as a context and active_model and active_id.
    3 - In hr_appraisal, _get_default_employee function calculates the default employee_id by looking to context and especially by looking to active model and id.
        3.1 - If active_model is hr.employee and there is active_id, it finds the employee automatically (that is the case when we are coming directly from employee -> smart button hr_appraisal)
        3.2 - When we first click to department and then we click to employee and smart button, active_model is hr.department and default_employee_id cannot be calculated in default version.

Bug solution:
    1 - I have passed the default_employee_id to the context in action_send_appraisal_request function. Since we know the employee in the action_send_appraisal_request function we can pass it directly.

task - 6285434

Forward-Port-Of: odoo/enterprise#119737

[FIX] hr_appraisal: fix auto-fill of employee in appraisal

Bug production:
    1 - employee app -> department -> select employees -> select any employee -> use appraisal smart button in top -> employee_id is not coming

Bug cause:
    1 - When we press smart button of appraisal action_send_appraisal_request in hr_employee is called.
    2 - It send the self.env.context as a context and active_model and active_id.
    3 - In hr_appraisal, _get_default_employee function calculates the default employee_id by looking to context and especially by looking to active model and id.
        3.1 - If active_model is hr.employee and there is active_id, it finds the employee automatically (that is the case when we are coming directly from employee -> smart button hr_appraisal)
        3.2 - When we first click to department and then we click to employee and smart button, active_model is hr.department and default_employee_id cannot be calculated in default version.

Bug solution:
    1 - I have passed the default_employee_id to the context in action_send_appraisal_request function. Since we know the employee in the action_send_appraisal_request function we can pass it directly.

task - 6285434

Leaving a session open and idle (page open, no activity at all) eventually pops an error dialog:

    UncaughtPromiseError > RequestPendingError
    REGISTER request already in progress, waiting for final response
        at Registerer.register (sip.js)
        at Registerer.register (registerer.js)
        at UserAgent.attemptReconnection (user_agent_service.js)

When the WebSocket transport drops while a REGISTER is in flight (which happens on an idle tab: SIP.js sends a periodic re-REGISTER before the registration expires, and the socket may be closed by an idle timeout or by the machine going to sleep in the meantime), the final response never comes back. SIP.js only clears its internal `waiting` flag from the REGISTER response callbacks (onAccept/onReject/onRedirect); it is never reset on transport loss or request timeout. The Registerer is then stuck `waiting` forever, and every subsequent register() rejects with a RequestPendingError.

On top of that, our wrapper's register() did not return the SIP.js promise, and attemptReconnection() called it without awaiting, so the rejection escaped the surrounding try/catch and surfaced as an unhandled promise rejection. Worse, the WebSocket error was resolved right after, so the user appeared reconnected while VoIP registration was actually dead until the page was reloaded.

This commit makes register() recreate the underlying SIP.js Registerer when it is stuck `waiting` (a clean instance starts with waiting=false), and return the promise so callers can await it. attemptReconnection() now awaits it, so any rejection goes through the existing retry/back-off logic instead of bubbling up as an uncaught error.

The recreation is intentionally conditional: disposing a healthy registerer would send an unregister (REGISTER expires=0) racing with the fresh register (expires=600) and could leave us unregistered, so we only recreate when a request is actually stuck.

Forward-Port-Of: odoo/enterprise#120424
Forward-Port-Of: odoo/enterprise#119701

Steps to reproduce
---
1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56").
2. Map the columns to Debit and Credit and import.

The imported amounts are multiplied by 100: "1.234,56" is imported as 123,456.00.

Issue
---
This only happens when both `account_bank_statement_import_csv` and `account_bank_statement_extract` are installed, which is the default in any Accounting database since both modules are auto-installed.

`account_bank_statement_extract` turns debit and credit into real Monetary fields on `account.bank.statement.line`:

https://github.com/odoo/enterprise/blob/af863c5a53d0ab50fe67cb9ea910391d4a1979dd/account_bank_statement_extract/models/account_bank_statement_line.py#L7-L8

Because they are now real fields, the generic importer already converts those columns to floats:

https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/base_import/models/base_import.py#L1281-L1285

The CSV statement wizard then parses the same columns a second time:

https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L92-L93

The first pass correctly reads "1.234,56" as "1234.56", but the second pass sees a lone dot, mistakes it for the thousands separator, strips it, and produces 123456. The wizard now parses debit and credit only when they are virtual fields, so when they are real fields the values parsed by the generic importer are reused instead of being parsed twice.

Without `account_bank_statement_extract`, debit and credit exist only as virtual import fields, so the generic importer skips them and the wizard parses them once. That is why the regression stays hidden until the extract module is present.

opw-6227083
---

Forward-Port-Of: odoo/enterprise#118979

### Issue
When importing an electronic bill (such as a German XRechnung) that uses the Peppol EAS 'EM' (Email) with an email address as the endpoint, the import fails during the automatic partner creation

An error is logged in the chatter stating that the Peppol endpoint is not valid and should contain only letters and digits

Since 'EM' stands for Email, the system should allow the '@' character and validate the endpoint format

### Cause
While the export logic supported the 'EM' EAS, the validation flow triggered during automatic partner creation on import was too restrictive

The global regex `PEPPOL_ENDPOINT_INVALIDCHARS_RE` did not include the '@' character, causing the
validation to fail for any email address

Additionally, there was no specific format check implemented for the 'EM' EAS type to ensure the endpoint is a valid email string

### Steps to reproduce
- Install `account_edi_ubl_cii`
- Go to Accounting / Vendors / Bills
- Upload an electronic invoice containing an EM EAS and an email endpoint (you can use the added test file or the one from the ticket)

Before the fix, an error is raised in the chatter and the partner cannot be created automatically

opw-6205745

Forward-Port-Of: odoo/odoo#266894

Description:

- The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings.
- Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position.
- Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements.
- This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations.

19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486

Before fix:
<img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" />

After fix:
<img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />

Forward-Port-Of: odoo/enterprise#118937

Steps to reproduce:
- Start from a database where the eCommerce app is not installed.
- Open the website configurator.
- In the first step, choose "I want an eCommerce".
- In the Pages and Features step, select all Pages.
- Select a theme that adds an eCommerce category snippet, for example "Treehouse".
- Build the website. => During the first `configurator_apply`, `website_sale` is installed
   after the theme and the configured menu items are already created.
=> The homepage rendering then needs a `website_sale` configurator
   snippet template requested by the theme, but it was not generated
   during that first call.
=> The client retries `configurator_apply`. It now succeeds because
   `website_sale` is fully installed, but page and menu creation runs
   again and duplicates the menu items.

Before this commit, primary snippet template generation only read the manifest of the module being generated. When `website_sale` was installed from the first `configurator_apply`, it did not see addon snippets declared by the already installed theme. The first call could therefore fail while rendering the homepage after pages and menus were created.

After this commit, generation also reads installed theme addon snippets that target the module being generated. The `website_sale` configurator templates requested by the selected theme are created before the first homepage rendering, so `configurator_apply` does not retry after creating menu items.

task-5973739

Forward-Port-Of: odoo/odoo#261022

Steps to reproduce
---
1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56").
2. Map the columns to Debit and Credit and import.

The imported amounts are multiplied by 100: "1.234,56" is imported as 123,456.00.

Issue
---
This only happens when both `account_bank_statement_import_csv` and `account_bank_statement_extract` are installed, which is the default in any Accounting database since both modules are auto-installed.

`account_bank_statement_extract` turns debit and credit into real Monetary fields on `account.bank.statement.line`:

https://github.com/odoo/enterprise/blob/af863c5a53d0ab50fe67cb9ea910391d4a1979dd/account_bank_statement_extract/models/account_bank_statement_line.py#L7-L8

Because they are now real fields, the generic importer already converts those columns to floats:

https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/base_import/models/base_import.py#L1281-L1285

The CSV statement wizard then parses the same columns a second time:

https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L92-L93

The first pass correctly reads "1.234,56" as "1234.56", but the second pass sees a lone dot, mistakes it for the thousands separator, strips it, and produces 123456. The wizard now parses debit and credit only when they are virtual fields, so when they are real fields the values parsed by the generic importer are reused instead of being parsed twice.

Without `account_bank_statement_extract`, debit and credit exist only as virtual import fields, so the generic importer skips them and the wizard parses them once. That is why the regression stays hidden until the extract module is present.

opw-6227083
---

Forward-Port-Of: odoo/enterprise#118979

### Issue
When importing an electronic bill (such as a German XRechnung) that uses the Peppol EAS 'EM' (Email) with an email address as the endpoint, the import fails during the automatic partner creation

An error is logged in the chatter stating that the Peppol endpoint is not valid and should contain only letters and digits

Since 'EM' stands for Email, the system should allow the '@' character and validate the endpoint format

### Cause
While the export logic supported the 'EM' EAS, the validation flow triggered during automatic partner creation on import was too restrictive

The global regex `PEPPOL_ENDPOINT_INVALIDCHARS_RE` did not include the '@' character, causing the
validation to fail for any email address

Additionally, there was no specific format check implemented for the 'EM' EAS type to ensure the endpoint is a valid email string

### Steps to reproduce
- Install `account_edi_ubl_cii`
- Go to Accounting / Vendors / Bills
- Upload an electronic invoice containing an EM EAS and an email endpoint (you can use the added test file or the one from the ticket)

Before the fix, an error is raised in the chatter and the partner cannot be created automatically

opw-6205745

Forward-Port-Of: odoo/odoo#266894

Version:
----------
- 18.0+

Steps to reproduce:
-------------------
- Install `stock` module
- Enable `Storage Locations` from Inventory settings
- Create a tracked storable product with on-hand 8 units in `Shelf 1`
- Create Delivery 1 for 5 units and click `Mark as To Do`
- Create Delivery 2 for 5 units and click `Mark as To Do`
- Verify reservations:
  - Delivery 1 reserves 5 units
  - Delivery 2 reserves remaining 3 units
- Relocate all 8 units from `Shelf 1` to `Shelf 2` using the `Relocate` action from `stock quant`
- Reopen both deliveries

Issue:
------
After relocating stock between internal locations, reservations are reassigned
in the wrong order:
- Delivery 2 becomes fully reserved with 5 units
- Delivery 1 is reduced to 3 reserved units

This incorrectly swaps the original reservation priority between deliveries.

Cause:
------
The relocation wizard starts from:
`stock.quant.relocate.action_relocate_quants()`
which calls `move_quants()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/wizard/stock_quant_relocate.py#L70

`move_quants()` validates an internal stock move through `_action_done()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_quant.py#L1572

During validation, `_synchronize_quant()` moves the stock quantity from
`Shelf 1` to `Shelf 2`.

However, the already reserved delivery move lines still reference `Shelf 1`.
This temporarily makes the source quant negative (`available_qty < 0`),
triggering `_free_reservation()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L695-L700

Inside `_free_reservation()`, move lines are ordered using
`current_picking_first`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L816-L821

Since both deliveries share the same scheduled date, the fallback ordering
uses `-cand.id`, causing Delivery 2 (higher id) to be processed before
Delivery 1 (lower id).

The reservation cleanup therefore happens in this order:
- Remove Delivery 2 reservation (3 qty)
- Remove Delivery 1 reservation (5 qty)

The corresponding moves are then added to `move_to_reassign`
in the same order:
`[Delivery 2, Delivery 1]`
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L849

Later, `move_to_reassign._action_assign()` processes the moves in recordset
order:
- Delivery 2 reserves 5 units first
- Delivery 1 only gets the remaining 3 units

As a result, reservation priority is unintentionally reversed after relocation.

Fix:
----
Before calling `_action_assign()`, reverse `move_to_reassign` 

This ensures reassignment preserves the original reservation order:
- Delivery 1 is reassigned first and recovers 5 units
- Delivery 2 receives the remaining 3 units

The reservation state therefore remains consistent before and after
internal stock relocation.

---

opw-6218256

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

Forward-Port-Of: odoo/odoo#269973
Forward-Port-Of: odoo/odoo#265169

Description:

- The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings.
- Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position.
- Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements.
- This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations.

19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486

Before fix:
<img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" />

After fix:
<img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />

Forward-Port-Of: odoo/enterprise#118937

### Issue
On Runbot, trial, and client databases, the automatic extraction of the description does not work when a user changes the database language

When an expense is first generated up to 19.0, it requires a name and is temporarily given a localized placeholder like "Dépense sans titre..." in French

When the OCR results arrive, the system is supposed to detect this generic fallback string and overwrite it with the real extracted description

However, because of a language mismatch, the system fails to recognize its own placeholder. It incorrectly assumes the user manually entered that text and, to prevent losing user data, refuses to replace it

Before the fix, the title remains stuck on the placeholder
In very rare cases, the translation applies correctly, but it fails most of the time

### Cause
The OCR successfully finds the correct description, but in `_fill_document_with_results`, the expense name is not replaced

This seems to happen because `self` in `self._get_untitled_expense_name("")` carries a residual context that could override the correct language to use during the automated extraction process

Even though the user record and the detected language are correctly set to the alternative language, `default_receipt_name` appears to be generated in English ("Untitled Expense")

This would cause the subsequent string comparison with the actual translated name stored in the database to fail, blocking the update

### Fix
I made some tests in some generated RunBot and the user is correct and also the associated lang

I supposed self was containing lang details overriding the correct language to use

`self.env['hr.expense'].with_context(lang=user_id.lang)` seems to be working

### Steps to reproduce
The issue cannot be reproduced locally, follow these steps on a Runbot instance:
- Retrieve IAP OCR credentials from a trial database
- Enable Developer Mode in Settings
- Go to Settings -> Technical -> IAP -> IAP Accounts
- Add the credentials for the Document Digitization service
- Go to the Expenses app
- Change the user's language to French
- Import the expense image from the ticket
- Open the newly created Expense and click Refresh

Before the fix, the title should stay `Dépense sans titre...` If it's not the case, try a second import, it works times to times

opw-6103935

Forward-Port-Of: odoo/enterprise#118661

Steps to reproduce:
--------------------------------------------
1. Install `website_project` module
2. Create a new project
3. Add a customer to the project
4. Go to customer > add email and phone
5. Create a new task in that project:
    * Observe that the customer is the same as the project
6. Go to Website > Contact Us > Edit > Click on submit button
7. Set action to 'Create a Task' and select the created project in 'Project'
8. Click on Save and Open the URL in Incognito Mode
9. Go to the Contact Us page > Fill in the details > Submit
10. Comeback to our window and open tasks of the created project

Observation:
--------------------------------------------
1. A new task is created using the customer details entered in the form.
2. The existing task’s customer and the project’s customer are also incorrectly updated to this new customer.

Issue:
--------------------------------------------
The bug is in the `extract_data` method of the website form controller for projects.
A non-logged-in user submits the Contact Us form with name and an email that doesn't match any existing partner. The old code's `else` branch would set `partner_name` in the task record values without setting a `partner_id` https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/controllers/main.py#L65-L66

During task creation, the computed field `_compute_partner_id` automatically sets `partner_id` to the project's partner
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/project/models/project_task.py#L1440-L1441

`partner_name` is defined as
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/models/project_task.py#L12

In Odoo, a related field is essentially a shortcut to a field on a linked record The key attribute here is `readonly=False`. This tells Odoo:
    * On read: Get the value from `self.partner_id.name`
    * On write: Propagate the write back to `self.partner_id.name` (this is the inverse). So writing `task.partner_name = 'TEST'` is equivalent to writing `task.partner_id.name = 'TEST'`. It modifies the partner record itself, not just the task.

So, the partner record itself was renamed. Every record that references a partner now sees the new name

Solution:
--------------------------------------------
The fix passes `False` to `partner_id`, this way:
    * The existing partner is untouched
    * All other tasks and the sales order keep their correct customer

opw-6206080

Forward-Port-Of: odoo/odoo#264738

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

Steps to reproduce:
--------------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
2. Switch to a Swiss company.
3. Create an employee and create a user with HR rights but without Payroll rights.
4. Log in with this new user.
5. Update any value on the employee form (e.g., marital status or add a tag).

Issue:
-----------
Updating the employee raises the following error:
```python
You do not have enough rights to access the fields "slip_ids" on Employee (hr.employee). Please contact your system administrator.

Operation: read
User: 2
Fields:
- slip_ids (allowed for groups 'Payroll / Officer: Manage all contracts')
```

Cause:
---------
After this 4416eda, open payslips are recomputed automatically on every employee update:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/l10n_ch_hr_payroll_elm_transmission/models/hr_employee.py#L210-L213
`slip_ids` is restricted to payroll users:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/hr_payroll/models/hr_employee.py#L14 As a result, when an HR user without payroll rights updates an employee,
accessing slip_ids raises an **AccessError**.

Solution:
-----------
Use sudo() when accessing slip_ids so HR users can update employee records 
without issue.

**NOTE:**
The issue has been resolved from version saas~18.4 with the following commits:
279f09a9587674c035c514f966788a4dddfe9794 and  75d66d8

opw-6210358

Forward-Port-Of: odoo/enterprise#117387

At the end of the year, or when ending collaboration with an employee,
the employer may have to compute (not pay) the gross amount of the 13th
month that the employee is supposed to get, and send it to a Special
Social HORECA Fund.
Then, this fund will take care of the rest of the paperwork to deduct
taxes from the 13th month and send a payslip to the employee.

Since the employer does not pay the 13th month, but the Social Fund, the
employer has to send an equivalent of *12%* of the amount of the gross
salary submitted to the ONSS, each month, to the social fund.
For workers, the percentage is applied on *108%* of the gross salary.

Those values concerning the 13th month do not impact the employee's
payslip, but still have to appear on it. So an "is_informative"
field has been added to tell whether it should be displayed in this
special section of the payslip.

- If you're an employee, then your non-proratized 13th month (i.e.: its
max value) is the wage of your last payslip (i.e.: `employee_id.wage`)
- If you're a worker (*ouvrier*), then the 13th month's max value is
`your hourly wage * average max number of hours per month`

You then need to proratize the result in relation to the number of days
that have really been prestated and assimilated.

**NOTE:**
- **prestated days** are days you have really worked
- **assimilated days** are leaves that still count as a work days (e.g.:
legal leaves)

The sectorial documentation describes multiple proratization methods,
but they are all equivalent to this basic formula:
`(hours you have prested and assimilated / max number of hours you can
prestate or assimilate) * max 13th month you can get`

**These work entries are always assimilable:**
- legal leaves
- extra legal leaves
- public holidays
- small unemployment
- compensatory rest
- civic duties
- public mandates
- union obligations
- strikes
- temporary unemployment
- unemployment force majeure

**These work entries are assimilable with a limit of time per year:**
- maternity leaves: 15 weeks
- union education: 12 days
- military service: 6 months
- compelling reasons: 10 days
- paternity leaves: 10 days
- military reserve calls': 74 days

**The first 12 months of partial incapacities following a total incapacity
can be assimilated.**
But, the partial incapacity must be of at least of 66%, by 66%, they
mean at least 2/3 of the week should be a time off due to the
incapacity.
Since we don't really have a way to define that, as of now, partial
incapacities are not assimilated.

**Long sick leave periods can be assimilated at a rate of _50%_:**
- The period must be uninterrupted and of at least 6 months
- If it's smaller than 6 months, then we can see accross neighboring
years if it continues, and if it is more than 6 months
- If in the end it's more than 6 months, you can assimilate the period
of the current year (max 6 months per year)
- No period can be assimilated twice (e.g.: a period of two years cannot
be assimilated in both years)

**Short sick leave periods can be assimilated:**
- Up to 7 uninterrupted days per year can be counted assimilated. But,
if you have more than a defined threshold of sick leave days, then none
are counted.
- If you have at least a year of seniority, then the threshold becomes 6
months (i.e.: you still have your days if the number of days are below
six months). Otherwise, the threshold is 7 days. In both cases, max 7
days can be assimilated per year.

**Some days after the end of the contract up to the end of the year can be assimilated:**
- All days if the personnel is retired
- All days of early reitrement (aka "Prépension") assimilated at a rate
of 20%
- Max. 6 months for dead personnel

Even though this 13th month is not directly paid by the employer, it
still is a gross wage for the employee, so, the value of the 13th month
should be included in the computation of the CSS (*special social cotisation*)

[PARTENA's sectorial documentation](https://drive.google.com/file/d/1i8bj425ccEW0ZGvNSaQvEV6VIedmLYCS/view):

task-5477296

Version:
- 19.0

Steps to reproduce:
- Install Attendances and Time Off
- Create an internal user.
- Give the user: Attendances Officer access & No Time Off Officer/Manager rights
- Create an employee linked to the user.
- Configure the employee with a Flexible Working Schedule.
- Create and approve a Time Off request for the employee.
- Open: Attendances -> Gantt View
- Navigate to the month containing the employee's approved leave.

Issue:
- An access error is raised when opening a month that contains the employee's
  approved leave.

Cause:
- In `_handle_flexible_leave_interval`, the code accesses `leave.holiday_id`
  to read fields such as `request_unit_half`, `request_unit_hours`, and
  `request_hour_from/to` on the `hr.leave` model.
- When the current user has Attendances Officer rights but no Time Off
  access(rare cases), the ORM access check on `hr.leave` raises an AccessError,
  even though this read is purely for internal calendar computation and
  does not expose leave data to the user interface.
 
Fix:
- Added sudo() on holiday_id to access the employee's leave details
  and compute the work interval as expected.

Task-6264510

## Problem
If `qty_available` is computed with sudo (this can happen downstream of a `value_svl` compute), `bom_find` will discover boms that do not belong to the currently selected company. This can lead to discrepancies with the apparent available quantity.

## Solution
We will more strictly enforce the contextual companies when building the `_bom_find_domain`, looking at `self.env.context.get('allowed_company_ids')` and `self.env.companies.ids` as well as the original `company_id` and `self.env.context.get('company_id')`.

## Steps to Reproduce (runbot v18)
- 2 companies
- Storable product available to both companies
1. Create a BoM while on company 1, set to kit type, specify company 1, and consume at least one component
2. Switch to company 2 and receive 10 units (this should create inventory of the product itself, not the component)
3. On the product form, note 10 units on hand
4. Navigate to Inventory > Reporting > Stock, and search for the product. There are 0 units available (because you have no components)

opw-6228875

Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading directly from a file path, it fails when reading the exact same content from a buffer, returning a generic 'application/octet-stream' instead.

Because `guess_mimetype` primarily evaluates buffers, this upstream bug breaks MIME type detection for ZIP files (and related formats like docx, xlsx, etc.) in Odoo environments running this libmagic version.

Since we cannot directly fix the library itself, this commit adapts Odoo's `guess_mimetype` to fallback to our custom implementation when libmagic returns the generic 'application/octet-stream' to workaround this library's bug.

Upstream libmagic fixes:
- https://github.com/file/file/commit/f1adef05b8a85be50d28965b1fd21fcceacf7a4e
- https://github.com/file/file/commit/60b2032b96fc185b37fb0f2152e834efb2edad6e

Upstream python-magic issue:
- https://github.com/ahupp/python-magic/issues/354

runbot-938197