Problem:
When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if an invoice has been marked as blocked, it might be automatically unblocked during reconciliation.

Solution:
The `_compute_payment_state` method will now prioritize a move's `payment_state` being blocked over whether it has been posted. This prevents a blocked move from being unblocked unexpectedly.

Steps to Replicate (Runbot 18)
- Create a product
	- Track inventory
	- Cost > 0
	- Control policy = On ordered quantities
	- Product category is valuated in real-time (Inventory Valuation - Automated) (requires 'Stock Accounting Automatic' group)

1. Create a PO for the product
2. Create a bill, validate it
3. Block the bill using the contextual action
4. Receive the product

If you navigate back to the Vendor Bill, you will see that it has been unblocked.

opw-4981799

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

Forward-Port-Of: odoo/odoo#223351
Forward-Port-Of: odoo/odoo#222906

Currently, there is inconsistent behavior in price calculation 
when a user places a self order for a product containing attributes.

**Pre-requisites:**
- POS module installed and configured.
- Variant enabled in settings.
- Self-ordering is enabled in the POS configuration.
- Two product attributes created in the settings/attributes:
   - One of type radio with variant creation set to Instantly.
   - Another of type multi-checkbox with variant creation set to Never.
- Create attribute lines for both attributes with default extra prices.

**Steps to reproduce:**
1) Create a product template linking the above attributes 
2) Ensure the product is available in POS and self ordering 
3) Open a POS session in one browser tab and the self-ordering in another. 
4) Select the product in the self-ordering interface, first choosing
   an option for the radio attribute, then selecting one or more options
   for the multi-checkbox attribute.

**Error:**

You will see the difference between the expected price and the displayed price

**Example for Clarity:**

Consider a product called Pizza with 2 attributes. The base price of the pizza is $10.

| Attribute                           | Option           | Extra Price           |
| ----------------------------------- | ---------------- | --------------------- |
| **Size** (radio)                    | Small (S)        | \$0 (no extra charge) |
|                                     | Medium (M)       | \$5                   |
|                                     | Large (L)        | \$10                  |
| **Extra Toppings** (multi-checkbox) | Veggies          | \$3                   |
|                                     | Extra Cheese     | \$3                   |
|                                     | Veggies & Cheese | \$5                   |

If the user selects a medium-sized pizza with veggie toppings, 
The expected price is: 
```
$10 (base) + $5 (Medium size) + $3 (Veggies) = $18. However, the price shown is only $13.
```

**Root Cause:**
For attributes of the multi-checkbox type, variant creation is set to Never by default. 
This means no product variants are generated for such attributes.

Because of this, when calculating the price, the extra price associated with the 
multi-checkbox attribute is added directly to the base price of the product template
instead of the price of the selected variant. 

This happens because the variant information is not properly passed to the price calculation method:
https://github.com/odoo/odoo/blob/9df334c0aca8a57dcbed4c87b43b18403f3a7c6e/addons/pos_self_order/static/src/app/services/card_utils.js#L187-L196 https://github.com/odoo/odoo/blob/9df334c0aca8a57dcbed4c87b43b18403f3a7c6e/addons/point_of_sale/static/src/app/models/product_template.js#L185-L189

As a result, the extra price for the multi-checkbox attribute is incorrectly added 
to the product template’s base price rather than the variant’s price.

**Solution:**

Pass the product_variant derived from the selected product.product to the price calculation method. 
This ensures that if a variant exists based on the user’s selection, 
the extra price is added to the variant’s price rather than the base product template price, 
resulting in the correct total price.

opw-4963537

Problem:
On large screens, the `s_showcase` template shows blocks stacked vertically instead of side-by-side as in the editor.

Cause:
After commit 10008b32334152ada1a847b091189d1d9d5aa3d3, `s_showcase` was refactored to fix selection/formatting issues. Mixing relative widths (`col-sm`) with fixed widths (`col-1`) breaks in `convert_inline`, exceeding the 12-column grid.

Solution:
- Use `Math.floor` when calculating the `colSize` to prevent overflow

Before:
<img width="1862" height="948" alt="image" src="https://github.com/user-attachments/assets/35d82103-1f84-4754-862d-50ef3481bcb3" />
After:
<img width="1847" height="955" alt="image" src="https://github.com/user-attachments/assets/20e1b454-dfc4-4ad0-9e6a-3b38c230d0fd" />

Steps to reproduce:
1. Open a new email marketing.
2. Drop the `s_showcase` snippet.
3. Send a test email.
4. Observe the received template is misaligned compared to the editor.

