Steps to reproduce:
- Configure POS → enable Allow Flexible Pricelist and assign the Default pricelist.
- Create product A with variants.
- Add product A to the Default pricelist.
- Set a fixed price for product A in that pricelist.
- Open POS session.
- Select product A in POS.

Observation:
- In ProductConfiguratorPopup dialog, pricelist price is not considered

Cause:
- After this [commit](https://github.com/odoo/odoo/commit/5e77c14912324bf967a55a1a40bb01071eca5c8b) the text appears from `get title()` method, which do not consider pricelist

Fix:
- we now consider pricelist for displaying title.

**Before**
<table>
<tr>
<td>
<img width="400" height="300" alt="image" src="https://github.com/user-attachments/assets/6faac3e4-a579-41db-a2ad-fdc9c24e422f" />
</td>
<td>
<img width="400" height="300" alt="image" src="https://github.com/user-attachments/assets/14035707-aa23-4fb3-97d7-d0ce2f6e6b46" />
</td>
</tr>
</table>

**After**
<img width="340" height="225" alt="image" src="https://github.com/user-attachments/assets/3beeaf76-fc1a-42a5-9f3c-dabc43389d36" />


opw-5270319

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

Forward-Port-Of: odoo/odoo#237899

## Problem

A logout occurs when an image in the chatter is requested through a third-party security proxy (like Cisco Secure Email or Microsoft SafeLinks) via a boomerang redirect following this flow:

- A user (Person A) opens an Odoo record. The chatter contains an image previously sent by a correspondent (Person B) whose email client or mail server rewrote the image URL to point to a security proxy.
- Firefox tries to load the image. The URL points to `cisco.com/...`. (for example)
- The proxy scans the link and redirects the browser back to the original Odoo URL: `odoo.com/web/image/...`.
- Firefox follows the strict (now deprecated) `rfc6265bis` rule: it looks at the whole redirect chain.
Since it sees a cross-site hop (cisco.com), it flags the final request as cross-site.
    -> Because Odoo's session_id is `SameSite=Lax`, Firefox refuses to send
    the cookie on this "false" redirect
- Odoo receives the request at `/web/image` without a session_id.
- Odoo creates a new, empty session to process the request.
- At the end of the request, because save_session is True by default, Odoo sends a `Set-Cookie: session_id=NEW_EMPTY_ID` header in the response.
- The browser receives this `Set-Cookie` header, and this time *applies a different policy*: it considers the header as same-origin, allowing it to overwrite the previously valid session cookie with this new one that corresponds to a fresh, unauthenticated session.
- The user is instantly logged out of their current Odoo tab.

## Context on Web Compatibility

This "redirect chain consideration" was a controversial part of the `RFC6265bis` draft.
Chrome and Safari never fully implemented it because telemetry showed it broke ~1% of the web. In March 2024, the HTTP Working Group (HTTPWG) officially decided to remove this requirement from the spec (reverting to a more permissive model) because it was deemed not web-compatible. Firefox, however, still enforces this strict behavior in many versions.

## How to we fix this

We set `routing={'save_session': False}` on the `/web/image controller`.

- This prevents Odoo from sending the `Set-Cookie` header if the session is dirty or new.
- Even if Firefox sends the request without a cookie, Odoo won't "reply" with a new session ID.
- The user's legitimate session cookie remains untouched in the browser.

## Sources
- HTTPWG Decision (March 2024): https://github.com/httpwg/http-extensions/issues/2104
- Reverting RFC6265bis: https://github.com/httpwg/http-extensions/pull/2750

opw-5184217
opw-4698750
opw-5166151

Forward-Port-Of: odoo/odoo#242582
Forward-Port-Of: odoo/odoo#242061

Steps to reproduce:
---------------------------------
1. Install `hr_skills` module
2. Open the Employees app and open any employee record
3. Go to the Resume tab
4. In the Skills section, click Add for any skill type
5. Select a skill that is already added to the resume
6. Click Save & Close in the Select Skills wizard
7. A validation error is displayed, click Close
8. Close the Select Skills wizard.

Observation:
---------------------------------
After closing the wizard, another default skill is added to the resume even though a validation error was raised.

Issue:
---------------------------------
In the following code:
https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/hr_skills/static/src/fields/skills_one2many/skills_one2many.js#L79-L82 During record save, the validation error scenario was not handled properly. When a validation error occurred, changes made to the virtual record were not discarded, causing the initial (invalid) changes to be incorrectly retained instead of being rolled back

Solution:
---------------------------------
When a validation error occurs while adding a skill, discard all changes made to
the virtual record before throwing the error. This ensures that no unintended
skill is added.

opw-5423196

Forward-Port-Of: odoo/odoo#247464
Forward-Port-Of: odoo/odoo#240697

Steps to reproduce:
--------------------------------
1. Install `industry_fsm_sale` module
2. Go to Settings > Configure Document Layout
3. Select the Bubble document layout and save
4. Open any Field Service task
5. Use the Products smart button to add one or more products
6. Click the Settings icon > Print > Field Service Report

Observation:
--------------------------------
In Time & Material tables using the Bubble layout, table borders show a mix of rounded corners and sharp edges, resulting in inconsistent visuals

Issue:
--------------------------------
The table tags in the report were missing the `table-borderless` class. As a result, the layout-applied rounded borders conflicted with the default table borders

Solution:
--------------------------------
Add the `table-borderless` class to the affected table tags so the tables inherit consistent rounded borders from the document layout


Before:
<img width="787" height="317" alt="before_css" src="https://github.com/user-attachments/assets/dac136a8-022a-4c36-8cdb-1c0fbb048f3e" />


After:
<img width="816" height="372" alt="after_css" src="https://github.com/user-attachments/assets/b5f96e75-2cd3-44cf-89e3-9a3b564c8369" />


opw-5401612

Forward-Port-Of: odoo/enterprise#105616

**Steps to reproduce:**
* Install the `stock_barcode`, `quality_control` modules.
* Go to *Inventory > Configuration > Settings* and enable **Packages**.
* Create a product with **By Lot** tracking enabled and set a barcode reference.
* Create a quality control point for this product with following configuration:
  * Operation: *Receipts*
  * Control per: *Quantity*
  * Control Frequency: *All*
  * Product: the previously created lot-tracked product.
* Create a receipt for this product with a quantity of 6 and `mark as todo`.
* Open the *Barcode* app and process the receipt.
* Scan the product barcode.
* Scan some quantity of the product with lot *LOT01* and put those units into a 
package(Put-In-Pack).
* Scan the remaining quantity with lot *LOT02* and put those units into a
 different package(Put-In-Pack).
* Click on **Quality Checks**.

**Observed behavior:**
* Only one quality check is created, even though the receipt contains two different
lots that should each generate a quality check.

**Cause:**
* In `_inverse_qty_done`, move lines are marked as *picked* when `qty_done` is
equal to quantity(Demand).
* During the `write` operation, quality checks are created only for move lines
that are not picked, which prevents creating a quality check for each lot.
* Relevant code: https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/quality_control/models/stock_move_line.py#L39 https://github.com/odoo/enterprise/blob/464dc0c65548f3f440b293b534616743ddd5e130/stock_barcode/models/stock_move_line.py#L67-L71

**Fix:**
* Ensure that quality check points are generated correctly when validating
products through the Barcode app using the Put in Pack option.

---

opw-5405221

Forward-Port-Of: odoo/enterprise#105535
Forward-Port-Of: odoo/enterprise#102714

Currently journal items shown don't belong to the account group that
they should belong to, and from saas-18.3 an error will be generated
after following the below steps or step mentioned in ref PR [1].

- Install `Accounting (accountant)` with demo data
- Create account groups e.g., name as `Test 1` and code prefix `1 to 1`
- Go to the general ledger report
- Click on `Journal Items` of the account group line `1 Test 1`

Error from saas-18.3:
`ValueError: Cannot convert account.account.group_id to SQL because it is ...`

This error occurs because PR with ref [1] in 17.0 added the` group_id` field of the
`account.account` model to the search domain. However, in 18.0, commit [2] modified
this field so that it is no longer stored. As a result, when a search domain includes
this `non-stored` field, Odoo skips the domain evaluation and logs a error at code
line [3]. Consequently, the changes introduced by commit [1] have no functional effect from 18.0.

Also, starting from saas-18.3, passing such a non-stored field in a domain raises an
explicit error at code line [4], instead of being silently ignored.

This commit resolves the issue by introducing an SQL query that
returns the account ids related to `record_id(account group id)`
include `record_id` as `None`.

[1]: https://github.com/odoo/enterprise/pull/100191
[2]: https://github.com/odoo/odoo/commit/854c3b27aa5476c208572f19e64f8f3364bfc381#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R114-R767
[3]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/odoo/osv/expression.py#L1166-L1174
[4]: https://github.com/odoo/odoo/blob/00517e9e085c6fa9e00bedb8aee122a60e407fea/odoo/orm/fields.py#L1201

sentry-7100657414

Forward-Port-Of: odoo/enterprise#103137

### Issue:
When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0

### Cause:
In `export_boe()`, the `report_lines` were get based on the `section_report` options
However, `section_reports` do not store the date
or return periodicity of the selected report
As a result, using their options always fetched data for the current period instead of the specified year

### Note:
`_generate_mod_390_page2()` also had issues:
some lines were missing or incorrectly indexed

The mod 360 format, it strict in the structure with specific index so it may produce invalid documents

The latest documentation for mod 390:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` and switch to ES Company
- Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025)
- Open Tax Return, switch to Mod 390, and set year to 2025
- You should see data in the 2 first sections
- Use the gear icon, and download the BOE
- Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report

opw-5457374

Forward-Port-Of: odoo/enterprise#106676
Forward-Port-Of: odoo/enterprise#104928