Steps to reproduce:
-------------------
* Let's say you're on company A, create a pos payment method
* Don't assign a pos yet
* Create a branch company sub_A
* Switch to that branch company
* Create a pos
* Now switch to company A but also select sub_A
* In the config of the pos from sub_A, try to add the new payment method and save
> Validation error -> Normal
* Now instead go to the payment method form
* In the point of sales select the pos sub_A
* Save
> No error
* Try opening the pos sub_A
> Validation error, same as the first one -> Normal

Why the fix:
------------
We already have a contraint on the pos config model checking that the companies match.
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/point_of_sale/models/pos_config.py#L469-L473

However when writing on the model pos payment there is no constraint and the ORM currently does not trigger constraints on comodel of the field we're modifying so we need to add this constraint on the pos payment method model as well

opw-6000206

Forward-Port-Of: odoo/odoo#253858

## [FIX] resource_mail: change placeholder for the many2many_avatar_resource in kanban

The default placeholder is "Search users...." which made little sense in the context of searching for resources.

## [FIX] web: give specification to AutoComplete in m2m tags popover

Before this commit, when the user uses the quick edit of m2m avatar
widget, the specification is not given to props since the popover does
not have the specification of the main component.

This commit makes sure the specification is given to popover to
correctly give them to the Autocomplete widget.

## [FIX] web: allow to change the popover to use in KanbanMany2ManyTagsAvatarFieldPopover

Before this commit, it was not possible to change the popover used in
KanbanMany2ManyAvatarFieldPopover in the case, we need to extend that
popover class used.

This commit allows to alter the popover class.

## [FIX] resource_mail: review m2m resource field widgets

This commit reviews the code in the different components for m2m
resource to use as much as possible the methods defined in the basic m2m
avatar widgets defined in web and mail.

## [FIX] resource: make sure resource without calendar set is flexible one

Before this commit, when an employee does not have a working schedule
set, neither work per day set, this employee is not considered as a
resource flexible in resource.resource record associated.

This commit makes sure this kind of employee be considered as flexible
resource.

task-6020304

Since the [website builder refactor], the `OptionContainer` component filters the option based on access right when rendering the list of options, and hides itself if there is no options visible when rendered. With [folding of options], the options are rendered only when the group is unfolded. Thus the component can hide itself only if unfolded. Generally, there is at least one option visible when a group is rendered, which appears when the group is unfolded. But when options are filtered because of access right, the filtered list is often empty, and the group disappears when unfolded.

This commit moves the filtering slightly earlier, so the options are filtered before rendering. If the filtered list of options is empty, the component shows nothing at all as it knows it has zero options, instead of a folded group.

Steps to reproduce:
- With a user with only the "restricted editor" access right (and not "editor and designer")
- Open website builder on /blog
- Click in the title in the cover
- Bug: the "Blog Page" options group appears (but it is empty, and disappears when opened)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
[folding of options]: 64d35ccd6fade9e0473686b8484f561b5f4215ce

task-6032728

This commit resolves a performance bottleneck that occurred when handling very
large sale orders (e.g., ~200 order lines). Previously, the util function
`getParentSectionRecord` determined the parent (sub)section of an order line by
iterating over all preceding order lines. Since this logic was executed for each
order line, the overall complexity became O(n²).

Moreover, this function was invoked inside the `shouldCollapse` method, which is
used in multiple UI flows during rendering. As a result, large sale orders could
cause noticeable UI slowdowns and block the main JavaScript thread.

To address this, we now build a parent–child section mapping once per render
in O(n) time. Subsequent lookups simply read from this mapping instead of
recomputing the parent by scanning previous lines.

This significantly reduces the computational cost and prevents UI blocking when
working with large orders, leading to a much smoother rendering experience.

opw-5865167

Benchmark:

| No. records | Before      | After        |
|----------------|---------------|--------------|
|       150      |   1300ms  |   ~850ms |


