**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

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

Forward-Port-Of: odoo/enterprise#116320
Forward-Port-Of: odoo/enterprise#112879

Currently, the field `l10n_co_edi_ubl` is displayed without a label 
in the UoM form, confusing users.

**Steps to reproduce:**
- Install the `l10n_co_edi` module and switch to the CO Company.
- Navigate to Invoicing > Settings.
- Enable `Units of Measure & Packagings`.
- Open `Units & Packagings` and click `New`.

**Observation:**
The `l10n_co_edi_ubl` field appears between the `Quantity` label and 
its corresponding field, but its own label is not visible.

<img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" />


**Root Cause:**
The inherited view [1] inserts the field `l10n_co_edi_ubl` before 
`relative_factor` in the base view [2].

In the base view, `relative_factor` is wrapped inside a `<div>` with a 
shared label (`Quantity`). Since the new field is inserted inside this 
structure, it inherits the same layout without having its own label, 
resulting in the label being hidden.

**Fix:**
This commit updates the view to ensure that the field `l10n_co_edi_ubl` 
is properly displayed with its own label, avoiding UI confusion and 
improving form clarity.

**After:**
<img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" />

[1]:
https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13

[2]:
https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34

opw-6180769

Forward-Port-Of: odoo/enterprise#115933

In odoo/enterprise#106192, we have modified the function userPermissionViewOnly that was preventing the user from editing document he cannot: we have removed the condition preventing user to edit protected document (mainly folder at the company root). That was an error as even if the user has "edit" access (which is ensured in that method), the document can still be protected and the form to edit it should be in readonly then. We ensure here that the form in the details panel is in readonly in that case.

How to reproduce:
- log as demo and go to Document
- Click on Inbox folder
- Open details panel
- Change for example the contact of the document
You get an error while you shouldn't be able to edit it (as the folder is protected).

Technical note: we re-add the condition in the method userPermissionViewOnly:
(!this.documentService.userIsDocumentManager
&& this.record.data?.user_folder_id === "COMPANY")
that we slightly modify to limit the protected document to folder only:
(!this.documentService.userIsDocumentManager
&& this.record.data?.user_folder_id === "COMPANY"
&& this.record.data?.type === "folder")

Task-5881531

Forward-Port-Of: odoo/enterprise#116709

**Steps to reproduce:**
* Go to Accounting App.
* Open the Journals list view (Configuration > Accounting > Journals).
* Click on the "Action" (cog) menu.

**Observed behavior:**
* The "Import records" option is completely missing.

