Steps to reproduce:
- Create one user linked to two companies.
- Create one employee per company for that user.
- Select one company and approve a time off for the employee.
- Open Tasks > Gantt and create a task during the approved time-off period the warning is shown and the Gantt cell is grayed out.
- Select both companies and create a task during the same time-off period in Tasks > Gantt.

Issue:
When multiple companies are selected, the time-off warning is still displayed but the corresponding Gantt cells are no longer grayed out, leading to an inconsistency between the warning logic and the Gantt rendering.

Cause:
In multi-company setups, a user can be linked to multiple resources. The Gantt unavailability logic assumed a one-to-one relationship between user and resource causing unavailability intervals from some resources to be overwritten.

Solution:
Aggregate unavailability intervals from all resources linked to the same user, limited to the selected companies, and merge them with the company calendar unavailability to ensure consistent Gantt gray rendering.
Related PR: https://github.com/odoo/enterprise/pull/57028

task-5089385

Steps to reproduce:
1. Install `appointment`
2. Create an appointment type using resources
3. Create a resource with capacity `4`
4. Book an appointment on that resource with reserved capacity `4`
5. Try to reduce the resource capacity
6. Cancel the appointment
7. Try again to reduce the resource capacity

Current behavior:
- Reducing the resource capacity raises: `The capacity used can not be lesser than the capacity reserved`

Issue:
- Canceled appointments still prevent lowering the resource capacity, even though the booking is no longer active.

Cause:
- Canceling an appointment only archives the related `calendar.event`, it does not remove the corresponding `appointment.booking.line`. That booking line keeps its previous `capacity_reserved` value, while `capacity_used` is a stored computed field depending on the resource capacity. When the resource capacity is reduced after cancellation, the archived booking line is recomputed with the new lower resource capacity and this violates the SQL constraint

Solution:
- For inactive booking lines: Set `capacity_used = capacity_reserved`

opw-6036053

Forward-Port-Of: odoo/enterprise#112485

