Switching companies can let a contact merge bypass the check that prevents multiple users from ending up linked to the same contact.

### Steps to reproduce

1. As a user with Contact Creation rights and access to companies A and B, select company A.
2. Create two contacts with no company set and grant each portal access.
3. Select only company B.
4. Merge the contacts.

The merge succeeds and links both portal users to the surviving contact. With company A selected, the same merge is correctly rejected.

### Cause

The wizard checks that the contacts have at most one linked user in total, including archived users. However, it reads `user_ids` with the acting user's permissions. Company record rules hide both portal users when only B is selected, so the check finds none. The subsequent SQL update still moves both users' contact links to the surviving contact.

### Fix

Use `sudo()` only for this check, since it must count every user whose link the merge would move. Retain `active_test=False` to include archived users. Add a regression test covering both company selections.

opw-6586945

Forward-Port-Of: odoo/odoo#290537
Forward-Port-Of: odoo/odoo#290296

When searching for an archived bom (filer archived activated), if the main product is also archived, the search on the produt will not find the bom.

Steps to reproduce:
-------------------
* Create product AA
* Create a bom for product AA
* Archive product AA
* Products > bom
* Search for "Archived" and Product: "AA" -> It will not find the bom

Observation:
-------------
When doing the search, it will start a web_search_read ['&', ('active', '=', False), ('product_tmpl_id', 'ilike', 'AA')].

While in _search it will decide if we filter active elements: https://github.com/odoo/odoo/blob/60b5b99d569dbe183ef9c980217ccfe9bf243756/odoo/orm/models.py#L5363-L5369 In the first level since "active = False" is in the domain (for the bom) it will not add the filter. 

The _search will optimize the domain query level by level by calling optimize_full.

First the outher layer :
optimize_full (Domain '[]')> _optimize (DomainNary '&')> _optimize_step (DomainNary '&') 

Then the children [1: (active bom), 2: (product template display name)]:
_optimize>optimize_step> ...

While optimizing the second child the domain condition is: [('product_tmpl_id', 'any', [('display_name', 'ilike', 'AA')])]
Since it's a any operation, in optimize_step, it will use the _optimize_any_domain_at_level:
https://github.com/odoo/odoo/blob/16aaaafd7d314c04f39b1f633af3b5e15b46d78b/odoo/orm/domains.py#L970-L972
After doing some checks it will continue to optimize per level with the related comodel:
https://github.com/odoo/odoo/blob/60b5b99d569dbe183ef9c980217ccfe9bf243756/odoo/orm/domains.py#L1389-L1393
Since it's an "any" operator it need to respect the following guidelines : https://github.com/odoo/odoo/blob/60b5b99d569dbe183ef9c980217ccfe9bf243756/odoo/orm/domains.py#L98-L101 
this is no done in `_optimize_any_domain_at_level` since it resolves a relational field's 'any' domain by looking up a fresh comodel recordset without adjusting its context. 

Which means that for the following level, on the product template, the active_name is not on the domain anymore and the context was not passed corretly, so _search will automaticly add the filter ("active = True").

opw-6514762

Forward-Port-Of: odoo/odoo#290380
Forward-Port-Of: odoo/odoo#285942

**Problem:**
When modifying the start time of an all-day Calendar Event created from the Validation of a Time Off Request, the end time will be shortened dramatically, no longer spanning the correct timespan. In the case of the ticket referred to below, this occurs during Google Calendar sync.

**Cause:**
When a Calendar Event is created from a Time Off Request being Validated, its duration is set according to the amount of days the Time Off Request spans multiplied by the employee's daily work hours as defined on their contract, even if the Calendar Event will be an all-day event. When the start time of a Calendar Event is modified, the end time is recomputed according to the duration added to the new start time. As such, if the duration of the Event does not match the duration of the dates covered, it will be shortened dramatically.

**Purpose:**
Modify the values defined when creating a Calendar Event as a result of a Validated Time Off Request so that, if the created Event will be an all day Event, the duration is computed according to `calendar.event._get_duration`.

**Steps to Reproduce in Runbot:**
1. Create and Validate a Time Off Request of the Paid Time Off leave type spanning multiple days.
2. Modify the start time of the Calendar Event that is created as a result of the validation. (This step will likely require a nonstandard flow as the start time field is normally hidden for all-day Calendar Events)

