**Problem:**
Since this PR https://github.com/odoo/odoo/pull/261798, both cogs lines have an 
analytic account, which causes the cogs 
to not appear on the project profitability 
report because cogs lines balance each other

**Steps to reproduce:**
- enable 'anglo saxon accounting' and 'analytic accounting'
settings
- create a storable product with automated std 
category, a cost of 10 and on hand quantity
- create a service product and set the 
'create on order' field to 'project'
- confirm a SO for 1 unit of the product and 
1 unit of the service
- validate the delivery and create and confirm invoice
- from the sale order, click on the project smart button
- from the project click on the dashboard smart button

**Current behavior:**
the cogs section don't appear in the profitability report

**Expected behavior:**
it should appear with a line with a value of -10

**Cause of the issue:**
since this PR https://github.com/odoo/odoo/pull/261798, both 
cogs line are linked to the analytic account. 
That's the expected behaviour but in the case of 
the project profitability reports, it prevents the user 
the see the cost of the product in the cogs section.

That's because, inside the 
_get_revenues_items_from_invoices() method, 
bot cogs_line are added to the cogs_line list.
https://github.com/odoo/odoo/blob/141cb292dc5e456161119e19f7a91665feaa0198/addons/sale_project/models/project_project.py#L699-L700

So when computing the amount_to_invoice for 
the costs ml_type, the balance of the lines 
will zero out each other and amount_to_invoice 
will be 0.
https://github.com/odoo/odoo/blob/141cb292dc5e456161119e19f7a91665feaa0198/addons/sale_project/models/project_project.py#L703-L716

As a consequence, the cost of goods sold 
section won't be created
https://github.com/odoo/odoo/blob/141cb292dc5e456161119e19f7a91665feaa0198/addons/sale_project/models/project_project.py#L718-L719

**fix:**
only the line with an account of internal type 
'expense' reflects the actual cost of the product 
sold in the context of the project.
So when computing the profitability report 
that's the only line we should consider

**test:**
test_report_invoice_items_anglo_saxon_automatic_valuation
checks that the cogs section is well displayed in the 
project profitability report.
In the PR (mentionned above) which sets the analytic 
account on the stock cogs line, lines were  
added in the test to manually remove the analytic 
account on the stock cogs line to make the test pass.

With the fix of this PR we can remove those additional 
lines in the test and it will check our use case well again.

opw-6412409

Forward-Port-Of: odoo/odoo#283144

Steps to reproduce:
===================
1. Add a video (e.g. a YouTube URL) to a product from the Sales app.
2. Open the product page on the website.
3. Slide the carousel to the video.

=> The video preview cover is blurry.

Root cause:
===========
The product images are rendered in a carousel (the shop_product_carousel template in ) where only the first slide  gets the "active" class; https://github.com/odoo/odoo/blob/af1b3ee2e7ac56a35bff5e030c3a831c27dbcf24/addons/website_sale/views/templates.xml#L3224-L3226 every other slide is "display: none".
A product video is rendered as a live <iframe> inside its slide, so when the video is not the first media its iframe loads while its container has no  dimensions (0x0). The embedded player then initializes as a small mobile player and loads a low resolution cover thumbnail (120x90), which looks blurry once the slide is shown at full size. Reloading only the iframe while the slide is visible fixes it, a full page reload does not.

Fix:
====
Defer loading the video iframes located on hidden slides their src is moved to a data-src attribute on start and restored once the slide becomes visible. The player then initializes at full size and loads a high resolution cover.

opw-6349394


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

Forward-Port-Of: odoo/odoo#274002

#### Steps to reproduce:
- In an editor field, select some text.
- Type `/` to open the powerbox: the selected content gets deleted.
- Apply any command, e.g. `Separator`.

=> Error: Selection is not in editor

