**Problem:**
When a template is restricted to a department, appraisals for employees of that department do not use it — a generic (global) template is used instead.

**Steps to reproduce:**
1. Create an appraisal template and restrict it to a department.
2. Make sure at least one global (no department) template also exists.
3. Open a new appraisal and select an employee of that department.
4. Observe the appraisal template stays on the global one.

**Current behavior:**
The global template that was auto-selected before an employee was chosen is kept, ignoring the department-restricted template.

**Expected behavior:**
The template restricted to the employee's department is selected.

**Cause of the issue:**
On a new appraisal the template is computed before an employee (and therefore a department) is set, so a global template is pre-selected. When the employee is then chosen, `_compute_appraisal_template` reruns but the `appraisal.appraisal_template_id or ...` clause short-circuits on the already set global template and never falls through to the department's template.

**Fix:**
Evaluating the department's template before the existing value ensures a department-restricted template takes precedence over a template that was only auto-selected as a default. The existing value is still preserved when the department has no template of its own, so deliberate choices are untouched.

opw-6293936

Forward-Port-Of: odoo/enterprise#121377

Issue :-

Steps to Reproducet: SaaS 19.3
- Create a new database Install the Sale module.
- Create a product set some On Hand quantity for that product (via Inventory adjustment).
- Create a Quotation using that product.
- Confirm the quotation (turning it into a Sales Order).
- Open the Forecasted Report for that product.

The Reserve / Unreserve button in the Forecasted Report not render.
<img width="1811" height="323" alt="image" src="https://github.com/user-attachments/assets/4093bddb-f332-4b84-a482-a6604ebcb318" />

Regression from the OWL3 rendering context migration ("[REF] stock,*: run rendering context migration script"), which rewrote the template call `displayReserve(line)` into `this.displayReserve(line)`. https://github.com/odoo/odoo/commit/df40bc9e261a62c045e7e6150a60663a582e7dae and it comes in 19.2 onwards version.

The previous bare call compiled to `ctx['displayReserve'](...)`, so the method executed with `this` bound to that render context, which does own `line` and `line_index`. The lookups resolved by accident, not by design. as far as i have known.