opw-4946126

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

Forward-Port-Of: odoo/odoo#222801

### Steps to reproduce:

- Go to the To-Do app and type something in the editor.
- Select the typed text.
- Click on the Font Size Input and choose a value from the dropdown (e.g.,80).
- Try typing again in the editable area.
- Selection is still visible, the focus is no longer in the editable area.

### Description of the issue/feature this PR addresses:

- `focusEditable()` skipped restoring focus if the selection was inside the editor, even when the editor itself wasn’t focused.
- When the font size input (inside an iframe) is focused, editable loses focus.
- Selecting a value from the dropdown blurs the iframe input, but focus is not returned to the editable area.
- As a result, the selection is still visible but the user cannot type.

### Desired behavior after PR is merged:

- Does nothing if the editor or its descendants have focus.
- Focuses the editor if needed.
- Restores selection only when it's outside the editor.
- When the iframe input is blurred, focus is returned to the editable area.

task-4932364

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

Forward-Port-Of: odoo/odoo#218774

Steps:
-Install the hr_holidays_contract module
- Create two contracts for the same employee: 
- Contract A (Part-time) starting from 01/01/2025 and set to Running 
- Contract B (Full-time) also starting from 01/01/2025 and set to New 
- open holiday dashboard for that employee

Description of the issue/feature this PR addresses: 
The Time Off dashboard incorrectly considers the full-time contract instead of the part-time one, even though the part-time contract is in the running state.

Cause:
The contract selection logic did not correctly prioritize the running contract when multiple contracts existed for the same period.

Fix:
This PR updates the logic to ensure that:
   - If a contract is in the running state at a given time, it is used to determine the working schedule and time off calculations.
   - If no contract is running during that time and multiple contracts exist, the contract with the latest creation_id will be considered.

task-4724155

Forward-Port-Of: odoo/odoo#212959

Currently, an error occurs when a user sign the document and tries to validate and send the completed document.

**Steps to reproduce:**

- Install the `sign` module.
- Go to: `Sign Settings > Cryptographic Signature` > Create a 'Signing certificate' and upload any random PDF (Observe: A warning appears `'This certificate could not be loaded. Either the content or the password is erroneous.'`).
- In the Sign app, upload any document, drag and drop a `Signature` field, and sign the document.
- Click `Validate & Send Completed Document`.

**Note:**
- [1] Make sure your system has cryptography version `41.0.7 or above`.
- Refer to [2] for steps to reproduce.

**Error:**
`TypeError: expected bytes-like object, not bool`

**Root Cause:**
At [3], when the certificate is not correctly created, `certificate.pem_certificate` is `False`, which leads to an error.

This commit allows validating and sending a signed document, when the certificate is invalid.

[1]:
https://github.com/odoo/odoo/blob/d730518fa6a1fba3b3edba6f3b65bcc88ed992fe/odoo/tools/pdf/signature.py#L16

[2]:
https://drive.google.com/file/d/19fd82TdGzVPRUVW3PDMGEhyaQLTwL41h/view?usp=sharing

[3]:
https://github.com/odoo/odoo/blob/a6fa3784b20f75490e405e3728d5a335f2104fa0/odoo/tools/pdf/signature.py#L85

sentry-6796501254

Forward-Port-Of: odoo/odoo#222417

When user tries to open the website,
A traceback will appear.

Steps to reproduce the error:
- Install ``website_livechat`` with demo data
- Sign in as ``Mitchell admin`` on one browser window
- Create a new ``User A`` > Set login and password for User A
- In Incognito tab, Go to Sign in Page > click on the livechat button > Send any message > End the conversation >
  Sign in as ``Marc Demo`` > Open Website > Sign out
- User will face Access Error
- In Same Incognito Tab > Go to ``/web/login`` > click on the livechat button > Send any message > End the conversation >
  Sign in as ``User A`` > Open the Website

Traceback:
```
AttributeError: 'discuss.channel' object has no attribute 'channel_ids'
```

https://github.com/odoo/odoo/blob/d9c63a85955c2321bae1a705cc09b2554155f826/addons/website_livechat/models/website_visitor.py#L113
Here, The ``guest_livechats`` variable contains records of the ``discuss.channel`` model.
However, the ``discuss.channel`` model does not have a ``channel_ids`` field.
So, It will lead to the above traceback.