#### Description of the issue this PR addresses:
- `makeSavePoint` overwrites the preserved cursors with the selection staged on the last reverted step, then re-applies the draft mutations. Here those mutations are the deletion of the selected content, done by `onBeforeInputInsertText` before `SearchPowerboxPlugin.onBeforeInput` makes the savepoint. Re-applying them removes the very nodes the staged selection points to, so the cursors end up detached.

#### Desired behavior after PR is merged:
- Only reset the cursors when there is no draft mutation, so the initially preserved selection is restored instead.
- This check added in 19.0 [1], but it isn't in 18.0 to saas-18.4.

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

task-6442210

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

Forward-Port-Of: odoo/odoo#282162

Root cause:
Since https://github.com/odoo/odoo/commit/f5cf856 the table of contents uses the scrollTo helper from web to reach the clicked heading. The helper only makes the element visible. When the heading is below the screen it is placed at the bottom border of the scrollable area, so the reader sees the heading but not the section under it. The second scrollTo call that was meant to correct this does nothing because the heading is already visible after the first scroll, so no branch of the helper runs.

Fix:
Pass isAnchor to the scrollTo call in scrollIntoView of table_of_content_manager.js. With this option the helper always places the element at the top of the scrollable area in both scroll directions, and the offset computed for sticky elements keeps working. The second scrollTo call is removed since one call is enough. This method is the one changed by the commit above and it is used by the editor and the readonly viewer, so both are fixed.

Steps to reproduce:
1. Open the Knowledge app and create an article
2. Add several headings with paragraphs between them so the article is longer than the screen
3. Type /table and insert a Table of Contents at the top of the article
4. Click an entry of the table of contents that points to a heading below the visible part of the page

=> the page scrolls so the heading is at the bottom of the page instead of the top

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6376092)

opw-6376092

Steps to reproduce:
--------------------------------------
1. Install the `mail_group` module
2. Go to Settings > Technical > Email > Alias Domains
3. Create an alias domain, for example, `localsystem.com`
4. Go to Settings > Technical > Discuss > Mail Groups
5. Open a mail group, for example, My Company News
6. Click the Emails smart button.
7. Create a new email, set the subject, author, and content, and accept the message
8. Go to Settings > Technical > Email > Emails and click Send Now if necessary
9. Inspect the Reply-To header of the received email.

Current Behavior:
--------------------------------------
The Reply-To address uses the display name of the author.
`Reply-To: 'Mitchell Admin' <newsletter@localsystem.com>`

Expected Behavior:
--------------------------------------
The Reply-To address should use the display name of the mail group.
`Reply-To: 'My Company News' <newsletter@localsystem.com>`

Issue:
---------------------------------------
When email notifications were sent from a mail group (`mail.group`), the `Reply-To` header incorrectly used the author's display name instead of the mail group's name (`self.name`)
https://github.com/odoo/odoo/blob/8990a10aa786be4c124ba3d228e7e23c50886fad/addons/mail/models/models.py#L693-L696

Solution:
---------------------------------------
1. Extracted display name logic into a separate `_notify_get_reply_to_name` method, which is overridden in `mail.group` to use the group's name as the Reply-To display name.
2. Updated `_notify_get_reply_to_batch` to browse the specific `res_id` before calling `_notify_get_reply_to_formatted_email`, since the method only needs the record being processed instead of the entire multi-record in self.
3. Ensured safe batch processing by providing a singleton record to the `mail.group` override, allowing it to safely access `self.name` without causing Expected singleton errors.

opw-6379281

Before:
--------------
<img width="930" height="354" alt="image" src="https://github.com/user-attachments/assets/ef8a297b-28c4-4601-8c5f-b69e9ed43296" />

After:
--------------
<img width="996" height="359" alt="image" src="https://github.com/user-attachments/assets/bd83a7ac-2026-4ad8-ac02-c167417fec7c" />

Clicking the translate button saves the form's root record before opening the translation dialog, since https://github.com/odoo/odoo/commit/9da52919a03dbcee5209430918195158c0652099. A record opened in an x2many form dialog keeps its changes for itself until the dialog is saved, see https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/web/static/src/model/relational_model/static_list.js#L193. Its pending changes are not part of the root record changes, so saving the root sends nothing to the server, and the translation dialog then shows the stored terms instead of the current content, or no terms at all when the stored value is empty.