opw-6426586

Forward-Port-Of: odoo/odoo#290315
Forward-Port-Of: odoo/odoo#284552

Steps to reproduce:
- Add a product to a draft order, do not pay
- Open the same PoS in a second tab of the same browser (the first tab is sent to the backend), or reload while a draft is being removed
- Pay the restored draft, then make and pay a new order

Issue:
Both orders carry the same pos_reference (e.g. 264-3-000701). The number is printed on both receipts and sent to fiscal integrations that use it as the unique invoice number.

Cause:
The receipt number is issued client side by DeviceIdentifierSequence, a per-device counter kept in localStorage that all tabs of a browser share. When a draft is removed, its number is pushed on `unsynced_number_stack` to be reused by the next order.

`removeOrder` pushes the number synchronously, then deletes the order from IndexedDB without waiting for the transaction. If the page unloads before it commits (the tab is closed by another tab opening the same PoS, a redirect to the backend, a reload), the next load restores the draft from IndexedDB with its number while the stack hands that same number to the next new order. Both are then created on the server with different uuids and the same pos_reference: the server only deduplicates by uuid.

Fix:
Recycle the number only once the order is gone from IndexedDB. A new `recycleOrderNumber` helper waits on the deletion of the order before calling `saveUnusedNumber`; `removeOrder` uses it after `localDeleteCascade`. `deleteOrders` awaits the recycling so that a delete followed by a new order still reuses the freed number, as before.

opw-6558992

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

Forward-Port-Of: odoo/odoo#290305
Forward-Port-Of: odoo/odoo#287667

Description of the issue/feature this PR addresses:
    
The Google Merchant Center feed builds the extra image URL list of each product, and must skip the `product.image` records holding a video, as their image is only a thumbnail of that video. It filters those out by accessing `image_128`, which is wrong on two counts:
    
- A video record does have an `image_128`: the thumbnail, fetched from the video URL or uploaded by the user. Video thumbnails were therefore listed in the feed as if they were product images.
- Binary fields are read and base64-encoded in full by default, so the binary content of every extra product image was loaded into memory just to evaluate a truthiness check. On a database with ~4261 products with images, rendering the feed exhausts the worker memory limit and raises an out-of-memory error.
    
Current behavior before PR:
    
`_get_extra_image_1920_urls()` keeps every extra image whose `image_128` is set, including video thumbnails, and forces the ORM to fetch and base64-encode the full content of every extra image attachment.
    
<img width="2038" height="1462" alt="image" src="https://github.com/user-attachments/assets/e3b375e5-ac17-4b5c-b0c3-59264d7e36f7"/>
    
Desired behavior after PR is merged:
    
The records are filtered on `video_url`, the field that actually flags a video, so videos are properly excluded and no image binary is read at all.

opw-6513194

Forward-Port-Of: odoo/odoo#288323
Forward-Port-Of: odoo/odoo#286782

Closing a session fails with an unbalanced journal entry when it holds the refund of an order whose global discount falls on a specific rounding.

Steps to reproduce:
- configure a 20% tax and sell 2 x 2.12 in the PoS
- apply a 10% global discount, pay the order, then refund it
- close the session

The tax of the discount line cannot be recomputed from its price: the UI splits the rounded tax included amount, 0.51 here, into 0.42 of base and 0.09 of tax, where 0.42 taxed at 20% would give 0.08. It pins both amounts in 'extra_tax_data' with the quantity they were computed for, and they are used again only if the line still matches that snapshot. Refund orders reverse that quantity, so the discount line the UI builds for them no longer matches and its taxes are computed again.

Reverse those amounts only when the quantity they were computed for has the opposite sign to the one now used. Refunds made with "Return Products" copy the line with its quantity already negated, so reversing them as well would break those instead.

opw-6533657

Forward-Port-Of: odoo/odoo#289735
Forward-Port-Of: odoo/odoo#288573

The Time Off Ledger report shows the same "Expected Hours" value for every working day of an employee, even when their working schedule assigns different hours to different weekdays.

### Steps to reproduce:
1) Install hr_holidays_attendance.
2) Create/assign a working schedule where daily hours vary across the
   week (e.g. Monday-Thursday 8.5h, Friday 5h).
