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

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

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

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