| Before      | After        |
|---------------|--------------|
|   <img width="287" height="284" alt="image" src="https://github.com/user-attachments/assets/dd73ab18-3c53-4958-99b7-083dd5cd9e64" />  |   <img width="311" height="277" alt="image" src="https://github.com/user-attachments/assets/b6e90fa3-85eb-4d72-b616-28aff9a938e8" />|
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#252991

**PROBLEM**
Here is the client use case:
The client uses fixed tax to do 'vidange/consignage'. When selling a product with a 'consigne/vidange', they add a fixed tax which amount correspond to the 'consigne/vidange'. When returning the 'consigne', you would create an invoice line, with a product with a price of 0, negative quantity,a 0% tax and the fixed tax for the 'consigne'. When an invoice contains such lines, it fails peppol validations.

**STEP TO REPRODUCE**
1. Create a fixed tax used for 'vidange/consigne'.
2. Create an invoice, with a line with unit price of 0, negative quantity, a 0% tax and the fixed tax for the 'consigne'.
3. Send the invoice using peppol, use a validator to validate the xml and notice you get the following errors: [BR-E-01] [BR-E-08].

**CAUSE**
Fixed tax (like the one used for vidange) are aggregated in new invoice lines by the function `_ubl_turn_emptying_taxes_as_new_base_lines()`. Let say we have the following invoice:
line 1: qty=2, unit_price=3, taxes: 21% & vidange(fixed tax of 1). line 2: qty=-1, unit_price=0, taxes: 0% & vidange.

After calling `_ubl_turn_emptying_taxes_as_new_base_lines()`, we got: line 1: qty=2, unit_price=3, taxes: 21%.
line 2: qty=-1, unit_price=0, taxes: 0%.
line 3: qty=1, unit_price=1(amount of the fixed tax), taxes:None.

When generating the VAT breakdown, we have 2 line will end up being tax exempted (line 2 and 3). Because the `tax_exemption_reason` differs, they will not be merged in the same entry in the breakdown, which break the constraint of peppol saying we can only have one VAT breakdown with code 'Exempt from tax'.
Line 2 reason comes from:
https://github.com/odoo-dev/odoo/blob/de22093ee225df499b2de80e1f07dd281ac686bc/addons/account_edi_ubl_cii/models/account_edi_common.py#L271-L274

opw-5912986

Forward-Port-Of: odoo/odoo#254875
Forward-Port-Of: odoo/odoo#250413

Steps to reproduce:
===================
1- Enter the website editor
2- Enable mobile view
3- Edit the alignment of the mobile menu to be center or right aligned

The group labels (e.g. "Shop", "Forum") stay left-aligned regardless
of the chosen alignment.

This can also be seen on desktop by switching to the sidebar header
template.

Cause:
======
The class .accordion-button uses `display:flex` and `text-align:left`
and that class is used for the menu groups labels.
this prevents the alignment from working.

Solution:
=========
When right-aligned (`text-end`), reverse the flex direction so the arrow
moves to the left and the text stays on the right.

When centered (`text-center`), let the text span fill the remaining
space and center its content via `text-align: center`,
keeping the arrow on its position.

The default left-aligned case is unchanged.

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

Forward-Port-Of: odoo/odoo#244565

Steps to reproduce:
-------------------
* Let's say you're on company A, create a pos payment method
* Don't assign a pos yet
* Create a branch company sub_A
* Switch to that branch company
* Create a pos
* Now switch to company A but also select sub_A
* In the config of the pos from sub_A, try to add the new payment method and save
> Validation error -> Normal
* Now instead go to the payment method form
* In the point of sales select the pos sub_A
* Save
> No error
* Try opening the pos sub_A
> Validation error, same as the first one -> Normal

Why the fix:
------------
We already have a contraint on the pos config model checking that the companies match.
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/point_of_sale/models/pos_config.py#L469-L473

However when writing on the model pos payment there is no constraint and the ORM currently does not trigger constraints on comodel of the field we're modifying so we need to add this constraint on the pos payment method model as well

opw-6000206

Forward-Port-Of: odoo/odoo#253858

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Additionally, `_get_localized_times` called `.astimezone()` on naive UTC datetimes without first localizing them, producing incorrect local times for the same reason.