**Steps to reproduce:**
- Install Documents app
- Go to a folder and select a file
- SelectionBox appears at the top
- Click on another folder containing the same file (e.g. "All")
- Box is still there, but interactions are broken (can't clear/add)
- Going to another view type (kanban/list) or clicking elsewhere reset it

**Issue:**
`SelectionBox` doesn't update itself on folder changes, but `_reapplySelection` still tries to re-select the relevant records when switching folders (it was probably done to make it work when switching views, as it re-mount the component).

**Fix:**
Add current selected category to the `t-key` to trigger a re-rendering of the `SelectionBox` using a state with the current folder id. In 18.3 it was partially fixed in the same way by using the `targetRecords.length` in [1].

Feels like a hack (and we add a state just for this) but it ensures the component has the proper data for the current folder.

We could also disable it on load for now, and we should make sure people don't accidentally use the state as the actual folder value...

[1] https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d

(Also a module update is needed to apply the fix due to the xml changes, so it might be better to apply it in master)

opw-6348049

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

When rendering floating-point numbers with high decimal accuracy (e.g., UoM quantities set to 10 decimals), the UI can occasionally display a trailing parasitic digit (such as 53000.0000000002 instead of 53000.0000000000).

This commit resolves the issue by backporting the formatting logic from master. The `maxDecDigits` calculation is moved outside the conditionals so it unconditionally caps precision for all numbers. Furthermore, the global significant digit ceiling is reduced from 15 to 14.

This 14-digit ceiling reserves a 1-digit buffer, allowing the newly introduced `formatFixedDecimals` utility to safely run `roundDecimals` on the float. This mathematically sanitizes the trailing corrupted digit before it is ever converted to a string.

opw-6313540

**Current behavior before PR:**
- With Product UoM set to 10 Decimal Accuracy, floats such as 53000 are displayed with a corrupted digit (e.g. 53000.0000000002)

**Desired behavior after PR is merged:**
- With Product UoM set to 10 Decimal Accuracy, floats such as 53000 are displayed without corrupted digits (e.g. 53000.000000000)

This PR is essentially a backport of https://github.com/odoo/odoo/commit/07da917f6e3319b4acde1029e77f69f1aba314b8 and https://github.com/odoo/odoo/commit/c4e7ba8d8fdfd7b0c442cf834f562ef8cedf019b for numbers.js

Forward-Port-Of: odoo/odoo#272940

Steps to reproduce:
------------------------------------------------
1. Install Event module
2. Create a multi day event
3. Create one attendee for the event
4. Change the event dates
5. Go to attendee and Click on Send by Email

Observation:
------------------------------------------------
The event start date displayed in the email body is not updated after the event dates are modified.

Issue:
------------------------------------------------
In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58

However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields
https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f

* `event_begin_date` is made stored for cohort view grouping
* However, the base compute method only depends on `event_id` and `event_slot_id`
https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180
* When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`)
* Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work
* Stored computed fields only recalculate when their explicit dependencies change

Solution:
------------------------------------------------
* Corrected the dependencies of `_compute_event_begin_date`.
* Added tests in the enterise module as issue occurs on installing enterprise module only.

opw-6284576

Issue:
    - When the attendance is flexible, the weekly expected hours shown in reports are incorrect.
    - This happens because the calculation is based only on the `Average Hour per Day` and doesn't take into account the `Hours per Week` set on the employee resource. It ignores the weekly limit defined in the employee's working schedule. -As a result, if an employee works more days than expected, the report may show more than the allowed weekly hours.

    Example:
    - An employee has a 32h/week contract and 8h/day.
    - If they work 5 days, the system still counts 8h as expected for each day — totaling 40h instead of 32h.

Steps To reporduce:
    - Set up a flexible contract with 32 hours/week (8 hours/day) for an employee.
    - Log 5 attendances in one week with 8 worked hours each.
    - Go to report and filter by employee by week, notice the current behavior yields 5 x 8 = 40 hours in expected_hours.

Solution:
    - Check the weekly hours cap defined in `resource_calendar_id.full_time_required_hours`.
    - If total `expected_hours` from earlier attendances this week exceeds that limit, set expected_hours = 0 for any excess.

OPW-4583064

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

Forward-Port-Of: odoo/odoo#218384

**Steps to reproduce:**

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

**Why the fix:**

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

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

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

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

opw-6153000

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

# How to reproduce
- Install the Website module
- Install another module that has atleast one model with one html field,
sanitize=Flase or sanitize_form=False and groups
- Remove the field's group from the current user
- Enable dev mode
- Go to Settings > Technical > Database Structure > Models
- Pick any model (e.g. sale.order.line)
- Add a field to that model & Save
- Delete the added field & Save

> Note : Significantly harder to reproduce since :
https://github.com/odoo/odoo/commit/9a336bbb94b0a4266d84f7554c024c3abd2d1e7c
I am not sure a field as mentionned in the steps exists

# The problem
An access error is raised for the module wich access rights were
removed, even if the module is not linked in any way with the picked
model

# Cause of the issue
Deleting the field will endup calling the `unlink()` method of
`BaseModel` on the `ir.model.fields` record. This function triggers all
`@api.delete` methods defined on the model :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/odoo/models.py#L4548-L4552

This will call the this method :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/addons/website/models/website_form.py#L153-L154

That was introduced by :
https://github.com/odoo/odoo/commit/c0a827519844ec43537e4487f6abe358bb82ba9a

Which prevents a field from being deleted if it is actively used in any
website form. But this method does a search on every model return by
`_get_html_fields` which may contains models that are not accessible by
the user, so we get an access error.

# Proposed solution
Since `_check_if_used_in_website_form` should perform the same
independently from the user, we can do the search in sudo

opw-6231951

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

Forward-Port-Of: odoo/odoo#272916
Forward-Port-Of: odoo/odoo#265781

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates, in the template, whether the real messages are rendered. That mirroring effect both read `mountedAndLoaded` as one of its dependencies and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write `[isLoaded=true, mountedAndLoaded=false]` pair; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window it drives `mountedAndLoaded` back to false while `isLoaded` stays true, and the settling patch then computes the very `[true, false]` pair already recorded. The effect never re-runs, so `mountedAndLoaded` is stranded at false and no message is rendered.

Depend on a monotonic `resetCount` instead. Reading it in the effect dependency array subscribes the render to it (OWL subscribes a `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: while loading, `applyScroll` resets on every patch, so an unconditional bump would spin the render loop; the guard re-arms only in the case that heals. `reset()` still clears `mountedAndLoaded` (the false dip is needed for the reload scroll handshake), so behaviour is otherwise unchanged.

The race is not deterministically reproducible with this version's test tooling, which cannot advance the render loop a single frame, so no test is added here; the fix is covered by tests on later versions.

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

Forward-Port-Of: odoo/odoo#274059

**Problem:**
When scheduling a message using an email template with custom attachments, those attachments will not have their `res_model` and `res_id` updated to relate to the scheduled message record. This can lead to access errors.

**Cause:**
When composing a message using an email template with attachments, those attachments are created with their `res_model` and `res_id` values corresponding to the mail composer record. However, when scheduling a message, only attachments with no `res_id` value (or a value of 0) are updated to correspond to the scheduled message record. https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mail/wizard/mail_compose_message.py#L1198-L1201
https://github.com/odoo/odoo/blob/30ca89b9e0d3c43d019167ec2de816c263f4bb92/addons/mail/models/mail_scheduled_message.py#L86

**Purpose:**
Modify the `mail.scheduled.message` override of `create` to not require an attachment have no `res_id` value to be properly updated.

**Steps to Reproduce in Runbot:**
1. Add an attachment to an email template.
2. Open a mail composer using that email template, then schedule the message for later.
3. Attempt to view the scheduled message with a different user.

More specific example flow:
1. Add an attachment to the Sales: Send Quotation email template.
2. Create a Quotation and send it with the Send by Email button, selecting Send Later instead of Send.
3. Attempt to view the Quotation with a different user.

opw-6293587

Forward-Port-Of: odoo/odoo#272261