Version: saas-18.3

Reported issue:
1. Marc Demo creates a sign request from a template whose fields are automatically populated from the linked record.
2. It is sent to himself. He does not have access to all records of a referenced model (e.g. Sales Orders).
3. The "Linked To" (reference_doc) field is edited afterwards to point to a record the signer does not have access to. By the time it's signed, the value of that record becomes visible - so a user can, simply by changing the linked record, see the value of a record they were never authorized to access. Even a Sign Manager could link a request to a record they have no access to and later see its value through it.

Issue:
`reference_doc` could be set or changed to any record of any allowed model with no validation that the acting user actually has access to it. In the interface, you can only create a signature request from a record you can see, but editing `reference_doc` manually (via write(), RPC, etc.) was not held to the same rule, making it an easy way to leak information about records outside your normal access.

Cause:
The only restriction was cosmetic, enforced client-side by the record picker widget filtering its search results. Nothing on the server validated the value being written to `reference_doc`.

Fix:
`write()` now checks that the acting user has read access to the target record before allowing `reference_doc` to be set, raising a ValidationError otherwise, bringing manual edits in line with what the interface already enforces when creating a request.

**Steps to reproduce:**
* Install the **Accounting** module.
* Unhide the **Start Date** and **End Date** fields on invoice lines.
* Create and post a customer invoice with deferred dates.
* Go to **Accounting → Reports → Deferred Revenue Report**.
* Add an annotation to a deferred revenue line by clicking the **annotate** from three dots next to the account.
* Export the report in **XLSX** format.

**Observed behavior:**
* The export fails with a server error: `UnboundLocalError: cannot access local variable 'annotations_x_offset' where it is not associated with a value`

**Cause:**
* The variable `annotations_x_offset` is assigned inside the `for header_level_index, header_level in enumerate(options['column_headers'])` loop, which writes the "Annotations" column header for each header level.
* The Deferred Revenue Report produces an empty `column_headers` list, so the loop body never executes and `annotations_x_offset` is never assigned.
* When the code later tries to write annotation data for each report line, it references the unassigned variable, causing Python to raise `UnboundLocalError`.

**Fix:**
* Introduce a boolean flag `annotations_header_written = False` before the header loop to explicitly track whether the "Annotations" column header has already been written.
* Inside the header loop, set `annotations_header_written = True` after writing the header.
* After writing all individual column headers (where `x_offset` already points to the first free column after all data columns), add a fallback: if `report_annotations` is set but `annotations_header_written` is still `False`, assign `annotations_x_offset` from the current `x_offset` and write the "Annotations" header.

opw-6354473

Forward-Port-Of: odoo/enterprise#122768

[FIX] l10n_ch: fix default contract type

This task is runbot error fix that occured from 19.0 to 19.2

Bug reproduction:

1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step

Bug cause:

1 - When l10n_ch_hr_payroll_account is installed:

    1.1 - contract type becomes "Permanent contract with monthly salary"
    1.2 - the employee is not swiss but it has this CH contract type

2 - data-tooltip starts with Permanent contract instead of contract

    2.1 - Tour fails

3 - contract_type_id is overwritten in swiss modules

    3.1 - Default is assigned without looking to the country of self.env

Bug solution:

1 - If the country is not swiss, the default is assigned as False

    1.1 instead of assigning swiss contract type to the non-swiss emp.

Note: I started to fix it from 17.0 BUT:

. in above versions field overwrite might be in different CH modules . fix all in the above versions

task-6392040

runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358

Forward-Port-Of: odoo/enterprise#126507

Description of the issue/feature this PR addresses:

Installing Odoo via the .deb package continuously causes issues with the asset bundles. This is because of the following daisy chain of behaviors:

- `dpkg-buildpackage` parses `SOURCE_DATE_EPOCH` from debian/changelog and then clamps the Modified date of all files to at max that epoch ([src](https://launchpad.net/debian/+source/dpkg/1.18.8)). The relevate date is the one written after the email in the topmost changelog entry
- This is preserved when unpacking the .deb package, the OS does not change it
- The Asset loading logic in ir.qweb and ir.asset relies on the Modified date (via [`os.path.getmtime`](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/ir_asset.py#L49)) to determine the hash that serves a Version for the asset bundles ([src](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/assetsbundle.py#L775), [src](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/assetsbundle.py#L148))
- The controller and ir.qweb compiler rely on this Version hash to correctly invalidate outdated asset bundles and force re-generation of the bundle content as neccessary

Current behavior before PR:

debian/changelog has not been changed or maintained since 2020 and its timestamp remains `Tue, 15 Dec 2020 10:28:49 +0100` This results in the Modified Date being clamped to 2020, which means the files no matter how much is changed always look like last modified on this date. Therefore the Version hash for the asset bundles never changes, and the asset reload logic does not trigger correctly.
This is especially dangerous for setups which use several code sources with different file delivery methods, for example installing Community via .deb but Enterprise via git. This results in only some asset bundles not being updated (those not touched by Enterprise modules) while others are, which then generates an OWL error as it detects the content being different between the bundles ([src](https://github.com/odoo/odoo/blob/17.0/addons/web/static/lib/owl/owl.js#L3333))
For versions 18+, a very common result of this behavior is the portal chatter failing to work. This is because the same files like for example mail/static/src/core/common/thread.xml being loaded into both [`portal.assets_chatter`](https://github.com/odoo/odoo/blob/18.0/addons/portal/__manifest__.py#L69), which is not touched by an Enterprise module, but also into [`web.assets_frontend`
](https://github.com/odoo/odoo/blob/18.0/addons/im_livechat/__manifest__.py#L90) via im_livechat, which is a bundle touched by many modules, including Enterprise modules. Thus, is a file in the mail addon is changed, the changes are correctly applied to `web.assets_frontend`, but not `portal.assets_chatter`, causing an OWL error. This is extremely frustrating to fix, since it not only requires a manual Asset Rebuild, but also for every user to empty their Browser Cache, since the assets bundles are so large as to be guaranteed to be cached, and if the old version of the bundle is loaded from cache, the OWL error persists. A similar error can also happen with website, since the assets for the WYSIWIG editor are loaded as a module-specific bundle, `website.assets_wysiwyg`, which also fails to update, while of course the same assets being loaded to the general website asset bundle will be updated.

Desired behavior after PR is merged:

The builder for the nightly .deb package of Odoo writes a complete debian/changelog entry instead of merely replacing the first line. This entry includes the current date, thus ensuring the Modified date for the files is not clamped to years in the past. Down the line, this fixes the assets loading issue.


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

Forward-Port-Of: odoo/odoo#269458

# Introduction
This PR fixes broken mention links linked to the fact that we replace strings
without paying attention to the fact that some strings may contain others
that we want to replace later. This affects both id's and names of records.
See commit messages for more details.

# How to reproduce
- Create Contact A and then Contact B and either :
   - Contact B's id need to contain Contact A's id (e.g. Contact B id = 12; Contact A id = 1)
   - Contact B's name need to contain Contact A's name (e.g. Contact B name = ABC; Contact A name = AB)
- In a chatter create a message mentionning first Contact B and then Contact A
> Depending on the version, you might need to reload the page here

- Edit the message and save

# The issue
We see a broken mention in the chatter

# Cause
When saving an edited message, we give the raw body of the message (without the mention links) and the mentionend partners to `generateMentionsLinks` : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L152

This method's purpose is to replace the text links ("@Contact A") with actual html links. It does so by enumerating each partner given as an argument and replace the text mention with a placeholder :
https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L158

It will then replace the placeholders with actual links : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L208-L218

The issue is that in both of those steps, we can try to replace a string that is contained
in another string we want to replace. 

For exemple : 
"string123 some text string12"
If we try to replace "string12" first, then we will select the wrong string : 
"[string12]3 some text string12".

opw-6313748

Forward-Port-Of: odoo/odoo#272549

Before this commit, the test "Shows warning badge on mic/camera on non-granted permission in meeting conversations" failed on runbot, on 19.0:

Failed to find 1 of "button[title='Turn camera on']" (Timeout of 10 seconds). Found 0 instead.

This happens because the mock server numbers a new record with the highest id of the model plus one, so a record created right after the last one is deleted takes its id back. Joining another call leaves the meeting call first, and the session of the new call carries the id of the one just left. Leaving broadcasts
"discuss.channel.rtc.session/ended" for that id, and under load it lands after the join: the client reads it as its own session being closed and ends the call it has just joined.

This commit numbers the records of a model with a counter, started above the ids its definition gives, as a database sequence does, so a notification about a deleted record can no longer name a live one.

https://runbot.odoo.com/odoo/error/945965

Forward-Port-Of: odoo/odoo#282244

Steps to reproduce
------------------
1. Configure a product with a subcontracted BoM and a subcontractor.
2. Create a purchase order of 10 units for that product and confirm it.
3. Receive the 10 units.
4. On the receipt, use "Return for Exchange" on 3 units and validate both the return and the exchange receipt.

Issue
-----
After the exchange, the 3 units stay in the subcontracting location instead of reaching `WH/Stock`, and the received quantity on the purchase order line stays at 7 instead of 10.

`mrp_subcontracting` overrides `_prepare_move_default_values` to force the move `location_dest_id` to the subcontractor location for every `is_subcontract` move:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25
That is correct for the return, but the same override also runs for the exchange re-receipt, an `incoming` picking whose destination should be the stock location from `return_type.default_location_dest_id`:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/stock/wizard/stock_picking_return.py#L137-L153

The exchange move then goes from the subcontracting location back to itself, so validating it nets zero and `WH/Stock` never receives the units. Skipping the override when `new_picking.picking_type_id.code` is `incoming` lets the exchange land in stock.

The received quantity must also count that receipt. `_should_count_for_quantity_received` only counts `supplier` or `transit` sources:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/stock/models/stock_move.py#L330-L331 so the exchange, sourced from the internal subcontracting location,
is skipped while the return still subtracts its quantity. Counting subcontracting-sourced moves:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/mrp_subcontracting/models/stock_move.py#L312-L314 restores `qty_received` to 10.

opw-6410978

Forward-Port-Of: odoo/odoo#279431

Behavior before:
When uploading an animated GIF to fields utilizing image responsive sizing or cropping (such as employee avatars or product images), no downscaling or cropping occurs for sub-variants like 'image_128' or 'image_1024'. The responsive fields replicate the exact file size and data footprint of the original large image, leading to heavy storage overhead and unnecessary frontend asset loading.

Behavior after:
Animated GIF images scale down and crop correctly to match requested responsive dimensions and aspect ratios. Sub-variants take up significantly less space in the filestore, matching proportional dimensions without dropping or stripping the underlying animation loop. Large images that are smaller than requested boxes are safely left un-upscaled to maximize database deduplication.

Root Cause:
Historically, a legacy safeguard bypassed GIF resizing and cropping because older versions of the Pillow library did not gracefully handle multi-frame sequential image buffers. As a result, standard 'image.crop()', 'image.thumbnail()', or 'image.resize()' implementations would flatten multi-frame animated sequences down into a single, static first frame or throw dimension/mode mismatches during save operations.

Fix:
Intercept the image processing pipeline when encountering an asset identified as a GIF where 'is_animated' evaluates to True. Implemented a unified, in-place multi-frame helper routine (`_apply_gif_operation`) using PIL's 'ImageSequence.Iterator' to cleanly step through, normalize to a uniform color mode (RGBA), duplicate, and modify each animation frame individually. 

This single helper handles sequential workflows for both 'crop' and 'thumbnail' operations while preserving individual frame duration arrays and native loop metadata. Both 'resize' and 'crop_resize' leverage this logic to achieve precise dimensions cleanly.

Crucially, upscaling (expanding) is intentionally unsupported for animated GIFs. Forcing a low-resolution, 256-color indexed animation to stretch beyond its native dimensions forces heavy color dithering across every single frame. This breaks the sequential LZW pattern compression, causing the resulting file sizes to skyrocket catastrophically. The logic utilizes thumbnail boundaries to completely block this expansion, protecting the filestore from accidental bloat.

Benchmark:

--------------------------------------------------------------------------------------------
| GIF size    | Variant          | Size Before (KB)   | Size After (KB)   |
|---------------|--------------------|--------------------------|-----------------------|
| (2.5MB)    | image_1024  | 2475.87                 | 2475.87             |
|                   | image_128    | 2475.87                 |  257.93              |
|---------------|--------------------|--------------------------|-----------------------| 
| (3.8MB)     | image_1024 | 3724.93                 | 3724.93             |
|                    | image_128   | 3724.93                 |  463.62              |
|----------------|-------------------|--------------------------|-----------------------|
| (442KB)     | image_1024 |  432.49                  |  432.49              |
|                    | image_128   |  432.49                  |   36.14               |
|----------------|-------------------|--------------------------|-----------------------|
| (3.6MB)     | image_1024 | 3491.98                 | 3491.98             |
|                    | image_128   | 3491.98                 | 1728.25             |
|----------------|-------------------|--------------------------|-----------------------|

opw-6232841

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

Forward-Port-Of: odoo/odoo#273098

The product specifications table is displayed whenever the product has tags, even if none of them are visible on the ecommerce website.

The product tags template filters out non-visible tags, but the surrounding table remains rendered and appears empty.

Only display the tags table when at least one tag is visible on ecommerce.

@Tecnativa TT63855

**Description of the issue/feature this PR addresses:**

The condition used to display the product tags table considers all tags associated with the product, including those that are not visible on ecommerce.

**Current behavior before PR:**

When a product only has non-visible tags, the tags table is displayed without any content.

<img width="669" height="350" alt="image" src="https://github.com/user-attachments/assets/4758ea76-5186-4035-a065-aa4c71ce7053" />


**Desired behavior after PR is merged:**

The tags table is only displayed when the product has at least one tag visible on ecommerce.




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

Forward-Port-Of: odoo/odoo#278604