Solution:
- In `_get_overtimes_to_update_domain`, localize check_in/check_out to the employee's timezone before computing the overtime search date range (with a ±1 day buffer) so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.
- Fix `_get_localized_times` to call `utc.localize()` on naive UTC datetimes before converting to the employee's timezone.

opw-5931665

Forward-Port-Of: odoo/odoo#251812

**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
  * activate Peppol
  * set "Rounding Method" to "Round Globally"

- Create an invoice:
  * Customer: [a Belgian customer with a VAT]
  * Invoice Lines:

    | Label | Quantity | Price | Taxes | 
    | ------- | ---------- | ------- | ------- |
    |  Line 1   |   1.0    | 90.30 |   0%  |
    |  Line 2   |   0.45   |  2.54 |   6%  |
    |  Line 3   |   0.28   |  6.87 |   6%  |

- Confirm the invoice
- Send the invoice to Peppol

**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:

`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`

**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.

**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.

opw-5933545




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

Forward-Port-Of: odoo/odoo#255095
Forward-Port-Of: odoo/odoo#253625

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

Some stock queries determine whether a location belongs to the subtree of a set of locations by checking the parent_path prefix against candidate parent locations. This is done using a correlated EXISTS subquery with a LIKE parent.parent_path || '%' condition.

When the list of candidate locations becomes large (for example tens or hundreds of thousands of ids), this approach causes extremely poor performance because the database must repeatedly compare hierarchical path strings for every candidate row.

This PR improves the performance of this ancestry check by replacing the string prefix comparison with a direct check on the ancestor ids contained in parent_path.

### Current behavior before PR:

The query determines whether a location belongs to the subtree of one of the provided locations using:

location.parent_path LIKE parent.parent_path || '%'

For each row, PostgreSQL must evaluate a correlated subquery against all candidate parent locations. Because this relies on string prefix comparisons on parent_path, when the location list is large, this results in extremely slow queries.

### Desired behavior after PR is merged:

Instead of performing string prefix comparisons, the query extracts the ancestor ids directly from parent_path.

The path is:

1. Trimmed to remove leading and trailing /
2. Split into an array of ancestor ids
3. Expanded using unnest
4. Checked for intersection with the provided location ids

This converts the ancestry check from repeated string comparisons into a simple integer membership check.

### Benchmarks

Comparing performance of old subquery:

```
SELECT stock_location_inner.id 
FROM stock_location AS stock_location_inner 
WHERE EXISTS (
    SELECT 1
    FROM stock_location parent
	WHERE parent.id IN (long list)
		AND stock_location_inner.parent_path LIKE parent.parent_path || '%%'
);
```

to new one:

```
SELECT stock_location_inner.id 
FROM stock_location AS stock_location_inner 
WHERE EXISTS (
    SELECT 1
    FROM unnest(
        string_to_array(trim(both '/' FROM stock_location_inner.parent_path), '/')::int[]
    ) AS path_id(id)
	WHERE path_id.id IN (long list)
);
```

Depending on the number of elements in 'long list'

| # of elements | Before | After |
| --- |---|---|
| 130,000 | 21min | 0.8sec |  
| 10,000 | 95sec | 0.5sec |  
| 1,000 | 10.5sec | 0.5sec |  

In practice, on the reference ticket this causes the "Validate" button on a stock picking to go from timing out to taking 8 seconds. 

### Reference

opw-5932436

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

Forward-Port-Of: odoo/odoo#254245

**Steps to reproduce:**

- Make sure you have 3 companies (comp A, B and C)
- Navigate to Settings/Users & Companies/ Companies 
- for each company in the 'Inter Company Transactions' tab: 
check 'generate Sale Orders', 'generate purchase orders' and 
'synchronize Deliveries to your receipts' then select a warehouse 
and a receipt operation type

From company A
- create a storable product
- in the Purchase tab, set the company B as a vendor

From company B 
- in the Purchase tab of the product, set company C as a vendor

From company C
- set a positive on hand quantity

From Company A
- create a SO for 1 quantity of your product
- on the sale order line, unhide de route_id column and 
set it to dropship
- confirm the SO and the linked PO

