**Purpose:**
Out of stock was not completely managed in eCommerce.

The out of stock ribbon was not reflecting correctly the status of the partially out of stock products. The notification and wishlists buttons were inconsistents with the rest of the features.

**Specification:**
Shop page:
- Make the out of stock ribbon appear only if all variants are out of stock.
- If a product if completely out of stock, hide the add to cart button.
- If a variant is still available, select the first available variant in the configurator or when clicking on the tile to open the product page.

Product page:
- Make the notification button replace the Add to cart button.
- Rationalise the wishlist button of out of stock products.
- When clicking notify me, show form to enter email if not logged in, subscribe directly if logged in

Task-6026756

See also:
- https://github.com/odoo/enterprise/pull/130684

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/54a0597b26 [REL] 19.5.0-alpha.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4f0daee34e [IMP] index: export `owlPlugins` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/532243ce63 [REL] 19.5.0-alpha.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7907b8e368 [PERF] evaluation: clip range to sheet [Task: 6483083](https://www.odoo.com/odoo/2328/tasks/6483083)
https://github.com/odoo/o-spreadsheet/commit/1fe87f3046 [IMP] owl3: remove `env.getPopoverContainerRect` [Task: 6510584](https://www.odoo.com/odoo/2328/tasks/6510584)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

This PR redesigns the gift card template by improving the space utilization and adding a white background to enhance readability on dark mode.
It also 
- slightly modifies the layout of the related PDF
- increases the minimum width to provide more space for the mail preview in the chatter.

task-6246180

| Before | After |
|--------|--------|
| <img width="616" height="779" alt="Screenshot 2026-06-25 at 10 53 22" src="https://github.com/user-attachments/assets/b7f05c43-aaaa-4f4f-ba5b-fa93f4aaaad2" /> | <img width="504" height="595" alt="Screenshot 2026-06-25 at 10 25 22" src="https://github.com/user-attachments/assets/19bca54b-923a-44d7-9c08-3901ff08a532" /> |
|--------|--------|
| <img width="448" height="720" alt="Screenshot 2026-06-02 at 10 43 53" src="https://github.com/user-attachments/assets/d5fed6d0-1d05-44a2-9bc8-090259a10291" /> | <img width="555" height="721" alt="Screenshot 2026-06-25 at 10 26 34" src="https://github.com/user-attachments/assets/8e26db94-d654-4d18-8e34-8bee277a9f44" /> |
|--------|--------|
| <img width="798" height="884" alt="Screenshot 2026-06-25 at 10 54 39" src="https://github.com/user-attachments/assets/54bf2940-988c-4754-8677-19bc980a6684" /> | <img width="790" height="856" alt="Screenshot 2026-06-25 at 10 26 52" src="https://github.com/user-attachments/assets/f2ca78d5-97f8-456d-9416-fbd2f680b013" /> |













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

**Time Credit Work Entries :-**
. LEAVE300 (Credit Time)
. LEAVE301 (Parental Time Off)
. LEAVE281 (Partial Incapacity)


### Regular Pay :-
**1. Wage proration for time credit**
The `wage proration` applies only to the payslip calculation, not to the employee's contractual wage, the employee's full-time contractual wage remains unchanged. The wage displayed on the employee's version remains the original amount agreed in the contract, where **The proration is applied only when calculating the worked days and corresponding amounts on the payslip**. This ensures that the payslip reflects the employee's actual working time while preserving the contractual wage as the reference amount.

The used range to calculate the proration ratio depends on the schedule type :-
_. Fixed Calendars:_ The proration ratio is computed using a standard 1-week period (Monday to Sunday) from the attendance schedule, as fixed schedules repeat weekly.
> Fixed Calendar Example (1-Week):
> Schedule: 4 working days (30.4h) + 1 time credit day (7.6h) = 38h total schedule
> Calculation range: 1 week
> Proration ratio: $\frac{30.4\text{ actual working hours}}{38.0\text{ total schedule hours}} = 0.80$.
> Contractual Wage: €5,000 (Unchanged).
> Prorated Payslip Amount: $€5,000 \times 0.80 =  €4,000$.

_. Variable Calendars:_ The proration ratio is computed over the entire target evaluation period to accurately capture work entries, taking the full month for a monthly payslip or the full 3-quarter/3-month period for DMFA reporting.
> Schedule: Alternating shifts across a monthly payslip period totaling 152 total scheduled calendar hours, of which 38 hours are marked as time credit and 114 hours are actual working hours.
> Calculation range: Full calendar month (e.g., 1st to 30th/31st).
> Proration ratio: $\frac{114\text{ actual working hours}}{152\text{ total schedule hours}} = 0.75$.
> Contractual Wage: €5,000 (Unchanged).
> Prorated Payslip Amount: $€5,000 \times 0.75 =  €3,750$.

Ex: If an employee has a contractual wage of €5,000 and their schedule includes time credit:
Employee/contract wage: €5,000 → remains unchanged
Basic wage used as the contractual reference: €5,000 → remains unchanged
Payslip worked-days amount: prorated according to the actual working time
This distinction is important because time credit changes the amount paid for the payroll period, but it does not change the employee's underlying contractual full-time wage.


**2. Version Work Time Rate**
The `work_time_rate` is computed at the employee version level, where the time-credit situation belongs to the employee's version.
The existing behavior for flexible/variable calendars is preserved, **where currently the work_time_rate not computed for variable calendars and the user is expected to enter the appropriate work_time_rate manually for the variable calendars, So the overidden work_rime_rate computation deals with the `credit_time_fixed_calendars`**

For fixed calendars with time credit, the computation is handled specifically for the employee version:
. Only versions flagged with l10n_be_time_credit and using a fixed calendar are handled by the custom computation.
. The employee's reference calendar is used to determine the full-time weekly hours.
. The calculation considers both, regular working attendances & attendances marked as time credit.
The time-credit hours are therefore included when determining the employee's work_time_rate, **But Importantly, the actual working hours of the resource calendar are not changed.**, where The time-credit attendances are included only for the purpose of calculating work_time_rate. They are not treated as actual working hours, and hours_per_week continues to represent the employee's effective working hours without the time-credit period.

Ex: For a full-time reference calendar of 38 hours:
Actual working hours: 30.4h/week
Time-credit hours: 7.6h/week
Hours considered for work_time_rate: 30.4 + 7.6 = 38h
work_time_rate: 100%
Actual working hours remain: 30.4h/week


-----

### Double Holiday :-
The Double Holiday Pay calculation requires special handling for time-credit periods because two different rates need to be considered:
. The **computed work_time_rate** that used to normalize the wage  "include credit_entries"
. The **effective/real work_time_rate** used to determine the assimilated months "not include credit_entries""

The used wage is the version wage itself that's not prorated. The calculation first uses the full contractual wage **(so no need to change the wage on the tests)** and divides it by the version's current computed work_time_rate. This is important for time-credit versions because their computed work_time_rate can include the time-credit attendances. 
However, when calculating the _double_holiday_assimilated_months, the time-credit periods are treated differently. The calculation uses the effective working-time rate, where regular time-credit entries are not considered as working time. The exception is `LEAVE281 (Partial Incapacity),` which is considered in the assimilated-month calculation and therefore contributes with its corresponding rate.

Ex: An Employee works with wage €2,500
. January → June with Normal Schedule
. July → September with 4/5 Partial Incapacity (LEAVE281)
. October → December with 4/5 Credit Time (LEAVE300)
The employee's version wage remains €2,500 throughout the calculation and the used work_time_rate for the wage will be the current computed work_time_rate which will be 1.0

The Double Holiday Pay calculation can therefore be represented as:
€2,500 / 1.00 × [(6 × 1.0 / 12) + (3 × 1.0 / 12) + (3 × 0.8 / 12)]

. For the wage normalization: the computed work_time_rate of the relevant version is used. This rate can include time-credit attendances.
. For _double_holiday_assimilated_months: the calculation uses the effective/real working-time rate for each period. Regular time-credit (LEAVE300) is therefore reflected as 80%, while LEAVE281 (Partial Incapacity) is treated as an assimilated period and remains at 100% in this example.

check:-
```
def _l10n_be_get_paid_double_holiday() 
def _compute_double_holiday_assimilated_months()
```

-----
### Eco Voucher :-
The Eco-voucher calculation depends directly on the employee version's work_time_rate.

The voucher amount is therefore automatically updated when the work_time_rate changes. This is particularly important for time-credit versions, because the work_time_rate now correctly represents the employee's contractual occupation rate, including the relevant time-credit periods.
This means that a time-credit version does not necessarily result in a reduced Eco-voucher entitlement. In particular, when the employee is on a reduced working schedule but the reduction is entirely due to time credit, the computed work_time_rate can remain at 100%, because the time-credit periods are included when calculating the rate.

Ex: An employee is entitled to a maximum of €250 in Eco-vouchers and has the following situation during the reference period:
01/06/2020 → 31/10/2020: Full-time schedule → work_time_rate = 100%
01/11/2020 → 31/05/2021: 3/5 schedule with Tuesday and Wednesday represented as credit-time entries.

Although the employee only has 22.8 actual working hours per week, the two non-working days are explicitly represented as time credit. Therefore, for the purpose of the employee version's work_time_rate, the time-credit hours are included and the rate remains 100%.

The Eco-voucher calculation consequently uses: €250 × 100% = €250
110 valid working days during the full-time period, out of 261 scheduled days.
82 valid working days during the 3/5 time-credit period, out of 157 scheduled days, after excluding 9 unpaid-time-off days.

Therefore: €250 × 110 / 261 + €250 × 82 / 157 = €235.94

This confirms that time credit does not incorrectly reduce the Eco-voucher amount simply because the resource calendar contains fewer actual working hours. The employee's work_time_rate correctly remains 100% when the missing hours are accounted for as time credit.

check:-
`def _get_eco_vouchers_amount(self, get_explanation=False):
`

-----
### Representation Fees :-
The REP.FEES calculation depends directly on the employee version's work_time_rate. Therefore, for time-credit versions, the newly computed work_time_rate is automatically taken into account when determining the amount.
For time-credit versions, the computed rate includes the time-credit hours. Therefore, a 4/5 schedule with one full day of time credit has a work_time_rate of 100% (the 4/5 worked hours + the 1/5 time-credit hours represent the full reference schedule). As a result, the existing representation-fee proration logic is not triggered, and the full representation-fee amount is maintained.

check :-
`def _get_representation_fees(self, localdict):
`

-----
### DMFA :-
The DMFA declaration requires two separate considerations for time credit:
**. Working days,** where the employee's days_per_week is preserved and the time-credit attendances are not considered as actual working days.
This is important because the time-credit hours may be included when determining the employee's work_time_rate, but they must not be reported as worked days in the DMFA declaration, So the time credit can affect work_time_rate, but it does not create additional working days for DMFA.

**. Termination contribution type,** The contribution type is determined based on the employee's yearly salary, which is accumulated from the amounts reported on the payslip worked-days lines, The resulting yearly salary is compared against the configured salary thresholds to determine the appropriate contribution type.
Because the yearly salary is based on the actual amounts coming from the payslip worked-days lines, a time-credit period can reduce the yearly salary used for this calculation.
As a result, the employee's contribution type can legitimately move to a lower category.

check:- 
```
DMFAWorkerContribution() __init__ class
yearly_salary = payslips[0]._l10n_be_get_termination_yearly_salary()
```


-----
task-5126195

Before this commit:
Subscription lines needed a product. Lines with no product were not treated as recurring, so invoicing, renew, upsell, plan counts, and MRR ignored them.

After this commit:
A line with only a description on a subscription with a plan is recurring. It can be invoiced, renewed, upsold (with prorata when prepaid), counted on the plan, and included in MRR.

Impact:
Users can build subscriptions without creating a product for every line. Product lines keep the same behavior as before.


Performance:
Profiler on Subscription Report (list), product only dataset on master vs this branch (2000 subscriptions)
Main report query (sale_subscription_report ... LIMIT 80):
- master: 58.97 ms
- this branch: 59.52 ms


No meaningful difference on that path. 

Flame graphs:

Current master-
<img width="1920" height="1002" alt="image" src="https://github.com/user-attachments/assets/c81fd63a-c9b7-4506-a4a8-8f04b1427549" />

PR Branch-

<img width="1920" height="1002" alt="image" src="https://github.com/user-attachments/assets/9b750b14-739f-4b1c-b661-e915dac60c5c" />


Task id:  6410240

**Description :-** 
This PR adds support for declaring ONSS/DMFA quarterly CO₂ contributions for pool vehicles (vehicles owned by the employer that are not assigned to am employee on a contract, but are used during the period).
According to Belgian social security (ONSS) regulations, CO₂ fees must be paid for all company vehicles used during the quarter:

. Assigned Company Cars: CO₂ fees are calculated and declared directly via employee monthly payslips.
. Pool Cars: Must be declared at the employer level for any month in which they had active assignment/driver logs (fleet.vehicle.assignation.log) and were not already declared on an employee payslip.

**Implementation :-** 
. Vehicles declaration on the DMFA (_compute_vehicle_ids)
Retains all active vehicles with valid license plates that have driver assignment logs during the DMFA quarter.
Ensures eco-friendly and pool vehicles appear under the XML <CompanyVehicle> declaration block.

. Month-by-Month Vehicles Contribution (_get_vehicles_contribution)
Evaluates the DMFA quarter on a per-month basis rather than applying a static quarterly multiplier.
Prevents double-counting by excluding vehicles already charged via an employee payslip for a specific month (covered_vehicle_ids).
Dynamically checks driver log date overlaps (date_start and date_end) per month to properly handle mid-quarter acquisitions or transitions.
Evaluates CO₂ indexation parameters historically per month by passing co2_fee_date in the context (vehicle.with_context(co2_fee_date=current_month)._get_co2_fee(...)).

**Example :-**
> CAR-001 (Diesel, CO₂=120):
((120 * 9 - 600) / 12) * (181.93 / 114.08) * 2.75 = 175.42

> CAR-002 (Gasoline, CO₂=100):
((100 * 9 - 768) / 12) * (181.93 / 114.08) * 2.75 = 48.24

> CAR-003 (Diesel, CO₂=110):
((110 * 9 - 600) / 12) * (181.93 / 114.08) * 2.75 = 142.53

> TEST (Class Default Car):
= 33.22

> Payslips CO₂ Fees:
> CAR-002 on Employee Payslips (Jan & Feb): 48.24 * 2 = 96.48
> Pool Cars Monthly CO₂ Fees (Iterating Jan, Feb, Mar):
> 
> January:
> CAR-001: 175.42
> TEST: 33.22
> Subtotal Jan: 208.64
> 
> February:
> CAR-003: 142.53
> CAR-001: 175.42
> TEST: 33.22
> Subtotal Feb: 351.17 (Cumulative pool fees: 559.82)
> 
> March:
> CAR-003: 142.53
> CAR-001: 175.42
> CAR-002: 48.24
> TEST: 33.22
> Subtotal Mar: 399.41 (Cumulative pool fees: 959.23)
> 
> Therefore, Total Vehicles Contribution: 96.48 (payslips) + 959.23 (pool) = 1055.71

task-6147532

Purpose:
Turkish regulations allow an e-Archive invoice to serve directly as the
dispatch document, eliminating the need to send a separate e-Dispatch XML.
This is commonly used in e-commerce marketplace fulfillment or third-party
logistics scenarios.

This commit adds support for the "Invoice Serves as e-Dispatch" workflow:
- Extend `l10n_tr_nilvera_dispatch_type` on `stock.picking` with the new
  option `IS_DESPATCH` ("Invoice Serves as e-Dispatch") and update its label
  to "Dispatch Handling".
- When `IS_DESPATCH` is selected on linked pickings for e-Archive invoice, skip
  sending separate e-Dispatch and instead inject '<cac:AdditionalDocumentReference>'
  node with `<cbc:DocumentTypeCode>IS_DESPATCH</cbc:DocumentTypeCode>`
  into e-Invoice XML.
- Hide the "Send GİB e-Dispatch (XML)" and "Update From GİB e-Dispatch (XML)"
  buttons when Dispatch Handling is set to `IS_DESPATCH`.
- Vehicle and carrier information is not required when Dispatch Handling is
  set to `IS_DESPATCH`.
- Replace the blocking warning for invoices with linked pickings but no
  e-Dispatch orders with an info message, allowing the XML to be sent without
  e-Dispatch information.
- Keep the existing flow when both linked delivery and e-Dispatch orders are
  provided.

task-6369988

**Description :-**
The payroll system currently applies a minimum legal yearly BIK/ATN for company cars.
So even if the employee’s theoretical calculated car benefit is lower than the legal minimum, payroll still taxes the employee on the legal minimum.

That is correct as long as the employee keeps that same car all year, 
But if later in the same year the employee changes to a another car, with a lower or a bigger BIK, In that case, the employee may already have paid too much earlier in the year because the minimum was applied month-by-month indirectly.

So, in December, or in the Month that the contract ends, must:
1. recompute the true yearly ATN
2. compare it with what was already paid
3. refund/deduct the excess if too much ATN was charged.

. Add a salary rule to calculate the regularization amount in case of employee have paid too much for the car bik, which applied in December, or in the Month that the contract ends,

**Implementation :-**
. Min legal car ATN: this's minimum yearly ATN that need to be paid.
. Yearly Theoretical ATN: This's the sum of the real BIK calculated from the car formula without applying the min legal car atn per month
. Yearly ATN paid: this's the sum of ATN paid on the payslips during the year

∴ Yearly ATN to pay = MAX( Min legal car ATN, Yearly Theoretical ATN)
∴ Regularization amount = Yearly ATN to pay - Yearly ATN paid
  If +ve ,then employee paid less and owes more ATN  **(not our case)**
  If -ve ,then employee paid too much and need to refund


**Example :-**
min_car_atn = 1,690€ / year  _(in 2026)_

car1 (Volkswagen/Golf 8) from January to June:
car_value = 38,000  €
yearly_theoretical_atn = 1,938 €/year
yearly_paid_atn = 1,938 €/year

car2 (Nissan) July to December::
car_value = 20,000 €
yearly_theoretical_atn = 1,371.43 €/year
yearly_paid_atn = 1,690 €/year


Calculations:
∵ monthly_car_atn is calculated based on the month calendar days so need to get the car covered assignment on days

∵  car1 covered_days = 181 days
∵  car2 covered_days = 184  days
∴ Yearly Theoretical ATN = 1,938 * (181 / 365) + 1,371.43 * (184 / 365)
                                            = 1,652.39 €

∴ Yearly ATN to pay = Max(min_legal_car_atn, yearly_theoretical_atn) 
, where it's the final ATN that should have been paid after applying the legal minimum. 
                                    = Max(1,690, 1,652.37) = 1,690 €

∵ Yearly ATN paid _(payslips)_  = 
     car1 -> (1,938/365) * (31 + 28 + 31 + 30 + 31 + 30) = 961.035616438 €
     car2 -> (1,690/365) * (31 + 31 + 30 + 31 + 30 + 31) = 851.945205479 €
                              = 1,812.98 €


∴ Regularization amount = yearly_atn_to_pay - yearly_atn_paid
                                              = 1,690 - 1,812.97
                                              = -122.97 €

**∴ Need to refund  122.97 € to the employee**


**Example :-**
min_car_atn = 1,690€ / year  _(in 2026)_
Car 1 (Corolla) Jan-Jun:
  Yearly Theoretical ATN = 1,748.57€
  Yearly Paid ATN = 1,748.57€
Car 2 (Clio)  Jul-Nov:
  Yearly Theoretical ATN = 1,371.43€
  Yearly Paid ATN = 1,690€

>>The contract end at 30th November

Calculations:
∵ monthly_car_atn is calculated based on the month calendar days so need to get the car covered assignment on days

∵ car1 covered_days = 181 days
∵ car2 covered_days = 152 days
∴ Yearly Theoretical ATN = 1,748.57 * (181 / 365) + 1,371.43 * (152 / 365)
                                             = 1,438.215 €

∵ The regularization will be applied till the contract end not the full year, so the min_legal_car_atn will be prorated
∴ min_atn_prorated = 1,690 * ((181 + 152) / 365)
                                     = 1,541.8356 €

∴ Yearly ATN to pay = Max(1,541.8356, 1,438.215) = 1,541.8356 €

∵ Yearly ATN paid (payslips) =
    car1 -> (1,748.57/365) * (31 + 28 + 31 + 30 + 31 + 30) = 867.11 €
    car2 -> (1,690/365) * (31 + 31 + 30 + 31 + 30 + 29) = 571.12 €
                = 1,570.87 €

∴ Regularization amount = 1,541.8356 - 1,570.87
                                             = -29.03 €

∴ Need to refund 29.03 € back to the employee

**Tests :-**
. Payslip Simulation for December & Termination Tests:
Updated all test cases covering December payslip computations and mid-year contract terminations 
(e.g., test_274_declaration_december, test_end_of_contract, test_simple_n_holiday_pay_recovery_higher_salary) 
to ensure that fully validated payslips exist for all preceding months of the active fiscal year, where The `ATNCARREGUL` salary rule computes regularization by inspecting historical payslips (_get_line_values / cumulative paid BIK from January up to the current month), so December or exit payslips in isolation without prior validated payslips skews the total paid BIK (atn_paid_before_current_payslip), which does not accurately reflect a real-world payroll state.
check:-
`def _get_holiday_pay_recovery()
`

. Updated Assertions (M.ONSS):
Adjusted expectations for year-to-date-dependent lines, for special ONSS contributions (M.ONSS) across these specific tests. **Because previous months' payslips are now added, processed and validated sequentially, which reflect exact real-life behavior.**
check:-
`def _l10n_be_get_special_social_contribution()
`

. Updated 274_xx december declarations
Make sure that the payslips are computed and validated **sequentially**, where all payslips from January through November is computed first then December payslips,
Before M.ONSS computed for December first which leads to Zero values, that makes taxable_amount_10 & pp_amount_10 not correct, **But now payslips are now processed and validated sequentially, which reflect exact real-life behavior.**
check:-
`def _compute_line_ids(self): "l10n_be_274.xx"
`
`def _l10n_be_get_special_social_contribution()
`

-----

task-6197625

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/532243ce63 [REL] 19.5.0-alpha.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7907b8e368 [PERF] evaluation: clip range to sheet [Task: 6483083](https://www.odoo.com/odoo/2328/tasks/6483083)
https://github.com/odoo/o-spreadsheet/commit/1fe87f3046 [IMP] owl3: remove `env.getPopoverContainerRect` [Task: 6510584](https://www.odoo.com/odoo/2328/tasks/6510584)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Before:
Belgian employees had two different ways to change their working schedule:
Directly updating the Working Schedule field on the employee. Using the "Working Schedule Change" action.
Only the dedicated action correctly handled related payroll operations such as leave allocation adjustments and employee version creation.
The action was not easily discoverable and created confusion about which workflow should be used.

After:
The "Working Schedule Change" action has been removed. Changing the Working Schedule directly from the employee form now opens a dedicated wizard.
The wizard allows payroll officers to review and adapt the related leave allocation and wage before applying the change. Employee versions are automatically created when required. Existing allocation recomputation, wage update and version creation logic is preserved.

To support this workflow:
Added a custom widget on the employee Working Schedule field to trigger the wizard when the schedule changes.
Reworked the wizard to focus on the Belgian paid time off use case. Added user notifications to clearly communicate the actions performed after validation.

Impact:
Provides a single and more intuitive workflow for working schedule changes.
Prevents users from bypassing payroll-specific recomputations. Improves usability while preserving existing business behavior.

Task: 6247606

### Description:

Predicting fields can be slow when the database has a large amount of move lines (AML). This is caused by the fact that `_predicted_field` will search on all these AMLs to find the ones related to the searched fields. It can be an issue when using Peppol since it is used a lot in most localizations to match each line to its product/account/tax.

To speed up the queries, the move IDs have been inlined in `_build_predictive_query` to avoid suboptimal execution plans caused by LIMIT and ORDER BY clauses. Additionally, materialization of the `account_move_line` CTE has been removed so the planner can inline filters and stream rows directly, which improves performance in most use cases.


### Benchmark:

**For a `history.limit`[^1] of 100:**

| Nb of invoice line | Before    | After   | AMLs scanned |
|--------------------|-----------|---------|--------------|
|                 33 | 7s        | 4s      | 232          |
|                172 | 11.39min  | 5min    | 99859        |
|               1934 | 3h+ [^2]  | 1h40min | 102503       |

**For a `history.limit`[^1] of 50:**

| Nb of invoice line | Before  | After   | AMLs scanned |
|--------------------|---------|---------|--------------|
|                 33 | 6s      | 4s      | 187          |
|                172 | 2.52min | 1.27min | 21002        |
|               1934 | 40min   | 20min   | 21002        |

[^1]: System parameter `account.bill.predict.history.limit`
[^2]: Stopped manually after 3h; full runtime not measured

### Reference:
opw-5937519

Forward-Port-Of: odoo/enterprise#130242
Forward-Port-Of: odoo/enterprise#128172

`_intrastat_groupby_label_builder` calls `sorted(grouping_keys)` on JSON
strings to determine the order of intrastat report lines. Those strings
contain `"invoice_currency_id": <int>`, an environment-dependent integer.
When two groups share all other dimensions but differ only in currency,
the sort compares the serialised integers lexicographically, so the group
order depends on the specific integer values of each currency in the DB.

The values differ between environments because `odoo/modules/db.py` reads
the `ODOO_RUNBOT` / `ODOO_TEST` environment variables at import time
(`RANDOM_SERIAL`). When set, it runs `base/data/base_data_test.sql` after
the normal bootstrap, which executes
`select setval('res_currency_id_seq', 97)`, advancing the sequence by 96
before any currency is loaded from `res_currency_data.xml`. This shifts
every currency ID up by 96: SEK becomes 114, EUR becomes 222. As strings,
"114" < "222" (first character), so SEK sorts before EUR, breaking the
test. On a standard local install the sequence is not advanced: SEK=18,
EUR=126. As strings "18" > "126" (second character, '8' > '2'), so EUR
sorts first, matching what the test expected.

Steps to reproduce the failure (before this fix):

  Local (EUR sorts first, test passes):
    ./odoo-bin -d test_local -i account_intrastat --stop-after-init
    > SEK=18, EUR=126 → "18" > "126" as strings → EUR first

  Runbot-like (SEK sorts first, test fails):
    ODOO_RUNBOT=1 ./odoo-bin -d test_runbot -i account_intrastat --stop-after-init
    > base_data_test.sql pre-advances res_currency_id_seq to 97
    > SEK=114, EUR=222 → "114" < "222" as strings → SEK first
    > Alternative: restore any master-all runbot DB dump

Issue:
Internal users assigned to a task in an "Invited internal users" project can read the task but may receive an access error when opening it. Adding them as project followers avoids the error but also exposes the project's other tasks.

Steps to reproduce:
- Set a project's visibility to "Invited internal users".
- Assign an internal Project user to one of its tasks.
- Keep the user out of the project's followers.
- Open the assigned task through its access link.

Cause:
The task form loads feature flags whose computations read their values from the parent project. These computations run as the assignee, who can read the assigned task but not the invited-only project, causing a project access error.

Additionally, the project many2one widget declares `is_template` as a related field. This makes web_read request `project_id.is_template` even though the widget uses the task's own `is_template` value.

https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/models/project_task.py#L277
https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/models/project_task.py#L295
https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/static/src/components/project_many2one_field/project_many2one_field.js#L36-L39

Solution:
We need to compute the inherited task feature flags with elevated access so their values do not depend on the assignee's access to the parent project.

declare `is_template` as a dependency of the current task instead of a related field of `project_id`. The task form therefore no longer reads the inaccessible project while its access restrictions remain intact.

opw-6475880

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

Forward-Port-Of: odoo/odoo#284196

[FIX] html_editor, website: generalize Switch component
---
__Problem__

In the "Add font" dialog, the "Serve font from Odoo server" switch never
shows its check mark, and cannot be toggled with Enter.

__Reason__

The dialog reimplements the switch markup by hand instead of using the
`Switch` component. Two things the component does were lost in the copy:

- the knob glyph is a `::before` ligature, so it only renders if the
  span carries the `oi oi-filled` classes. The copy has a bare `<span/>`
  and stays blank once checked.
- `Switch` supports toggling with `Enter`, which the copy does not
  handle at all.

`Switch` itself was not directly usable here: it had no way to set an
`id` (needed by the external `<label for=...>`).

__Fix__

Make `extraClasses` optional, add an `id` prop, and use the component in
the dialog. Toggling with `Enter` also failed to call `onChange` in
`Switch`, leaving the owner state out of sync with the displayed value;
this is fixed too.

`labelIcon`/`labelIconClass` props are added for the `ai_website`
counterpart of this fix.

Finally, `website.editor.ui.scss` still carried a copy of the
`.o_switch` rules, dead since the styles moved next to the component in
`html_editor`. It is removed.

+ Enterprise PR: odoo/enterprise#130453

task-6377407

## Issue

When uninstalling a module that defines a model referenced by an `ai.composer` configuration, the corresponding `ir.model` is deleted.

Deleting the `ir.model` sets the `focused_model_id` of the related `ai.composer` record to `NULL`.

The unique index on `ai.composer` uses `NULLS NOT DISTINCT`:

```python
_unique_agent_interface_model = models.UniqueIndex(
    "(ai_agent_id, interface_key, focused_model_id) NULLS NOT DISTINCT",
)
```

As a result, `NULL` values are considered equal by the unique index.

If both a generic rule and a model-specific rule exist:

* `(agent, media_dialog, NULL)`
* `(agent, media_dialog, product.image)`

uninstalling the module that provides `product.image` deletes its `ir.model`, which sets `focused_model_id` to `NULL` on the model-specific rule.

This results in two identical `(agent, media_dialog, NULL)` entries and raises a `UniqueViolation`, preventing the module from being uninstalled.

## Fix

Set `focused_model_id` to `ondelete='cascade'`.

When the `ir.model` is deleted during module uninstallation, the corresponding model-specific `ai.composer` record is deleted instead of setting `focused_model_id` to `NULL`.

runbot-945683

The issue fixed in commit[1] is again reproducible after commit [2] the pos order line for gift card is now not considered as a refund

Step to reproduce:
- Install pos_loyalty and l10n_es_edi_tbai_pos with demo data
- Create a gift card (add a tax to the discount product, any 0%)
- start pos, add a product and use the gift card
- fulfill the order
- go to backend and open that order
- In the TicketBAI XML, the values for the giftcard product will be positive, causing an inconsistency between the product line total and the invoice total

[1] https://github.com/odoo/odoo/commit/0bbc5ebdcc7e014d87130b2ff9cee98e3aa7479a
[2] https://github.com/odoo/odoo/commit/b17c9713e7a3305c240298fa54fcf1bc87a9bb8c

FIX
- we used to determine `sign` based on each order line's `is_refund` property
- this property is quite sensitive as it depends on factors like line's qty, price, is reward or not.
- so its better to depend on order's refund property for sign reversal

https://github.com/odoo/odoo/blob/4fef2c5b69fac10594fac81b149d542ee4621b13/addons/point_of_sale/models/pos_order.py#L1768


opw-6226003



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

Forward-Port-Of: odoo/odoo#286448
Forward-Port-Of: odoo/odoo#278042

### Issue before this commit:
When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Currencies and activate another currency like EUR
3. Go to Journals and create a new one with bank type and curency EUR
4. Go to dashboard > new test bank journal created > 3 dots in the upper-right corner > Models > create a new one (ex Tester) setting the new test bank created as journal
5. Go to test bank journal and create a new bank matching
6. After the line is created click the 3 dots and go to Manage Models
7. See that the new model Tester created does not appear

### Cause of the issue:
Foreign currency journals append their currency to the display_name (e.g., "Bank (EUR)"). The JS search framework passes this full decorated string into the search domain. The backend then attempts to match "Bank (EUR)" exactly in the database name and code fields, which fails because the database name is "Bank" without the currency added. 
https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/addons/account/models/account_journal.py#L1095-L1100

### Reason to introduce the fix:
The filter is not working correctly. In this case it's better to change 
it to a domain instead of a default filter.

opw-6481970

Forward-Port-Of: odoo/enterprise#129992

## Steps to Reproduce:
- Install the hr_work_entry module.
- Create an employee.
- Payroll tab > create a contract by setting only the start date (leave the end date empty).
- From the contract version timeline (navigation bar), click the "+" button and create a new version.
- Open the cog menu (gear icon) and click 'Export Time Entries'.

## Error:
`ValueError - Expected singleton: hr.version(257, 258)`

## Cause:
Method `_get_contract_versions()` returns multiple versions for the given period.
for example:
`contract_dict = {datetime.date(2026, 8, 1): hr.version(1, 2)}`
The code assumes each value is a singleton and builds the recordset using `c.id`,
`[c.id for c in contract_dict.values()]`
Since `c` contains multiple records, accessing the ID will raise an error.

## Fix:
Instead of accessing `id`, it will access `ids`, and it returns the list of all records (`[1, 2]`). 
`chain.from_iterable()` flattens this list into one iterable sequence `(1, 2, ...)`, and 
then it will convert into a list and be passed to `browse()` to fetch the corresponding recordset.

sentry-7623869169

Forward-Port-Of: odoo/odoo#278858

Steps to reproduce:
- From the website editor, open the Theme tab.
- Upload a custom font.
- Open the media dialog and go to the "Documents" tab.

Issue:
The uploaded font files appeared in the Documents tab. When a zip file
was uploaded, every font it contained appeared individually, along with
the generated "CSS font face" attachment and the Google fonts metadata
cached by the server.

Cause:
Fonts uploaded through `/website/theme_upload_font` are created as
public attachments. The Documents tab of the media dialog lists every
public attachment that is not an image or an asset, so the font files
(mimetype `font/...`), their font face declaration (mimetype `text/css`)
and googleFontMetadata (server caches it as public attachment) were
listed.

Fix:
Create those attachments with a technical `/web/font/{id}/{name}` url
and exclude it from the Documents tab domain.

Existing databases are adapted by an upgrade script(https://github.com/odoo/upgrade/pull/10999)

Upgrade PR: https://github.com/odoo/upgrade/pull/10999
task-[4771523](https://www.odoo.com/odoo/project/974/tasks/4771523)

Steps to reproduce
1. On a Manufacturing Order, open the Miscellaneous tab, click in Additional Notes, type "/file", pick "File" (Insert a file from Documents), select a document and save.
2. Open the Shop Floor of that Manufacturing Order.
3. On the order card, click the link shown in the note.

Expected: the link opens in a new tab.
Actual: the Notes edition dialog opens and the link is not opened.

Issue
---
On the Shop Floor the Additional Notes HTML field is rendered inside a container whose click handler opens the note edition dialog, its links carry no target and the handler stops the event propagation, so clicking a link opens the edition dialog instead of the linked document. Additional Notes became an HTML field in ebc30649c0f5, which allowed such links while this rendering was never adapted to open them.
https://github.com/odoo/enterprise/blob/bfda5100ddd423f9e5fb91a9f83b4719c1f58397/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L58-L63 The note links now receive target="_blank" after mount and on every patch so they open in a new tab like the readonly HTML field viewer, and the container handler ignores clicks landing on a link so it no longer opens the edition dialog for them. https://github.com/odoo/enterprise/blob/bfda5100ddd423f9e5fb91a9f83b4719c1f58397/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L106-L111

opw-6487702

Forward-Port-Of: odoo/enterprise#128979

Currently, an error occurs when user tries to pay on a vendor bill and removes the currency.

Steps to replicate:
- Install `l10n_account_withholding_tax`and activate multiple currencies.
- Open Invoicing > Vendors > Bills and create a new bill and add a vendor and bill date.
- Add a product and tax `2% WTH`.
- From the Cog menu > Click Pay > Remove the Currency.

Error:
```
  File '/home/odoo/src/odoo/saas-19.4/addons/l10n_account_withholding_tax/models/account_withholding_line.py', line 208, in _compute_original_amounts
    line.original_base_amount = line_curr.round(base_amount * rate)
  File '/home/odoo/src/odoo/saas-19.4/odoo/addons/base/models/res_currency.py', line 264, in round
    self.ensure_one()
  File '/home/odoo/src/odoo/saas-19.4/odoo/orm/models.py', line 5342, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: res.currency()
```

Cause:
- As the user removed currency, the `comodel_currency_id`is received as false.
- Later when we call `round()` on the empty res.currency recordset causes this error to occur.

Solution:
- Added the company currency as a fallback value when `currency_id` is removed by user, since `currency_id` is a required field user will need to select a currency when saving.

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

Forward-Port-Of: odoo/odoo#283737
Forward-Port-Of: odoo/odoo#277507

**Steps to reproduce:**
1. Install Sales, l10n_be, payment_stripe and switch to belgian company
2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium
3. Enable stripe payment provider
4. Add SEPA payment method in stripe configuration
5. Create a sale order with a name that doesn't include any characters (numbers only), confirm, click preview and attempt to make a payment using SEPA

**Issue:**
`The statement descriptor must contain at least one Latin character.`

**Cause:**
The previous fix (4fde0232b821c9a1d46d589ff14495f4e19029f4) passed the order reference directly, assuming it will contain characters.

The intended behavior is to actually have the company name used in the statement descriptor field: https://support.stripe.com/questions/what-is-a-statement-descriptor-and-how-do-i-update-it
This was the existing behavior before the fix, so will revert back to it.

opw-6497127

Forward-Port-Of: odoo/odoo#286620
Forward-Port-Of: odoo/odoo#286287

Before this commit, TestPartner.test_res_partner_to_store fails on the all-modules and per-country builds:

AssertionError: '2024-06-06' != '2024-06-07'
 : Return date is the return date of the main user of the partner

This happens because the test reads the first entry of the hr.employee list, which holds one employee per user of the partner: back on the 7th for the main user, on the 6th for the other.

This comes from "[FIX] hr*: load out-of-office dates from all user employees", which added the employees of the partner to the payload, where it held those of the main user only.

The problem is that the list keeps the order of employee_ids, which is 'name' with no tiebreaker, and both employees are named test1, as an employee takes the name of its user and creating the second user renames the partner. Postgres is then free to return either one first, and the failing builds get the second one.

This commit fixes the issue by ordering the employees on 'name, id', so that employees sharing a name keep a stable order instead of the one the database picks. The test asserts the whole hr.employee list, one entry per user of the partner, rather than its first entry alone, and that assertion pins the order.

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

Forward-Port-Of: odoo/odoo#286796
Forward-Port-Of: odoo/odoo#286236

Steps to reproduce:
1. Install Documents
2. In the Documents list view, select a document to display the inspector.
3. Edit a field such as Owner or Customer which uses a Many2one widget.
4. In the field dropdown, click "Search More..." to open a modal dialog.
5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers).

Issue:
- The modal dialog immediately closes, and the contact cannot be selected.

Root cause:
- When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack.

Solution:
- Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer.
Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear
the main selection and destroy the inspector field.


opw-6253360

Forward-Port-Of: odoo/enterprise#128812
Forward-Port-Of: odoo/enterprise#119262

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `quality_control` module
- Create a picking order with a product
- From the gear menu, create an on-demand Quality Check
- Set the check to *Control per Quantity* and back to the picking
- Set the done quantity to 10
- Open the Quality Check wizard
- Try to fail 3 units

Issue:
------
Validating the partial failure raises a `ValidationError`:

    - Missing required value for the field 'Team' (team_id)

The quality check split is not performed and the picking cannot be processed.

Cause:
--------
Quality checks created on-demand from the picking (via the gear menu) have 
no associated `quality.point` or `stock.move.line` — only 
`picking_id` is set at creation time.

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L457

In `_move_to_failure_location()`, the `move_line` branch assumes 
`check.move_line_id` is populated. Since it is empty for on-demand 
checks, the split logic operates on an empty recordset.

The new quality check for the split is then created via:

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L493

At this point both `failed_move_line` (a copy of the empty move line) and
 `check.point_id` are empty. `_get_check_values(False)` cannot derive 
fields normally sourced from the quality point (`team_id`, `company_id`,
 `measure_on`, `test_type_id`, etc.), causing the `ValidationError` on record creation.

Fix:
----
- If the quality check is not linked to a move line, find the matching move line
 from the picking before splitting the failed quantity.

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/stock_move_line.py#L94-L97

- `_get_check_values()` normally takes values from a Quality Point. 
Since on-demand quality checks do not have one, fill the missing 
values (`team_id`,  `measure_on`) from the original quality check instead.

This allows manually created quantity-based quality checks to be 
split correctly after a partial failure.

---

opw-6428749

Forward-Port-Of: odoo/enterprise#130275
Forward-Port-Of: odoo/enterprise#126505

Currently, an error occurs when the `sync_shopee_pickings` cron tries to fetch
shipment labels for multiple batches of shipments. If some shipments do not
contain the required data in the Shopee API response, the error causes the
cron to stop, preventing the remaining batches from being processed.

Error:
`ValueError: KeyError('status') while evaluating 'model._sync_shopee_pickings()'`

This issue was introduced by a recent refactoring commit [1] focused on linting
and formatting the Python file. The commit replaced the generic `Exception`
with `UserError` when handling errors during batch label printing.

As a result, errors other than `UserError` are no longer handled at the batch
level. When such an error occurs, the entire cron process stops instead of
failing only the affected batch and continuing with the remaining batches.

This commit fixes the above issue by handling generic `Exception` during
shipment label generation, ensuring that the error is handled for the
affected batch while the remaining batches continue to be processed.

[1]: https://github.com/odoo/enterprise/commit/cfe5d947579739ad770ac3f1525ce157af530846#diff-e072c3ecf980add685bb4a4f25cf2b0ab5d4625988e4afc2c4d4faeae687ca88R199

sentry-7685943988

Forward-Port-Of: odoo/enterprise#130295
Forward-Port-Of: odoo/enterprise#130181

Replaced `useLayoutEffect` with `onMounted` + `onPatched` because
`useLayoutEffect` is deprecated in OWL3.

`useLayoutEffect(() => { ... }, () => [this.state.selectedDay])`
scrolled to the selected slot after each day change. OWL3 has no
direct equivalent with a dep array. The natural port to `useEffect`
ran eagerly before mount and crashed all 10 room_booking_form tests
(`this.root.el` was null). `onMounted` + `onPatched` guarantee the
DOM is present; a closure variable `scrolledDay` skips re-scrolls
when the day hasn't changed, preserving the original dep-array
semantics. An `onWillRender` subscription on `this.state.selectedDay`
ensures OWL schedules a re-render — and thus triggers `onPatched` —
whenever the day changes.

When commenting out the useLayoutEffect there was no error,
the code we refactored had NO TEST coverage. A test was written
to ensure our fix was correct, and it was tested against the
previous useLayoutEffect:
- Passed with previous useLayoutEffect.
- Failed with previous useLayoutEffect commented.
- Passed with our OWL3 replacement.