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

Fetch-button and matching UX improvements for e-Dispatch (receipts & deliveries), plus a fix to commercial (TICARIFATURA) invoice status handling and its response banner on account.move.

## Current behavior before PR:

- "Upload e-Dispatch (XML)" is only available as a list-view toolbar button.
- There is no single action to fetch e-Dispatch XMLs and then their PDFs.
- "Update From GİB e-Dispatch (XML)" shows even when no XML is linked to the receipt.
- Updating a receipt from its XML does not (re)fetch the matching Nilvera PDF.
- Outgoing deliveries do not fetch the Nilvera PDF on status synchronization.
- Fetched XML attachments are hard to match (no customer name in the name).
- Commercial (TICARIFATURA) invoices that succeed without a recipient answer never reach the "succeed" status, and the commercial response banner (awaiting / approved / rejected) does not display correctly.

## Desired behavior after PR is merged:

- "Upload e-Dispatch (XML)" is moved to the Actions menu on the list view.
- A new "Fetch e-Dispatches" action fetches the XMLs and then the PDFs, in order (receipts and deliveries).
- "Update From GİB e-Dispatch (XML)" is hidden until an e-Dispatch XML is linked.
- Updating a receipt from its XML (re)fetches the matching Nilvera PDF.
- Outgoing deliveries fetch the Nilvera PDF (via the Sale channel) on a successful status sync.
- Fetched XML attachments carry the customer name for easier matching.
- Commercial invoices persist "succeed" while awaiting the recipient's answer, and the awaiting / approved / auto-approved / rejected banners display correctly.

Upgrade PR: https://github.com/odoo/upgrade/pull/10625

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

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

The `Product Reference Price` feature in `website_sale` cannot correctly handle products sold in large packs when the reference quantity requires a very small `base_unit_count`.

For example, a product sold as a `box of 10000` screws should be able to use `0.0001` as its `Base Unit Count`, so the reference price can be computed against the box quantity correctly.

**Current behavior before PR:**

`base_unit_count` uses the default float precision, so values with more than two decimal places are rounded in the product form.

When trying to set `Base Unit Count` to `0.0001`, the value is rounded to `0.00` / `0.01`, which makes the Product Reference Price computation incorrect.

Steps to reproduce:

1. Go to Settings > Website and enable Product Reference Price.
2. Create or open a product named `Screws`.
3. Set Sales Price to `$ 1.00`.
4. On the product form, set Base Unit Count to `0.0001`.
5. In Custom Unit of Measure, type `box of 10000` and press Create.


<img width="1374" height="740" alt="1" src="https://github.com/user-attachments/assets/2d4f7863-b2cd-4c7c-87e1-11526dc50551" />

**Desired behavior after PR is merged:**

`base_unit_count` keeps high-precision values such as `0.0001`.

This allows `Product Reference Price` to correctly support large-pack scenarios, such as selling screws in a `box of 10000`, by storing `base_unit_count` with unlimited numeric precision.


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

Forward-Port-Of: odoo/odoo#270261
Forward-Port-Of: odoo/odoo#262579

[FIX] point_of_sale, pos_viva_com: automatic receipt printing
3 Fixes for the app-to-app integration of Viva

1. Under the normal flow the `OrderPaymentValidation` does the payment
   validation and post validation operations (such as receipt printing or
   preparation prints). Then it launches the `FeedbackScreen` with the
   validation promise on the `waitFor` prop.

   The `pos_viva_com` app-2-app integration does the payment validation on
   the backend on the callback endpoint. Then it redirects the user
   directly on the `FeedbackScreen` skipping the normal validation and post
   validation operations. This means that receipts and preparation prints
   do not get processed.

   This PR adds a check on the `FeedbackScreen` to see whether there is
   anything set on the `waitFor` prop. If the prop is undefined, we can
   expect that the screen was mounted outside the normal flow, so we run
   the post validation operations manually.

---

2. Using the fast payment method with Viva would use
   `order.addPaymentLine` instead of the overloaded
   `payment_screen.addNewPaymentLine`. So the integration pop up which
   is defined in the `payment_screen` would never fire.

   Now I've added a check on `validateOrder` to detect whether we're about
   to use a `fastPaymentMethod`, in which case it will apply the same
   behaviour as the override of the `payment_screen.addNewPaymentLine`

---

3. Added a patch for `reloadData` which will remove the answer for the
   Viva wallet pop up from local storage in case users change their minds
   or made a mistake

Task-[6251297](https://www.odoo.com/odoo/project/1737/tasks/6251297)

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

Forward-Port-Of: odoo/odoo#267714

The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24)
override builds link.tracker short URLs from
`website.get_current_website()` and the current company's website
domain. It was introduced by
https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a
for a multi-company backend flow (users switching companies to post
social marketing links), but it runs for every compute, including
CRON contexts with no HTTP request such as the mass-mailing queue.

Without a request, `get_current_website()` picks an arbitrary website
(the first in the database) and `self.env.company` resolves to the
user's main company, so the short URL uses that company's website
domain instead of `web.base.url`.

Fall back to `super()._compute_short_url_host()` (which uses
`web.base.url`) when no website is resolvable from the request,
session, or context. Backend flows with a real request still hit the
company-aware branch.

