Steps to reproduce:

0. Create an employee with a fixed working schedule and an overtime ruleset, then enable Absence Management in attendances
1. Go to Attendances and make sure that the employee has no attendances recorded for the previous working day
2. Run the "Attendance: Detect Absences for employees" scheduled action
3. Observe the absence attendance created on the previous working day, along with the amount of overtime hours calculated
4. Create an attendance on the day that the absence was recorded
5. Observe that the overtime hours on the absence attendance are not updated 5a. If a full day attendance is recorded on that day, the overtime hours on the absence attendance should change to 0, since we've now recorded hours worked for the day

When an absence attendance is created from the Absence Management feature, overtime hours are calculated to represent the time the employee was unjustifiably absent on a given day. If an attendance is later created on the day the absence was recorded, the overtime hours should update to reflect the hours the employee actually worked. Changes were introduced in [this PR](https://github.com/odoo/odoo/pull/272447) that broke this functionality due to the use of `pytz`, which incorrectly calculated timezone offsets. This caused absence attendances to not be picked up by `_get_overtimes_to_update_domain()`, and overtime was not correctly updated. This commit ensures that we get proper time calculations with respect to the employees timezone.

[opw-6380343](https://www.odoo.com/odoo/my-tasks/6380343?debug=assets)

Forward-Port-Of: odoo/odoo#281844
Forward-Port-Of: odoo/odoo#279556

Before this commit, some layouts had the customer address on the right
(light, boxed, bold, striped) and some had it on the left (bubble, wave,
folder). For the latter, when an information_block with the address existed,
it would be inserted before the address pushing it further right. This was
inconsistent since the address position should not depend on whether an
information_block is present or not.

The customer address must stay in a fixed place to match the transparent
window of the envelope when sending a physical letter by snailmail.

This commit fixes this issue by ensuring that in all cases the customer
address position stays fixed regardless of the presence or absence of
the information_block and regardless of the layout used for the letter.

It also fixes the addresses displayed on the sale order report:
1) If invoicing address = partner address != shipping address
or invoicing address != partner address = shipping address
then the three addresses would be printed, even though 2 addresses
are identical.
2) The shipping address and the invoicing address are now printed
horizontally rather than vertically to get rid of the resulting large
blank block under the partner address in that case.

backport of: https://github.com/odoo/odoo/pull/276622

task-6340467

Forward-Port-Of: odoo/odoo#281937
Forward-Port-Of: odoo/odoo#273640

Steps to reproduce:

0. Create an employee with a fixed working schedule and an overtime ruleset, then enable Absence Management in attendances
1. Go to Attendances and make sure that the employee has no attendances recorded for the previous working day
2. Run the "Attendance: Detect Absences for employees" scheduled action
3. Observe the absence attendance created on the previous working day, along with the amount of overtime hours calculated
4. Create an attendance on the day that the absence was recorded
5. Observe that the overtime hours on the absence attendance are not updated 5a. If a full day attendance is recorded on that day, the overtime hours on the absence attendance should change to 0, since we've now recorded hours worked for the day

