### Steps to reproduce

1. Create a invoice with a section and add products under it with values
2. Enable **Hide Composition** on the section.
3. Print the invoice PDF.

<table>
  <tr>
    <td>
      <img width="1278" height="425" alt="image" src="https://github.com/user-attachments/assets/969a222a-5e2f-48e2-962d-fc1cf6440619" />
    </td>
  </tr>
 </table>

### Description

When an invoice contains a section and products in it with values and with **Hide Composition** enabled, the PDF invoice report incorrectly displays the **Disc.%** column header even though no discount values in that section line.

The report currently computes `display_discount` using `o.invoice_line_ids`:

```xml
<t t-set="display_discount" t-value="any(l.discount for l in o.invoice_line_ids)"/>
```

Since `o.invoice_line_ids` still contains the hidden product lines, `display_discount` evaluates to `True`, causing the **Disc.%** column header to be displayed. However, those product lines are replaced by the section line in the report, so no discount values are shown, resulting in an empty column.


### Current behavior

The **Disc.%** column is displayed, but all its cells are empty.

<table>
  <tr>
    <td>
      <img width="808" height="488" alt="image" src="https://github.com/user-attachments/assets/7d9afee6-fef5-49c8-bc4e-b01caa8b43bd" />
    </td>
  </tr>
</table>

### Expected behavior

The **Disc.%** column should not be displayed when the reported lines do not contain any discounts.

<table>
  <tr>
    <td>
      <img width="798" height="427" alt="image" src="https://github.com/user-attachments/assets/6ffe7985-a7d0-43f5-8d40-41e700ecbed3" />
    </td>
  </tr>
</table>

### Solution

Compute `lines_to_report` before evaluating `display_discount` and use it instead:

```xml
<t t-set="lines_to_report" t-value="o._get_move_lines_to_report()"/>
<t t-set="display_discount" t-value="any(l.discount for l in lines_to_report)"/>
```

Forward-Port-Of: odoo/odoo#276003
Forward-Port-Of: odoo/odoo#275793

Steps to reproduce:
- Add an `s_add_to_cart` snippet inside a mega menu
- Open a product detail page for a storable product
- Change the product variant several times
- Stock availability messages keep appending under `availability_messages` instead of replacing the previous one

`_onChangeCombinationStock` removed existing messages with `document.querySelector('.oe_website_sale').querySelectorAll(...)`, but appended the new message with
`this.el.querySelector('div.availability_messages').append(...)`.

`document.querySelector('.oe_website_sale')` only returns the first `.oe_website_sale` element in the document. When a mega menu contains an `s_add_to_cart` snippet, that element appears before the product page container, so the removal step runs on the wrong subtree and never clears the messages on the product page.

Fix by scoping the removal to `this.el`, the current `WebsiteSale` interaction root, so both removal and insertion target the same product page container.

Forward-Port-Of: odoo/odoo#276252
Forward-Port-Of: odoo/odoo#274928

**Steps to reproduce:**

- Create a dynamic variant with 2 values, A and B
- B should have an extra price of 200
- Create a product which has those two variants, with a price of 1000
- Set up a barcode for the product with the B variant only
- Go to the PoS, enter the barcode for the product with the B variant
- The price is 1400 instead of 1200

**Why the fix:**

The extra price for dynamic variants ordered through the barcode will be counted twice.
This is because it is first counted in the _scan(code) method when we fetch the product from the models, then counted again when adding the line to the current order.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/point_of_sale/static/src/app/services/pos_store.js#L1264-L1269

This step is necessary for the usual flow without the barcode as we need to add this extra price, but when using the barcode, the list price of the product we fetch is already 1200, as the extra price is already included when fetching it from the backend.

It works for always attributes because we explicitly check that we are not adding the extra price again in the above code, and that the list price already includes the extra price. It also works for the never attributes because values.product_id.product_template_variant_value_ids.length is 0, so the code to update the extra price is never triggered.

As we still need to add the extra price for the usual flow, we now just check if we have a code, meaning we added the product through the barcode and that we do not need to add it again, as the list price already accounts for the extra price.

opw-6328600

