Steps to reproduce:
------------------------------------------
1. Install Time Off module
2. Create a new Time Off type with Payroll Code (e.g, TEST)
3. Duplicate the Time Off type

Observation:
------------------------------------------
User Error raised:
```
Cannot insert 'Test (copy)':
Work entry type 'Test' of code 'TEST', with no country assigned, already exists.
```

Issue:
------------------------------------------
When you duplicate a Time off type, Odoo's default `copy()` method doesn't modify the code field. The `_check_code_unicity` constraint enforces that each combination of `code` and `country_id` must be unique. Since your duplicated record has the same `code`, the same `country_id` and a different `name`. The constraint correctly raises an error.

Solution:
------------------------------------------
Override the `copy()` method to automatically append a suffix to the code field when duplicating, similar to how the name field gets '(copy)' appended.

opw-6225931

Forward-Port-Of: odoo/odoo#265144

Steps to reproduce:
-------------------
1. Install Fleet with demo data.
2. Create a contract for a vehicle (A) with a recurring cost of 1000
 and "Monthly" frequency.
3. Go to Reporting > Costs and verify the monthly cost
 (it shows 1000).
4. Create another contract for the same vehicle (A) with a
 recurring cost of 50 and "Monthly" frequency.
5. Check the monthly cost again.

Issue:
------
The reported cost is incorrect. Instead of 1050 (1000 + 50), it shows 2100.

Cause:
------
The query uses multiple LEFT JOINs on the contract table, including:
https://github.com/odoo/odoo/blob/9ca36dbe53692309bac84329de3b54a1c510cce0/addons/fleet/report/fleet_report.py#L103

These joins overlap and produce duplicate rows for the same
vehicle and month, which results in inflated cost totals.

Solution:
---------
Replace the multiple LEFT JOINs with a single LATERAL join.
This ensures the contract table is processed once per vehicle per month and
avoids duplication, resulting in correct totals.

**Before:**
<img width="940" height="609" alt="image" src="https://github.com/user-attachments/assets/e5b3e747-1135-4674-97c9-4e4fd9986dfd" />

**After:**
<img width="1053" height="590" alt="image" src="https://github.com/user-attachments/assets/f0df3819-07fb-4de5-aab3-5b4c6f10d213" />



opw-6024132





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

Forward-Port-Of: odoo/odoo#256051

Currently, error occurs when user removes date on Accrued Expense Entry wizard.

Steps to replicate:
- Install `purchase` and `accountant` with demo.
- Open any Purchase Order > Click on cog menu > Accrued Expense Entry.
- Remove value from `date` and click else where.

Error:
```
  File '/home/odoo/odoo19/community/addons/account/wizard/accrued_orders.py', line 67, in _compute_reversal_date
    if not record.reversal_date or record.reversal_date <= record.date:
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'

```

Cause:
- As the user removed value from `date`, [here] `record.date` is received as False.
- As a result the comparison `record.reversal_date <= record.date` causes this error to occur.

Solution:
- Added a conditional check for `date` before the date comparison.

[here]: https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/account/wizard/accrued_orders.py#L67

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

Forward-Port-Of: odoo/odoo#269418
Forward-Port-Of: odoo/odoo#262568

Have an x2many field displayed as a list in a form view. In the arch, the x2many form view **isn't** inlined. In that x2many form view, there's a properties field.

When a record is clicked, `extendRecord` is called to add the new fields (those of the form) into `this.fields` and those fields are fetched. If there're properties in the property definition, fake fields are created to represent them (see `_processProperties`). However, because of extendRecord, the static list and the record don't share the same reference to the `fields` object. As a consequence, the `fields` object of the static list isn't updated with the fake property fields.

If the user closes the record, and opens/closes it again, there's a crash, because the record is re-updated with the fields of the static list, and thus doesn't know about those property fields anymore.

This commit fixes the issue by ensuring that we keep the same `fields` object when extending a record, s.t. the list and all its records always share the same object.