When an absence attendance is created from the Absence Management feature, overtime hours are calculated to represent the time the employee was unjustifiably absent on a given day. If an attendance is later created on the day the absence was recorded, the overtime hours should update to reflect the hours the employee actually worked. Changes were introduced in [this PR](https://github.com/odoo/odoo/pull/272447) that broke this functionality due to the use of `pytz`, which incorrectly calculated timezone offsets. This caused absence attendances to not be picked up by `_get_overtimes_to_update_domain()`, and overtime was not correctly updated. This commit ensures that we get proper time calculations with respect to the employees timezone.

[opw-6380343](https://www.odoo.com/odoo/my-tasks/6380343?debug=assets)

Forward-Port-Of: odoo/odoo#281844
Forward-Port-Of: odoo/odoo#279556

Steps to reproduce the bug:
- Enable 2-step delivery (pick + ship) on a warehouse.
- Set both rules on the delivery route to "Pull" (instead of the default Pull + Push):
    - Pick rule (Stock -> Output): action = Pull, procure_method = make_to_stock
    - Ship rule (Output -> Customers): action = Pull, procure_method = make_to_order
- Create a sale order for qty 1 and confirm it.
- Validate the Pick transfer.
- Return the Pick transfer.
- Cancel the sale order.
- Set it back to quotation and confirm it again.

Problem:
The newly created delivery (ship) move ends up asking for a wrong, inflated quantity instead of the ordered one (e.g. 3 times the ordered qty for the scenario above; the multiplier depends on the number of prior confirm/cancel/return cycles).

`_action_cancel` (addons/sale_stock/models/sale_order.py) only cancels pickings that are not `done`, so after the pick is validated and returned, cancelling the SO only cancels the still-pending ship move. The pick move and its return stay `done` and linked to the sale order line.

`SaleOrderLine._get_outgoing_incoming_moves` determines which rule "started" the pull/push chain by picking the rule of the first surviving (non-cancelled) move, grouped by warehouse: https://github.com/odoo/odoo/blob/d7bad3dc6c068ffe8643ecb01da1865d743bfb8f/addons/sale_stock/models/sale_order_line.py#L338-L347

Once the ship move is cancelled, it is excluded from that computation, so the Pick rule is wrongly identified as the "triggering" rule instead of the Ship rule. The done pick move and its return share that rule, so they both end up wrongly classified as incoming (returned) quantities instead of being excluded from the computation like before the cancellation, corrupting `_get_qty_procurement`. On reconfirm, `_action_launch_stock_rule` computes
`product_qty = product_uom_qty - qty`, inflating the quantity requested on the new ship move.

Solution:
Identify the triggering rule from the sale order line's full move history, including cancelled moves, so cancelling a move later doesn't change which rule is considered to have started the chain.

opw-6364113

Forward-Port-Of: odoo/odoo#280280

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

Before this commit, some layouts had the customer address on the right
(light, boxed, bold, striped) and some had it on the left (bubble, wave,
folder). For the latter, when an information_block with the address existed,
it would be inserted before the address pushing it further right. This was
inconsistent since the address position should not depend on whether an
information_block is present or not.

The customer address must stay in a fixed place to match the transparent
window of the envelope when sending a physical letter by snailmail.

This commit fixes this issue by ensuring that in all cases the customer
address position stays fixed regardless of the presence or absence of
the information_block and regardless of the layout used for the letter.

It also fixes the addresses displayed on the sale order report:
1) If invoicing address = partner address != shipping address
or invoicing address != partner address = shipping address
then the three addresses would be printed, even though 2 addresses
are identical.
2) The shipping address and the invoicing address are now printed
horizontally rather than vertically to get rid of the resulting large
blank block under the partner address in that case.

backport of: https://github.com/odoo/odoo/pull/276622

task-6340467

Forward-Port-Of: odoo/odoo#273640

Steps to reproduce:
-------------------
1. Install `hr` module
2. Create two employees (e.g., emp1 and emp2) and assign
   emp1 as the manager of emp2
   → emp2 is now a direct subordinate of emp1
3. In the employee list view, apply the custom filter
   "Direct subordinates is set" (child_ids != False)
   → emp1 appears in the results as expected
4. Archive emp2
5. Apply the same filter again
   → emp1 still appears in the results even though it has
   no active subordinates

Issue:
------
When an employee (e.g., `emp2`) is archived, their manager (`emp1`) should no longer appear in the "Direct subordinates is set" (child_ids != False) filter — since `emp1` no longer has any active subordinates.

However, `emp1` still appears in the search results after `emp2` is archived, because the underlying EXISTS subquery checks all subordinates regardless of their active state.

