This commit fixes two issues regarding the filmstrip in the /shop page :

- Adding a minimum height to the elements of the `default` and `bordered` designs, so that their heights remain consistent whether they contain an image or not.
- Display a placeholder image for the `images` filmstrip if empty.

task-5491550

| Before | After |
|--------|--------|
| <img width="613" height="103" alt="image" src="https://github.com/user-attachments/assets/852ef2ce-6265-4622-9e30-4e8112bbf264" /> | <img width="618" height="114" alt="image" src="https://github.com/user-attachments/assets/0933c0c2-a669-4236-9148-a25226214ce6" /> |
| <img width="718" height="164" alt="image" src="https://github.com/user-attachments/assets/ac1b8d91-44fa-4ce0-8ddb-beba271a2423" /> | <img width="718" height="164" alt="image" src="https://github.com/user-attachments/assets/8676e9f9-074b-40e9-a75b-76561437c081" /> | 

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

Forward-Port-Of: odoo/odoo#263118
Forward-Port-Of: odoo/odoo#255543

### Issue:
With `l10n_ro_edi_stock_batch`, internal transfers using multi-step routes were requiring a delivery carrier
This makes no sense for internal moves

### Cause:
The method `_compute_l10n_ro_edi_stock_enable` was overridden to check for `not picking.batch_id`
However, for multi-step delivery routes, internal pickings still triggered the carrier validation, as no check on the `picking_type` was performed

### Steps to reproduce:
- Install `l10n_ro_edi_stock_batch` with demo data and switch to RO Company
- In Settings, enable `Multi-Step Routes`
- Set the RO Warehouse's Outgoing Shipments to `Pick then Deliver (2 steps)`
- Create a Product (e.g. RO product)
- Create a Delivery Method (e.g. RO Delivery, Partner: Any, Delivery Product: RO Product)
- Create and Confirm a Sale Order for the RO Product
- From the Sale Order, click Delivery and validate the picking 
### Before the fix, internal transfers raised:
`The picking RO Co/PICK/00001 is missing a delivery carrier.`

enterprise-PR: https://github.com/odoo/enterprise/pull/114166
opw-5925087

Forward-Port-Of: odoo/odoo#263036
Forward-Port-Of: odoo/odoo#257293

Currently, when a res.parter is given a parent, base_address_extended runs _onchange_city_id. This sees the city change and alters the zipcode to match the city's zipcode. However, this field can be manually altered to differ from the city's zipcode. Thus, when a parent has a city, the zipcode will override the manually entered zipcode for a child contact.

This commit solves this by checking for the parent's zipcode before blindly setting it to the city's zipcode.

Steps to reproduce:

1. Install `base_address_extended`
2. Enable "Enforce Cities" on a country `(res.country)`
3. Add a city to that country with a zipcode of 123
4. Create a new contact (parent) and select the configured country
5. Select the city (the zipcode will fill in from the city's zipcode)
6. Overwrite the zipcode with 456
7. Save the contact (parent)
8. Create a new contact (child)
9. Set the company to the parent contact and save
10. The zipcode of the child will be the city's zip (123), not the parents' zip (456), thus the addresses will be different, and the child contact type will be 'other'

opw-6131280
closes #262651

Forward-Port-Of: odoo/odoo#262651

**Steps to reproduce:**
Log in as admin and ensure notifications are handled in Odoo.
Enable push notifications and the 'Task Created' subtype for a project.
As a second user, create a new task in that project.

**Current behavior before PR:**
admin received escaped content in the push notification
(e.g., `A new task has been created in the "Project Name" project`)

**Cause:**
For inbox users, we send a client-side push notification using `previewText` as
the body. This field returns a markup object containing escaped characters,
which are converted to a string when passed to the notification body. Since the
notification body only accepts plain text, these characters are displayed
literally to the user.

**Desired behavior after PR is merged:**
admin receives the unescaped content in the push notification.
(e.g., `A new task has been created in the "Project Name" project`)

task-5112810

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

Forward-Port-Of: odoo/odoo#263187
Forward-Port-Of: odoo/odoo#240331

Steps to reproduce:
---
- Install the `Sales and Inventory` modules.
- Enable `Units of Measure & Packagings` from Settings.
- Go to `Sales > Configuration > Products > Units & Packagings.`
- Create a new unit > Pack of 12 with quantity 12 and unit Units.
- Create a new product > enable Track Inventory, set Quantity On Hand to 100, and in the `sales` tab,
 under `Upsell & Cross-Sell`, set `packaging` as` Pack of 12`.
- Create a Sales Order > add the product and set the quantity to 3, with a unit Pack of 12.
- Confirm the order and validate the delivery.
- Create and confirm the invoice.
- Return `1 unit` from the delivery and validate it.
- From the invoice, create a `credit note` with quantity 1 unit and confirm it.
- Go back to the Sales Order.

Issue:
---
- On the Sales Order: `Delivered Quantity` shows` 2.92` while `Invoiced Quantity` shows `2.91`.

Root cause:
---
- At [1] & [2], in `_compute_qty_invoiced`, the `_compute_quantity` method is called without specifying a `rounding_method`, so it defaults to `UP` (1/12 rounded to 0.09), while `_compute_qty_delivered` explicitly uses `HALF-UP` (1/12 rounded to 0.08), leading to inconsistent rounding.

Solution:
---
- In this PR, the same rounding method (HALF-UP) is applied when computing the invoiced quantity to ensure consistency with the delivered quantity.

[1]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale/models/sale_order_line.py#L896-L912
[2]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale_stock/models/sale_order_line.py#L193-L209

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

Forward-Port-Of: odoo/odoo#263011
Forward-Port-Of: odoo/odoo#258024

### Steps to reproduce:
- Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps
- Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets = User:own timesheets'
- In Sales, create a service with the following specifications:
    - 'Create on Order' is 'Project'
    - 'Invoicing Policy' is 'Based on Timesheets'
- Create a new quotation that requests this service and click 'Confirm'
- In 'Project' > 'Configuration' > 'Projects', choose the newly created project and add a line that has the new employee in the 'Invoicing' tab
- Log in as that employee and go to 'Timesheets'
- Create a new entry for the newly created project
- Click the project's name
> Access Error: You are not allowed to access 'Collaborators in project shared'
(project.collaborator) records.

### Cause of Issue:
This happens because the user doesn't have access rights to the 'Project' app, hence they don't have access to `collaborator_ids` which are retrieved here. https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/project/models/project_project.py#L1113-L1120

### Fix:
Since an access to the 'Projects' app isn't necessary to view a project assigned to you, `sudo()` is necessary for hr_timesheet users without project access rights.

opw-6074833

Forward-Port-Of: odoo/odoo#263152
Forward-Port-Of: odoo/odoo#258370

Steps to reproduce:

* Enable multiple languages
* Go to Sale Order Templates and create a new template
* Add a product line, then click the translate button on the description field
* A confusing validation error appears for missing `sale_order_template_id`

Issue:

* Instead of highlighting the missing required fields on the sale order template form view, it raises a misleading validation error on `sale_order_template_id`

Cause:

* `useTranslationDialog` always attempts to save the passed record directly. In O2M list views, the field can belong to a nested relational record, so the correct behavior is to save the root record instead.

Affected Version: 17.0

Before:
<img width="1919" height="1014" alt="image" src="https://github.com/user-attachments/assets/cd61381d-289a-4df4-bdf2-7881fa851939" />

After:
<img width="1920" height="887" alt="image" src="https://github.com/user-attachments/assets/5218c74b-c024-4994-b816-cb7ae69b420f" />

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

Forward-Port-Of: odoo/odoo#262988
Forward-Port-Of: odoo/odoo#262755

The session id rotates softly every 3 hours

For some features, the mobile app sometimes does requests "outside" of the mobile app, through a webview for instance, and if the session rotation interval is reached at that moment, it rotates the session and the `set-cookie`
instruction setting the new session cookie is received by the webview only, it's not propagated back to the mobile app.

Then, this could lead for the user to be logged out of the mobile app if the soft automatic session rotation happens at the very unfortunate moment the request through that webview happens.

For instance, the mobile app uses a webview to download attachments. If the session rotation happened during that request, the mobile app doesn't receive the `set-cookie` header and doesn't receive the new session id, leading for the user to be logged out of the mobile app.

This revision aims to provide an option for the mobile app to temporary skip the session rotation for a specific request, such as the requests done through the webview during downloads.

This option to be able to disable the rotation is not a security threat: If an attacker passes that header to disable the interval session rotation, he would avoid the session to be changed every 3 hours, but if he wouldn't he would still receive the new session id every 3 hours.
The session rotation is for legitimate user / computer to rotate their session every 3 hours so that in case of data leak of their browser cookies, there is a chance the session cookie is already no longer valid when published on the public web. Legitimate users have no benefit using this option header to disable the rotation.

Forward-Port-Of: odoo/odoo#263325

#### Issue:
The budget report displays duplicate analytic lines.

#### Steps to reproduce:
In a new company:
- Create a budget with one budget line (Analytic Account A).
- Create one analytic item (linked to Analytic Account A).
- Open the budget report and remove the default "open budget" filter.
Duplicate amounts appear in the pivot view and duplicate lines appear in the list view.

#### Cause:
In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report.

#### Fix:
Use three separate queries, each with specific filter conditions to guarantee unique results:
Q1 - Analytic lines with no matching budget line.
Q2 - Analytic lines matched to a budget line with no company (null-company).
Q3 - Analytic lines matched to a company-specific budget line.

OPW-6051696

Forward-Port-Of: odoo/enterprise#116612