When the Marc Demo user logs out, the following line will raise an access error:
because now the user is considered as a guest, and guest users do not have the necessary access rights to update the ``livechat_visitor_id`` field.
To resolve this, ``sudo()`` is used to bypass access rights at the following line: https://github.com/odoo/odoo/blob/254d66e1e3d646c9c82fbb3561a40aba7790c3b5/addons/website_livechat/models/website_visitor.py#L112-L114

sentry-6670622453

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

Steps to Reproduce:
1. Go to Delivery Methods.
2. Enable and configure Shiprocket, then publish it.
3. Go to Settings.
4. Search for Google Merchant Center Data Source.
5. Enable the checkbox.
6. Click on the Copy File Link button.
7. Open the copied link in a new browser tab.


Observation:
A traceback occurs, stating that some of the customer’s fields are missing.


Issue:
In the `_prepare_best_delivery_by_country` method, we create a temporary partner
record. Later, in `_check_required_value`, we validate the Street, Email, Pincode,
and Phone Number fields for that partner. However, these fields are not set
in the temporary record, which causes the validation to fail.


Solution:
Added a check on `recipient._origin` to ensure that required field validations are only
applied on actual partner records. This prevents raising validation
errors when using temporary partner records in Shiprocket flow.

Added `@mute_logger('odoo.tools.translate')` to suppress translation warnings in
test. In our test case, we are calling `_check_required_value` directly, which
internally calls `_get_lang`. The `_get_lang` method attempts to fetch the
language from `http.request`, but since `http.request` is not available in test
context, it fails to retrieve the language and logs a warning.

https://github.com/odoo/odoo/blob/642dde9546417115cbce5b826cdf996970dfbb48/odoo/tools/translate.py#L514C5-L517C1


opw-4972889

Currently, an IndexError traceback occurs when changing the order state 
in the preparation display if it contains only one stage.

**Steps to reproduce this issue:**
1) Install POS, Kitchen Display
2) Create a preparation display by removing all but
   one stage in the prep settings.
3) Open a restaurant session and create an order.
4) Open the preparation display and mark the created order as DONE. 5) A traceback will occur

**Error:**
```
IndexError: tuple index out of range
```

**Cause:**

When the Done button is clicked in a preparation display with only one stage, 
an ORM call to `change_state_status` is triggered. This then calls 
`_record_status_change_prep_time`, followed by `is_stage_position`.
https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_state.py#L31-L40
https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_stage.py#L21-L22
In `is_stage_position`, static positions [0, -1, -2] are used to access items in the `stage_ids`. 
If only one stage exists, accessing indices -2 results in an IndexError.

**Solution:**

Before accessing a stage by position, check that the length of stage_ids 
is greater than or equal to the absolute value of the position.
This prevents attempts to access out-of-range indices.

opw-4985306

**Steps to reproduce:**
- Install Accounting and l10n_nl
- Switch to a Dutch company (e.g. NL Company)
- In company form, set VAT and Omzetbelastingnummer

- Create an invoice with tax for previous month
- Confirm the invoice

- Go to "Accounting / Reporting / Statement Reports / Tax Return"
- Select previous month
- Create "Closing Entry" and post it

- On "Miscellaneous Operations" journal in Accounting dashboard, click on "Pay tax: [date]" link
- A wizard will appear fot the VAT payment

**Issue:**
The value of the "Communication" field is incorrect.

**Cause:**
The "Communication" field is always computed from the VAT of the company.
However, when the "Omzetbelastingnummer" field is set, it should be used instead of the VAT.

**Solution:**
Use the "Omzetbelastingnummer" field to compute the "Communication" of the VAT payment when it is set.
This is done through an overridden method because "Omzetbelastingnummer" is defined in an independent module.

opw-4836615

Forward-Port-Of: odoo/enterprise#92563
Forward-Port-Of: odoo/enterprise#92407

**Issue:**
When adding contacts with incorrect address data, the Map View could display outdated or incorrect markers

**Cause:**
The `partner_latitude` and `partner_longitude` fields were not reset for child contacts when the parent’s address changed

**Fix:**
We added a `partner_latitude` and `partner_longitude` reset when changing address in write
We added `partner_latitude` and `partner_longitude` in the _address_fields to update the value each time it can be required, like on address change or contact creation
The extension in the _address_fields is there to detect the changes on children synchronization, because it only replace the value that where present in vals for the fields in that list
In that way, it will detect more address changes and trigger the write for the children with the corresponding parent `partner_latitude` and `partner_longitude`
We also make sure that those extra _address_fields will not be displayed in the formatted address by removing them from `_formatting_address_fields`

