**Problem:**
In view Inventory valuation, generate entry doesn't work when 
multiple companies are selected. 

In the view only the main company matters. 
That means that even if multiple companies are selected, only the stock 
variation lines related to the main company selected are displayed
(which is expected).
But if you then click on 'generate entry' the account move lines created
will have wrong values (not matching the values appearing in the view)

**Steps to reproduce:**
- create 2 new companies (to have clean accounting)
- create a warehouse for both companies
- for both comp, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).

From company 1 : 
- create a storable prod with avco perpetual category
- confirm PO for 2  @ 10, receive 
- bill only 1 @ 10

From company 2: 
- make sure the category is also perpetual average from this 
other company
- confirm PO for 2 @ 50, receive, don't bill

Notice how from the 'Inventory Valuation' view, rightfully,
only the main company matters (no matter what 
other comp are selected):
- If main comp is comp 1 there is stock variation lines
for amount of 10 (which is expected because we have 
20 in stock and only 10 in stock valuation account)
- If main comp is comp 2 there is stock variation lines
for amount of 100 (which is expected because we have 
100 in stock and only 0 in stock valuation account)

With comp 1 and 2 selected and comp 1 as main company: 
- click on 'Generate Entry'

**Current behavior:**
- both line have a balance of 110

**Expected behavior:**
- they should have a balance of 10 as we saw 
on the 'inventory valuation' view

**Cause of the issue:**
To generate the data from the 'inventory valuation' 
view, inside _get_report_data() we call stock_value() 
and stock_accounting_value() to compare values 
from inventory and value from accounting. 
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L36-L37

stock_value() sums total_value() of each product in 
the valued accounts
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L90-L94
Whereas stock_acounting_value(), sums the balance 
of each account move line of each valuation account
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L112-L114
All of this is related to the main company because 
we call _get_report_data() with context 'allowed_company_ids' 
set to only the main company
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L13

But when we click on generate entry, 
_get_stock_valuation_account_vals() is called with no context
modification to 'allowed_company_ids' so when we call 
stock_value(),
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L238-L239
total_value will be based on both company
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L92

Note that stock_accounting_value() is still rightfully based only 
on main company because we use self.id in the domain
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L105-L108

opw-6168699

Forward-Port-Of: odoo/odoo#262776

Steps to Reproduce (Fresh Database):
--------------------------------------
1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules
2. Create a product > New -- Name: "Test Product" > Save
3. Create BoM v1
   - Go to Manufacturing > Products > Bills of Materials > New --Product: Test Product
   - Add component: any
4. Create and apply ECO 1 on BoM v1
   - Go to PLM > ECOs > New-- Product: Test Product | Apply on: Bill of Materials
   - BoM: Test Product (v1) > Confirm > Apply Changes
   - This creates BoM v2 (previous_bom_id = BoM v1)
5. Create and apply ECO 2 on BoM v2
   - Same as step 4 but select BoM v2
   - This creates BoM v3 (previous_bom_id = BoM v2)
6. Create a separate unrelated BoM for the same product
   - Go to Manufacturing > Bills of Materials > New
   - Product: Test Product | Component: "Component B" > Save
7. Create ECO 3 on the separate BoM
   - Go to PLM > ECOs > New - Product: Test Product | Apply on: Bill of Materials
   - BoM: select the separate BoM from step 6 > Confirm

Observed Bug:
-------------
- Open BoM v3 > ECO(s) stat button shows count = 2
- Click the button > opens 3 records (ECO 3 incorrectly included)

Explain:- 
----------
The ECO stat button on the BoM form was showing a mismatched count vs
the actual records opened when clicking it. This happened because
[button_mrp_eco](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L56) was using all keys from [_get_previous_boms](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L67)() as the
domain, which includes BoMs from unrelated lineages of the same product
template, while [_compute_eco_data](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L20) only counts ECOs belonging to the
current BoM's version lineage.

Fixed by filtering the domain to only include BoM IDs whose lineage set
contains the current BoM ID, making the opened records consistent with
the displayed count.

Before Fix
<img width="1901" height="875" alt="image" src="https://github.com/user-attachments/assets/3208aed5-ebd3-47a3-a457-a7d61b7743cb" />

```
In [24]: labo = self.env['mrp.bom'].browse(710)
In [25]: previous_boms_mapping = labo._get_previous_boms()
In [26]: Test = ['&', ('bom_id', 'in', list(previous_boms_mapping.keys())), ('type', '=', 'bom')]
In [27]: Test
Out[27]:
['&',
 ('bom_id',
  'in',
  [710,
   1991,
   2049,
   1913,
   1840,
   1823,
   1676,
   1759,
   1794,
   1651,
   1604,
   1544,
   1537,
   1527,
   1506,
   1460,
   1265,
   1259,
   1196,
   1221,
   1223,
   1060,
   1029,
   960,
   858,
   850,
   791,
   739,
   723,
   698]),
 ('type', '=', 'bom')]
```

With My Fix
<img width="1824" height="947" alt="image" src="https://github.com/user-attachments/assets/0d68fdbc-7e42-4ce4-a326-2fb030ba1d06" />

```
In [15]: labo = self.env['mrp.bom'].browse(710)
In [16]: previous_boms_mapping = labo._get_previous_boms()
In [17]: previous_boms_mapping
Out[17]:
{710: {710},
 1991: set(),
 2049: set(),
 1913: set(),
 1840: set(),
 1823: set(),
 1676: set(),
 1759: set(),
 1794: set(),
 1651: set(),
 1604: set(),
 1544: set(),
 1537: set(),
 1527: set(),
 1506: set(),
 1460: set(),
 1265: set(),
 1259: set(),
 1196: set(),
 1221: set(),
 1223: set(),
 1060: set(),
 1029: set(),
 960: set(),
 858: set(),
 850: set(),
 791: set(),
 739: set(),
 723: set(),
 698: {710}}
In [18]: relevant_bom_ids = [
    ...:     bom_id
    ...:     for bom_id, current_bom_set in previous_boms_mapping.items()
    ...:     if labo.id in current_bom_set
    ...: ]
In [19]: relevant_bom_ids
Out[19]: [710, 698]
```

