Currently, an error occurs when a user sorts tasks by Planned Date.

**Steps to reproduce:**
 - Install the `project_enterprise` module with demo data.
 - Go to Projects in the portal (`/my/projects`), open any `project`, and sort the 
   tasks by `Planned Date`.

KeyError: 'order'

After a [recent change], the sort order is retrieved from searchbar sortings. When sorting by 
Planned Date, it attempts to access the order key from the corresponding sorting configuration [1]. 
However, the planned_date_begin entry does not define an order key [2], which raises 
error when it tries to access order.

This commit ensures that the order key is added with its value for planned_date_begin in 
searchbar sorting.

[recent change]: https://github.com/odoo/odoo/commit/8be5dacf9fbfe8c23b04c876994bea2ce7cbb89a

[1]: https://github.com/odoo/odoo/blob/2ae9b57b86cd0bc4816ff8ec207564631baa8ad6/addons/project/controllers/portal.py#L424

[2]- https://github.com/odoo/enterprise/blob/9dd3a9b2c09a6d23a3f71d3e531edd6d78b30277/project_enterprise/controllers/portal.py#L8-L11

sentry-7556050938

Forward-Port-Of: odoo/enterprise#121230
Forward-Port-Of: odoo/enterprise#121141

Currently, flexible employees can request a multi-day leave spanning a public holiday when the leave type includes public holidays in duration. However, requesting the public holiday date alone is rejected.

### **Steps to reproduce:**
- Create a public holiday.
- Create a time off type with "Public Holiday Included" enabled.
- Select/create an employee with a flexible work schedule and its time zone must be same as admin.
- Request a time off on the public holiday date only.

### **Observed Behavior:**
The request is rejected because its duration is computed as 0 days.

### **Expected Behavior:**
The request should be allowed and count as 1 day, consistent with the multi-day request behavior.

### **Root Cause:**
At [1], a dedicated duration computation path is used for single-day leaves of flexible employees. This logic always retrieves overlapping public holidays and computes the leave duration based on the remaining intervals. As a result, a leave requested entirely on a public holiday is computed as 0 days, even when `include_public_holidays_in_duration` is enabled.

[1]- https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/hr_holidays/models/hr_leave.py#L436-L444

### **Fix:**
This commit ensures that the `include_public_holidays_in_duration` setting is taken into account when computing single-day leave durations for flexible employees

**opw-6284768**

Forward-Port-Of: odoo/odoo#272217
Forward-Port-Of: odoo/odoo#269743

__To reproduce__
1. Drop a popup on the website.
2. Click twice rapidly on the popup show/hide toggle in the sidebar.
=> The popup visibility will be in an inconsistent state compared
   to the toggle's eye icon.

__Reason__
Bootstrap ignores any call to show/hide if the popup is still
transitioning.

__Fix__
- Set `_isTransitioning` to `false` to trick Bootstrap into firing the
event regardless of its current state.
- When hide/show are triggered in quick succession, the modal can enter an
inconsistent state with `.show` class but `display: none` style (hide removes
`.show` immediately, show restores it with `display: block`, then hide applies
`display: none` after animation). Dispatching `transitionend` event before
resetting `_isTransitioning` ensures Bootstrap completes its state transitions.

__Note__
This commit also fixes `custom_popup_snippet`, which fails
non-deterministically with the following error:
`TypeError: Cannot read properties of undefined (reading 'after')`

This error occurs when trying to add a popup inside another popup
that never closes due to this bug.

runbot-939039

Forward-Port-Of: odoo/odoo#269782

Currently, an error occurs when a user insert a dynamic product snippet onto website.