From company B
- on the SO created with company A as customer (you might need to 
remove the 'my quotations filter to find it), set the dropship 
route in the route_id column of the sale order line
- confirm the SO and the linked PO

From company C
- confirm SO created with company B as customer
- validate the delivery

From company B
- validate the dropship

**Current behavior:**
the quantity delivered on the sale order line is 0 

**Expected behavior:**
it should be 1

**Cause of the issue:**
inside _compute_qty_delivered, we fetch the incoming 
and outgoing moves using _get_outgoing_incoming_moves()
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200
There, for the move of the dropship picking, inside the 
if condition, move._is_dropshipped_returned() will be True
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354
That's because the move is going from transit to transit
https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195
So it will not be added to the outgoing moves and 
qty_delivered will stay 0.

**fix**
is_dropshipped_returned should not prevent the move 
to be added to the outgoing moves if is_dropshipped() is 
aslo true (i.e. it's a transit to transit move)

opw-5023215

**Problem:**
When manually registering a payment using a Stripe SEPA Direct Debit token, the associated `account.payment` is immediately canceled, even though the Stripe transaction is in "Pending" status. Later, when Stripe confirms the transaction, the payment remains canceled, leading to subscription closures after 90 days of apparent non-payment.

**Steps to reproduce:**
1) Set a customer address to Belgium and add a SEPA Direct Debit payment token via Stripe.
2) Change the company currency to euro.
4) Create a manual invoice for that customer.
5) Pay the invoice using the pre-configured Stripe SEPA token.
6) Observe the `account.payment` is immediately canceled despite the transaction being "Pending".
7) When Stripe confirms the transaction, the payment stays canceled.

**Cause:**
In `account_payment.action_post()`, after sending the payment request, all payments whose transaction state was not `done` were canceled. For asynchronous payment methods like SEPA Direct Debit, the transaction starts in `pending` (not `done`), so the payment was wrongly canceled.

**Solution:**
- Only cancel payments whose transaction ended in a failure state (not in `done`, `pending`, or `authorized`), so pending/authorized payments stay in draft/in_process.

opw-5934381

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

Step to reproduce:
- install spreadsheet_dashboard_sale and pos_sale
- create a order in pos , invoice it too
- open sale dashboard

Observation:
- the order fulfilled in pos, does not reflect in dashboard

Cause:
- sale has 4 status i.e ["draft", "sent", "sale", "cancel"]
- when pos_sale is installed, new status oders are added i.e ['paid', 'invoiced', 'done']
- sale dashboard pivot relies on sale defined status only, which so not consider orders that have status in  ['paid', 'invoiced', 'done']

Fix:
- fix the domain of pivots such that, it will now accept other orders too

**Before:**

<img width="1058" height="277" alt="image" src="https://github.com/user-attachments/assets/e58c88fa-5ad3-4194-9f9c-ddf41f2f73de" />

<img width="1116" height="190" alt="image" src="https://github.com/user-attachments/assets/259e0347-5d5b-4d5c-9aeb-74102aa4becd" />
<br/>


**After**
<br/>

<img width="1137" height="232" alt="image" src="https://github.com/user-attachments/assets/406b71a5-1dd8-4164-9d4e-4f0bca34c9e8" />

<img width="1125" height="235" alt="image" src="https://github.com/user-attachments/assets/fded3203-7d72-45ea-b5aa-142ebcd52136" />


opw-5487654

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

**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Payroll).
- Go to Settings → Technical → Security → Groups.
- Open any group and assign an inherited view in the Views section.
- Upgrade the module.

**Issue:**
- Odoo already prevents assigning groups directly on inherited view records in
ir.ui.view. However, it is still possible to indirectly assign groups to
inherited views through res.groups via the view_access relation.

- This creates entries in ir_ui_view_group_rel and can trigger a ValidationError
during module upgrades. As a result, users may unknowingly create invalid
group-view relations, leading to errors and confusion.

**Solution:**
- Add a validation constraint on res.groups to prevent linking groups to
  inherited views via the view_access relation.