Forward-Port-Of: odoo/odoo#272395

### Steps to reproduce

1. Create a invoice with a section and add products under it with values
2. Enable **Hide Composition** on the section.
3. Print the invoice PDF.

<table>
  <tr>
    <td>
      <img width="1278" height="425" alt="image" src="https://github.com/user-attachments/assets/969a222a-5e2f-48e2-962d-fc1cf6440619" />
    </td>
  </tr>
 </table>

### Description

When an invoice contains a section and products in it with values and with **Hide Composition** enabled, the PDF invoice report incorrectly displays the **Disc.%** column header even though no discount values in that section line.

The report currently computes `display_discount` using `o.invoice_line_ids`:

```xml
<t t-set="display_discount" t-value="any(l.discount for l in o.invoice_line_ids)"/>
```

Since `o.invoice_line_ids` still contains the hidden product lines, `display_discount` evaluates to `True`, causing the **Disc.%** column header to be displayed. However, those product lines are replaced by the section line in the report, so no discount values are shown, resulting in an empty column.


### Current behavior

The **Disc.%** column is displayed, but all its cells are empty.

<table>
  <tr>
    <td>
      <img width="808" height="488" alt="image" src="https://github.com/user-attachments/assets/7d9afee6-fef5-49c8-bc4e-b01caa8b43bd" />
    </td>
  </tr>
</table>

### Expected behavior

The **Disc.%** column should not be displayed when the reported lines do not contain any discounts.

<table>
  <tr>
    <td>
      <img width="798" height="427" alt="image" src="https://github.com/user-attachments/assets/6ffe7985-a7d0-43f5-8d40-41e700ecbed3" />
    </td>
  </tr>
</table>

### Solution

Compute `lines_to_report` before evaluating `display_discount` and use it instead:

```xml
<t t-set="lines_to_report" t-value="o._get_move_lines_to_report()"/>
<t t-set="display_discount" t-value="any(l.discount for l in lines_to_report)"/>
```

Forward-Port-Of: odoo/odoo#276003
Forward-Port-Of: odoo/odoo#275793

**Steps to reproduce:**

- Create a dynamic variant with 2 values, A and B
- B should have an extra price of 200
- Create a product which has those two variants, with a price of 1000
- Set up a barcode for the product with the B variant only
- Go to the PoS, enter the barcode for the product with the B variant
- The price is 1400 instead of 1200

**Why the fix:**

The extra price for dynamic variants ordered through the barcode will be counted twice.
This is because it is first counted in the _scan(code) method when we fetch the product from the models, then counted again when adding the line to the current order.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/point_of_sale/static/src/app/services/pos_store.js#L1264-L1269

This step is necessary for the usual flow without the barcode as we need to add this extra price, but when using the barcode, the list price of the product we fetch is already 1200, as the extra price is already included when fetching it from the backend.

It works for always attributes because we explicitly check that we are not adding the extra price again in the above code, and that the list price already includes the extra price. It also works for the never attributes because values.product_id.product_template_variant_value_ids.length is 0, so the code to update the extra price is never triggered.

As we still need to add the extra price for the usual flow, we now just check if we have a code, meaning we added the product through the barcode and that we do not need to add it again, as the list price already accounts for the extra price.

opw-6328600

Forward-Port-Of: odoo/odoo#272395

Problem:
When posting expenses, if the expense domain is set as mandatory in any of the analytic plans, users can still submit expenses without entering an analytic distribution. This only happens when the expense is auto-approved on submission, which happens when the expense's employee is also the expense's manager or when the employee doesn't have an expense manager.

Steps to reproduce:
1. Create an analytic plan with optional default applicability
2. Add an applicability rule with the domain set as Expense and set its applicability as mandatory.
3. Create a new expense
4. Set the expense's manager the same as the expense's employee.
5. Don't enter any analytic distribution.
6. Submit the expense
7. Notice how the expense is submitted and auto-approved without any error, even though no analytic distribution is entered and the analytic plan has a mandatory rule for expenses.

Cause:
The validation of the analytic distribution was only triggered on the approval of the expense, but when the expense is auto-approved on submission, the validation is not triggered at all.

