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

…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

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119760
Forward-Port-Of: odoo/enterprise#118759

[FIX] account_reports: only restore horizontal group from previous_options when it's available

The 'Ledger' group will only be available when in multicompany or using different journal groups. It was still restored from previous options, even when it shouldn't have been available.


=============================================


[FIX] account_reports: properly compute Ledger group when there's no journal group

To reproduce the issue

1) Populate the db with some data impacting the Balance Sheet
2) Delete all the journal groups that would be created by default
3) Open the Balance Sheet, with multiple companies active.
4) Select the "Ledger" horizontal group
====> The report is displayed horizontally grouped by company, but all amounts are 0.

This happens because, when no journal group exists, the "Ledger" horizontal group creates a column group per company, applying a domain doing ('journal_id', 'in', []), so nothing matches. This is caused by the fact that, in this case, options['journals'] will require to match all journals, and will hence be an empty list. We fix it by properly searching for all journals to build the horizontal group's domain when options['journals'] is empty.

Forward-Port-Of: odoo/enterprise#119418

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

[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

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#120492
Forward-Port-Of: odoo/enterprise#119084

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

Forward-Port-Of: odoo/enterprise#120233

Currently, an error occurs when downloading the asset template.

**Steps to Reproduce:**
 - Install the `account_asset` module without demo data.
 - Go to `Accounting` > `Configuration` > `Accounting` > `Chart of Accounts`.
 - Open the `Fixed Assets` account, set a `Depreciation` value, and remove the `account code`.
 - Go to `Accounting` > `Accounting` > `Assets & Liabilities` > `Assets`.
 - Click `With our template` on the screen.

`TypeError: startswith first arg must be str or a tuple of str, not bool`

After this [recent commit], account codes became optional and can be removed. As a result, when 
the code is removed from the Fixed Assets account and when donloading the asset template, the 
system checks whether the account name starts with the account code [1]. Since the account 
code is `False`, it raises an error.

This commit ensures that the check is only performed when the account code exists; otherwise, 
the account name is used directly for the asset account.

[recent commit]: https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277

[1]- https://github.com/odoo/enterprise/blob/421fce171dc158faa3b13406b6cea5c1c907ee49/account_asset/controller/asset_template_controller.py#L46-L49

sentry-7487406857

Forward-Port-Of: odoo/enterprise#117580

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

Forward-Port-Of: odoo/enterprise#120668
Forward-Port-Of: odoo/enterprise#119116

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#119303
Forward-Port-Of: odoo/enterprise#113227