Task-6065020

Forward-Port-Of: odoo/enterprise#114039

**Steps to reproduce:**
- Create a new marketing campaign with two activities
- Set them to occur some number of days after the beginning
- Save the campaign and start it
- Modify one of the activities to occur some number of days after the
other activity and save
- Modify the child activity by changing the number of days after its
parent that it should run and save
- An error will be thrown

**Issue:**
The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line:
`base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date`

**Fix:**
Prevent the activity hierarchy to be modified on started campaigns.
We also change the indexing to avoid further out of range issue and
properly default on the participant create value.

Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running
campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could
impact the behavior between test and actual executions.

opw-5362978

Forward-Port-Of: odoo/enterprise#107556

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
    - Wage: $0
    - (Set the contract's status to *Running*)
    - (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
    - Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).



opw-5999856

Forward-Port-Of: odoo/enterprise#116653
Forward-Port-Of: odoo/enterprise#112724

__

## Short functional explanation of the error
When we create 2 shifts for the same day for an employee, on a non-working day for their schedule. When trying to create the second one after setting the end date to midnight, we get the error:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Reproduction Steps
1. Create an Employee. In the Payroll tab, Make sure they have an active contract. Set their Working Hours to a fixed schedule, where they have saturdays as non-working days. In the Settings tab, set an Overtime Ruleset.
2. Click on the overtime ruleset. Then, for each rule, under Action, set the Work Entry Type To Use as Overtime Hours.
3. Go to Attendances. In Configuration > Settings, under Extra Hours, set the Extra Hours Validation as Approved By Manager.
4. Create an attendance for your Employee on a Saturday, from 12h to 18h.
5. Create a second attendance for your Employee on that same Saturday, from 18h to 00h00. Try to Save.
Note: the timezone of your computer, the working schedule and the employee should be set at Brussels time. 

### Expected behavior
The Overtime is registered.

### Unexpected behavior
An error occurs:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Origin of the issue
The end time of the overtime is defined as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L54-L56 However, in the case where our shift ends after the computed end of the day (in our case, the end time of the shift is 00:00:00 and the end of the day is set at 23:59:59), it creates some problems. The end time of the overtime is set 1 second too early. Later we compute the start time of the overtime as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L57 Thus, the time start of the overtime is also set one second too early. As our second shift starts right after the first one, after the execution of this code, we will get a second shift that starts before the end of the first one.
Then, we add these values in a list:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L59 which will contain overlapping timeframes, and with which we create an Interval:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L60 But when we create an Interval with overlapping timeframes, we obtain only one interval as the timeframes are merged.
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L173 As a result, `overtime_intervals` will contain only one time frame with 2 different corresponding overtimes, which causes a singleton error when reaching:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L179 __
opw-6096454

Forward-Port-Of: odoo/enterprise#114147

Steps to reproduce:
------------------------------------
1. Install Timesheets Module with demo data
2. Create a new Employee with: 
    * Payroll Page > Contract > Start from 1st March
    * Payroll Page > Working hours set to 'Standard 40 hours/week'
3. Go to Timesheets > All Timesheets
4. Add Timesheet for any task as follows:
    * Select a date in a past week (e.g., 14th April)
    * Hours: 8 hours
    * Select the newly created employee
5. Go to Timesheets > All Timesheets:
    * Filter by the new employee
    * Navigate to the same past week
    * Observe the remaining hours for the employee (e.g, -32:00)
6. Open the newly created employee form:
    * Click on '+' to create a new contract version
    * Set the version date before the timesheet date (e.g., 12th April)
    * Change Working Hours to Standard 38 hours/week.
7. Repeat Step 5

Observation:
------------------------------------
The Remaining Hours shows -32:00, meaning the system still uses the 40 hours/week schedule instead of the updated one. The expected value should be -30:00 based on the 38 hours/week schedule.

Issue:
------------------------------------
The method `_get_contracts_valid_periods` determines which working calendar applies for which time period. It uses `contract.contract_date_start` and `contract.contract_date_end` to build calendar validity intervals, but these are the contract employment dates (shared across all versions of the same contract), NOT the version-specific effective dates.
Both versions share the same `contract_date_start`, so both claim the entire period as valid. The 40h calendar produces larger work intervals that win when combined via Intervals union, so the old 40h schedule is used instead of the current 38h one.

Solution:
------------------------------------
Replace `contract.contract_date_start` / `contract.contract_date_end` with `contract.date_start` / `contract.date_end`
These dates represent each version's effective validity period, computed from `date_version` and bounded by the next version's start date. Using these ensures each calendar is only valid during the period its version was actually in effect correctly splitting the working hours at version boundaries.

opw-6142137

Forward-Port-Of: odoo/odoo#260614

**Description of the issue/feature this PR addresses:**
The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage.

In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67).

**Steps to reproduce bug:**
1. Create an event website
2. Create an event and visit it
3. On the page click Site > Properties
4. Enable `Is Homepage`
5. Return to the homepage of the application and open the editor

https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link

**Current behavior before PR:**

https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link

**Desired behavior after PR is merged:**

https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link

opw-6101680

Forward-Port-Of: odoo/odoo#262886
Forward-Port-Of: odoo/odoo#258502