**Limitations:**
One issue remains during import: the parent-child address synchronization is disabled on contact creation
This means children may be created with addresses different from the parent’s and have mismatch positions on Map
This can be corrected by updating or re-importing the parent to trigger synchronization

**Steps to reproduce:**
With Form:
- Add a parent contact company with a valid address
- Add a child contact related to company, with a valid address
- Open the Map View, both address must appear on Map
- Modify the parent address to remove street (make it invalid)
- Check that the child address match the parent one
- Check the Map View, before the fix the child should remain with a wrong position

With import:
Create an import file (an example is in on the ticket)
- Add a sheet for the Parent contact with an valid address
- Add a sheet to add the Child contact with a parent_Id, with a valid address
- Add a sheet to break the address on the parent, removing the street
- Open the contacts app
- Import the valid Parent and Child sheets (you need to select Related Company / External ID)
- Add a filter to get your created contacts
- Check the Map View (You should see both parent and child)
- Import the Break parent sheet
- Check that the child address match the parent one in the Form
- Check the Map View, before the fix the child should remain with a wrong position

A file can be found on the ticket with pre-made data

**Technical notes:**
The reset logic is duplicated from the `base_geolocalize` module, because this module is optional and may not be installed in all cases
Since `base_geolocalize` is not always present, its `write` override will not be triggered consistently

On the other hand, `web_map` is automatically installed with the Enterprise version of Odoo
Therefore, it is necessary to implement this fix in at least one of the two modules to ensure the behavior is active when Enterprise is used

We chose to keep the override in both `base_geolocalize` and `web_map` to cover both Community and Enterprise cases reliably

An alternative approach would be to move the reset logic directly into `res.partner` in the `base` module, making it always available regardless of installed addons and avoiding the duplication

opw-4842910

Forward-Port-Of: odoo/enterprise#90392

**Step to reproduce:**

1. Install sale_planning module
2. Create a product (Sales -> Products):
    - Set Product Type to Service
    - Enable Plan Services 
    - Assign both a Planning Role and resources.
3. Create a sales order for this product.
4. Confirm the Sales Order.
5. Click the "To Plan" button.
6. Switch to List View.
7. Open the Unscheduled Shifts (None) section.
8. Try to generate an Auto Plan.

**Issue:**

A traceback is raised during auto-planning when the start_datetime or end_datetime on the planning slot is missing.

`AttributeError: 'bool' object has no attribute 'astimezone'`

**Cause:**

The `auto_plan_ids()` method assumes that shifts have valid start_datetime and end_datetime. 
However, for unscheduled shifts, these fields can be empty (i.e., False), causing the error.

https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/planning/models/planning.py#L1076-L1077

**Solution:**
we hide the auto-plan button, in case we do not have startdate or enddate

opw-4812509

co-authored by: Ajit Singh (aksi@odoo.com)

Forward-Port-Of: odoo/enterprise#89383

**Problem:**
An inconsistent behavior occurs when a user changes the commission plan 
while creating an upsell order for a recurring Sales Order (SO).

**Steps to reproduce:**
1) Install the Subscriptions and partner_commission modules. 
2) Create a subscription SO with a referrer_id and set a recurrence. 
3) Enable the Freeze Plan option and create a commission plan from the view 
4) Add a rate of 50 and product category as service in the commission rules. 
5) In SOL add a subscription product contains recurrence with unit price of 100 
6) Confirm the SO → Create Invoice → Confirm → Pay. 
7) Go back to the SO and create an upsell for it.
8) Change the commission plan rate to 30 by creating a new plan. 
9)Repeat step 4.

**Issue:**
When you navigate to the referrer record from the SO and open the Purchase Order 
via the smart button, you will see two Purchase Order lines both showing a value of 50, 
even though the upsell order had a new commission plan with a rate of 30.

**Cause:**
When the invoice is marked as paid, a Purchase Order with POL is created 
using values from the commission plan.

For subscription orders, the system intentionally uses the subscription’s original 
commission plan instead of the updated one.
https://github.com/odoo/enterprise/blob/03a5efc04538fce380ec3ea993e7586047fe117e/partner_commission/models/account_move.py#L197-L203

However, the problem is that the commission plan field remains editable in upsell SOs 
even when the parent SO has Freeze Plan enabled, misleading users into thinking 
the new commission plan will be applied.

**Solution:**
Make the commission plan field read-only for upsell SOs 
when the parent SO has Freeze Plan enabled.

opw-4954307

Forward-Port-Of: odoo/enterprise#92157