- Raise a ValidationError when such an assignment is attempted, with the message:
  "Groups should instead be defined using the 'groups' attribute inside the view XML definition."

This ensures that inherited views cannot be assigned to groups,
avoiding invalid configurations and preventing errors during module upgrades.

**opw-6015526**

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

Forward-Port-Of: odoo/odoo#254849

Before this commit, if the user configured the sales journal to be locked by a hash, then a cancellation in ticketbai would 1/ send the cancel request to ticketBAI. This would be processed successfully 2/ try to reset the invoice to draft inside of Odoo, then cancel it. This would fail with an error since account moves protected by a hash cannot be reset to draft.

The result is a blocked database where the invoice cannot be altered in Odoo while its status doesn't match the status in ticketBAI.

In this commit, we propose to check for the secure hash before sending the invoice over to ticketBAI. The invoice is not altered yet at that stage to account for potential ticketBAI errors in the normal flow.

While this option is not great from a usability perspective (preventing secure hashes with ticketBAI is probably best), we believe the current solution offers the best compromise in the context of a bugfix.

The issue does not seem to be reproducible outside of production as the core of the problem is a mismatch in state between ticketBAIand Odoo.

opw-5912848

**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Payroll).
- Go to Settings → Technical → Security → Groups.
- Open any group and assign an inherited view in the Views section.
- Upgrade the module.

**Issue:**
- Odoo already prevents assigning groups directly on inherited view records in
ir.ui.view. However, it is still possible to indirectly assign groups to
inherited views through res.groups via the view_access relation.

- This creates entries in ir_ui_view_group_rel and can trigger a ValidationError
during module upgrades. As a result, users may unknowingly create invalid
group-view relations, leading to errors and confusion.

**Solution:**
- Add a validation constraint on res.groups to prevent linking groups to
  inherited views via the view_access relation.

- Raise a ValidationError when such an assignment is attempted, with the message:
  "Groups should instead be defined using the 'groups' attribute inside the view XML definition."

This ensures that inherited views cannot be assigned to groups,
avoiding invalid configurations and preventing errors during module upgrades.

**opw-6015526**

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

Forward-Port-Of: odoo/odoo#254849

…r rejections

Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors.

The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use.

This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ...

The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading.

closes odoo/odoo#250388

See-also: #243119
Backport: #247057

Forward-Port-Of: odoo/odoo#254670

…r rejections

Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors.

The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use.

This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ...

The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading.

closes odoo/odoo#250388

See-also: #243119
Backport: #247057

Issue
-----
When receiving product after having billed it already, if:
- the product is valuated,
- the purchase is in a foreign currency,
- there is an underlying exchange diff between time of bill and reception
- the diff exchange rate is negative

then the exchange difference account move will occur in the regular exchange account.

Steps to reproduce
-----
- Enable automatic (anglo-saxon) accounting & dropshipping
- Enable the EUR currency and add 2 exchange rates
    - today with 2:1 (EUR:USD)
    - yesterday with 1:2 (EUR:USD)
- Create a new AVCO product category
    - costing method: AVCO
    - valuation: automatic
- Create a new product
    - type: storable
    - category: AVCO
    - purchase: 5€
    - set dropship route
- Create and confirm a SO
- Confirm PO and validate delivery
- Create bill for the PO
    - change bill date to before yesterday & confirm

> Journal entry created in "Exchange Difference" journal

Cause
-----
Thanks to commit 80ff2d2 the flow is well behaved if the new rate is higher (company currency worth more comparatively) because we use the credit aml

https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/addons/account/models/account_move_line.py#L2214-L2215

whose move has a svl

https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/addons/stock_account/models/account_move.py#L335

This is not the case for the debit aml, so we end up using the default currency exchange account.

-----
Ticket:
opw-4797287

**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Payroll).
- Go to Settings → Technical → Security → Groups.
- Open any group and assign an inherited view in the Views section.
- Upgrade the module.

**Issue:**
- Odoo already prevents assigning groups directly on inherited view records in
ir.ui.view. However, it is still possible to indirectly assign groups to
inherited views through res.groups via the view_access relation.