3) Go to Attendance > Reporting > Time Off Ledger, filter on that
   employee.

### Observed behavior:
"Expected Hours" is identical on every day (the schedule's average hours/day), regardless of which weekday the row is for.

### Expected behavior:
"Expected Hours" should match the hours actually scheduled for that specific weekday, so a shorter Friday shows less than a full Monday.

### Root cause:
`Time off Ledger` is a SQL view.
Its `_select()` builds `expected_hours` from `rc.hours_per_day` at [1], i.e. `resource.calendar.hours_per_day`, a field explicitly labelled **"Average Hour per Day"** and is computed via [_get_hours_per_day] as `hours_per_week / days_per_week`,
a single flat value for the whole calendar.

The per-weekday hours are available in `resource.calendar.attendance` it stores `dayofweek`, `hour_from`/`hour_to` and a computed `duration_hours` per line, and can legitimately differ per weekday (e.g. Monday 8h vs Friday 4h) at [2]. The report's own [_cte_cal_workday()] CTE already reads this table to decide whether a weekday is a working day (`cal_workday`, joined as `cw` in `_from()`), but discarded the actual hours, keeping only `(calendar_id, dayofweek)`. `_select()` then fell back to the calendar-wide average via `rc.hours_per_day` instead of the per-day value.

Example: calendar with Monday 8h and Tuesday 4h -> `hours_per_day` averages to 6h; the report showed 6h on both Monday and Tuesday instead of 8h and 4h respectively.

[1]- https://github.com/odoo/odoo/blob/5568f6e472e2e53bc2931e744421015b0f0f3550/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L256

[_get_hours_per_day]: https://github.com/odoo/odoo/blob/5568f6e472e2e53bc2931e744421015b0f0f3550/addons/resource/models/resource_calendar.py#L703-L707

[2]- https://github.com/odoo/odoo/blob/5568f6e472e2e53bc2931e744421015b0f0f3550/addons/resource/models/resource_calendar_attendance.py#L15-L31

[_cte_cal_workday()]: https://github.com/odoo/odoo/blob/5568f6e472e2e53bc2931e744421015b0f0f3550/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L82-L89

### Fix:
`_cte_cal_workday()` now aggregates `SUM(duration_hours)` per `(calendar_id, dayofweek)` from `resource_calendar_attendance`, instead of just selecting the distinct keys. `_select()` reads this per-weekday value (`cw.hours_per_day`) instead of the calendar-wide `rc.hours_per_day` for both `expected_hours` and `difference_hours`.

**opw-6425167**

Forward-Port-Of: odoo/odoo#289034
Forward-Port-Of: odoo/odoo#280664

When the VAT of an Ecuadorian company's partner contains characters other
than decimal digits, confirming an invoice raises a traceback.

Steps to reproduce the error:
- Install ``l10n_ec_edi`` module and switch to EC Company
- Open the partner of EC Company > Set a VAT containing non-digit characters
- Create a new invoice > fill the required fields > Confirm

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'E'
```

During invoice confirmation, ``_l10n_ec_set_authorization_number()`` method is
called to generate the authorization number at [1],
It builds the ``key_value`` using the vat of company's partner at [2].
The generated ``key_value`` is then passed to ``_l10n_ec_get_check_digit`` method,
which converts each character of ``key_value`` to an integer using ``int()`` at below line.
https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L830
When the VAT contains a character that cannot be converted to an integer,
It will raises the above traceback.

To build the ``key_value``, the company's partner vat should be RUC consisting of 13 digits.
Ref: https://www.sri.gob.ec/o/sri-portlet-biblioteca-alfresco-internet/descargar/fb95cafc-a8ca-4a4c-afb6-12c4153165f0/FICHA%2520TECNICA%2520COMPROBANTES%2520ELECTR%25C3%2593NICOS%2520ESQUEMA%2520OFFLINE.pdf

Solution:
If the identification type of the company's partner is not RUC, return an empty string.

[1]: https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L806
[2]: https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L825-L826

sentry-7642961403

Related Community PR: https://github.com/odoo/odoo/pull/280047

Forward-Port-Of: odoo/enterprise#132478
Forward-Port-Of: odoo/enterprise#126519