similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and path@test.com)
3) Generate offer and sign with all the required signer. 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as john@example.com).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as path@test.com)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

**opw-6280170**

Forward-Port-Of: odoo/enterprise#124215
Forward-Port-Of: odoo/enterprise#123767

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

### 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

…nding

When cash rounding is enabled with "Only for cash payment methods", an order partially paid in cash and completed with an online payment could neither request the correct online amount nor be marked as paid.

Steps to reproduce:
- Enable cash rounding (e.g. 0.05, HALF-UP) with "Only for cash payment methods"
- Create an order with a total of 15.28
- Add a cash payment of 10.00, then an online payment for the remainder

The frontend requests 5.28 for the online payment, but as soon as the order contained a cash payment the server rounded the whole order total: get_and_set_online_payments_data() returned an unpaid amount of 5.30 (15.30 - 10.00), so the validation failed with "Invalid online payments".

Even once the online payment of 5.28 was processed, the order remained stuck in draft with the money captured: _is_pos_order_paid() compared the paid amount (15.28) against the rounded total (15.30).

Only the part of the order actually settled in cash must be rounded: non-cash payments (card, online, ...) always pay their exact share.

- get_amount_unpaid() now returns the exact residual of the order when the rounding only applies to cash payment methods.
- _get_rounded_amount() now only rounds the amount not covered by non-cash payments, resolving its old TODO. Cash-only orders and orders where the cash payment settles the rounded remainder are unaffected.

opw-6314690

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

Forward-Port-Of: odoo/odoo#275472
Forward-Port-Of: odoo/odoo#275305

Description of the issue/feature this PR addresses:

When reversing or replacing an invoice with a C-symbol (tax code requiring approval), the reverse_moves method used an undefined `_l10n_vn_edi_lookup_invoice`, which is an old artifact from 19.2.

This commit replaces it by a call to the SInvoiceService `lookup_invoice`, following the same pattern used throughout the rest of the module.

Steps to reproduce:
1- Install `l10n_vn_edi_viettel`
2- Use credentials to put in Account settings
3- Fill the TIN under res.company
4- Go to symbols under configuration, fetch and select a symbol with a 'C' in the name
5- Create invoice, use symbol for VN e-invoice. Click Send
6- Create Credit note, click confirm on wizard

Current behavior before PR:
Validating the Credit Note would raise a Traceback.
```
AttributeError: 'account.move' object has no attribute '_l10n_vn_edi_lookup_invoice'
```

Desired behavior after PR is merged:
Validating the Credit Note should process as expected, without errors.



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

Typing in an HTML field (e.g. a contact's Internal Notes) and validating
a URL-like token with Enter or Space can crash the editor with
"IndexSizeError: The index is not in the allowed range", leaving the
user unable to continue typing. It happens on Safari (not Chromium).

The trigger is a URL-like token that the editor auto-converts into a
link. The splitText calls in prepareConvertToLink, run during
beforeinput, leave Safari's native selection anchored on an empty text
node with an out-of-range offset. Anything reading the selection
afterwards then works from a broken position: on Enter, splitBlock
reads it and makeActiveSelection ends up throwing in Range.setStart;
on Space, the browser inserts the character in the wrong node and the
selection is corrupted the same way.

```
UncaughtClientError > IndexSizeError
Uncaught Javascript Error > The index is not in the allowed range.
    setStart@[native code]
    createEditorSelection@.../web.assets_web.min.js:12239:15
    getSelectionData@.../web.assets_web.min.js:12242:145
    updateActiveSelection@.../web.assets_web.min.js:12230:92
    @.../web.assets_web.min.js:12218:873
    handler@.../web.assets_web.min.js:14366:121
```

Steps to reproduce:

1. Use Safari (Chromium-based browsers work fine)
2. Open any record with an HTML field (e.g. Contacts -> a contact ->
   Internal Notes).
3. Type a URL-like token such as KF.16D2.0204.CG (.CG is a valid TLD,
   so the editor auto-links it). Do not paste it.
4. Place the caret at the end of that token and press Enter or Space.
5. IndexSizeError is raised and the editor stops accepting input.

Fix it at the source: re-anchor the selection right after the splits in
prepareConvertToLink, so every consumer sees a valid caret position.
Since moving the selection during beforeinput makes WebKit cancel the
pending text insertion, the Space case now prevents the default and
performs the conversion, the space insertion and the caret placement
itself, in two history steps so that undo still reverts the link
conversion while keeping the typed space.

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

Forward-Port-Of: odoo/odoo#275587
Forward-Port-Of: odoo/odoo#270910

CertificateAdapter presents a client certificate stored in the database instead of on disk when opening an HTTPS connection (used by the l10n_es EDI modules verifactu, sii and tbai). It loaded that certificate on the connection path of requests 2.31, but requests >= 2.32 changed that path (no longer calls get_connection()), so the step was skipped and the call crashed with: "TypeError: expected str, bytes or os.PathLike object, not certificate"

Odoo pins requests 2.31.0 (max depending on Python version), but online databases can use the version shipped by the OS (2.32.x on recent Ubuntu 26).

Set the certificate up when the adapter is created instead of on that connection call. That step runs the same on every requests version, so the fix works both before and after 2.32.

Steps to reproduce:
  - Spanish company with Veri*Factu and a certificate, on a server
  running requests >= 2.32 (saas-19.3 database for exemple on ubuntu 26)
  - Post a customer invoice and send it to Veri*Factu.
  => TypeError

Reference: https://github.com/psf/requests/blob/f361ead047be5cb873174218582f7d8b9fcd9f49/HISTORY.md?plain=1#L146

Ticket [link](https://www.odoo.com/odoo/project.task/6366028)
opw-6366028

Forward-Port-Of: odoo/odoo#275324

**Steps to reproduce:**
1. Go to Website > Edit a page.
2. Add multiple Badges side by side.
3. Save the page.
4. Switch the website language, click on Edit/Translate and
translate the badges.
5. Save.

**Issue:**
After saving in translate mode, all badge elements are merged into
one.

**Why this happens:**
During save, `cleanForSave` triggers `mergeAdjacentInlines` on a
detached clone of the dirty element. This clone lacks all the css
styling, so `getComputedStyle` returns `""` for all padding/margin
on detached nodes. Consequently, `areSimilarElements` incorrectly
considers sibling `s_badge` spans as identical and merges them.

A recent fix (https://github.com/odoo/odoo/commit/91972ec2bbd85f9cfd7a1af794bbb2385a312f30) applied to `BadgeOptionPlugin` registers
`s_badge` as unsplittable via `unsplittable_node_predicates`,
preventing the merge in normal edit mode. However, translate mode
loads a separate plugin, `BadgeTranslationPlugin`, which was added
in the commit https://github.com/odoo/odoo/commit/cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 that lacks the same predicate.

opw-6261146

Forward-Port-Of: odoo/odoo#276040
Forward-Port-Of: odoo/odoo#273986