The fix changes openTranslationDialog in translation_button.js, the place that decides which record to save. When the record keeps its changes for itself (record._noUpdateParent), the record is saved directly, like the button did before the commit above. The root record is still saved in the other cases, so the editable list case that commit fixed keeps working.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app, open a survey and click a question in the Questions tab
3. In the Description tab, change the description
4. Click the EN button on the description field

=> the translation dialog shows the terms of the previous description, not the current one

Ticket [link](https://www.odoo.com/odoo/project.task/6237291)
opw-6237291

Forward-Port-Of: odoo/odoo#269507

Steps to produce:
---
- Install `sale_management` and `sale_loyalty` module without demo.
- From sales > products > discounts & loyalty, create new loyalty card program and save.
- Now create new product of 100$.
- Create a user which have sales rights as `user: own documents only`.
- With that user, create new sale order with product and confirm.
- Try to cancel the order.

Issue:
---
- It shows the access error: 
```py
You are not allowed to delete 'Sale Order Coupon Points - Keeps track of how a
 sale order impacts a coupon' (sale.order.coupon.points) records.

This operation is allowed for the following groups:
	- Sales/Administrator

Contact your administrator to request access if necessary.
```

Root cause:
---
- Users with the `Sales: Own Documents Only` access right only have read permissions ([1]). When they cancel a Sales Order, the `_action_cancel` method attempts to clean up the temporary pending points allocated to the order by calling `self.coupon_point_ids.unlink()`. Because this call is executed without elevated privileges, the system blocks the deletion and raises an Access Error

Solution:
---
- Added `.sudo()` to the `unlink()` call for `coupon_point_ids` in the `_action_cancel` method. This ensures the pending point records are cleaned up with the necessary elevated privileges.

[1]https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/sale_loyalty/security/ir.model.access.csv#L16

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

Forward-Port-Of: odoo/odoo#283535
Forward-Port-Of: odoo/odoo#281477

The aim of this commit is to allow customer to make their batch payment
without facing a Traceback.

Context:
odoo/enterprise@35f5341b9b44cc16eaea311295a064189dd802cb introduced bug
during a badly handled forward port.
The method was removed in saas-18.3 in favor of a function. The forward-port
was half handled and now surfaces to Odoo's own production.

Generating a batch payment could generates the following Traceback:
```py
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal_sepa_ct.py", line 69, in _get_PstlAdr
    return super()._get_PstlAdr(partner_id, payment_method_code)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal.py", line 501, in _get_PstlAdr
    CtrySubDvsn.text = self._sepa_sanitize_communication(partner_address['state'][:35])
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'account.journal' object has no attribute '_sepa_sanitize_communication'
```

Task-id: None (internal issue)

**Steps to reproduce:**

- Create a contact with a phone number that has 9 characters
- Setup an UPS carrier, a configuration that works is UPS Saver as Service Type and UPS Package/customer supplied as a package type
- Create a quotation, put the created contact as a client
- Try adding a shipping and getting the rates
- An User Error appears, the phone number is too short

**Why the fix:**

Before this commit, any phone number that was less than 10 characters would raise an User Error, but some countries, such as Luxembourg, use phone numbers that are nine characters long or even less.

If we check the official UPS documentation (https://developer.ups.com/tag/Shipping?loc=en_EN#operation/Shipment), we can see in the Ship_to/Phone section, that the phone number should be a number between 1 and 15, not saying it should be 10 characters or more.
<img width="495" height="473" alt="image" src="https://github.com/user-attachments/assets/fed82987-ffb8-4b84-b282-6c3d3b4f304e" />


After this commit, we adapt the way we prevent the user from inputing phone numbers to fit the official UPS documentation.

opw-6307577

Forward-Port-Of: odoo/enterprise#122831