- This creates entries in ir_ui_view_group_rel and can trigger a ValidationError
during module upgrades. As a result, users may unknowingly create invalid
group-view relations, leading to errors and confusion.

**Solution:**
- Add a validation constraint on res.groups to prevent linking groups to
  inherited views via the view_access relation.

- Raise a ValidationError when such an assignment is attempted, with the message:
  "Groups should instead be defined using the 'groups' attribute inside the view XML definition."

This ensures that inherited views cannot be assigned to groups,
avoiding invalid configurations and preventing errors during module upgrades.

**opw-6015526**

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

**Behaviour:**
When creating a sale order line for an item with multiple packagings, modifying the packaging quantity will trigger the computation of the product quantity which will trigger the computation for the packaging itself. This creates a dependency between the chosen package and the quantity selected which can end up triggering unexpected reactions when following specific flows.

**Steps to reproduce:**
- Enable packages for sales in configuration
- Create a product, in the inventory tab, add two packages: Pack of one, and Pack of four and set corresponding unit.
- Create a quotation and set the SO line to Quantity to one, this should set Packaging and Packaging Quantity to 1 aswell
- Now change Packaging Quantity to 4, this should visually only change the Quantity to 4
- Now if you change Quantity to 5, you should see Packaging switch to packs of 4 and Quantity jump to 20.

This is caused because when in` _compute_product_uom_qty` we try to get the `product_packaging_id` which in turn triggers `_compute_product_packaging_id `before completing the previous compute. https://github.com/odoo/odoo/blob/cf9805874722b6729b5301fdea4f107ae221a1d2/addons/sale/models/sale_order_line.py#L397-L411
When we change the packaging_qty to 4, the packaging_id doesnt change as the compute is triggered before assigning 4 to the uom_qty. But when we change packaging_qty to 5, the packaging_id changes to packs of 4 as the compute is triggered before the uom_qty should go to 5 which then results in the uom_qty switching to 20.

The solution removes the dependency between package_id and qty.

# How to reproduce
- Install the Peppol Self-Billing module (account_peppol_selfbilling)
- Go to any contact
- In the accounting tab, set the Electroing Invoicing to "Factur-X (CII)"
- Try to access any Vendor Bill

# The problem
A traceback is shown

# Why
This commit (https://github.com/odoo/odoo/commit/c696a11ee735b0689ef6a00f1a189916724d4854) backported the peppol self-billing feature.

When the user try to access a Vendor Bill, this check is run :

```py
def _is_exportable_as_self_invoice(self):
        return (
            self.state == 'posted'
            and self.is_purchase_document()
            and self.commercial_partner_id.ubl_cii_format
            and (edi_builder := self.commercial_partner_id._get_edi_builder()) is not None
            and edi_builder._can_export_selfbilling()
            and self.journal_id.is_self_billing
        )
```

In the case of Factur-X invoicing (account.edi.xml.cii), ```_can_export_selfbilling()```is not defined.

opw-6022938

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

Define the correct hours in the leaves if the calendar has defined dates (`date_from` and `date_to`)

Use case example:
- Create a calendar and define on Friday (Morning: from 08:00 to 13.00, Afternoon: from 19:00 to 21:00) with date_to=2025-01-01.
- Define another specific Friday (Morning: from 09:00 to 14.00, Afternoon: from 17:00 to 20:00) in the same calendar with date_from=2025-01-01.
- Create an employee and define the calendar created for him/her.
- Create a leaves for the employee and select a Friday (2025-05-02).
- The start hour of the leave must be 2025-05-02 09:00:00
- The end hour of the leave must be 2025-05-02 20:00:00

![ejemplo-1](https://github.com/user-attachments/assets/e7f6bcf9-73f2-4412-840c-cbe42e5e9200)
![ejemplo-2](https://github.com/user-attachments/assets/211c07c8-c068-4137-b032-e26f9567e8b3)

Please @pedrobaeza can you review it?

@Tecnativa TT56218


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

Forward-Port-Of: odoo/odoo#208378