Steps to reproduce:
-------------------------------------
1. Install the Subscription module.
2. Go to Subscription > Configuration > Recurring Plans.
  * Open a Monthly recurring plan and enable Align to Period Start.
3. Create a new Subscription:
  * Select the configured monthly plan.
  * Add any subscription product.
  * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025).
4. Confirm the subscription.
5. Create a draft invoice.

Observation:
-----------------------------------
In the invoice line, you see the message:
`61 days 11/01/2025 to 12/31/2025`

It should be:
`1 Month 11/01/2025 to 11/30/2025`

Issue:
-----------------------------------
https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range

Solution:
-----------------------------------
Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled

For upsell orders, the fix is NOT applied because for upsells, `new_period_stop`
is already set to the parent subscription's `next_invoice_date`, which
represents the correct billing boundary.

opw-5920036

Forward-Port-Of: odoo/enterprise#107407

**Problem:**
When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in the wrong position in the generated PDF.

**Steps to reproduce:**
1. Create a product named: لوحة توزيع كهربائية 100 أمبير (شنايدر )
2. Create an invoice with that product
3. Print the invoice PDF in English
4. Observe the brackets are misplaced in the description column

**Current behavior:**
Parentheses appear detached from the Arabic word they enclose, floating at the wrong end of the text.

**Expected behavior:**
Parentheses correctly wrap the enclosed Arabic text.

**Cause of the issue:**
Odoo's report CSS sets `direction: ltr` on elements that are ancestors of the line description span. When CSS `direction: ltr` targets the same element as `dir="auto"`, wkhtmltopdf's WebKit engine lets the CSS rule win, keeping the paragraph base direction as LTR. The Unicode BiDi algorithm then resolves parentheses (neutral characters) using LTR as the base direction, misplacing them.

**Fix:**
Placing `dir="auto"` directly on the `<span>` that renders the line description — rather than the parent `<td>` — avoids the CSS override. wkhtmltopdf then detects the first strong character (Arabic) and uses RTL as the base direction for that span, allowing the BiDi algorithm to correctly position the brackets.

opw-5884712

Forward-Port-Of: odoo/odoo#258521
Forward-Port-Of: odoo/odoo#251190

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

Steps to reproduce:
=================
1. Go to eLearning > Courses and create a published course
2. In the Description tab, add a button with a link and save
3. Go to /slides on the website
4. The course card appears with a grey overlay (0.5 opacity)

=> Published course cards with a button in the description show a grey overlay
=> Only unpublished course cards should have the grey overlay

Cause:
======
In [1], the opacity for unpublished courses was moved from `.o_wslides_course_unpublished` to its container using a `:has()` selector. However, the selector `div:has(> .card + .card-body, ...)` was too broad: it matched any container whose `.card` child had a sibling `.card-body`, regardless of whether the course was unpublished.

When a course description contains a button (or any block-level element), the browser renders the button outside the `.card` element. This creates the structure `div > .card + .card-body` that the selector matches, applying a 0.5 opacity grey overlay to fully published courses.

Solution:
========
The fix restricts the first selector arm to only match when `.o_wslides_course_unpublished` is the sibling, ensuring published courses with buttons in their descriptions are not affected.

[1]: https://github.com/odoo/odoo/pull/249969

opw-5900287

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

Forward-Port-Of: odoo/odoo#258700

## 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/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).

**Example**:
- **Context**:
  - Two companies exist: Company A and Company B.
  - Two users exist: User A and User B.
  - User A can only access Company A (company_ids=[A], company_id=A).
  - User B is linked to both companies (company_ids=[A, B], company_id=A).
  - The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
  - User A edits User B and saves the form.

- **Steps**:
  - User A performs a web_read to load User B: company_ids contains only Company A.
  - User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.

**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.

**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.

Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904

**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

Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either.

E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68).

So here, we skip the update of relations to accounts on tax groups, if the account already exists.

Forward-Port-Of: odoo/odoo#259160