**Contract Amendment & Versioning Logic**

* When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract.
* For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract.
* When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data.
* Added a warning to notify users when a new offer will replace existing future versions.

**Technical Refactoring**

* Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's
* Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation.

**Simulation & Chatter**

* Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors.
* To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`.
* Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution.

task: 5408192

Forward-Port-Of: odoo/enterprise#103846

Cause:
======
Because the debounce function is called with await, the execution of
`debouncedSCSSColorsCusto` pauses for every mousemove event.
This prevents subsequent calls from overlapping, meaning the debounce
logic never triggers to cancel previous timers. This results in the
heavy SCSS generation running sequentially for every single mouse
movement, causing performance lag.

In other words, the await forced the browser to handle one request at
a time, completely finishing it before accepting the next one.

Solution:
==========
In the gradient picker, only update the visual CSS gradient preview
during drag and defer the `onGradientChange` callback to mouseup to
avoid triggering heavy operations (e.g. SCSS generation) on every
mousemove.

Steps to reproduce:
===================
1. Go to website & edit mode.
2. Click on Header block.
3. Click on background color preview & select Gradient & Custom.
4. Click and drag the Angle knob.
=> The website preview triggers excessive updates dragging the knob

opw-5411628

Forward-Port-Of: odoo/odoo#241764

## Context
On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it.

## Issue
When uploading a new picture, users can only replace the image or reorder it, but they cannot reshape it, crop it, or edit its size.

## Steps to reproduce
1. Install the *eCommerce* (`website_sale`) app.
2. Create a product and set a picture for it.
3. Go to that product's page in the Website app and open the website editor.
4. Click on the picture and replace it.
5. **The options to transform the picture are not displayed.**

## Cause
The transformation options are disabled due to the following static `exclude` variable in `ImageToolOption`:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/html_builder/static/src/plugins/image/image_tool_option.js#L16

## Solution
We should prevent the transformation options from being displayed **only** when the image is external. In such cases, certain options from the `ImageToolOption` (such as the `ImageTransformOption` or the `ImageShapeOption`) cannot be applied. This is confirmed by the message displayed when trying to crop an external image:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/web_editor/static/src/js/wysiwyg/widgets/image_crop.js#L164-L173

We can determine whether an image is external by looking at its `data-attachment-id` property. If it is present, the image was recently uploaded to Odoo.

On top of updating the `exclude` variable, we need to filter out the options that cannot be used on images from the eCommerce. These options are:
- Description
- Tooltip
- Transform (*"Transform the picture"*)
- Size

## Tests
The test checks that the behavior matches the one from previous versions: the options to edit an image are not displayed before replacing the image, but are displayed after. Both the test `image field should not be editable, but the image can be replaced` (shown below) and the new test from this PR fail if the modified `exclude` variable allow to edit the image before replacing it.

https://github.com/odoo/odoo/blob/dea5a1d28a1935c2b4d87c3c6e8c07cd874c7d6b/addons/html_builder/static/tests/image_field.test.js#L7-L16

## Options displayed
|   | Before this commit  | After this commit  | Previous versions |
|---|---|---|---|
|  **Before replacing the image**  | Media, Re-order | Media, Re-order  | Media, Re-order
|  **After replacing the image**  | Media, Re-order | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality


opw-5251864

Forward-Port-Of: odoo/odoo#247539
Forward-Port-Of: odoo/odoo#241071

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

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.


https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef


Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus.

Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657)

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

Forward-Port-Of: odoo/odoo#259257
Forward-Port-Of: odoo/odoo#250294

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

Forward-Port-Of: odoo/odoo#258909

Steps to reproduce:
----------------------------------------
1. Install the `hr_recruitment` module
2. Create a new user and configure the following access rights:
    * Employees: No
    * Recruitment: Officer Manage all applicants
3. Create new job position > Set created user in Recruiter
4. Log in with the created user
5. Go to Recruitment > Click on the Configure button of that job position

Observation:
----------------------------------------
The Trackers page is not visible on the job position form for the recruitment officer user.
If the user is additionally granted the Employees → Officer: Manage all employees group, the Trackers page becomes visible. The access to the recruitment Trackers should not depend on the Employee 'Officer: Manage all employees' access right.

Issue:
----------------------------------------
The visibility of the Trackers page depends on the Employees → Officer: Manage all employees group instead of the recruitment officer access rights

Solution:
----------------------------------------
Grant access to the Trackers page using the Recruitment Officer group so recruitment officers can access it without requiring the employee officer privileges

opw-5969416

Forward-Port-Of: odoo/odoo#252209

**Steps to reproduce:**
- Set up an event, go put it's state to Annonced
- Set up any online payment method (Demo also triggers the bug)
- Go to a PoS that sells the event tickets
- Purchase one and pay with the online payment method
- Once on the ticket screen, the button to download the event tickets is not displayed

**Why the fix:**
The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration.

The problem is that with an online payment method, once we enter the **read_pos_data** method that sets
the values for the frontend, the order is still in draft, so we just return without doing anything.

We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment.
In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed.

A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed.

opw-5438432

Forward-Port-Of: odoo/odoo#258986
Forward-Port-Of: odoo/odoo#249306