**Cause:**
* In [commit](https://github.com/odoo/odoo/commit/082c70e6d411afd28efffbaf437d8b56d8351e38), `create="False"` was added to the `account.journal` list view to hide the "New" button, intentionally redirecting users to use the journal creation wizard instead.
* However, Odoo's standard `base_import` framework evaluates the XML architecture of the view (`config.viewArch.getAttribute("create")`). Because `create="False"` was set on the view, the framework automatically hid the `Import records` action menu item, assuming importing was entirely restricted.

**Fix:**
* Remove `create="False"` from the XML view architecture so the `base_import` framework evaluates it correctly and displays the "Import records" action.
* Introduce a custom `js_class` (`account_journal_list`) for the journal list view. By explicitly setting `this.activeActions.create = false` inside the controller's `setup()` lifecycle method, we can safely hide the inline "New" button on the UI layer without interfering with the backend XML architecture evaluation.

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

Forward-Port-Of: odoo/odoo#260561

The current query to delete unnecessary records from `res.device.log` must be run on all records in the table.
This means that the entire table will be placed in the psql buffer. This can degrade performance if autovacuum is very frequent.

This commit introduces a fix so that a seq scan does not have to be performed on the table to carry out the cleanup.

We can use an `USING` if the condition on the joined table (L2) significantly reduces the volume before the join.
This will avoid having the corresponding rows from the first table (L1).

Pseudo query:
```sql
DELETE FROM L1
USING L2
WHERE
    <L2_selective_filter>
    AND L1.<device> = L2.<device>
    AND L1.last_activity < L2.last_activity
```

If `<L2_selective_filter>` is very selective, PostgreSQL will use L2 as the "base" table for the join.
PostgreSQL will therefore not place the entire table in the buffer.

With:
```
d: device
c: cron
t: time
```
```
d t1 - insert
d t2 - insert
d t3 - insert

c t4 - cleanup (delete d t1 and d t2)

d t3
d t5 - insert
d t6 - insert

c t7 - cleanup (delete d t3 and d t5)

d t6
d t8 - insert

c t9 - cleanup (delete d t6)

d t8

c t10 - cleanup

d t8
...
```
In the example, cron t9 cannot look at the time window between the moment it runs and the last cron t7. The proof is that the device inserted in t6 must be deleted because a device t8 has been inserted.

It is not possible to cleanup between two crons because older lines can still be deleted by a later cron if a more recent line has been inserted after the previous cron.

So if a device is inserted between the time of the current cron (t0) and the previous cron (t-x), it is necessary to scan the entire table to cleanup the previous devices.
Therefore, it is possible to create a filter so that devices for which there has been no new insertion in the table between the two crons (t0 and t-x) do not need to be checked.

Pseudo query becomes:
```sql
DELETE FROM L1
USING L2
WHERE
    L2.last_activity >= <last_cron_time>
    AND L1.<device> = L2.<device>
    AND L1.last_activity < L2.last_activity
```

Task-5951999

Forward-Port-Of: odoo/odoo#263625
Forward-Port-Of: odoo/odoo#249738

Steps to reproduce
1. Go to Accounting → Configuration → Analytic Distribution Models
2. Create a new model, name it, and in the distribution column pick an analytic account
3. Click outside the row and reload the page

Issue
The newly created record vanishes because `web_save` received
`analytic_distribution: false`. The single click that closes the popover
also triggers the editable list's `leaveEditMode`, which calls
`record.save()`. That save runs before the widget has flushed the user's
pick into `record.data`, so the write goes out with stale/empty data.

This became reliably reproducible after [37d78a47bb20],
which moved the list renderer's outside-click listener from `document`
(bubble) to `window` (capture). Because the list is mounted before the
widget, its capture-phase listener now fires first: `leaveEditMode` →
`record.save()` is already in flight by the time the widget's own
window click handler runs, so the widget's commit loses the race.

Solution
`record.save()` awaits `_askChanges()` before writing:
https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/web/static/src/model/relational_model/record.js#L268-L271
`_askChanges()` triggers `NEED_LOCAL_CHANGES` on the model bus and
awaits any proms handlers push onto it:
https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/web/static/src/model/relational_model/relational_model.js#L249-L253
This is the framework's standard hook for widgets that hold uncommitted
local state; `ace_field` and `domain_field` already use it.

Subscribe the analytic distribution widget to the same event and, when
the dropdown is open, push a `commitChanges()` prom that awaits the
existing `save()`. Because `record.save()` awaits these proms before
running `_save`, the widget's pending distribution is guaranteed to be
on `record.data` by the time the write payload is built, regardless of
click-listener ordering.

opw-6106309

Forward-Port-Of: odoo/odoo#260421

Currently, the field `l10n_co_edi_ubl` is displayed without a label 
in the UoM form, confusing users.

**Steps to reproduce:**
- Install the `l10n_co_edi` module and switch to the CO Company.
- Navigate to Invoicing > Settings.
- Enable `Units of Measure & Packagings`.
- Open `Units & Packagings` and click `New`.

**Observation:**
The `l10n_co_edi_ubl` field appears between the `Quantity` label and 
its corresponding field, but its own label is not visible.

<img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" />


**Root Cause:**
The inherited view [1] inserts the field `l10n_co_edi_ubl` before 
`relative_factor` in the base view [2].

In the base view, `relative_factor` is wrapped inside a `<div>` with a 
shared label (`Quantity`). Since the new field is inserted inside this 
structure, it inherits the same layout without having its own label, 
resulting in the label being hidden.

**Fix:**
This commit updates the view to ensure that the field `l10n_co_edi_ubl` 
is properly displayed with its own label, avoiding UI confusion and 
improving form clarity.

**After:**
<img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" />

[1]:
https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13

[2]:
https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34

opw-6180769

Forward-Port-Of: odoo/enterprise#115933

The current query to delete unnecessary records from `res.device.log` must be run on all records in the table.
This means that the entire table will be placed in the psql buffer. This can degrade performance if autovacuum is very frequent.

This commit introduces a fix so that a seq scan does not have to be performed on the table to carry out the cleanup.

We can use an `USING` if the condition on the joined table (L2) significantly reduces the volume before the join.
This will avoid having the corresponding rows from the first table (L1).

Pseudo query:
```sql
DELETE FROM L1
USING L2
WHERE
    <L2_selective_filter>
    AND L1.<device> = L2.<device>
    AND L1.last_activity < L2.last_activity
```

If `<L2_selective_filter>` is very selective, PostgreSQL will use L2 as the "base" table for the join.
PostgreSQL will therefore not place the entire table in the buffer.

With:
```
d: device
c: cron
t: time
```
```
d t1 - insert
d t2 - insert
d t3 - insert

c t4 - cleanup (delete d t1 and d t2)

d t3
d t5 - insert
d t6 - insert

c t7 - cleanup (delete d t3 and d t5)

d t6
d t8 - insert

c t9 - cleanup (delete d t6)

d t8

c t10 - cleanup

d t8
...
```
In the example, cron t9 cannot look at the time window between the moment it runs and the last cron t7. The proof is that the device inserted in t6 must be deleted because a device t8 has been inserted.

It is not possible to cleanup between two crons because older lines can still be deleted by a later cron if a more recent line has been inserted after the previous cron.

So if a device is inserted between the time of the current cron (t0) and the previous cron (t-x), it is necessary to scan the entire table to cleanup the previous devices.
Therefore, it is possible to create a filter so that devices for which there has been no new insertion in the table between the two crons (t0 and t-x) do not need to be checked.

Pseudo query becomes:
```sql
DELETE FROM L1
USING L2
WHERE
    L2.last_activity >= <last_cron_time>
    AND L1.<device> = L2.<device>
    AND L1.last_activity < L2.last_activity
```

Task-5951999

Forward-Port-Of: odoo/odoo#263625
Forward-Port-Of: odoo/odoo#249738

We do not need this extra aggregate expression.

The purpose of this aggregate expression is only
to invert the sign of the computation returned by
the expression account_tax_report_payg_w2_tag. Instead of doing the sign inversion through a separate aggregate expression, we can directly include the negative (-) sign in account_tax_report_payg_w2_tag itself, as already done in the new report expressions.
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/l10n_au/data/bas_a.xml#L386 https://github.com/odoo/odoo/commit/2c9ab8e77db7aa127a259f7f3e06ecfed94252ab

Why is this fix needed?

This aggregate expression creates issues during the tax_to_invert upgrade process. Since the sign conversion is handled through a separate expression, the upgrade query is unable to correctly identify the actual expression sign, which leads to incorrect computations during migration.

Related PR: https://github.com/odoo/upgrade/pull/10162

- OPW: 6097598

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

Currently, the field `l10n_co_edi_ubl` is displayed without a label 
in the UoM form, confusing users.

**Steps to reproduce:**
- Install the `l10n_co_edi` module and switch to the CO Company.
- Navigate to Invoicing > Settings.
- Enable `Units of Measure & Packagings`.
- Open `Units & Packagings` and click `New`.

**Observation:**
The `l10n_co_edi_ubl` field appears between the `Quantity` label and 
its corresponding field, but its own label is not visible.

<img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" />


**Root Cause:**
The inherited view [1] inserts the field `l10n_co_edi_ubl` before 
`relative_factor` in the base view [2].

In the base view, `relative_factor` is wrapped inside a `<div>` with a 
shared label (`Quantity`). Since the new field is inserted inside this 
structure, it inherits the same layout without having its own label, 
resulting in the label being hidden.

**Fix:**
This commit updates the view to ensure that the field `l10n_co_edi_ubl` 
is properly displayed with its own label, avoiding UI confusion and 
improving form clarity.

**After:**
<img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" />

[1]:
https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13

[2]:
https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34

opw-6180769

Forward-Port-Of: odoo/enterprise#115933

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/a8493394cc [REL] 19.1.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/e267f5db92 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1d4311e3d2 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/dfff07841c [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/2e87404919 [FIX] workflow: Split the workflow in parallel jobs [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>

In odoo/enterprise#106192, we have modified the function userPermissionViewOnly that was preventing the user from editing document he cannot: we have removed the condition preventing user to edit protected document (mainly folder at the company root). That was an error as even if the user has "edit" access (which is ensured in that method), the document can still be protected and the form to edit it should be in readonly then. We ensure here that the form in the details panel is in readonly in that case.

How to reproduce:
- log as demo and go to Document
- Click on Inbox folder
- Open details panel
- Change for example the contact of the document
You get an error while you shouldn't be able to edit it (as the folder is protected).

Technical note: we re-add the condition in the method userPermissionViewOnly:
(!this.documentService.userIsDocumentManager
&& this.record.data?.user_folder_id === "COMPANY")
that we slightly modify to limit the protected document to folder only:
(!this.documentService.userIsDocumentManager
&& this.record.data?.user_folder_id === "COMPANY"
&& this.record.data?.type === "folder")

Task-5881531

Forward-Port-Of: odoo/enterprise#116709

When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.

Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me

Observed Behavior:
All the documents are fetched.

Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.

Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown

From:
`('need_my_signature', '=', True)]`

To:
`[('need_my_signature', 'in', [True])]`

This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.

As a result, instead of filtering documents, all documents are returned.

[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108

[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177

Fix:
Corrected the return domain logic to fetch the correct documents.

opw-6026935

Forward-Port-Of: odoo/enterprise#113760

__
## Short functional explanation of the error
When creating a Purchase Order. We add a line containing a product
that has an analytic distribution. After setting a project on this PO,
when we add another line containing the same product, the analytic
distribution of the product isn't added anymore, only leaving it with
the analytic distribution of the project.

## Reproduction Steps
1. Go to settings and enable Analytic Accounting.
2. Go to Accounting > Configuration > Analytic Distribution model.
Create a model with a product (prd) you remember, and add an analytic
distribution (ad).
3. Go to Project. On a given project (p), select the Hamburger menu and
click Settings. Then, in the Settings tab, under Analytic, make sure
the Project field is filled.
4. Create a new Purchase Order. Select a vendor and add a line with the
product (prd). On the top right of the Form, click on the view button
and select Analytic Distribution to show it on the form.
There, we should see the product (prd) with its corresponding Analytic
Distribution (ad) on the form.
5. Click on the Other Information tab and select the project (p).
Click on the Product tab. There, under Analytic Distribution field,
you should see (ad) and the Analytic Distribution of the project (p).
6. Click on save and add another line with the exact same product.


### Expected behavior
Under Analytic Distribution, we should see (ad) and the Analytic
Distribution of the project (p), as for the first order line

### Unexpected behavior
Under Analytic Distribution, we only see the Analytic  Distribution of
 the project (p).


## Origin of the issue
When we add another line, we trigger the compute method of the
Analytic Distribution. However, due to this piece of code:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/project_purchase/models/purchase_order_line.py#L14
when we create a new order line, we never compute its analytic
distribution: `self` will contain only `project_lines`, and
`empty_project_lines` is empty as well. Therefore, we call the super
 method with nothing, so when we get in the
super method:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/purchase/models/purchase_order_line.py#L249-L259
we never compute the analytic distribution of the newly created line.

This piece of code was added in this commit:
https://github.com/odoo/odoo/commit/c1ea8446259bd3338c004e88d48ad77ded7ef2ae
to fix the issue that when a user enters manually an analytic
distribution, this entry will be lost when triggering the compute of
the analytic distribution.

However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic 
distribution, as it is much harder to add it again after its removal. 
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.
__
opw-6063418

Forward-Port-Of: odoo/odoo#257558

## The Problem
During the initialization of `stock_account`, the logic creating `product.value` instances triggered cache misses on `product.product`, accessing fields (`company_id` and `standard_price`) inside `_create_product_value`, and field `uom_id` inside `_run_fifo_get_stack`. Due to prefetching, this loaded all product data into memory, causing significant memory usage on large databases.

## The Solution
Disabled prefetching in the full flow.

Didn't go with fetching only the needed fields instead of disabling for two main reasons:
- Field `standard_price` accessed in the loop is company dependent, so it needs to be fetched inside, which would be a bit verbose.
- Fetching `company_id` outside the loop, `standard_price` inside the loop, and `uom_id` which is accessed down the stack in the `.create` call on `product.value` won't be an explicit/robust solution for the long term.

---

## Benchmarks
*Tested on a SaaS database with 500k products:*

| | Before | After | Note |
| :--- | :--- | :--- |  :--- |
| **Memory** | 3.6GB | 1.6GB | **-55%** (fits in memory limit) |
| **Time** | 10m | 11m | **+10%** (acceptable tradeoff) |

**OPW-6173153**

Forward-Port-Of: odoo/odoo#262702

Steps to reproduce
------------------
1. Create a sale order with 2 products, confirm it
2. Cancel the SO, then click "Set to Quotation"
3. Open PoS, settle the order and pay
4. Check the delivery order linked to the PoS order

The delivery is empty, yet the products still show as "delivered" on
the sale order.

Why it's happening
------------------
When the SO is cancelled, its moves go to 'cancel' state. After
resetting to quotation, those moves stay cancelled. When PoS creates
the delivery, the filter in `_create_move_from_pos_order_lines` checks
`has_valued_move_ids()` which returns False (all moves are cancelled),
and `not move_ids` is also False (cancelled moves still exist). So the
lines coming from the SO are excluded from the delivery.

The fix
-------
We now also create deliveries for lines whose SO moves are all
cancelled. These are lines coming from a cancelled SO that now need
to be shipped after we have settled their order from PoS.

Note
----
The commit c0f338711f028088c98ea459f27c1669b29738d7 fixes this starting from saas-18.2, by introducing a separate `pos_repair` module which simplifies the main `pos_sale` code. In 18.2+, only the test will be forward ported.

opw-6055856

Forward-Port-Of: odoo/odoo#263593
Forward-Port-Of: odoo/odoo#256693

Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377).

In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`).

When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass.

In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors.

To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present.

runbot-error-id~242235

**Steps to reproduce:**

Problem A)
- create a storable product avco perpetual
- add 2 unit in stock and set a cost of 10
- set the invoicing policy as "delivered quantities"
- create and confirm a SO for 2 quantities
- validate the delivery
- click on "Create Invoice" and confirm the invoice
- from the delivery, create and validate a return for 1 unit.
- from the product form, change the cost to 15
- from the sale order, click on "Create Invoice"
- confirm the Credit Note

Problem B)
- create a storable product with fifo perpetual
- confirm a PO for 1 unit at 10 and validate receive
- confirm a PO for 1 unit at 20 and validate receive
- confirm a PO for 1 unit at 60 and validate receive
- create a SO for 3 unit
- deliver 1 unit with backorder
- deliver another unit with backorder
- deliver the last unit
- create and confirm invoice
- return the second delivery
- from the invoice click on 'credit note' and validate
the credit note with a quantity of 1

**Current behavior:**

Problem A)
the cogs is 25

Problem B)
the cogs is 30

**Expected behavior:**

Problem A)
it should be 10

Problem B)
the cogs should be 20 cause the move returned
had a value of 20

**Cause of the issue:**
Inside \_get\_cogs_value(), if there is an original invoice
linked to the credit note we take the unit_price from this invoice.
But, if the credit note is not created from the invoice (via the
Credit Note button) but via the sale order (via create invoices),
the account\_move has no reverse\_entry_id so we won't
use the price_unit from the original line.
https://github.com/odoo/odoo/blob/686a0cf67bb1e818baf43309fc94f3f0462097ed/addons/stock_account/models/account_move_line.py#L56-L58
So basically what we do for now is:
If the credit note was created from invoice we use
the unit price from original invoice in all cases.
If the credit note was created from sale order we
use get\_price\_unit in all cases (which will work for
fifo because we'll use the value of the returned
move but fail for avco if the standard price has
changed cause we use the standard price)
https://github.com/odoo/odoo/blob/dccd2256660b1e211707b740074f5fbba95ae149/addons/stock_account/models/stock_move.py#L261-L265

**Fix:**
Regardless of how the credit note is created, if
it's fifo we use get\_price\_unit to adapt to the value
of the moves, if not we use the unit_price from
original invoice

opw-6097090

Forward-Port-Of: odoo/odoo#259630

**Description of the problem**
Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left.

**How to reproduce**
In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown.

**Why the problem happens**
1. Traceback when backspace is pressed
`LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash.
2. No deletion of the character to the left of the cursor
`DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp.

**Fix**
1. Prevent the crash in `LinkPlugin`
`LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns.
2. Fix backspace behavior in `DeletePlugin`
`deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left.

task-6102282

Forward-Port-Of: odoo/odoo#258858

We do not need this extra aggregate expression.

The purpose of this aggregate expression is only
to invert the sign of the computation returned by
the expression account_tax_report_payg_w2_tag. Instead of doing the sign inversion through a separate aggregate expression, we can directly include the negative (-) sign in account_tax_report_payg_w2_tag itself, as already done in the new report expressions.
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/l10n_au/data/bas_a.xml#L386 https://github.com/odoo/odoo/commit/2c9ab8e77db7aa127a259f7f3e06ecfed94252ab

Why is this fix needed?

This aggregate expression creates issues during the tax_to_invert upgrade process. Since the sign conversion is handled through a separate expression, the upgrade query is unable to correctly identify the actual expression sign, which leads to incorrect computations during migration.

Related PR: https://github.com/odoo/upgrade/pull/10162

- OPW: 6097598

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

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116794
Forward-Port-Of: odoo/enterprise#113804

Steps to reproduce:
===================
1. Enable a second language on the website
2. Add a Table of Content snippet to a page
3. Apply bold (or any inline style) to one of the headings, save
4. Switch to the second language in translation mode
5. Translate the styled heading and save

=> The TOC navbar entry keeps showing the source text on reload.
=> Expected: navbar shows the translated heading text, unstyled.

Cause:
======
When a TOC heading carries inline markup, the server emits the
heading and the navbar entry as two independent translation terms
with different `data-oe-translation-source-sha` values, even though
their textContent matches. A translation written under the heading's
sha therefore never reaches the navbar's slot.

`handleToC` was meant to bridge that by aliasing the navbar span's
sha to the heading's during translation-mode setup, but two issues
prevented it from working in saas-18.4+:

- The TOC navbar lives under `.o_not_editable`, so its translation
  spans were excluded from `findOEditable` and `handleToC` never
  ran on them. The class `o_translation_without_style` was never
  added, and the sha was never aliased.

Solution:
=========
- `prepareTranslation` iterates TOC navbar translation spans
  explicitly, so `handleToC` reaches them despite `findOEditable`
  skipping `.o_not_editable`.
- `handleToC` always tags the navbar span with
  `o_translation_without_style` when a matching heading exists.
- An `after_replication_handlers` hook flags every replicated
  unstyled-translation target as `.o_dirty`, so the replicated
  translation is included in the save.

opw-5950228

Forward-Port-Of: odoo/odoo#263161
Forward-Port-Of: odoo/odoo#260378

Currently, the field `l10n_co_edi_ubl` is displayed without a label 
in the UoM form, confusing users.

**Steps to reproduce:**
- Install the `l10n_co_edi` module and switch to the CO Company.
- Navigate to Invoicing > Settings.
- Enable `Units of Measure & Packagings`.
- Open `Units & Packagings` and click `New`.

**Observation:**
The `l10n_co_edi_ubl` field appears between the `Quantity` label and 
its corresponding field, but its own label is not visible.

<img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" />


**Root Cause:**
The inherited view [1] inserts the field `l10n_co_edi_ubl` before 
`relative_factor` in the base view [2].

In the base view, `relative_factor` is wrapped inside a `<div>` with a 
shared label (`Quantity`). Since the new field is inserted inside this 
structure, it inherits the same layout without having its own label, 
resulting in the label being hidden.

**Fix:**
This commit updates the view to ensure that the field `l10n_co_edi_ubl` 
is properly displayed with its own label, avoiding UI confusion and 
improving form clarity.

**After:**
<img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" />

[1]:
https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13

[2]:
https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34

opw-6180769

Forward-Port-Of: odoo/enterprise#115933

When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.

Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me

Observed Behavior:
All the documents are fetched.

Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.

Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown

From:
`('need_my_signature', '=', True)]`

To:
`[('need_my_signature', 'in', [True])]`

This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.

As a result, instead of filtering documents, all documents are returned.

[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108

[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177

Fix:
Corrected the return domain logic to fetch the correct documents.

opw-6026935

Forward-Port-Of: odoo/enterprise#113760

Currently, the field `l10n_co_edi_ubl` is displayed without a label 
in the UoM form, confusing users.

**Steps to reproduce:**
- Install the `l10n_co_edi` module and switch to the CO Company.
- Navigate to Invoicing > Settings.
- Enable `Units of Measure & Packagings`.
- Open `Units & Packagings` and click `New`.

**Observation:**
The `l10n_co_edi_ubl` field appears between the `Quantity` label and 
its corresponding field, but its own label is not visible.

<img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" />


**Root Cause:**
The inherited view [1] inserts the field `l10n_co_edi_ubl` before 
`relative_factor` in the base view [2].

In the base view, `relative_factor` is wrapped inside a `<div>` with a 
shared label (`Quantity`). Since the new field is inserted inside this 
structure, it inherits the same layout without having its own label, 
resulting in the label being hidden.

**Fix:**
This commit updates the view to ensure that the field `l10n_co_edi_ubl` 
is properly displayed with its own label, avoiding UI confusion and 
improving form clarity.

**After:**
<img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" />

[1]:
https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13

[2]:
https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34

opw-6180769

Forward-Port-Of: odoo/enterprise#115933

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c2bb3c8379 [REL] 18.3.46 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/998f03a0d3 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5b5147ef7f [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/66808b6063 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/af50462f8c [FIX] workflow: Split the workflow in parallel jobs [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>

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#116811
Forward-Port-Of: odoo/enterprise#115046

__
## Short functional explanation of the error
When creating a Purchase Order. We add a line containing a product
that has an analytic distribution. After setting a project on this PO,
when we add another line containing the same product, the analytic
distribution of the product isn't added anymore, only leaving it with
the analytic distribution of the project.

## Reproduction Steps
1. Go to settings and enable Analytic Accounting.
2. Go to Accounting > Configuration > Analytic Distribution model.
Create a model with a product (prd) you remember, and add an analytic
distribution (ad).
3. Go to Project. On a given project (p), select the Hamburger menu and
click Settings. Then, in the Settings tab, under Analytic, make sure
the Project field is filled.
4. Create a new Purchase Order. Select a vendor and add a line with the
product (prd). On the top right of the Form, click on the view button
and select Analytic Distribution to show it on the form.
There, we should see the product (prd) with its corresponding Analytic
Distribution (ad) on the form.
5. Click on the Other Information tab and select the project (p).
Click on the Product tab. There, under Analytic Distribution field,
you should see (ad) and the Analytic Distribution of the project (p).
6. Click on save and add another line with the exact same product.


### Expected behavior
Under Analytic Distribution, we should see (ad) and the Analytic
Distribution of the project (p), as for the first order line

### Unexpected behavior
Under Analytic Distribution, we only see the Analytic  Distribution of
 the project (p).


## Origin of the issue
When we add another line, we trigger the compute method of the
Analytic Distribution. However, due to this piece of code:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/project_purchase/models/purchase_order_line.py#L14
when we create a new order line, we never compute its analytic
distribution: `self` will contain only `project_lines`, and
`empty_project_lines` is empty as well. Therefore, we call the super
 method with nothing, so when we get in the
super method:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/purchase/models/purchase_order_line.py#L249-L259
we never compute the analytic distribution of the newly created line.

This piece of code was added in this commit:
https://github.com/odoo/odoo/commit/c1ea8446259bd3338c004e88d48ad77ded7ef2ae
to fix the issue that when a user enters manually an analytic
distribution, this entry will be lost when triggering the compute of
the analytic distribution.

However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic 
distribution, as it is much harder to add it again after its removal. 
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.
__
opw-6063418

Forward-Port-Of: odoo/odoo#257558

Currently, the field `l10n_co_edi_ubl` is displayed without a label 
in the UoM form, confusing users.

**Steps to reproduce:**
- Install the `l10n_co_edi` module and switch to the CO Company.
- Navigate to Invoicing > Settings.
- Enable `Units of Measure & Packagings`.
- Open `Units & Packagings` and click `New`.

**Observation:**
The `l10n_co_edi_ubl` field appears between the `Quantity` label and 
its corresponding field, but its own label is not visible.

<img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" />


**Root Cause:**
The inherited view [1] inserts the field `l10n_co_edi_ubl` before 
`relative_factor` in the base view [2].

In the base view, `relative_factor` is wrapped inside a `<div>` with a 
shared label (`Quantity`). Since the new field is inserted inside this 
structure, it inherits the same layout without having its own label, 
resulting in the label being hidden.

**Fix:**
This commit updates the view to ensure that the field `l10n_co_edi_ubl` 
is properly displayed with its own label, avoiding UI confusion and 
improving form clarity.

**After:**
<img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" />

[1]:
https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13

[2]:
https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34

opw-6180769

Forward-Port-Of: odoo/enterprise#115933

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

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

Forward-Port-Of: odoo/enterprise#116638
Forward-Port-Of: odoo/enterprise#112879

When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.

Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me

Observed Behavior:
All the documents are fetched.

Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.

Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown

From:
`('need_my_signature', '=', True)]`

To:
`[('need_my_signature', 'in', [True])]`

This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.

As a result, instead of filtering documents, all documents are returned.

[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108

[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177

Fix:
Corrected the return domain logic to fetch the correct documents.

opw-6026935

Forward-Port-Of: odoo/enterprise#113760

Steps to reproduce:
- Install web_enterprise and im_livechat on v18
- Migrate the database to v19
- Create a new user

Issue:
- On v18 → v19 migrated databases, creating a new user may fail with a ValidationError:

   The operation cannot be completed: Missing required value for the
   field 'Color Scheme' (color_scheme).
   Model: 'User Settings' (res.users.settings)
   - create/update: a mandatory field is not set
   - delete: another model requires the record being deleted, you can archive it instead
<img width="1155" height="286" alt="image" src="https://github.com/user-attachments/assets/57ad515a-c5fd-4826-9a7b-84d70c711af7" />

Cause:
- The im_livechat module defines a computed field livechat_lang_ids https://github.com/odoo/odoo/blob/19.0/addons/im_livechat/models/res_users.py#L24 with an inverse method that may run during user creation https://github.com/odoo/odoo/blob/19.0/addons/im_livechat/models/res_users.py#L114 before the res.users.settings record exists. In that case, the inverse method attempts to create the settings record without mandatory defaults.

Fix:
- By lowering the priority of the res.users.form.color_scheme view, the color_scheme field is loaded earlier, which triggers the proper creation of res.users.settings with default values. This ensures the livechat inverse updates an existing settings record instead of creating an incomplete one.

- OPW - 5435731
- UPG - 3794624

Currently, the field `l10n_co_edi_ubl` is displayed without a label 
in the UoM form, confusing users.

**Steps to reproduce:**
- Install the `l10n_co_edi` module and switch to the CO Company.
- Navigate to Invoicing > Settings.
- Enable `Units of Measure & Packagings`.
- Open `Units & Packagings` and click `New`.

**Observation:**
The `l10n_co_edi_ubl` field appears between the `Quantity` label and 
its corresponding field, but its own label is not visible.

<img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" />


**Root Cause:**
The inherited view [1] inserts the field `l10n_co_edi_ubl` before 
`relative_factor` in the base view [2].

In the base view, `relative_factor` is wrapped inside a `<div>` with a 
shared label (`Quantity`). Since the new field is inserted inside this 
structure, it inherits the same layout without having its own label, 
resulting in the label being hidden.

**Fix:**
This commit updates the view to ensure that the field `l10n_co_edi_ubl` 
is properly displayed with its own label, avoiding UI confusion and 
improving form clarity.

**After:**
<img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" />

[1]:
https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13

[2]:
https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34

opw-6180769

Forward-Port-Of: odoo/enterprise#115933

Steps to reproduce:
===================
1. Go to the shop page and use the rental date picker to select a start and end date with hours.
2. Find a rental product configured with "Days" pricing.
3. Add to card directly from the product card
4. Add a rental product from product image that has date type value date
5. Go to that product details page.
6. Click add to cart

-> Invalid operation, You cannot mix different rental periods...

Cause:
======
When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added.

However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing).

This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page).

Solution:
=========
The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist.

opw-5450576

Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#114086
Forward-Port-Of: odoo/enterprise#98571

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/06413dab98 [REL] 18.0.67 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/533e5f08da [FIX] package: update package-lock.json [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/090f75ba4d [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/2effff1d86 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/6a24b125d4 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d86edeb9f7 [FIX] workflow: Split the workflow in parallel jobs [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>

Current behavior: 
When any account (`account.account`) has `currency_id` set, the General Ledger CSV export silently outputs only the header row with no data. No error is shown to the user.

Expected behavior: 
CSV export should include all data rows regardless of whether accounts have `currency_id` set.

Required Modules
- `account_accountant` (Accounting App)

Steps to reproduce:
1. Start with a clean database with demo data loaded and only the Accounting app installed
2. Confirm only one active currency (e.g., USD) exists — no accounts have the "Currency" field (`currency_id`) set at this point
3. Go to Accounting → Reporting → General Ledger and export as CSV — it works fine, all data rows show up
4. Go to Settings → Currencies and activate a second currency (e.g., Hong Kong Dollar). Save
5. Go to Accounting → Configuration → Chart of Accounts (refresh the page). The "Account Currency" column now appears
6. Set a currency on any account (any currency works, even USD). Save
7. Go back to General Ledger and export as CSV again
8. Open the exported CSV — only the header row is there. All data rows are gone. No error is shown to the user

Recorded video on reproducing this bug: 
https://www.loom.com/share/644f01a9f0df4230a4be4ae1f5ba79ba

Cause of the issue: 
In `csv_format_account_line()` (line 885), the code does `col['currency'].id`, assuming `col['currency']` is a recordset. However, it can already be an integer, causing `AttributeError: 'int' object has no attribute 'id'`. This error is caught upstream, resulting in a silently empty CSV.

Fix: 
Handle the case where `col['currency']` is already an `int` instead of a recordset before calling `.id`.

opw-5974207