Steps to reproduce:
1. Install Email Marketing and Website.
2. Settings > Companies: create a second company B. Settings >
   Websites: ensure website A points to company A with domain A, and
   create website B for company B with domain B.
3. Settings > Technical > Parameters > System Parameters: set
   `web.base.url` to a third domain C, and add `web.base.url.freeze`
   = `True`.
4. On company A, Email Marketing: create a mailing with body
   `<a href="http://example.com">test</a>` and a recipient list,
   then click Send.
5. Settings > Technical > Automation > Scheduled Actions > "Mass
   Mailing: Process queue" > Run Manually.
6. Email Marketing > Configuration > Link Tracker: open the tracker
   generated for the mailing.

=> The Tracked URL uses domain A.
=> The Tracked URL uses domain C.

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

Forward-Port-Of: odoo/odoo#259200

The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities.  `_run_fifo_get_stack()` doesn't include the child companies in the `moves_domain`, so it is unable to create a FIFO stack for moves from a child. This leaves extra quantity unaccounted for, which defaults to the standard_price.

**Video of the bug:**
https://drive.google.com/file/d/11PIfNAIb_Yyo4A-3R0CRF0NV6_HE6EwF/view

**Issue:**
When multiple companies are selected, the displayed quantity on hand for a product is calculated as the sum of all selected companies. However, the moves domain only looks at the main selected company instead of all selected companies, leading to an incorrectly calculated standard price when using FIFO. This is more apparent on lot-valuated products because the lot standard price is recalculated every time the field is accessed.

**Reproduction steps:**
- Have a main company
- Create a branch company
- Create a product, configure it as FIFO on both the main company and branch company 
- Let the product be tracked by lots and set to `Valuation by Lot` (for demonstrative purposes)
- On the main company, set the product cost to $15 (for demonstrative purposes)
- Go to only the branch company, make a purchase for one unit of the FIFO product at $100 (make a warehouse for delivery) , validate the receipt
- Go to the lot -> When logged in to only the branch company, quantity is 1 and cost is $100 (correct). When logged in to both the main and branch company and viewing from the main company, quantity is 1 and cost is $15 (incorrect)

**Fix:** 
Allow `_run_fifo_get_stack()` to see the moves from all companies in the environment instead of just the main company

Related ticket: opw-6064126

Forward-Port-Of: odoo/odoo#270695
Forward-Port-Of: odoo/odoo#258199

Steps to reproduce:
- Install Attendance + Timesheets
- Disable "Attendances from Backend"
- Timesheet icon disappears from toolbar
 
Current behavior:
Bridge module permanently removes the `timesheet systray` from
the `registry` and merges it inside the attendance dropdown.
When `attendance_from_systray` is off, the dropdown hides itself
and takes the timesheet icon with it, leaving no way to log
hours from the toolbar.
 
Expected behavior:
Timesheet icon should remain accessible when attendance from
systray is disabled.
 
Issue:
`registry.remove()` at module load made the timesheet icon
impossible to restore.
 
Fix:
Keep the timesheet systray registered. Patch TimesheetSystray
to read `display_systray from lazy_session` on startup and show
itself standalone when attendance from systray is off.
 
The template no longer replaces nodes. Header and total_hours
are toggled via `position="attributes"` (`t-if="!props.signInOut"`,
a prop only passed by the attendance dropdown), and a
self-contained dropdown-only footer with the Check out button
is added after total_hours.

Ref: odoo/enterprise#104347
task-6285068

Forward-Port-Of: odoo/enterprise#121551
Forward-Port-Of: odoo/enterprise#119840

## Summary

Minimal alternative: make the "Inventory at Date" wizard open the same rich stock report view instead of the basic one.

### Problem
The wizard opens `stock.view_stock_product_tree` (basic product list) instead of `stock.product_product_stock_tree` (full stock report with action buttons and search panel).

### Solution
Change the wizard's `open_at_date()` to use the stock report view and its associated search view. The wizard flow is preserved — this is purely a view swap.

### Changes
- `stock_quantity_history.py`: Changed `tree_view_id` from `view_stock_product_tree` to `product_product_stock_tree`, added `search_view_id` for the stock report search view

### Alternative
See #263507 for a more integrated approach that replaces the wizard entirely with a date picker in the search panel.