With the explicit [`this.`](https://github.com/odoo/odoo/commit/df40bc9e261a62c045e7e6150a60663a582e7dae#diff-c556e01f9a3ebdb27bb6599d12b74c7bb0a433177cc0e126365cb763a874d9f4R81) form required by OWL3, `this` is correctly the component instance, so `this.line` and `this.line_index` are undefined:

```py
  - `this.line_index - 1 >= 0`    -> NaN >= 0 -> false, the block is
                                     skipped and `splittedLine` stays true
  - `this.lines[this.line_index]` -> undefined
  - `.includes(undefined)`        -> false, so `isOnHand()` is false
```
<img width="1404" height="786" alt="image" src="https://github.com/user-attachments/assets/6d2cb88b-a695-4388-9b5e-3eac266f1877" />

`displayReserve()` therefore always returns a falsy value and the `t-if` never renders the button. `isOnHand(line)`, which the template also calls directly to render the reservable quantity, is broken for the same reason.

Root cause: 
loop variables produced by `t-foreach`/`t-as` live only on the template render context and must never be read off `this` in a component method. The previous code depended on OWL2 resolving a bare template call against that context, which OWL3 no longer does.

``` with the displayReserve(line) ```
<img width="1185" height="599" alt="image" src="https://github.com/user-attachments/assets/ed79f6db-f95c-437f-baf8-f65391df14e7" />

```with the this.displayReserve(line)```
<img width="1020" height="641" alt="image" src="https://github.com/user-attachments/assets/61103db5-7e0a-4362-9dd4-c2f47db2bd97" />

Fix: 
derive the values from the `line` argument the methods already receive, instead of reading them off `this`.
```py
  - `displayReserve()`: `const line_index = this.lines.indexOf(line)`, and
    use the `line` argument in place of `this.line`
  - `isOnHand()` / `isReconciled()`: test against `line` directly, since
    `this.lines[line_index] === line` inside the loop
```
The template is unchanged: the OWL3-compliant `this.displayReserve(line)` call stays as the migration left it, and no method signature changes.

``` with the current fix```
<img width="1100" height="480" alt="image" src="https://github.com/user-attachments/assets/39147abb-ba5e-42ae-84f5-3d7cbadda1e1" />

<img width="1879" height="304" alt="image" src="https://github.com/user-attachments/assets/fafd3d6a-7591-4dbd-a85c-8fb9de541dd8" />


OPW:- 6363290

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

**Problem:**
On a job position whose company is left empty ("Visible to all"), the Recruiter dropdown does not propose any user anymore: only the "Create" option is offered. The same happens on applicants without a company. Only saas-19.2 is affected: 19.0/19.1 still use the res.users-based recruiter field, and on saas-19.3 the company became mandatory on job positions.

**Steps to reproduce:**
1. Install Recruitment
2. Open a job position whose Company is "Visible to all" (e.g. any demo job position)
3. Edit the Recruiter field

**Current behavior:**
The dropdown shows no user, only the "Create" option.

**Expected behavior:**
The dropdown lists the recruiters of all companies, as it does (per company) when a company is set.

**Cause of the issue:**
Commit 05e22346050d replaced the res.users-based `user_id` recruiter field with the hr.employee-based `recruiter_id`, declared with `check_company=True`. For check_company fields, `_description_domain()` sends the client `company_id and [('company_id', 'in', [company_id, False])] or [('company_id', '=', False)]`. When the record has no company, the domain falls back to `[('company_id', '=', False)]`, and since `hr.employee.company_id` is required, no employee can ever match. This reintroduces the issue previously fixed by 5dfe494e62af for the old user_id field: the `allowed_user_ids` mechanism introduced there was dropped by the field replacement.

**Fix:**
`check_company=True` brings nothing to these models server-side (neither `hr.job` nor `hr.applicant` has `_check_company_auto`): its only effect is that client-side domain. Folding the company condition directly into the recruiter domain with `('company_id', '=?', company_id)` keeps the per-company filtering when a company is set and degrades to no filtering when it is not, mirroring what is already done for `interviewer_ids` on the job position. The domains become strings so the client keeps evaluating `company_id` per record.

opw-6290312

Forward-Port-Of: odoo/odoo#270529

### Steps to reproduce

1. Trigger an error whose browser object has no `stack` property (for example, a `DOMException` such as `AbortError`).
2. Let the web error service format its traceback.

### Current behavior

`formatTraceback()` calls `error.stack.split(...)` unconditionally, which raises a second `TypeError` and masks the original error.

### Expected behavior

The original error is formatted and reported even when the browser does not provide a stack trace.

### Fix

Use the existing technical name and message as the traceback when `stack` is absent. A focused regression test covers an `AbortError`-like object without `stack`.

### Tests

- `git diff --check`
- `node --check addons/web/static/src/core/errors/error_utils.js`
- `node --check addons/web/static/tests/core/errors/error_service.test.js`
- `@web/core/errors` HOOT suite: 24 tests, 107 assertions passed.

---

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

Forward-Port-Of: odoo/odoo#276864

Selecting an online media-library illustration for a product image (or any field using the media dialog) saved the wrong image, or failed with "Please try to reupload this image" or a "raw is undefined" crash.

Steps to reproduce
==================
1. Open a product and edit its image
2. In "Select a media", search a term (e.g. "new")
3. Click one of the online library illustrations

=> The wrong image is saved, or an error notification is shown

Root cause
==========
Library media results carry a media-library id, not a local ir.attachment id.
imageSave persists them as real attachments (save_library_media, run inside super.save) but then reads them back using the original media-library id. That id either collides with an unrelated local attachment, e.g. a type='url' demo record with no raw, hence the wrong image and the "reupload" warning or matches no record at all, so the read returns undefined and accessing .raw throws.

Fix
===
Use the ids of the attachments actually created by the render step, carried on the rendered <img> elements (dataset.attachmentId), instead of the media-library ids.

opw-6353273

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

Before this commit, the maximum weight and volume allowed on a delivery method were checked against transfers using the quantity in the unit of the move, while the weight and volume of a product are expressed per reference unit. The same checks on sale orders already use the quantity in the reference unit.

Steps to reproduce:
- create a delivery method with a maximum weight of 10 kg
- create a product in Units weighing 1 kg with Dozens in its allowed units
- create a delivery transfer of 2 Dozen of the product and select the carrier on the transfer

The 24 kg shipment is weighed as 2 kg, so the carrier is proposed on the transfer although it exceeds its maximum weight, and it is correctly refused on a sale order for the same quantity. With a unit smaller than the reference one, valid carriers are hidden instead.

Solution:
Use the quantity in the reference unit of the product, as done for sale orders and everywhere else the shipment weight is computed.


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

Forward-Port-Of: odoo/odoo#277425

**Steps to reproduce:**

- Create an attribute of type always, 2 values A and B for it
- The two values should have an extra price, like 100 for A and 150 for B
- Create an attribute of type dynamic, 2 values C and D for it
- C should have an extra price of 100 and 150 for D
- Make a product with both of those product, set the price to 100

2 possibilities:

- In the PoS, click the product, on the product popup, the price is 100
- This 100 is the product's price and does not change even if we change the values
- Order that product and buy it with variants A and C
- Click on the product again, the price is 300, which is correct
- When we click on D, the price is reset to 100, but should be 350

**Why the fix:**

When computing the popup's title, we try to get the current product based on the variants choices in the popup. If the product is found, we take that, because it means that it's already in the database.

https://github.com/odoo/odoo/blob/0d7f5058664b501779b833609468e535b34356bf/addons/point_of_sale/static/src/app/components/popups/product_configurator_popup/product_configurator_popup.js#L260

If we do not find it, we just take the product template, which does not contain the current extra prices, which is why we got a price of 100 in the exemple.

The product is not found because in the case of dynamic variants, the product is only created once it has been ordered at least once. Which means that for this newly created product, it is not yet in the database, so we take the product template instead of the product itself.

We now also add the extra price for a product if it is undefined, meaning it has not been found in the database yet.

We can't directly update the getter for the priceExtra, as it's also used to build the payload. As the rest of the code works fine with dynamic products with extra price the way it is sent now, we only change the title instead of changing the entire logic and computation.

opw-6326125

Forward-Port-Of: odoo/odoo#273411

In the bubble layout, the `name="company_address"` div was inside an unconstrained `<td>`, causing percentage-based widths set in `company_details` (e.g. `width: 25%` on a image) to resolve against the full table cell width, resulting in oversized content compared to other layouts.
**Without fix:**

<img width="1127" height="411" alt="withoutfix" src="https://github.com/user-attachments/assets/244c3407-1dbb-4b83-95d9-ebaba2b2b13c" />

For e.g, The folder layout wraps the same block in a `w-50` div, so percentage widths resolve against ~half the page width.

<img width="1111" height="410" alt="folderexp" src="https://github.com/user-attachments/assets/ee72712a-94da-483c-9a8e-cb3a850dac8e" />

Added `w-50 ms-auto` to the `name="company_address"` div in the bubble layout to align its sizing context with the other layouts, ensuring consistent rendering of user-defined styles in `company_details` across both layouts.

**With fix:**

<img width="1119" height="413" alt="wfix" src="https://github.com/user-attachments/assets/6b1caf24-3a8e-450f-865e-cce2b9788fe9" />



Commit which made the bubble layout in table: https://github.com/odoo/odoo/commit/8eb61a245cd3b650e309fdb55d24654c34d785cd

opw-6287230



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

Forward-Port-Of: odoo/odoo#275228
Forward-Port-Of: odoo/odoo#270725