Solution:
Move the validation of the analytic distribution to the do_approve method, which gets called both when an expense is approved and when it's auto-approved on submission.

opw-6187340

Forward-Port-Of: odoo/odoo#270268

Currently, flexible weekly overtime deducts the raw leave interval duration.

## **Steps to reproduce:**
- Install hr_holidays and hr_attendance
- Create an employee with flex 40h/week working schedule.
- Employee profile>setting>Default Ruleset>Employee schedule Rule and set `If the worked hours on a`: `week`.
- Create a public holiday on Monday.
- Record daily 8h from Tue to Sat (12 AM to 8 AM).

## **Observed Behavior:**
Attendance List View computes "Worked Extra Hours" incorrectly as 20:30h

## **Expected Behavior:**
"Worked Extra Hours" should be computed as 8h

## **Root Cause:**
In [_get_daterange_overtime_undertime_intervals_for_quantity_rule](https://github.com/odoo/odoo/blob/53448e5445c8bcbf12126bf27bd675f4b9883d05/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L290-L342), the system manually calculates overtime for flexible employees by deducting `schedule['leave']` durations from the expected working hours at [1]. However, for global public holidays, the system mishandles the timezone conversion within this schedule dictionary. Because public holiday intervals are stored and processed using UTC datetimes before being converted to the employee's local timezone, converting it to the employee's local timezone causes the holiday hours to shift and overlap into the next calendar day. As a result, the `schedule['leave']` calculation incorrectly thinks the employee had time off on normal working days, which throws off the final overtime amount.

[1]: http://github.com/odoo/odoo/blob/53448e5445c8bcbf12126bf27bd675f4b9883d05/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L304-L307

## **Fix:**
Replace the manual leave subtraction logic with the existing `_get_expected_hours_from_contract` method. This method naturally handles global public holidays and computes attendance intervals safely across different timezones without shifting hours into the wrong day.

**opw-6259328,6284145**

Forward-Port-Of: odoo/odoo#274831
Forward-Port-Of: odoo/odoo#269293

**Steps to reproduce:**

- Create a product A, tracked by lots
- Create a kit product, include a component A
- Change the UoM to 0.5
- Go to the PoS, order this kit product
- Also order the component A, with a quantity of 2
- Pay for it, ask for an invoice
- Go to the created picking
- The Demand column is correctly computed and is 0.5
- The Quantity column is wrong and is 2

**Why the fix:**

When getting the data from https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L283 
we always get the component's line, as the move's product is the component, even if it used to be the kit product's move. This is because when exploding a kit's moves, it gets the kit's component as a product instead of keeping the kit product.

This was introducing a weird behavior because we took the quantity from the component line, and not from the kit line, meaning the kit would always have the same quantity as the component.

We now check if the move is actually a kit product's move, and if it is we adapt the qty to correct one by fetching the correct line's qty, and adapting it with the correct UoM.

Changing the line in itself would not work, as the kit itself is not tracked by lots, so we would not enter https://github.com/odoo/odoo/blob/e0d84c7fbb270d0d1f82572daefa96c2978d3785/addons/point_of_sale/models/stock_picking.py#L284 
and the move line would not be correctly created.

opw-6153000

Forward-Port-Of: odoo/odoo#276098
Forward-Port-Of: odoo/odoo#262551

**Issue**
The priority of a purchase order is not propagated to the corresponding picking

**Steps to reproduce**
- Create a PO for a product
- Click on the star (set priority)
- Confirm the PO and open the corresponding picking -> The priority is not set on the picking

**Cause**
The feature was introduced in 19.2 and worked through `_prepare_picking()` (4eb64d15d10a258e2902818304c29681fe268553): 
https://github.com/odoo/odoo/blob/4eb64d15d10a258e2902818304c29681fe268553/addons/purchase_stock/models/purchase_order.py#L401

However a refactor in 19.3 removed that method without preserving the priority propagation (a1fb39eb6ae0d1abc12ab2aaf876b10baed4d7cd). Instead of using `_prepare_picking`, it creates the moves and confirm it: 
https://github.com/odoo/odoo/blob/a1fb39eb6ae0d1abc12ab2aaf876b10baed4d7cd/addons/purchase_stock/models/purchase_order.py#L387-L388 
which will create the picking (if needed):
https://github.com/odoo/odoo/blob/9221edd716ac241a301fa25d511fde0edb17b3f4/addons/stock/models/stock_move.py#L1449 https://github.com/odoo/odoo/blob/9221edd716ac241a301fa25d511fde0edb17b3f4/addons/stock/models/stock_move.py#L1476

opw-6275965

#### Issue:
Opening the MRP planning view could raise a traceback when a maintenance
request had a `schedule_end` but no `schedule_date`.

`TypeError: '<' not supported between instances of 'NoneType' and 'datetime.datetime'`

#### Steps to reproduce:
1. Install maintenance, mrp, and mrp_maintenance.
2. Create a work center.
3. Create a maintenance request linked to that work center.
4. set a `Scheduled end` and Leave `Scheduled Date` empty.
5. Go to MRP > Planning > Work Orders.

#### Cause:
`maintenance.request` stores `schedule_end` as a writable field, but no
constraint enforces that `schedule_date` and `schedule_end` must be set
together.

Later, `mrp_maintenance` in `_get_maintenances_intervals` fetches maintenance
intervals for the gantt view without filtering null bounds. If a request has
`(schedule_date, schedule_end)` = `(False, datetime)`, that interval is passed
to `Intervals(...)`, which crashes when comparing `None` with a `datetime`.

#### Fix:
Add a constraint on `maintenance.request` to require `schedule_date` and `schedule_end`
to either both be set or both be empty. Also filter out incomplete intervals in the MRP
maintenance gantt query in this enterprise PR: https://github.com/odoo/enterprise/pull/117710

opw-6225772

enterprise PR: https://github.com/odoo/enterprise/pull/117710

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

Forward-Port-Of: odoo/odoo#265208

### Steps to reproduce

1. Create a invoice with a section and add products under it with values
2. Enable **Hide Composition** on the section.
3. Print the invoice PDF.

<table>
  <tr>
    <td>
      <img width="1278" height="425" alt="image" src="https://github.com/user-attachments/assets/969a222a-5e2f-48e2-962d-fc1cf6440619" />
    </td>
  </tr>
 </table>

### Description

When an invoice contains a section and products in it with values and with **Hide Composition** enabled, the PDF invoice report incorrectly displays the **Disc.%** column header even though no discount values in that section line.

The report currently computes `display_discount` using `o.invoice_line_ids`:

```xml
<t t-set="display_discount" t-value="any(l.discount for l in o.invoice_line_ids)"/>
```

Since `o.invoice_line_ids` still contains the hidden product lines, `display_discount` evaluates to `True`, causing the **Disc.%** column header to be displayed. However, those product lines are replaced by the section line in the report, so no discount values are shown, resulting in an empty column.


### Current behavior

The **Disc.%** column is displayed, but all its cells are empty.

<table>
  <tr>
    <td>
      <img width="808" height="488" alt="image" src="https://github.com/user-attachments/assets/7d9afee6-fef5-49c8-bc4e-b01caa8b43bd" />
    </td>
  </tr>
</table>

### Expected behavior

The **Disc.%** column should not be displayed when the reported lines do not contain any discounts.

<table>
  <tr>
    <td>
      <img width="798" height="427" alt="image" src="https://github.com/user-attachments/assets/6ffe7985-a7d0-43f5-8d40-41e700ecbed3" />
    </td>
  </tr>
</table>

### Solution

Compute `lines_to_report` before evaluating `display_discount` and use it instead:

```xml
<t t-set="lines_to_report" t-value="o._get_move_lines_to_report()"/>
<t t-set="display_discount" t-value="any(l.discount for l in lines_to_report)"/>
```

Forward-Port-Of: odoo/odoo#276003
Forward-Port-Of: odoo/odoo#275793

Steps to produce:
---
- Install the `sales` module.
- Create a product and `enable track inventory.`
- Log in as user with only view access rights in products and also have the sales access rights.
- Create a sale order containing product and confirm it.

Issue:
---
-  An access error is raised during order confirmation.

Root cause:
---
- In [commit], to handle inventory tracking, the `qty_available` field
was moved to `product.product`. Unlike before, this value is increased
or decreased depending on the operation performed.

- As a consequence, creating or updating a sale order triggers a write
to this `qty_available` field on the related product. This
write happens under the current user's permissions, so users who
only have read access to products (but can create/edit sale orders)
hit an `AccessError`, since they lack write access on
`product.product`.


Solution:
---
- Use `sudo()` when accessing the required product quantity information
  to ensure the operation can be completed without requiring additional product
  access rights.

The same issue also occurs when confirming a purchase order.

[commit]: https://github.com/odoo/odoo/commit/ca96992919b11105da44238c3e522f8eec4a740b

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

Forward-Port-Of: odoo/odoo#270067

**Steps to reproduce:**

- Create a dynamic variant with 2 values, A and B
- B should have an extra price of 200
- Create a product which has those two variants, with a price of 1000
- Set up a barcode for the product with the B variant only
- Go to the PoS, enter the barcode for the product with the B variant
- The price is 1400 instead of 1200

**Why the fix:**

The extra price for dynamic variants ordered through the barcode will be counted twice.
This is because it is first counted in the _scan(code) method when we fetch the product from the models, then counted again when adding the line to the current order.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/point_of_sale/static/src/app/services/pos_store.js#L1264-L1269

This step is necessary for the usual flow without the barcode as we need to add this extra price, but when using the barcode, the list price of the product we fetch is already 1200, as the extra price is already included when fetching it from the backend.

It works for always attributes because we explicitly check that we are not adding the extra price again in the above code, and that the list price already includes the extra price. It also works for the never attributes because values.product_id.product_template_variant_value_ids.length is 0, so the code to update the extra price is never triggered.

As we still need to add the extra price for the usual flow, we now just check if we have a code, meaning we added the product through the barcode and that we do not need to add it again, as the list price already accounts for the extra price.

opw-6328600

Forward-Port-Of: odoo/odoo#272395

**Steps to reproduce:**

- Create a dynamic variant with 2 values, A and B
- B should have an extra price of 200
- Create a product which has those two variants, with a price of 1000
- Set up a barcode for the product with the B variant only
- Go to the PoS, enter the barcode for the product with the B variant
- The price is 1400 instead of 1200

**Why the fix:**

The extra price for dynamic variants ordered through the barcode will be counted twice.
This is because it is first counted in the _scan(code) method when we fetch the product from the models, then counted again when adding the line to the current order.
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/point_of_sale/static/src/app/services/pos_store.js#L1264-L1269

This step is necessary for the usual flow without the barcode as we need to add this extra price, but when using the barcode, the list price of the product we fetch is already 1200, as the extra price is already included when fetching it from the backend.

It works for always attributes because we explicitly check that we are not adding the extra price again in the above code, and that the list price already includes the extra price. It also works for the never attributes because values.product_id.product_template_variant_value_ids.length is 0, so the code to update the extra price is never triggered.

As we still need to add the extra price for the usual flow, we now just check if we have a code, meaning we added the product through the barcode and that we do not need to add it again, as the list price already accounts for the extra price.

opw-6328600

Forward-Port-Of: odoo/odoo#272395

Problem:
When posting expenses, if the expense domain is set as mandatory in any of the analytic plans, users can still submit expenses without entering an analytic distribution. This only happens when the expense is auto-approved on submission, which happens when the expense's employee is also the expense's manager or when the employee doesn't have an expense manager.

Steps to reproduce:
1. Create an analytic plan with optional default applicability
2. Add an applicability rule with the domain set as Expense and set its applicability as mandatory.
3. Create a new expense
4. Set the expense's manager the same as the expense's employee.
5. Don't enter any analytic distribution.
6. Submit the expense
7. Notice how the expense is submitted and auto-approved without any error, even though no analytic distribution is entered and the analytic plan has a mandatory rule for expenses.

Cause:
The validation of the analytic distribution was only triggered on the approval of the expense, but when the expense is auto-approved on submission, the validation is not triggered at all.

Solution:
Move the validation of the analytic distribution to the do_approve method, which gets called both when an expense is approved and when it's auto-approved on submission.

opw-6187340

Forward-Port-Of: odoo/odoo#270268

#### Issue:
When creating a reordering rule for a shared manufactured product in a multi-company database,
saving the rule may raise an `AccessError` on `mrp.bom`.

The orderpoint is still created, but the user sees a record-rule error if the product also
has BoMs in companies that are not currently active.

#### Example:
A product is shared across multiple companies, and each company has its own BoM for that product.
In the reproduced case, the active company has the correct variant BoM.
However, the orderpoint computation first checks the broader product-template BoM relation,
which may include BoMs from the other companies. As a result, Odoo can try to access
a BoM from another company while the user is only working in the active company,
causing an access error.

#### Steps to reproduce:
Use a multi-company database with MRP enabled.
Create or use a shared product available to multiple companies. Create BoMs for that product in more than one company. Set the active company to the company where the reordering rule should be created.
Create a reordering rule for the product.
Save the reordering rule.
Note the AccessError related to mrp.bom.

#### Root Cause:
The MRP orderpoint computations read `product_id.bom_ids` directly. This is the product-template BoM relation and can include BoMs from other companies for a shared product. Reading fields on those BoMs, such as `product_uom_id`, can hit the standard `mrp.bom` multi-company record rule.

#### Fix:
Prefer `product_id.variant_bom_ids` before falling back to `product_id.bom_ids` in the affected orderpoint computations. This avoids reading template-level BoMs from other companies when the product has a variant-specific BoM for the current reordering-rule use case.

opw-6253743

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

Forward-Port-Of: odoo/odoo#267411

**Steps to reproduce:**
- Install Contacts app
- Open any record
- Go to the chatter
- Create an activity with a description
- Duplicate the tab
- Go back to the initial tab
- Description doesn't appear anymore
- Refreshing shows it but will remove it from the other tab

**Issue:**
Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`.

Computed fields are not recomputed on the receiver side after value insertion in `_onActivityBroadcastChannelMessage` (also related components are not (re)mounted, e.g. when a new activity is created the other tab doesn't show it without a refresh).

This means that `isNoteEmpty` keeps its default value `true` (added by `this.toData()`) and the `note` stays hidden here [1]:
```xml
<div t-if="!props.activity.isNoteEmpty" class="o-mail-Activity-note text-break" t-out="props.activity.note"/>
```

**Fix:**
Remove computed fields in activity `serialize` before broadcasting them to ensure they don't force the default value.

(note installing `calendar` in 19.3+ removes this issue due to [2] which overrides the condition on `isNoteEmpty`)

[1] https://github.com/odoo/odoo/commit/eb9f0658c3da1a9fef69f1cc1117c2d44f9d61b1
[2] https://github.com/odoo/odoo/commit/44e2c2c5ca07849fd8964140f3ca61122c47f0c6

opw-6247412

Forward-Port-Of: odoo/odoo#276032
Forward-Port-Of: odoo/odoo#275528

# How to reproduce
- Set an employee's work schedule to flexible 40hrs/week with 8hrs of work per day
- Create a new attendance for that employee that :
	- Is the very first attendance of that employee
	- Is not on a monday (e.g. a Friday)
- Create a second attendance for that employee that :
	- Is atleast one week after the first attendance
	- Is one of the two days of the week before the day of the week of the first attendance (e.g. a Wednesday or a Thursday)
- Go to the settings, update the value for "Tolerance Time In Favor Of Company" and save
- Come back to the second attendance

# The problem
The Extra Hours have changed and are equal to the worked time

# Cause
When we update the tolerance time, we recompute the overtime of every attendance of every employee.
In this recomputation, we compute the `expected_attendance` of every employee and transforms
them into a dict of the expected working time for each day :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L349-L356

Later, if an attendace of the employee was not in their expected working days, then we consider that all hours worked were overtime :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L381-L384

This makes sense but our issue is that days in the middle of the week are considered "time-off" when they
should not. That's because for flexible working schedules, we emulate the expected working hours based on
the total hours per week and the maximum hours per day :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/resource/models/resource_calendar.py#L384-L386

For every "week", we start from the first day and continue forward by greedily using all hours for that
day until there is no more hours for the week. The problem is that since this PR, we don't start "weeks" on
mondays, but on the `start_datime` :
https://github.com/odoo/odoo/commit/af36e73108cef4326f6125c3af491b07a51534fe

And in our case, `start_datetime` is the very first attendance day of the employee :
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/hr_attendance/models/hr_attendance.py#L344

So our expected working days are desynched with the days of the week

# Proposed solution
We partly revert https://github.com/odoo/odoo/commit/af36e73108cef4326f6125c3af491b07a51534fe

opw-6289079

Forward-Port-Of: odoo/odoo#269820

**Problem:**
On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist).

**Steps to reproduce:**
1. Create a subscription product with a recurring plan.
2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price).
3. Open the product page on the website.

**Current behavior:**
The page fails with a 500: Internal Server Error during price computation.

**Expected behavior:**
The page loads and shows the discounted recurring price.

**Cause of the issue:**
For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion.

**Fix:**
Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record.

opw-6306105

Forward-Port-Of: odoo/enterprise#121466

### Description

Installing or upgrading `l10n_pe_edi` aborts with a `psycopg2.errors.SyntaxError` whenever `account_move` already contains rows:

```
psycopg2.errors.SyntaxError: syntax error at or near "AND"
LINE 9:                    AND l10n_pe_edi_operation_type IS NULL
```

### Root cause

The `init_storage` SQL that backfills `l10n_pe_edi_operation_type` (added in e182608f13c6 `[REF] *: use init_storage`) closes the `WHERE` clause with a stray semicolon right after the country condition:

```sql
WHERE res_company.id = account_move.company_id
   AND move_type IN ('out_invoice', 'out_refund')
   AND res_country.code = 'PE';               -- stray ';' ends the UPDATE
   AND l10n_pe_edi_operation_type IS NULL     -- parsed as a new statement -> syntax error
```

The semicolon terminates the `UPDATE` early, so `AND l10n_pe_edi_operation_type IS NULL` is parsed as a separate statement starting with `AND`.

`init_storage` only runs when the table already has rows (`_init_column_data` in `odoo/orm/fields.py` skips empty tables), which is why the crash surfaces on databases that already contain journal entries — e.g. runbot `*-all` builds, or `button_immediate_install` over a populated database.

### Fix

Remove the stray semicolon so the NULL guard stays part of the `WHERE` clause.

### Validation

Reproduced and verified on `master` (community + enterprise), with a row present in `account_move`:

- **Before:** `-u l10n_pe_edi` fails with `syntax error at or near "AND"` at `LINE 9`.
- **After:** the module installs/updates cleanly and the column is backfilled without error.

Issue:
The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence 

According to CPA-005 standards on the Item Trace Number:
"The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36).
https://www.payments.ca/sites/default/files/standard005eng.pdf

Steps to reproduce:
1. Install the module l10n_ca_payment_cpa005
2. Go into "CA Company"
3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC"
4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal
5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence
6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error)
7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT"
8. Create a batch payment for both payments created
9. Validate the batch payment and the export file should show up in the chatter
10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence

Solution:
Set the Item Trace Number to be the payment's id

opw-6323432

Forward-Port-Of: odoo/enterprise#124016
Forward-Port-Of: odoo/enterprise#123633

Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule computations. However, doing so raises a traceback immediately upon closing the Studio editor, as well as when attempting to create a new Off-Cycle payslip.

### Steps to reproduce:
* Install `l10n_mx_hr_payroll` and `web_studio`.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Payroll > Payslips > Payslips and create a "New Off-Cycle"
* Use the Studio editor to add `l10n_mx_daily_salary` or `l10n_mx_integration_factor` fields.
* Close the Studio editor.

### Current behavior:
A traceback is raised depending on the field added

#### For the Daily Salary field:
```py
  File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 21, in _compute_daily_salary
    payslip.l10n_mx_daily_salary = payslip.version_id.wage / payslip._rule_parameter('l10n_mx_schedule_table')[payslip.version_id.schedule_pay]
                                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: False
```

#### For the Integration Factor field:
```py
  File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 33, in _compute_integration_factor
    payslip.employee_id.with_context(before_date=payslip.date_from)._get_first_contract_date()
  File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 493, in _get_first_contract_date
    versions = self._get_first_versions_filtered(no_gap=no_gap).filtered(lambda x: x.contract_date_start)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 461, in _get_first_versions_filtered
    self.ensure_one()
  File "/Users/ivgm/odev/worktrees/19.0/odoo/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.employee()
```

### Expected behavior:
No error is raised, and the fields are correctly displayed on the form view.

### Solution:
* Add Guard Clause: When creating a "New Off-Cycle" payslip, `payslip.version_id` is not initially set because no employee has been selected yet. Added a condition to check if `version_id` exists before computing the values to prevent the traceback.
* View Update: Since displaying these fields is a highly requested feature for traceability, they have now been added to the form view.

target: 19.0
task-6267003

Forward-Port-Of: odoo/enterprise#121718

# How to reproduce
You need to simulate the fact that you are creating an appraisal late so either : 
A) Directly edit the `next_appraisal_date` in SQL
B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days

Then :
- Click on Request Appraisal
- Save

# The problem
An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this.

# Cause
`next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57

When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92

This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85

opw-6147865

Forward-Port-Of: odoo/enterprise#123817
Forward-Port-Of: odoo/enterprise#114876

## [FIX] sale_renting_planning: check global leaves working schedule

Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.

After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.

if the leave has no `calendar_id` then the leave applies to all `resource.calendars`

if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well

## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones

This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.

It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.

task-6179505

Forward-Port-Of: odoo/enterprise#120983
Forward-Port-Of: odoo/enterprise#116430

steps to reproduce:
-----------
  - install the industry_fsm_repair module
  - create a product with type goods and enable `create repair`
  - enable `create repair orders` from returns in delivery orders in operation types
  - create a sale order with an fsm product and a goods product
  - confirm the sale order and validate the delivery
  - return the delivery and validate it (wh/in/0000x)
  - open the return receipt (wh/in/0000x) and create a repair
  - create an fsm user without stock access
  - log in with the fsm user
  - open a task, go to `pick up`, and open the stock move
  - open the repair order

issue:
--------
   the fsm user does not have access to stock lots and repair tags, which causes an access error.

fix:
----
  added the stock user group to the repair tags and stock lot fields so  that users without the stock user group cannot access them.

technical:
------
  in the stable version, i did not extend the repair view in the industry_fsm_repair module. instead, i added the group directly in the repair module.
  In master, the group is added through the industry_fsm_repair module.
  
  task-6032336

Issue:
---
If a product template has dynamic attributes, some variants might not exist. For those variants, we are showing wrong stock in the website.

To reproduce:
1- Create a product with a dynamic attribute and two values.
2- Publish the product and uncheck sell when out-of-stock and check show product when the qty is less than 5.
3- Create a purchase order with qty = 4 for the first value, so a variant is created for it.
4- Go to the website shop. Open the product. 4 available qty in stock is shown for the first variant which is correct.
5- Select 2nd variant.

As you see, still 4 available qty is shown which is wrong.

As the out-of-stock sale is unchecked, an out-of-stock warning should be shown.

Cause and Fix:
---
This is due to `isMainProduct` being always False when `product_id` is
not set which makes `free_qty` and `out_of_stock` not to be updated.

Also in `get_combination_info_website`, `is_storable` value is set to
variant `is_storable` field which will be False if product variant is
not exist.

opw-6237602

Forward-Port-Of: odoo/odoo#273104

The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself.

Steps to reproduce:
- Enable Sale Credit Limit in the settings of My Company (San Francisco)
- Set a Credit Limit of 100 on a customer, e.g. Deco Addict
- Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected
- Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies
- Open the same quotation again => The warning banner is gone, although neither the quotation nor the
   customer changed

The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one.

Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company.

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