[Task #6152466](https://www.odoo.com/odoo/rd-fun-logistics-966/6152466)

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

Forward-Port-Of: odoo/odoo#263509

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

The stock move value was inline-editable in the moves list, which is
misleading. Editing it directly behaves inconsistently across cost
methods: for FIFO products the edit updates the remaining value, but
for AVCO products there is no mechanism to propagate it, so the change
has no effect. The direct edit also bypasses the audited revaluation
channel, the Adjust Valuation wizard (product.value), which records the
user, date and justification.

Disable direct modification by marking the field read-only by default,
so manual revaluation always goes through Adjust Valuation. Internal
valuation writes are unaffected.

### Current behavior before PR:

The value field is editable in the stock move list view.

<img width="1890" height="460" alt="image" src="https://github.com/user-attachments/assets/8ddc6495-4beb-4481-bdbf-2a44b70f3784" />

### Desired behavior after PR is merged:

The value field should not be editable. Users should use the Adjust Valuation wizard to ensure the operation is auditable.

@qrtl QT6826

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

Forward-Port-Of: odoo/odoo#267360

Description of the issue/feature this PR addresses:

This error occurs when a model has properties and a `computed` field or `onchange` method depends on them.

`record.update()` is asynchronous. When an onchange or computed field is triggered, an additional request is sent to the server, increasing the time required to complete the update. See:

https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/model/relational_model/record.js#L1207-L1211

However, `PropertiesField` is rendered before the `update` is completed. See:

https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/views/fields/properties/properties_field.js#L86

As a result, the property labels are not yet available and the following traceback is raised:

`TypeError: Cannot read properties of undefined (reading 'getRootNode')
`
After this commit, the update is awaited before rendering PropertiesField, ensuring that the property labels are available.

**Steps to reproduce:**

1. Install the example module. [project_task_property.zip](https://github.com/user-attachments/files/29138424/project_task_property.zip)
2. Open or create a project task.
3. From the Action menu, click `Add Properties`.

The error is raised.

<img width="1520" height="956" alt="image" src="https://github.com/user-attachments/assets/a3051ddf-5af0-4d3a-8ff7-c3fb4f7a69d2" />


TT63331
@Tecnativa @pedrobaeza

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

Forward-Port-Of: odoo/odoo#272653
Forward-Port-Of: odoo/odoo#271082

Issue:
----------------------------------------
Doing a search on skills, the employees with the skill but no slot in the time frame aren't shown.

Steps to reproduce:
----------------------------------------
- Install `planning_hr_skills`
- Make sure an employee has the skill "English" and no slots
- Open Planning and type "English" in the search bar, click to search on Skills
- The employee does not show up

Cause:
----------------------------------------
Using the search view on skills, a filter on `resource_ids` is in the domain with a `OR`:

https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/views/planning_slot_views.xml#L9

Then a new filter on `resource_ids` is added [here](https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/models/planning_slot.py#L14-L43) to do the search on the skill names: `[('resource_ids', 'in', matching_resource_ids)]`.

The domain is then something like this: 
`['&', ('resource_ids', 'in', matching_resource_ids), '|', ('resource_ids', '=', False), ('employee_skill_ids', 'ilike', 'English')]`.

Since fbf8b2ac67c71ca0abfc75df543069696bd2d29b the resulting domain passes through `filter_map_domain()`. `filter_map_domain()` will only keep the leaves on `resource_ids` and the default `AND` will be used between them resulting in: 
`['&', ('resource_ids', 'in', matching_resource_ids), ('resource_ids', '=', False)]` 
which fetches no resources.

So `_group_expand_resource_ids()` doesn't expand.

Solution:
----------------------------------------
Instead of adding the new leaf to retrieve the resources with the right skills, we replace the leaf on `employee_skill_ids`. This ensures the `OR` operations are kept by `filter_map_domain()`.

opw-6296755

Forward-Port-Of: odoo/enterprise#120669

Issue:
----------------------------------------
The Planning / Timesheets Analysis report doesn't include most of the planning slots if they have a calendar based on duration.

Steps to reproduce:
----------------------------------------
- Have a 1 day planning slot (8h-17h) for an employee with a calendar based on duration.
- Planning > Reporting > Planning / Timesheets Analysis
- The slot is not included in the report

Cause:
----------------------------------------
The update of how calendars work in saas-19.2 included the `duration_based` option but the query was not adapted. It still checks if the slot start time is lower than the calendar end time on that day:

```sql
F.start_datetime < (d.date::date + (A.hour_to || ' hour')::interval)
AND F.end_datetime > (d.date::date + (A.hour_from || ' hour')::interval)
```

But for duration-based calendars `hour_from` and `hour_to` are stored as `0.0`. So `F.start_datetime < (d.date::date + (A.hour_to || ' hour')::interval)` evaluates to False.

Solution:
----------------------------------------
If the calendar has `duration_based` to True we only check the date.

opw-6217643

Forward-Port-Of: odoo/enterprise#118133

[FIX] point_of_sale, pos_viva_com: automatic receipt printing
3 Fixes for the app-to-app integration of Viva

1. Under the normal flow the `OrderPaymentValidation` does the payment
   validation and post validation operations (such as receipt printing or
   preparation prints). Then it launches the `FeedbackScreen` with the
   validation promise on the `waitFor` prop.

   The `pos_viva_com` app-2-app integration does the payment validation on
   the backend on the callback endpoint. Then it redirects the user
   directly on the `FeedbackScreen` skipping the normal validation and post
   validation operations. This means that receipts and preparation prints
   do not get processed.

   This PR adds a check on the `FeedbackScreen` to see whether there is
   anything set on the `waitFor` prop. If the prop is undefined, we can
   expect that the screen was mounted outside the normal flow, so we run
   the post validation operations manually.

---

2. Using the fast payment method with Viva would use
   `order.addPaymentLine` instead of the overloaded
   `payment_screen.addNewPaymentLine`. So the integration pop up which
   is defined in the `payment_screen` would never fire.

   Now I've added a check on `validateOrder` to detect whether we're about
   to use a `fastPaymentMethod`, in which case it will apply the same
   behaviour as the override of the `payment_screen.addNewPaymentLine`

---

3. Added a patch for `reloadData` which will remove the answer for the
   Viva wallet pop up from local storage in case users change their minds
   or made a mistake

Task-[6251297](https://www.odoo.com/odoo/project/1737/tasks/6251297)

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

Forward-Port-Of: odoo/odoo#267714

### Steps to reproduce:
- Download Calendar and Contacts app
- Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies
- Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies
- Create a another user who also have access to both companies
- Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field
- Switch the company of the logged in user to the other company
- Open the test contact form, use the meeting smart button and create a new meeting
- Open the kanban contact view

 **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.**
### Cause of Issue:
When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user.

### Fix:
Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope.
Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance.

opw-5874204

Forward-Port-Of: odoo/odoo#272832
Forward-Port-Of: odoo/odoo#248985

**Steps to reproduce**
- Use a french company with `l10n_fr_hr_holidays` installed
- Change the duration type of the time off type set as the "Company Paid Time Off Type" in the French Time Off Localization settings to "Half-Day"
- Company Working Schedule:
	- Attendance on a day from 10 to 19, Day Period: Full Day
- Part-time employee Working Schedule:
	- Attendance on the same day from 11 to 12, Day Period: Morning
	- Attendance on the same day from 13 to 19, Day Period: Afternoon
- Create a full day time off for the part time employee on that day, using the time off type set as the "Company Paid Time Off Type" (start am, end pm)

-> Excepted: time off duration is 1 day
-> Actual: time off duration is 0.89 day

**Change**
Now that `request_unit_half` of a leave is a simple related to the `request_unit` of the leave type, it becomes important to not rely on a call to `_get_durations` using the company's calendar to compute the leave's duration, as it may not be fully accurate when the company's working hours and employee's working hours are not aligned.
Continuation of 05e71eb206eb02a8d15708e6fb532a732a767d6d

`_get_fr_date_from_to` is also adapted to take into account multi-day leaves ending in the morning while the employee works in the afternoon (in which case it should not be extended in case the employee doesn't work the next day).

opw-6000011

Forward-Port-Of: odoo/odoo#270863
Forward-Port-Of: odoo/odoo#253059

Issue:
----------------------------------------
When changing multiple times the hours of a slot to include out-of-schedule time.

Steps to reproduce:
----------------------------------------
- Have planning_field_service installed
- Have an employee with a schedule from 7am to 3pm
- In planning view, create a new slot for this employee from 7am to 3pm (8h)
- Change the starting hour to 6am (8h + 1h of break time)
- Change it back to 7am
- The slot shows 7h07 of allocated hours and 53 minutes of break time

Cause:
----------------------------------------
Since 8ca9faabfdf7d15883ba52da47bd8c562cf601de the compute of `allocated_percentage` is overriden in `planning_field_service`. The new compute uses `break_time` to recompute `allocated_percentage`. `break_time` is the not work time over the whole duration of the slot, including hours out of schedule.

But the definition of `allocated_percentage` in `planning` is: the percentage of slot hours in schedule which are actually worked. So when changing the start to 6am `allocated_percentage` is still supposed ot be 100% because the employee is working 100% of the hours he is supposed to work considering its schedule.

With the actual code `allocated_percentage` is actually computed as 8/9 = 0.88888... because it will take into account the hours out of schedule.

As `allocated_percentage` is not recomputed if `allocated_hours` or `break_time` aren't modified by the user. It is then used [here](https://github.com/odoo/enterprise/blob/ae5008bdaf1b87269083f82280c7df44390129ff/planning/models/planning_slot.py#L2865-L2867) to compute the allocated_hours and the number of hours in schedule is divided base onthe percentage.

Solution:
----------------------------------------
We only consider the hours in schedule to recompute `allocated_percentage`.

`allocated_percentage` was used in `_onchange_break_time()` to get the previous ratio and calculate the allocated hours from which we deduct the break time. We cannot do this now so we also need to compute the working hours.

-----------------------------------------

# [FIX] planning_field_service: handle input of negative break_time

Issue:
----------------------------------------
When inputting negative break_time for a slot, it's possible to get a traceback.

Steps to reproduce:
----------------------------------------
- Have planning_field_service installed
- Have an employee with a schedule from 7am to 3pm
- In planning view, create a new slot for this employee from 7am to 3pm (8h)
- Input 9h of break time
- Input -1h of break time
- Traceback

Cause:
----------------------------------------
When `slot.allocated_hours` is 0 and we input a negative value in `break_time`, the code in `_onchange_break_time()` will give `allocated_hours` the positive value of `break_time` making them opposite.

Then in [`_compute_allocated_percentage()`](https://github.com/odoo/enterprise/blob/188dcc5078be7c7fee1a52f86505144d3b6309cf/planning_field_service/models/planning_slot.py#L98) we divide by their sum, which equals 0.

Solution:
----------------------------------------
We compute the divider part and check if it's zero in `_compute_allocated_percentage()`.

Also add a `max()` in `_onchange_break_time()` to convert the negative break time in allocated hours and resets `break_time` to zero.
This ensures the same behavior as inputting negative values in `allocated_hours`.

opw-6273559

Forward-Port-Of: odoo/enterprise#121168

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/446def9ad1 [REL] 19.3.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9af0bc5b97 [FIX] package: 19.3 is no longer the latest version [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9a69c22cd2 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/ae520eaad2 [FIX] sheet: add sheet tab color to custom colors [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/54af665a85 [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646)
https://github.com/odoo/o-spreadsheet/commit/babbc57eee [FIX] chart: zoomable chart height issue with rjsmin minification [Task: 6306092](https://www.odoo.com/odoo/2328/tasks/6306092)
https://github.com/odoo/o-spreadsheet/commit/4fd1a3439e [FIX] package-lock: revert changes [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4dc969c14e [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690)
https://github.com/odoo/o-spreadsheet/commit/be5939bcfb [FIX] Find and replace : selection after an UPDATE_CELL [Task: 4818132](https://www.odoo.com/odoo/2328/tasks/4818132)

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>

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

The stock move value was inline-editable in the moves list, which is
misleading. Editing it directly behaves inconsistently across cost
methods: for FIFO products the edit updates the remaining value, but
for AVCO products there is no mechanism to propagate it, so the change
has no effect. The direct edit also bypasses the audited revaluation
channel, the Adjust Valuation wizard (product.value), which records the
user, date and justification.

Disable direct modification by marking the field read-only by default,
so manual revaluation always goes through Adjust Valuation. Internal
valuation writes are unaffected.

### Current behavior before PR:

The value field is editable in the stock move list view.

<img width="1890" height="460" alt="image" src="https://github.com/user-attachments/assets/8ddc6495-4beb-4481-bdbf-2a44b70f3784" />

### Desired behavior after PR is merged:

The value field should not be editable. Users should use the Adjust Valuation wizard to ensure the operation is auditable.

@qrtl QT6826

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

Forward-Port-Of: odoo/odoo#267360

Issue:
----------------------------------------
When changing multiple times the hours of a slot to include out-of-schedule time.

Steps to reproduce:
----------------------------------------
- Have planning_field_service installed
- Have an employee with a schedule from 7am to 3pm
- In planning view, create a new slot for this employee from 7am to 3pm (8h)
- Change the starting hour to 6am (8h + 1h of break time)
- Change it back to 7am
- The slot shows 7h07 of allocated hours and 53 minutes of break time

Cause:
----------------------------------------
Since 8ca9faabfdf7d15883ba52da47bd8c562cf601de the compute of `allocated_percentage` is overriden in `planning_field_service`. The new compute uses `break_time` to recompute `allocated_percentage`. `break_time` is the not work time over the whole duration of the slot, including hours out of schedule.

But the definition of `allocated_percentage` in `planning` is: the percentage of slot hours in schedule which are actually worked. So when changing the start to 6am `allocated_percentage` is still supposed ot be 100% because the employee is working 100% of the hours he is supposed to work considering its schedule.

With the actual code `allocated_percentage` is actually computed as 8/9 = 0.88888... because it will take into account the hours out of schedule.

As `allocated_percentage` is not recomputed if `allocated_hours` or `break_time` aren't modified by the user. It is then used [here](https://github.com/odoo/enterprise/blob/ae5008bdaf1b87269083f82280c7df44390129ff/planning/models/planning_slot.py#L2865-L2867) to compute the allocated_hours and the number of hours in schedule is divided base onthe percentage.

Solution:
----------------------------------------
We only consider the hours in schedule to recompute `allocated_percentage`.

`allocated_percentage` was used in `_onchange_break_time()` to get the previous ratio and calculate the allocated hours from which we deduct the break time. We cannot do this now so we also need to compute the working hours.

-----------------------------------------

# [FIX] planning_field_service: handle input of negative break_time

Issue:
----------------------------------------
When inputting negative break_time for a slot, it's possible to get a traceback.

Steps to reproduce:
----------------------------------------
- Have planning_field_service installed
- Have an employee with a schedule from 7am to 3pm
- In planning view, create a new slot for this employee from 7am to 3pm (8h)
- Input 9h of break time
- Input -1h of break time
- Traceback

Cause:
----------------------------------------
When `slot.allocated_hours` is 0 and we input a negative value in `break_time`, the code in `_onchange_break_time()` will give `allocated_hours` the positive value of `break_time` making them opposite.

Then in [`_compute_allocated_percentage()`](https://github.com/odoo/enterprise/blob/188dcc5078be7c7fee1a52f86505144d3b6309cf/planning_field_service/models/planning_slot.py#L98) we divide by their sum, which equals 0.

Solution:
----------------------------------------
We compute the divider part and check if it's zero in `_compute_allocated_percentage()`.

Also add a `max()` in `_onchange_break_time()` to convert the negative break time in allocated hours and resets `break_time` to zero.
This ensures the same behavior as inputting negative values in `allocated_hours`.

opw-6273559

### Steps to reproduce:
- Download Calendar and Contacts app
- Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies
- Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies
- Create a another user who also have access to both companies
- Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field
- Switch the company of the logged in user to the other company
- Open the test contact form, use the meeting smart button and create a new meeting
- Open the kanban contact view

 **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.**
### Cause of Issue:
When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user.

### Fix:
Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope.
Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance.

opw-5874204

Forward-Port-Of: odoo/odoo#272832
Forward-Port-Of: odoo/odoo#248985

## Summary

Minimal alternative: make the "Inventory at Date" wizard open the same rich stock report view instead of the basic one.

### Problem
The wizard opens `stock.view_stock_product_tree` (basic product list) instead of `stock.product_product_stock_tree` (full stock report with action buttons and search panel).

### Solution
Change the wizard's `open_at_date()` to use the stock report view and its associated search view. The wizard flow is preserved — this is purely a view swap.

### Changes
- `stock_quantity_history.py`: Changed `tree_view_id` from `view_stock_product_tree` to `product_product_stock_tree`, added `search_view_id` for the stock report search view

### Alternative
See #263507 for a more integrated approach that replaces the wizard entirely with a date picker in the search panel.

[Task #6152466](https://www.odoo.com/odoo/rd-fun-logistics-966/6152466)

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

Forward-Port-Of: odoo/odoo#263509

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

The stock move value was inline-editable in the moves list, which is
misleading. Editing it directly behaves inconsistently across cost
methods: for FIFO products the edit updates the remaining value, but
for AVCO products there is no mechanism to propagate it, so the change
has no effect. The direct edit also bypasses the audited revaluation
channel, the Adjust Valuation wizard (product.value), which records the
user, date and justification.

Disable direct modification by marking the field read-only by default,
so manual revaluation always goes through Adjust Valuation. Internal
valuation writes are unaffected.

### Current behavior before PR:

The value field is editable in the stock move list view.

<img width="1890" height="460" alt="image" src="https://github.com/user-attachments/assets/8ddc6495-4beb-4481-bdbf-2a44b70f3784" />

### Desired behavior after PR is merged:

The value field should not be editable. Users should use the Adjust Valuation wizard to ensure the operation is auditable.

@qrtl QT6826

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

Forward-Port-Of: odoo/odoo#267360

### Steps to reproduce:

- Create a storable product P tracked by SN, fifo perpetual lot valuated using the MTO route and with a BOM: 1 x COMP
- Create, confirm and validate an MO for 10 unit of P using COMP's at 10$ (by setting its standard price).
- Create and confirm a Sales Order for 1 unit of P
> This generate an MO
- Validate this MO for a new serial say SN011 using a COMP at 20$.
- Validate the Delivery Order using SN011
- Create and post the customer invoice
#### > The invoice COGS uses Std Price rather than the 20$ lot's fifo value

### Cause of the issue:

The cogs value are generated based on the moves returned by the `_get_stock_moves` call of the acount.move.line:
https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/account_move_line.py#L66-L68 Currently, if an account.move.line is linked to a sale.order.line, this methods returns the entire pull of stock moves linked to the sol: https://github.com/odoo/odoo/blob/79c9e7de6764e7f8e47709b827df6eee81e72637/addons/sale_stock/models/account_move.py#L155-L156 However, these moves include both, the delivery move and the `move_finished_ids` of the MTO prodcution. This is problematic since the delivery move is considered as positive cogs qty and the MO is considered as incoming cogs qty leading to a sum of 0 cogs qty which in turns make the cogs price unit fall back to the product standard price instead of the fifo cost of the produced lot.: https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/stock_move.py#L257-L271

opw-6292048


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

Forward-Port-Of: odoo/odoo#271018

Currently, accounts with the `Other Expenses` account type cannot 
be selected in financial budget lines.

**Steps to reproduce:**
- Install the `accountant` module.
- Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`.
- Go to Accounting > Configuration > Financial Budgets.
- Create a new budget and add a budget line.
- Try to select the newly created account.

**Observation:**
Accounts with the `Other Expenses` type are not
available for selection in budget lines.

**Root Cause:**
At [1], the `expense_other` account type is missing from the `account_id` domain.

**Expected Behavior:**
Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting.

**Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709

**Fix:**
This commit ensures that users can add `Other Expenses` accounts to budget lines.

[1]:
https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120

opw-6313835

Forward-Port-Of: odoo/enterprise#121735

**Steps to Reproduce:**
-  Create a Server Action of type 'Webhook Notification'.
- Select a model containing a field that returns a `frozendict`-based structure (e.g. `account.move` → `needed_terms`).
- Add the field to the webhook fields.
- Open the webhook sample payload preview.

**Issue:**
- During sample payload generation:
   - The selected fields are read from a sample record.
   - A selected field returns a structure containing `frozendict` objects.
   - The payload is serialized using `json.dumps()`.
   - JSON serialization fails with:
```text
TypeError: keys must be str, int, float, bool or None, not frozendict
```
  - The webhook sample payload computation crashes and the preview cannot be displayed.

**Root Cause:**
- The webhook sample payload may contain `frozendict` objects returned by selected fields.
- The serializer used for payload generation does not handle such mapping-like objects, causing  `json.dumps()` to fail.

**Solution:**
- Use a serializer that converts mapping-like objects into JSON-compatible structures before serializing the webhook sample payload.

**OPW-6295777**

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#271864

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089




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

Forward-Port-Of: odoo/odoo#272596
Forward-Port-Of: odoo/odoo#269510

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089

Forward-Port-Of: odoo/enterprise#121988
Forward-Port-Of: odoo/enterprise#120210

Steps to reproduce
------------------
1. Install l10n_ke_edi_oscu_pos.
2. Select the Kenyan company.
3. Enable eTIMS on the PoS.
4. Register the products inside a combo, but not the combo itself.
5. Sell the combo in the PoS.

Observation
-----------
We see a warning that the combo must be registered to eTIMS, and the order can't be validated.

What's happening
----------------
In the PoS a combo adds a 0 price parent line for the combo product, but the combo is not a real item to send to eTIMS, only the products inside it are, and (as per step 4) the combo is not registered.

`checkEtimsFields` sees the combo as not registered, so it raises the warning in `showUnregisteredProductsWarning` and blocks the payment in `validateOrder`.

Fix
---
In the backend, we skip sending the parent combo line to eTIMS, and on the frontend, we make the combo parent line not need eTIMS registration, so the warning and the block don't apply to it.

opw-6253306

Forward-Port-Of: odoo/enterprise#121991
Forward-Port-Of: odoo/enterprise#119362

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d6cb26450f [REL] 19.1.25 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c82e76cc60 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/bd4f6fb56a [FIX] sheet: add sheet tab color to custom colors [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171)
https://github.com/odoo/o-spreadsheet/commit/357cb2273b [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646)
https://github.com/odoo/o-spreadsheet/commit/9cb37b2cd5 [FIX] chart: zoomable chart height issue with rjsmin minification [Task: 6306092](https://www.odoo.com/odoo/2328/tasks/6306092)
https://github.com/odoo/o-spreadsheet/commit/65527a70a3 [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690)

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>

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089

Forward-Port-Of: odoo/enterprise#121988
Forward-Port-Of: odoo/enterprise#120210

Currently, accounts with the `Other Expenses` account type cannot 
be selected in financial budget lines.

**Steps to reproduce:**
- Install the `accountant` module.
- Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`.
- Go to Accounting > Configuration > Financial Budgets.
- Create a new budget and add a budget line.
- Try to select the newly created account.

**Observation:**
Accounts with the `Other Expenses` type are not
available for selection in budget lines.

**Root Cause:**
At [1], the `expense_other` account type is missing from the `account_id` domain.

**Expected Behavior:**
Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting.

**Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709

**Fix:**
This commit ensures that users can add `Other Expenses` accounts to budget lines.

[1]:
https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120

opw-6313835

Forward-Port-Of: odoo/enterprise#121735

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#272874
Forward-Port-Of: odoo/odoo#269456

The full composer builds default_partner_ids by doing recipient.persona.id over allRecipients. When a recipient is not linked to a partner, the chatter input inserts it with persona: false here:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/static/src/core/web/recipients_input.js#L151

false.id is undefined, so the wizard gets a bad id and clicking the recipient tag crashes with `Invalid ids list: false`.

The persona is false because /mail/partner/from_email returns no partner for unresolved emails when the user does not have base.group_partner_manager. That matches the gate _prepare_post_data already uses for the simple post flow:

https://github.com/odoo/odoo/blob/28c11a068b2ecf521f8ba1da271ebee24f5345ae/addons/mail/controllers/thread.py#L153,L155

The full composer just was not handling that case.

Filter out persona-less recipients from default_partner_ids so the wizard only sees real partner ids. The full composer now drops them the same way the simple post path already does.

Steps to reproduce:
1. As Administrator, create a user with the Sales group only (no Contact Creation).
2. Log in as that user.
3. Open a CRM lead whose Email is set but Customer is empty.
4. Click Send message.
5. Click the expand icon to open the full composer.
6. Click the recipient tag in the To field.

=> Recipient shows as Unnamed and clicking it raises an RPC error.

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


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

Forward-Port-Of: odoo/odoo#251780

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#121493
Forward-Port-Of: odoo/enterprise#117879

Issue:
----------------------------------------
Doing a search on skills, the employees with the skill but no slot in the time frame aren't shown.

Steps to reproduce:
----------------------------------------
- Install `planning_hr_skills`
- Make sure an employee has the skill "English" and no slots
- Open Planning and type "English" in the search bar, click to search on Skills
- The employee does not show up

Cause:
----------------------------------------
Using the search view on skills, a filter on `resource_ids` is in the domain with a `OR`:

https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/views/planning_slot_views.xml#L9

Then a new filter on `resource_ids` is added [here](https://github.com/odoo/enterprise/blob/5d6d16aae43ffda1532cfa4b06fdcddd7e5b0fcc/planning_hr_skills/models/planning_slot.py#L14-L43) to do the search on the skill names: `[('resource_ids', 'in', matching_resource_ids)]`.

The domain is then something like this: 
`['&', ('resource_ids', 'in', matching_resource_ids), '|', ('resource_ids', '=', False), ('employee_skill_ids', 'ilike', 'English')]`.

Since fbf8b2ac67c71ca0abfc75df543069696bd2d29b the resulting domain passes through `filter_map_domain()`. `filter_map_domain()` will only keep the leaves on `resource_ids` and the default `AND` will be used between them resulting in: 
`['&', ('resource_ids', 'in', matching_resource_ids), ('resource_ids', '=', False)]` 
which fetches no resources.

So `_group_expand_resource_ids()` doesn't expand.

Solution:
----------------------------------------
Instead of adding the new leaf to retrieve the resources with the right skills, we replace the leaf on `employee_skill_ids`. This ensures the `OR` operations are kept by `filter_map_domain()`.

opw-6296755

Forward-Port-Of: odoo/enterprise#120669

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#121837
Forward-Port-Of: odoo/enterprise#120967

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

### Issue:
In 19.0, bank reconciliation stopped automatically matching statement lines against moves when the payment reference contains leading/trailing `+` or `*` characters

For example, a statement line with communication `000/0000/00123` would not auto-match an invoice with `payment_reference` `+++000/0000/00123+++`

This affects Belgian structured references, where QR codes are generated without the surrounding `+++`

### Cause:
The reconciliation SQL builds a list of words from `aml.ref` and `move.payment_reference` and compares them against the statement line's `payment_ref` using ILIKE

Before the fix, `+++000/0000/00123+++` was used as-is, so it never matched `000/0000/00123`

The regex delimiter pattern in the Python match also did not account for `+` and `*` as valid word boundaries

### Steps to reproduce:
- Install `account_accountant` and `l10n_be`
- Switch to the BE company
- Create and confirm at least 2 invoices for the same partner with the same total (to avoid single-match shortcuts)
- Note the Payment Reference of the first invoice (e.g. +++000/0000/00123+++)
- In Bank Reconciliation, create a statement line for that partner and total, using the reference without the `+++` (e.g. 000/0000/00123)
Before the fix, no automatic match was suggested

opw-6095533

Currently, accounts with the `Other Expenses` account type cannot 
be selected in financial budget lines.

**Steps to reproduce:**
- Install the `accountant` module.
- Go to `Chart of Accounts` and create a new account with `Type: Other Expenses`.
- Go to Accounting > Configuration > Financial Budgets.
- Create a new budget and add a budget line.
- Try to select the newly created account.

**Observation:**
Accounts with the `Other Expenses` type are not
available for selection in budget lines.

**Root Cause:**
At [1], the `expense_other` account type is missing from the `account_id` domain.

**Expected Behavior:**
Financial budgets should allow all Profit & Loss accounts, since the feature relies on P&L reporting.

**Reference**: https://www.odoo.com/odoo/project/49/tasks/4314709

**Fix:**
This commit ensures that users can add `Other Expenses` accounts to budget lines.

[1]:
https://github.com/odoo/enterprise/blob/41b66ba081f3938f7e55da209506c637850ae4ec/account_reports/models/budget.py#L114-L120

opw-6313835

Forward-Port-Of: odoo/enterprise#121735

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089

Forward-Port-Of: odoo/enterprise#121988
Forward-Port-Of: odoo/enterprise#120210

# 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

Description of the issue/feature this PR addresses:
The rating module does not correctly extend the mail modules onClick for NotificationItem

Current behavior before PR:
* mail NotificationItem onClick calls `this.onClickThread(isMarkAsRead, thread, message)`
* rating NotificationItem onClick calls `this.onClickThread(isMarkAsRead, thread)`
  * causing the [if in onClickThread](https://github.com/odoo/odoo/blob/18.0/addons/mail/static/src/core/public_web/messaging_menu.js#L39C17-L39C24) to be missed and falling backup to opening the thread
     ```javascript
            if (message?.needaction && message.message_type === "user_notification") {
                this.store.inbox.highlightMessage = message;
                this.openDiscussion(this.store.inbox);
                return;
            }
            this.openDiscussion(thread);
            return;
     ```

Desired behavior after PR is merged:
* rating should not change the fallback behaviour for messages without a rating_id and still allow opening the user_notification in inbox instead of switching to the thread

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

Info @wt-io-it

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

**Step To reproduce :**

1. Create a survey with `Scoring` set to `Scoring with answers after each page`
2. Add at least 2 pages, each with 1+ scorable question
3. As a public user, open the survey and start answering
4. Fill in the first page and click Continue
5. Correct answers are displayed with green/red highlights, submit button is replaced by Next
6. Click Next
7. Redirected to the homepage instead of the second page

**Issue:**

When survey scoring type is 'scoring_with_answers_after_page', after submitting a page the correct answers are displayed along with a "Next" button. Clicking "Next" redirects the user to the homepage because the answer_token is lost.

**Reason:**

The `<button id="next_page">` has no explicit `type` attribute, so it defaults to `type="submit"` per HTML spec. When clicked, the browser's default form submission fires a POST to `/survey/<survey_token>` (the answer_token is never in the URL path — only in the cookie). On the last page, `_nextScreen()` deletes the survey cookie to clean up after completion. The concurrent form POST then  arrives at the server with answer_token=None → `token_required` → `redirect("/")`.

Additionally, jQuery's event delegation matches `button[type="submit"]` against the `type` property (which is `"submit"` by default for bare `<button>` elements), triggering `_onSubmit` which makes a second stale RPC call, compounding the issue.

**Solution:**

Added `event.preventDefault()` in the Next button's click handler within `_showCorrectAnswers` to stop the browser's default form submission behavior at the event level. This prevents the unintended POST request regardless of the button's type attribute, ensuring only the JS-driven `_nextScreen` transition executes.

opw-6268296

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/e2afa94946 [REL] 17.0.101 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1ec83de135 [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646)
https://github.com/odoo/o-spreadsheet/commit/1dd2dad5e6 [IMP] package: add runbot script [Task: 6316690](https://www.odoo.com/odoo/2328/tasks/6316690)
https://github.com/odoo/o-spreadsheet/commit/e37d05ac2d [FIX] rolldown: Fix cjs file extension [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/44d7f637bb [FIX] package-lock: update with removing node_modules [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/fa9c81c197 [FIX] package.json: Update Node.js and npm engine requirements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

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>