Cause:
--------
Before this commit 5ef007a, `osv.expression`, filtering on a One2many field would automatically
search against [active co-records ](https://github.com/odoo/odoo/blob/5f65e92d7fa341193df53f5aba1620b596f9a1ec/odoo/osv/expression.py#L1260-L1265)only by default.

After that commit, the `condition_to_sql` method in `_RelationalMulti` constructs the comodel with [active_test=False](https://github.com/odoo/odoo/blob/463ca4cf867812890c17d1e1abf7640b04f70ad0/odoo/orm/fields_relational.py#L672-L686) when resolving relational field conditions. This causes the EXISTS subquery generated for `child_ids != False` to compare against all subordinates. (including archived ones rather than active ones only).

Solution:
---------
Added a callable `domain` attribute on the `child_ids` field definition so that only active subordinates are considered by default. This ensures [get_comodel_domain()](https://github.com/odoo/odoo/blob/2d8b24a791b6fe6bb214c32d4fb58b3d46eca70b/odoo/orm/fields_relational.py#L75-L85) returns a server-side domain that filters out archived subordinates, making the `child_ids != False` filter behave as expected.

**NOTE:**
> The ORM uses the **active_test** flag when doing searches. Having in [1, 2, 3] in domains bypasses the search method because we suppose that we already searched to find these ids.
For hierarchical resolution, we bypass rights and active_test.
The result is that inactive records are considered in the result.

confirmed with the framework team, and it is intended behaviour.
However, this is not the expected behaviour for the direct subordinates case in `hr`.
The fix is therefore applied at the field level by explicitly declaring
a domain on `child_ids` to filter out archived subordinates.

ORM commit: https://github.com/odoo-dev/odoo/commit/12eae5c85fa7facb299f0f1bf1fdd62e3ff82aa5



opw-6193104



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

Forward-Port-Of: odoo/odoo#281222
Forward-Port-Of: odoo/odoo#266658

- Compute the standard durations for all French leaves in a single
  `_get_durations()` call instead of recomputing them for each leave.

- Reuse the precomputed duration mapping while calculating the French
  legal duration for each leave.

- Keep the existing French-specific duration calculation unchanged,
  including public holidays, company calendar, date extension, and
  half-day handling.

This avoids repeated ORM computations when processing multiple French
leaves in a batch and significantly improves the performance of leave
duration computation.

Performance testing was performed using the `hr.leave.employee.report`
introduced in 19.1, which calls `_get_durations()` on a large batch of
virtual leaves.

Performance testing on a database containing 677 leaves, including
298 French leaves:

| Metric                              | Before          | After       |
|------------------------------------|-----------------|-------------|
| Standard duration computations    | 298             | 1           |
| Total `_get_durations()`          | >169s (timeout) | ~24s        |

not specific to the employee report and benefits
any caller that invokes _get_durations() on a larger batch.

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

Forward-Port-Of: odoo/odoo#281165

Before this commit, the Chat action of the meeting view could keep its unread dot instead of showing "1" after "Mark as Unread":

    FAILED: [14/21] Tour discuss.meeting_view_tour
    Step .o-mail-Meeting [title='Chat']:has(.badge:contains(1)).
    Element (.o-mail-Meeting [title='Chat']:has(.badge:contains(1)))
    has not been found.
    TIMEOUT step failed to complete within 10000 ms.

This happens because a mark as read carries the id of the newest message the client knew when it requested it, and under load it can reach the server after a newer message was posted. The new message separator then moves back before that message, which makes it unread before the user even asks for it. The click on "Mark as Unread" writes the separator the counter is already computed from, so the counter does not change, and the client, which holds the counter it displays while the user reads the thread, never refreshes it.

This commit moves the new message separator forward only, so reading messages never makes another one unread.

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

Before this commit, the html composer variant of "Opening thread with needaction messages should mark all messages of thread as read" failed at random on runbot:

    11. [verifySteps] expected the following steps
    > Expected: [
      "mark-all-messages-as-read",
    ]
    > Received: []

This happens because the channel of that variant holds no message, so the test goes to the inbox before the channel is loaded and it keeps scrollUnread set. Opening the channel again then loads its messages around the 0 separator, and that fetch calls set_message_done, which marks the needaction message as read and leaves nothing for mark_all_as_read to mark.

This commit fixes the issue by giving the channel two messages, pointing the separator at the first one and waiting for their display: loading messages around the separator is skipped when that message is already loaded, so opening the channel again fetches nothing, which the closing assertion checks as well.

The text composer variant gets the same fixture, so that both variants read as master does, from commit 8cd330e3e2d5b1d857d3effb80aa8176d60b38f9. It does not fail: it already waits for a message of its own, and a fetch around its non-zero separator leaves the messages alone in the mock.

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

Forward-Port-Of: odoo/odoo#281714

Steps:
- Install `account_peppol` module.
- Set `Peppol` compatible country and related details
- Go to my/account page.

Issue:
- Peppol related details always displayed on `my/account` page even though user select different invoice sending method like: `By Email`.

Casue:
- selector to manage visibility of Peppol related details in `my/account` is wrong and because of that those fields always display. Probably because https://github.com/odoo/odoo/pull/195764 and backport of this https://github.com/odoo/odoo/pull/198327 merged at same time.

Fix:
- Update selector to fix this

### [FIX] account_peppol: fix error when setting wrong endpoint

Steps:
- Install `account_peppol` module.
- Set `Peppol` compatible country and related details.
- Go to my/account page.
- Set some wrong Peppol value for `Peppol e-Address (EAS)` or `Peppol Endpoint` or `Electronic format`.

Issue:
- Not able to save those details without any error message on address page and getting error on console `Cannot read properties of undefined (reading 'classList')`.

Casue:
- In this PR https://github.com/odoo/odoo/pull/190312 when adapting portal page we set not existing fields in `invalid_fields` details and because of that it can't find related fields on address page and don't allow to save details without raising proper error message.

Fix:
- Updated `invalid_fields` values to properly target them

### [FIX] account_peppol: fix display issue for peppol related fields in address

Steps to reproduce
==================
1. Configure a delivery method with free shipping above a threshold
2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished
3. Lower the product price below the threshold
4. Recover the cart and confirm the order from /shop/checkout

=> The product prices are refreshed, but shipping stays free although
   the new total is below the threshold.

Root cause
==========
Since [1], nothing re-rates the carrier after /shop/confirm_order refreshes the cart prices: the delivery method is selected before the confirmation. In 17.0, the payment page auto-clicked the selected carrier on load, which re-rated the shipping cost and masked the issue.

Fix
===
Re-rate the selected delivery method in `shop_confirm_order` after the prices have been recomputed, as `_cart_update` already does.

[1]: https://github.com/odoo/odoo/commit/8e2b6cede55b51f7ccdbe7601aa7e6035fd6f9fe

opw-6383849


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

Forward-Port-Of: odoo/odoo#276905

# 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

## Issue
When filtering projects using the "Timesheets >100%" filter, some projects with negative remaining hours (and with their `is_project_overtime` field set to True) won't be displayed, even though their expected hours are completed.

This happens with projects which have tasks set to the "Done" or "Cancelled" state. The timesheets entries in those tasks are not taken into account when searching using the "Timesheets >100%" filter.

## Steps to reproduce
1. Install *Task Logs* (`hr_timesheet`)
2. Create a Project P (with Timehseets enabled)
3. Set the allocated hours of the project to 3:00 (3 hours)
4. Create two tasks:
    - T1: State "In progress", and one timesheet entry of 2:00 (2 hours)
    - T2: State "Done", and one timesheet entry of 2:00 (2 hours)
5. Back to the project view, set the filter to "Timesheets >100%"
6. **Project P is not shown, even though the total time spent on the project is 4 hours, completing the allocated hours set on the project.**

## Cause
The `_search_is_project_overtime` method filters out the tasks in "closed" states (Done/Cancelled) when computing the amount of time spent on the project.

https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L103-L114

This does not match with the behavior of the `_compute_is_project_overtime`, which does not take into account the state of the tasks to determine the value of the field:

https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L85-L94

This leads to a confusing behavior, where a project can have its `is_project_overtime` field set to True, but will still not be shown when using the "Timsheets >100%", even though that filter is defined as `[("is_project_overtime", "=", True)]`.

The compute method was updated by https://github.com/odoo/odoo/commit/d4252825f52a3172420dcda0ea394e42da9f8853, but the related search method was left unchanged, leading to this slight incoherence between the two methods.

opw-6422173