Bug originally reported here: https://github.com/odoo/odoo/pull/268312


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

Forward-Port-Of: odoo/odoo#269717

Issue:
----------------------------------------
When in a negative timezone, the "Out of Office until..." text in discuss shows the day before.

Steps to reproduce:
----------------------------------------
- Change the timezone of the user to "America/Toronto" for example
- Have an employee currently on leave until tomorrow
- Open discuss to chat with this employee
- The "Out of Office until..." shows today's date

Cause:
----------------------------------------
When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone).

Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date.

Solution:
----------------------------------------
Add `timeZone:"UTC"` in the options to avoid the timezone conversion.

opw-6252040

Forward-Port-Of: odoo/odoo#268886
Forward-Port-Of: odoo/odoo#267479

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

Steps to reproduce:
-----------------------
1 - Install the `purchase` and `stock` modules.
2 - Create a storable product with tracking enabled.
Set the Cost (standard price) to 50.
3 - Open the product form and go to the Purchase tab.
   * Add a vendor with:
   * Quantity: 2
   * Price: 10
 
4 - Create a Reordering Rule for this product:

   * Route: Buy
   * Trigger: Manual
   * To Order Quantity: 2
 
5 - Click on the Order button to generate a purchase order.
6 - Open the generated Purchase Order and verify the Unit Price
on the purchase order line.
7 - Open the same product and go to the Purchase tab.
In the existing vendor line, add an End Date lower than today so
the vendor pricelist becomes expired.
8 - Reopen the same reordering rule.
Change To Order Quantity to 1.
9 - Click on the Order button again

Issue:
-----
The generated purchase order line gets a Unit Price of 0
instead of keeping the product cost or a valid fallback price.

Root Cause:
--------------
- When clicking on `Order`, it triggers `action_replenish`, which calls the
procurement flow:
`_procure_orderpoint_confirm` → `run` → `run` → `_run_buy`.

- Inside `_run_buy`, the system checks whether a `purchase.order.line`
already exists. In this case, the PO line exists, so it calls
 `_update_purchase_order_line`.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L137

- In `_update_purchase_order_line`, the system tries to fetch a seller using
 `_select_seller`,
- which internally calls `_get_filtered_sellers`.
https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L759

- However, if the seller's `end_date` is less than `today`,
 `_get_filtered_sellers` skips that seller and returns no valid seller.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L731-L733

- As a result, `_update_purchase_order_line` does not find any seller and falls
back to setting `price_unit` to `0`, causing the purchase order line price to
be updated incorrectly.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L259

---

opw-6117461

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

Forward-Port-Of: odoo/odoo#269971
Forward-Port-Of: odoo/odoo#262396

## Issue
When using the browser's dark mode, non-mandatory text fields in sign documents appear with a dark background, which does not match the aesthetic of the rest of the page.

## Steps to reproduce
1. Set your browser's theme to a dark theme (in Chrome, go to Settings > Appearance > Theme, chose a theme from the dark options)
2. Install Sign (`sign`)
3. Open a Sign template and add 3 Text fields:
    - Mandatory
    - Non-mandatory
    - Read-only (for comparison)
4. Click *Sign Now*
5. **The non-mandatory text field has a dark background.**