**Steps to Reproduce:**

 - Install `website_sale` without demo data.
 - Go to `Website` > `eCommerce` > `Products` > `Ribbons`.
 - Open any ribbon and set `Assign` to `When New`.
 - Go to the `Website` > `Edit` > drag and drop the `Catalog` block, and select a `Dynamic Product` 
   block (`Generic Product Template (customizable)` [ref](https://drive.google.com/file/d/1ZYeQA8DhfYAf_jbPwL-tZXaVi1YAyFbd/view?usp=drive_link)).

`TypeError: unsupported operand type(s) for -: 'datetime.datetime' and 'bool'`

After this [recent commit], when a user drops a dynamic product snippet, the system attempts 
to set the ribbon value [1]. If no product records are available, it falls back to using sample products [2]. 
These sample products are virtual records created with model.new() [3] [4] and are not stored in 
the database, so they do not have a publish date.
When auto-assigned ribbon with the When New option assign, the system compares the ribbon's 
new period with the product's publish date. Since the sample products do not have a publish 
date, this comparison raises an error [5].

This commit ensures that the comparison between new period and publish date is only 
performed when the product has a valid publish date.

[recent commit]: https://github.com/odoo/odoo/commit/f427f795c24ee37ee02302642b77bfc314a9ea43

[1]- https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website_sale/templates/snippets/product_snippet_template_data.xml#L52-L58

[2]: https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website/models/website_snippet_filter.py#L75-L78

[3]- https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website/models/website_snippet_filter.py#L210-L215

[4]: https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website_sale/models/website_snippet_filter.py#L62-L95

[5]: https://github.com/odoo/odoo/blob/b70330df7dc2017ab592b075c8ad8e048f671d90/addons/website_sale/models/product_ribbon.py#L121-L124

sentry-7528296918

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

When a popover is used on top of an iframe, when clicking outside the
popover but inside the iframe to close the popover, the click away is
detected through a blur event.
The close during the click away is used by some features to apply the
change.

Setting the text color in the editor might modify the DOM structure
and therefore needs to readjust the selection to match the new DOM
nodes. When confirming a color, or when applying intermediary changes
this behavior is required. But when the color confirmation happens
because of a click away, this selection gets on the way of the
selection made by clicking away.

The sequence of events is as follows:
- pointerdown in iframe: sets the selection based on the click
- main window blur: color gets applied, and selection gets reset
- pointermove in iframe: expands selection to new position

This commit avoids this unwanted reset by detecting the click away
through a pointerdown on the iframe - thus making the selection
adjustment before the default browser handling of the event actually
sets the selection on the clicked position.

Steps to reproduce:
- Edit a website page
- Drop a text snippet
- Select a word
- Set a custom color using the color area - so that the color picker
remains open
- Click (and hold) in the empty area after the text paragraph
- Move pointer by a few pixels

=> The text anchor remained the one of the former selection, but the
focus was set according to the pointer position

Note that Firefox did not blur the main window, therefore this change
actually also unifies the behavior of Chrome and Firefox.

The discrepancy between Chrome and Firefox's handling of the blur
event in this situation seems to be related to either prioritizing the
DOM specifications or the HTML specifications - and the way the are
interpreted.

The DOM Standard [1] relies on UIEvents [2] which states: "A user agent
MUST dispatch this event when an event target loses focus."

The HTML Standard defines how to compute the focus [3] and relies on
nested browsing contexts [4].
Typically, the simpler readable description for developers says:
"document.hasFocus()
Returns true if key events are being routed through or to document;
otherwise, returns false. Roughly speaking, this corresponds to
document, or a document nested inside document, being focused."

[1]: https://dom.spec.whatwg.org/#biblio-uievents
[2]: https://w3c.github.io/uievents/#event-type-blur
[3]: https://html.spec.whatwg.org/multipage/interaction.html#focus-processing-model
[4]: https://html.spec.whatwg.org/multipage/document-sequences.html#nested-browsing-contexts

task-6268573

Forward-Port-Of: odoo/odoo#269742

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/enterprise#121542
Forward-Port-Of: odoo/enterprise#119530

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/odoo#271637
Forward-Port-Of: odoo/odoo#268527

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

**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#121677
Forward-Port-Of: odoo/enterprise#120967

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

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#271422
Forward-Port-Of: odoo/odoo#251780

When a popover is used on top of an iframe, when clicking outside the
popover but inside the iframe to close the popover, the click away is
detected through a blur event.
The close during the click away is used by some features to apply the
change.

Setting the text color in the editor might modify the DOM structure
and therefore needs to readjust the selection to match the new DOM
nodes. When confirming a color, or when applying intermediary changes
this behavior is required. But when the color confirmation happens
because of a click away, this selection gets on the way of the
selection made by clicking away.

The sequence of events is as follows:
- pointerdown in iframe: sets the selection based on the click
- main window blur: color gets applied, and selection gets reset
- pointermove in iframe: expands selection to new position

This commit avoids this unwanted reset by detecting the click away
through a pointerdown on the iframe - thus making the selection
adjustment before the default browser handling of the event actually
sets the selection on the clicked position.

Steps to reproduce:
- Edit a website page
- Drop a text snippet
- Select a word
- Set a custom color using the color area - so that the color picker
remains open
- Click (and hold) in the empty area after the text paragraph
- Move pointer by a few pixels

=> The text anchor remained the one of the former selection, but the
focus was set according to the pointer position

Note that Firefox did not blur the main window, therefore this change
actually also unifies the behavior of Chrome and Firefox.

The discrepancy between Chrome and Firefox's handling of the blur
event in this situation seems to be related to either prioritizing the
DOM specifications or the HTML specifications - and the way the are
interpreted.

The DOM Standard [1] relies on UIEvents [2] which states: "A user agent
MUST dispatch this event when an event target loses focus."

The HTML Standard defines how to compute the focus [3] and relies on
nested browsing contexts [4].
Typically, the simpler readable description for developers says:
"document.hasFocus()
Returns true if key events are being routed through or to document;
otherwise, returns false. Roughly speaking, this corresponds to
document, or a document nested inside document, being focused."

[1]: https://dom.spec.whatwg.org/#biblio-uievents
[2]: https://w3c.github.io/uievents/#event-type-blur
[3]: https://html.spec.whatwg.org/multipage/interaction.html#focus-processing-model
[4]: https://html.spec.whatwg.org/multipage/document-sequences.html#nested-browsing-contexts

task-6268573

Forward-Port-Of: odoo/odoo#269742

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#272571
Forward-Port-Of: odoo/odoo#271082

Steps to reproduce:
===================
1. Add several delivery addresses & billing addresses
2. Add a product to the cart and go to checkout.
3. Select a specific delivery address and a different invoice address.
4. Pay and click "Skip" immediately on that page.
5. Open the resulting sales order.

=> The delivery address is reset to the company's first delivery child
   instead of the one selected during checkout.

Root cause:
===========
`partner_shipping_id` and `partner_invoice_id` are stored computed fields
(compute + store + readonly=False) that depend on `partner_id`. Any write
that includes `partner_id`, even writing the same value, retriggers the
compute and overwrites a manually selected address with the result of
`partner_id.address_get()`.

`_get_and_cache_current_cart` resurrects the customer's draft cart when it
is no longer referenced in the session and re-runs
`_update_address(partner, ['partner_id'])` on it to refresh the
pricelist and fiscal position. Clicking "Skip" runs `sale_reset()`,
which clears the session cart key while the order is still draft, so the
next cart access takes that abandoned-cart branch and the redundant
`partner_id` write discards the selected delivery/invoice address.
Waiting a few seconds lets the order reach the 'sale' state first, so
the draft search no longer matches and the address is kept, which is why
the issue is timing dependent.

Fix:
====
In `_update_address`, when partner_id is written, keep the delivery and
invoice addresses already set on the cart if they still belong to the new
partner's company (same `commercial_partner_id`) by writing them in the same
`write()` so the recompute does not override them. Addresses that do not
belong to the new partner are still recomputed to the partner's defaults.

opw-6267188

Forward-Port-Of: odoo/odoo#270300

Problem:
Since saas-19.2 (99f38be260c3c5523306e4ffcb4cf18436d40568), portal users crash when opening a Knowledge article containing items with "Created by" or "Last edited by" columns.

Cause:
Portal users are restricted to their own res.users record. Reading create_uid and last_edition_uid of internal users raises an AccessError. This was not raised in 19.0.
Specifically, the `many2one_avatar_user` field widget defines `write_date` in `relatedFields`, which forces the RPC to read the `write_date` field of the target user. Since portal users cannot read other users' records, it raises an AccessError.

Solution:
Only include `write_date` in the field widget's `relatedFields` if the current user is an internal user. For portal users, `relatedFields` will be empty, avoiding the AccessError.

Steps to reproduce:
1. Create a Knowledge article.
2. Add an "Item list" element.
3. Add some items to the list.
4. Share the article with a portal user.
5. Open the article as the portal user.
6. Observe that only the list header is visible and the items are not displayed.

opw-6199714

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

**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#269890
Forward-Port-Of: odoo/odoo#253059

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#271422
Forward-Port-Of: odoo/odoo#251780

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

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

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

**Issue**
Quantity on subcontracted receipts could be overridden after running the
scheduler.

**Steps to reproduce**
- Create a subcontracting product
- Create a PO for 10 units of that product
- Go to receipt and open Subcontracting Productions'
- Change the quantity to 5
- Enable debug mode.
- Run Inventory/Operations/Procurement: run scheduler
- Return to the receipt
-> The receipt quantity is reset to 10 instead of remaining at 5.

**Cause**
Since the refactor introduced in commit: https://github.com/odoo/odoo/commit/fc66e2d4eb638f1486e69cd5920f02c787055da1,
subcontracting receipt moves are no longer automatically picked when the production quantity is modified.
In particular, this test case protects that behavior:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp_subcontracting/tests/test_subcontracting.py#L1629-L1631
When the scheduler runs:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L731
it computes the moves to assign:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L706-L710
However, subcontracting moves are still included in the assignment domain:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L680-L688
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/stock_rule.py#L127-L129
As a result, they are reassigned if they are not already picked:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_move.py#L1931-L1937

opw-6229668

Forward-Port-Of: odoo/odoo#270837

When a popover is used on top of an iframe, when clicking outside the
popover but inside the iframe to close the popover, the click away is
detected through a blur event.
The close during the click away is used by some features to apply the
change.

Setting the text color in the editor might modify the DOM structure
and therefore needs to readjust the selection to match the new DOM
nodes. When confirming a color, or when applying intermediary changes
this behavior is required. But when the color confirmation happens
because of a click away, this selection gets on the way of the
selection made by clicking away.

The sequence of events is as follows:
- pointerdown in iframe: sets the selection based on the click
- main window blur: color gets applied, and selection gets reset
- pointermove in iframe: expands selection to new position

This commit avoids this unwanted reset by detecting the click away
through a pointerdown on the iframe - thus making the selection
adjustment before the default browser handling of the event actually
sets the selection on the clicked position.

Steps to reproduce:
- Edit a website page
- Drop a text snippet
- Select a word
- Set a custom color using the color area - so that the color picker
remains open
- Click (and hold) in the empty area after the text paragraph
- Move pointer by a few pixels

=> The text anchor remained the one of the former selection, but the
focus was set according to the pointer position

Note that Firefox did not blur the main window, therefore this change
actually also unifies the behavior of Chrome and Firefox.

The discrepancy between Chrome and Firefox's handling of the blur
event in this situation seems to be related to either prioritizing the
DOM specifications or the HTML specifications - and the way the are
interpreted.

The DOM Standard [1] relies on UIEvents [2] which states: "A user agent
MUST dispatch this event when an event target loses focus."

The HTML Standard defines how to compute the focus [3] and relies on
nested browsing contexts [4].
Typically, the simpler readable description for developers says:
"document.hasFocus()
Returns true if key events are being routed through or to document;
otherwise, returns false. Roughly speaking, this corresponds to
document, or a document nested inside document, being focused."

[1]: https://dom.spec.whatwg.org/#biblio-uievents
[2]: https://w3c.github.io/uievents/#event-type-blur
[3]: https://html.spec.whatwg.org/multipage/interaction.html#focus-processing-model
[4]: https://html.spec.whatwg.org/multipage/document-sequences.html#nested-browsing-contexts

task-6268573

Forward-Port-Of: odoo/odoo#269742

Steps to reproduce:
===================
1. Add several delivery addresses & billing addresses
2. Add a product to the cart and go to checkout.
3. Select a specific delivery address and a different invoice address.
4. Pay and click "Skip" immediately on that page.
5. Open the resulting sales order.

=> The delivery address is reset to the company's first delivery child
   instead of the one selected during checkout.

Root cause:
===========
`partner_shipping_id` and `partner_invoice_id` are stored computed fields
(compute + store + readonly=False) that depend on `partner_id`. Any write
that includes `partner_id`, even writing the same value, retriggers the
compute and overwrites a manually selected address with the result of
`partner_id.address_get()`.

`_get_and_cache_current_cart` resurrects the customer's draft cart when it
is no longer referenced in the session and re-runs
`_update_address(partner, ['partner_id'])` on it to refresh the
pricelist and fiscal position. Clicking "Skip" runs `sale_reset()`,
which clears the session cart key while the order is still draft, so the
next cart access takes that abandoned-cart branch and the redundant
`partner_id` write discards the selected delivery/invoice address.
Waiting a few seconds lets the order reach the 'sale' state first, so
the draft search no longer matches and the address is kept, which is why
the issue is timing dependent.

Fix:
====
In `_update_address`, when partner_id is written, keep the delivery and
invoice addresses already set on the cart if they still belong to the new
partner's company (same `commercial_partner_id`) by writing them in the same
`write()` so the recompute does not override them. Addresses that do not
belong to the new partner are still recomputed to the partner's defaults.

opw-6267188

Forward-Port-Of: odoo/odoo#270300

### Issue:

Editing the `lot_ids` of a move of a `lot` tracked product from the picking form view leads to wildly unexpected results. This happens only with tracking by `lot` not by serial.

### Concrete Issue 1:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Create and confirm a delivery for 5 units of P
4. Set the quantity of the move to 5 from the Form picking view > save
5. Create and set 2 lots: LOT1, LOT2 on the serial numbers field
6. Save
#### > The quantity of the move has been updated to 2, only the first lot is set and it has been for this quantity of 2

### Concrete Issues 2 and 3:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Update the onhand quantity of P:
    - 1 units of LOT001 in Shelf1
    - 2 units of LOT001 in Shelf2
    - 2 units of LOT002 in Stock
4. Create and confirm a delivery for 5 units of P
5. Remove LOT002 from the Serial numbers in the Form picking view > save
#### > The quantity of the move is updated to 1 (only the 1 unit of LOT001 from Shelf2 is kept)
5'. Remove LOT002 and put it back
#### > The quantity is updated from 5 to 2 if you save, only LOT001 is kept.

### Cause of the issue:

The `_onchange_lot_ids` and `_set_lot_ids` methods have been tailored to work appropriately only with `serial` tracking, updating the quantities considering a 1 to 1 quantity, lot matching:
https://github.com/odoo/odoo/blob/c9715982134220aa8fa525d0cf6a8d47eaeb6ed6/addons/stock/models/stock_move.py#L623-L645
However, for lot tracked product the situation is much more subtle to handle.

### Behavior after the fix:

Editing the `lot_ids` on tracked products should adapt the reservation following these rules:
- Existing move lines with a valid lot or lot name should be kept unchanged.
- Removing a lot should delete its related move lines and adjust the move quantity accordingly.
- Each newly assigned lot must be linked to at least one move line of the move.

If the move is expected to bypass reservation (e.g. receipts, final move of a production,...):
- Assignment should be performed, in priority, on an existing free move line.
- If no suitable free move line exists, a new move line should be created with the largest possible quantity that does not cause the total assigned quantity to exceed the move demand.
- If such a quantity cannot be assigned, the new move line should be created with a quantity of 1 in the product.uom_id.

If the move is expected to be reserved (e.g. internal transfer, deliveries,...):
- Each new lot should be assigned from an existing quants with the maximum available quantity to satisfy at best the remaining demand.
- If no available quantity can be assigned from existing quants, the lot should be assigned a minimum quantity of 1 in product.uom_id.

### Additional note on the fix:

Since move that do bypass reservation use a different detailed operation view relying on lot_names form move line rather than lot_id from existing quants it is important to set both the `lot_name` as well as the `lot_id` on move lines for the changes to be visible in the detailed operations view.

### Note:

The current fix populated records on which the `label_production_view_pdf` report was tested (by the test_report) highlighting a template error:
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/mrp/report/mrp_production_templates.xml#L187
The value provided to the t-field being something else than a field but rather an or close between two fields.


opw-6173914
opw-5881661

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

Forward-Port-Of: odoo/odoo#263037

### Steps to reproduce:
- Install 'Accounting'
- From 'Accounting' > 'Journal Entries', Select multiple records from the list view.
- Try to schedule a 'Document' activity.
> Traceback: `KeyError: account.move(X, X)`

### Cause of Issue:
When scheduling an activity for multiple records, `_onchange_activity_user_id` calls `_mail_get_operation_for_mail_message_operation('create')` on the entire batch of records. This method returns a dictionary mapping *individual* records to their required operations. However, then it was attempted to retrieve the operation values using the whole thread (which now contains 2 records) as a key causing a `KeyError` since only individual records existed as keys. https://github.com/odoo/odoo/blob/337efb069f6cf2cb9478a970f075fd139c1e8e0a/addons/mail/wizard/mail_activity_schedule.py#L463

### Fix:
For each required operation type, filter the records requiring it from the `thread` recordset and evaluate `check_access` on those specific records, making access checking efficient.

opw-6290303

Forward-Port-Of: odoo/odoo#270277

Issue:
When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the invoice PDF to hide payment communication and bank account details.

Other localizations like Belgian companies, uses Belgian references, the reference is always generated regardless of customer country.

Steps to reproduce:
- Configure a Swiss company with a QR IBAN bank account
- Set the sales journal Communication Standard to Switzerland
- Create and confirm an invoice for a non swiss customer (US, BE)
- Observe in the pdf and in the other info tab -> no payment reference or payment details

Cause:
`get_l10n_ch_qrr_number()` was using on `l10n_ch_is_qr_valid()`, which conflicts QR-bill printability (partner country, currency) with payment reference generation. When the customer is outside CH/LI, `l10n_ch_is_qr_valid()` is False and no QRR reference is generated.

Solution:
Decouple QRR reference generation from QR bill printability. The Swiss communication standard now generates a QRR format reference when a QR-IBAN is configured, regardless of customer's country or currency.

opw-6222417

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

Forward-Port-Of: odoo/odoo#266861

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

**Issue**
Quantity on subcontracted receipts could be overridden after running the
scheduler.

**Steps to reproduce**
- Create a subcontracting product
- Create a PO for 10 units of that product
- Go to receipt and open Subcontracting Productions'
- Change the quantity to 5
- Enable debug mode.
- Run Inventory/Operations/Procurement: run scheduler
- Return to the receipt
-> The receipt quantity is reset to 10 instead of remaining at 5.

**Cause**
Since the refactor introduced in commit: https://github.com/odoo/odoo/commit/fc66e2d4eb638f1486e69cd5920f02c787055da1,
subcontracting receipt moves are no longer automatically picked when the production quantity is modified.
In particular, this test case protects that behavior:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp_subcontracting/tests/test_subcontracting.py#L1629-L1631
When the scheduler runs:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L731
it computes the moves to assign:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L706-L710
However, subcontracting moves are still included in the assignment domain:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_rule.py#L680-L688
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/stock_rule.py#L127-L129
As a result, they are reassigned if they are not already picked:
https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/stock/models/stock_move.py#L1931-L1937

opw-6229668

Forward-Port-Of: odoo/odoo#270837

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#271422
Forward-Port-Of: odoo/odoo#251780

The following error is raised in the POS when paying with an Adyen terminal:
```
TypeError: Cannot read properties of undefined (reading 'uuid')
at Proxy.handleAdyenStatusResponse
```

Adyen delivers webhook notifications at-least-once, so the ADYEN_LATEST_RESPONSE event can fire several times for a single payment, running handleAdyenStatusResponse concurrently. After the await on get_latest_adyen_status, a previous (duplicate) notification may already have resolved the payment line, so getPendingPaymentLine no longer returns it and the subsequent line.uuid dereference crashes.

opw-6237987 patched the same root cause on a single line by adding an optional chaining operator in isPaymentSuccessful, which only moved the crash to the next dereference.

Fetch the pending line once at the start of handleAdyenStatusResponse and bail out when it is gone, so every dereference below is safe. The same guard is added to the remaining branches of _adyen_handle_response for consistency with the existing Reject branch.

opw-6237987

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

Forward-Port-Of: odoo/odoo#270880
Forward-Port-Of: odoo/odoo#269720

## Problem
In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders.

## Solution
We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end.

## Steps to reproduce (runbot 19)
1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B.
2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id
3. Go back to MO B and plan it. This should give it precedence in Shop Floor
4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one

To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list.

opw-6303323

Forward-Port-Of: odoo/enterprise#121693

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238

Forward-Port-Of: odoo/enterprise#120219

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.

Note
----
Pushing onto `tax_ids` in the order widget makes the Kenyan receipt crash with "The 'tax_ids' array cannot be modified. Use the update method instead.", so we assign the taxes instead of pushing them.


opw-6253306

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

**Problem:**
partial quantities in a dropship picking 
is not taken into account for the svl quantity
(it's always the full initial quantity)

**Steps to reproduce:**
- create a storable product with dropship route
- set the category as avco auto
- set a vendor in the purchase tab with a price of 10
- confirm a SO for a quantity of 2
- confirm the related PO with a unit price of 10
- on the dropship picking change the quantity to 1
- validate without backorder
- click on the valuation smart button

**Current behavior:**
- the svls have quantities of 2 and -2
- the related amls have debit/credit of 20

**Expected behavior:**
- the svls should have quantities of 1 and -1
- the related amls should have debit/credit of 10

**Cause of the issue:**
when creating the svls we use the move's product_qty
instead of its quantity
https://github.com/odoo/odoo/blob/c97629d5efb82aed191de211593c539686cae65b/addons/stock_account/models/stock_move.py#L290

**fix:**
product_qty is expressed in the uom of the product
and quantity in the uom of the move so we need 
to add a uom conversion to the fix

opw-6113031

Forward-Port-Of: odoo/odoo#271531
Forward-Port-Of: odoo/odoo#270823

### Steps to reproduce:
- Insert a file using /file command and upload a file.
- Type any powerbox command (e.g. /file, /media)
- Press Enter to select the command
- IndexSizeError: Failed to execute 'setBaseAndExtent' on 'Selection': There is no child at offset 5.

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

- makeSavePoint() of history_plugin uses preserveSelection() to save current selection. However, preserved selections remain registered in the cursor update mechanism and continue to be updated when the editor adjusts cursors during DOM changes.
- During normalization, updateFeffs() updates all preserved cursors. Because the savepoint selection is stored using preserveSelection(), it is updated as well and can become inconsistent with the DOM state that the savepoint later restores, resulting in an IndexSizeError.

### Solution (backport-https://github.com/odoo/odoo/commit/1eb0e6de8f566d260ecb6c0dae3436e87ffe8436):
- Update preserved cursors after steps restoration so they stay in sync with the restored DOM state.
- Stage the selection in the clipboard plugin after `before_paste_handlers`, ensuring the selection reflects the final adjusted state before pasting.
- Fix `selectFullText` to trigger `pointerup` to have a correct staged selection.

task-6298761


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

Forward-Port-Of: odoo/odoo#270085

Issue:
When an invoice (sales journal) uses "Switzerland" localization and the invoice is issued to a customer outside Switzerland/Liechtenstein, no payment reference is generated. This causes the invoice PDF to hide payment communication and bank account details.

Other localizations like Belgian companies, uses Belgian references, the reference is always generated regardless of customer country.

Steps to reproduce:
- Configure a Swiss company with a QR IBAN bank account
- Set the sales journal Communication Standard to Switzerland
- Create and confirm an invoice for a non swiss customer (US, BE)
- Observe in the pdf and in the other info tab -> no payment reference or payment details

Cause:
`get_l10n_ch_qrr_number()` was using on `l10n_ch_is_qr_valid()`, which conflicts QR-bill printability (partner country, currency) with payment reference generation. When the customer is outside CH/LI, `l10n_ch_is_qr_valid()` is False and no QRR reference is generated.

Solution:
Decouple QRR reference generation from QR bill printability. The Swiss communication standard now generates a QRR format reference when a QR-IBAN is configured, regardless of customer's country or currency.

opw-6222417

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

Forward-Port-Of: odoo/odoo#266861

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

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

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

Forward-Port-Of: odoo/enterprise#115444

### Issue:
When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated

Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment
Only languages installed afterwards are affected

### Cause:
The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates
Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files
The `TranslationImporter` finds nothing to import for them

The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed

`TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced
This is the standard way to push translations while preserving any manually modified values

### Notes:
Languages installed before this fix are not updated
Only newly installed languages will get the synced translations

### Steps to reproduce:
- Install `l10n_co_dian`
- Enable Developer Mode in Settings
- Install any language (e.g. `fr_FR`)
- Go in Settings > Technical > Email > Email Templates
- Search for DIAN and open Invoice or Credit Note

Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html

opw-6269979

Forward-Port-Of: odoo/enterprise#120855

Currently, an error occurs when a user sorts tasks by Planned Date.

**Steps to reproduce:**
 - Install the `project_enterprise` module with demo data.
 - Go to Projects in the portal (`/my/projects`), open any `project`, and sort the 
   tasks by `Planned Date`.

KeyError: 'order'

After a [recent change], the sort order is retrieved from searchbar sortings. When sorting by 
Planned Date, it attempts to access the order key from the corresponding sorting configuration [1]. 
However, the planned_date_begin entry does not define an order key [2], which raises 
error when it tries to access order.

This commit ensures that the order key is added with its value for planned_date_begin in 
searchbar sorting.

[recent change]: https://github.com/odoo/odoo/commit/8be5dacf9fbfe8c23b04c876994bea2ce7cbb89a

[1]: https://github.com/odoo/odoo/blob/2ae9b57b86cd0bc4816ff8ec207564631baa8ad6/addons/project/controllers/portal.py#L424

[2]- https://github.com/odoo/enterprise/blob/9dd3a9b2c09a6d23a3f71d3e531edd6d78b30277/project_enterprise/controllers/portal.py#L8-L11

sentry-7556050938

Forward-Port-Of: odoo/enterprise#121230
Forward-Port-Of: odoo/enterprise#121141

Issue:
Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference"

Steps to reproduce on any database with DIAN and Colombian localization:

  1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”.
  2. Find a res.partner with a ref field, or add a ref field to any partner.
  3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it.
  4. Send that invoice to DIAN.
  5. Create a Debit Note for that invoice. Use the journal created in step 1.
  6. Add a product, price, and tax to the debit note. Confirm it.
  7. Send the debit note to DIAN.
  
Explanation:
The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents.

Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output.

opw-6181039

Forward-Port-Of: odoo/enterprise#121458
Forward-Port-Of: odoo/enterprise#121422

**Steps to reproduce:**
- Install Documents app
- Upload a sound file (mp3 for example, but the
    behavior is the same for other formats)
- Share the document and copy the link
- Log out
- Paste the link
- Click on preview button
- Media is working fine on Firefox
- Media won't read on Chrome
```
Loading media from '' violates the following Content Security Policy directive: "default-src 'none'".
Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback.
The action has been blocked.
```

**Issue:**
Since [1] default CSP Headers are too strict for Chrome default media rendering, which breaks the file preview (and force user download).

This only impacts Chrome as they seem to render generate `<video><source>` elements to render the file which triggers a secondary request and fails due to the CSP constraint.

**Fix:**
Could re-apply the header fix of 17.4 (see [2]), but it seems better to block the preview of audio files as well by default (to match how we manage videos).

(Note: we don't want to be used as a media streaming platform)

[1] (set csp to none by default) https://github.com/odoo/odoo/commit/64beb80205dffe4b432c8b5813a3271b073fa85e
[2] (similar issue which was not fixed in 18.0+) https://github.com/odoo/enterprise/commit/a7af78eeb2b9763045a5bda8714172f5e7402df8
[3] (mp4 preview removed) https://github.com/odoo/enterprise/commit/ea88cf7c6d5f077b60fb59347659507fded0e2fe

opw-6235043

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

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

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