## Cause
Since a [PDF.js update](https://github.com/mozilla/pdf.js/commit/ae1cbc6a9ecc738d6777830488ad5481b97338bc), the `light dark` color-theme was added to `:root`. This means that the element will react to the settings of the browser and adapt its background and text color. In this case, there's no other `background-color` provided to mandatory fields, resulting in them using the dark color of the browser theme.

## Fix
We make the default background of text fields transparent then we update the selector of `.o_sign_sign_item_required` to prevent their `background-color` from being overwritten by that new transparent background.

|            | Before | After |
|------------|--------|-------|
| **Light mode** |    <img width="211" height="99" alt="6213059-before-light" src="https://github.com/user-attachments/assets/c4c70394-c7c2-4dbf-92b9-c1362d1cf9c8" />    |   <img width="207" height="89" alt="6213059-after-light" src="https://github.com/user-attachments/assets/63142be5-9f7d-4d5d-94e8-ef9428e1b778" />    |
| **Dark mode**  |    <img width="220" height="95" alt="6213059-before-dark" src="https://github.com/user-attachments/assets/19149c3d-511e-407c-821e-f318f373368a" />    |    <img width="210" height="103" alt="6213059-after-dark" src="https://github.com/user-attachments/assets/0b412d4f-061f-41b3-aae9-569b9a8219dc" />   |

opw-6213059

Forward-Port-Of: odoo/enterprise#117589

## Issues
When creating a new timesheet entry from the systray menu, that entry is added at the end of the list, which is inconvenient when the list gets long, as it requires to scroll through the entirety of it to see the most recent entry.

## Steps to reproduce
1. Install Timesheets (`timesheet_grid`)
2. Open the systray menu
3. Create two timesheet entries
4. The second (= most recent) entry appears below the first (= oldest) entry

## Cause
Since https://github.com/odoo/enterprise/commit/5901619141c81085111f2ee65b54492abf1e324f the entries are sorted based on the create date in ascending orer. This means that the oldest entries appear at the top, and the most recent at the bottom. On top of that, new entries were added at the end of the list instead of the start.

## Test
The existing test `Creating a new timesheet places it at the top of the list` was only adding one entry to the list, thus was not properly testing **where** the new entries were added.

opw-6284059

Forward-Port-Of: odoo/enterprise#120258

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

In v19.3, [PR #241780](https://github.com/odoo/odoo/pull/241780/changes) 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.

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

**Solution:**
Use `.sudo()` to bypass access control for the system-level computation. This allows:
- HR users without payroll rights to view employee type counts
- The computation to complete without access errors

**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
tbg- 2751

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

…unt number

When a provider returns an account without `account_number` (typical for Canadian banks, which do not use IBANs), the existing-journal search ran with `bank_account_number = False`. Because `bank_account_number` is a related field on `bank_account_id.account_number`, that search matched every bank journal in the user's allowed companies whose `bank_account_id` was unset.

If any of those journals was tied to a connected online link, the new sync was blocked with the misleading error "There's already a synchronized journal linked to this IBAN", even though no IBAN was involved.

Skip the search entirely when `account_number` is falsy: without an identifier there is nothing meaningful to dedup against, and the downstream code already handles `existing_journals` being empty by creating a fresh journal.

Note: when the provider omits `account_number`, a delete-and-recreate of the connection will now create a fresh journal rather than coincidentally reusing an unlinked empty-`bank_account_number` journal. That reuse path already failed (with a spurious "IBAN already connected" error) as soon as the user had more than one such journal, so the prior behavior was not reliable. The supported recovery path remains the reconnect button on the existing journal, which uses the `active_id` branch and is unchanged.

opw-6253563

Forward-Port-Of: odoo/enterprise#119848

Problem:
When printing an invoice for a Latin American (LATAM) company, the company's document layout is not used in the header of the invoice. For example, if an Argentinian company has set up a Bubble layout as its document layout, the header of the invoice will not have the bubble.

Steps to reproduce:
1. Install l10n_ar
2. Create an invoice using Electronic Sales Journal
3. Set document layout to Bubble in the company settings
4. Print the invoice
5. Notice that the header of the invoice does not have the bubble

Cause:
Most LATAM localizations use custom headers for their reports. In report_templates of l10n_latam_invoice_document, it checks if custom_header is set to decide whether to display the custom header. If custom_header is set, the div with class "header" will be hidden, and the custom header will be displayed after the div with class "header". Since the div with class "header" contains the background image that corresponds to the document layout, the background image will not be displayed when div with class "header" is hidden.

Solution:
Instead of hiding the entire div with class "header" when custom_header is set, only hide the table inside the header. This way, the background image of the document layout will still be displayed even when a custom header is used.

opw-6204062

Forward-Port-Of: odoo/odoo#267164

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