Issue Before This Commit:
========================
Currently, when a product variant has multiple UoMs, those UoMs 
appear for all variants when selecting a product in a Sale Order Line,
even though they are only available for a specific variant.

Steps to Reproduce:
=========================
1: Install the sale and sale_management modules.
2: Enable Units of Measure and Packagings.
3: Create two variants, V1 and V2, and set an Extra Packaging of 'Pack of 6' on V2.
4: Add the product to a Sale Order Line. A product configuration wizard will open.
5: Select V2. The Unit and 'Pack of 6' UoMs are correctly displayed.
6: Select V1. Both UoMs are still displayed, even though 'Pack of 6' is not available for V1.

Cause of the issue:
=========================
When the variant is changed to V2 in the wizard, _get_basic_product_information is 
called. At that point, the condition is true, so available_uoms is updated with the UoMs available for V2.

However, when the variant is changed back from V2 to V1, the method is called again, 
but V1 does not have multiple UoMs. Therefore, product_or_template._has_multiple_uoms()
returns False, and available_uoms is not updated.

As a result, the UoMs from V2 remain in available_uoms and are incorrectly displayed for V1.

After This Commit:
========================
Update _get_basic_product_information to ensure that the available UoMs are updated
whenever the variant changes. This ensures that only the UoMs available for the 
selected variant are displayed.

Steps to reproduce:
- Send an invoice to the SPV (Romanian e-Factura).
- Once the SPV finished processing it, click "Fetch Status" on the e-Factura document.
- Odoo crashes with binascii.Error: Incorrect padding

Cause of the issue:
_request_ciusro_download_answer extracts the signature file from the SPV zip answer and re-serializes it with etree.tostring(...), which gives plain XML bytes, not base64

But _l10n_ro_edi_fetch_invoice_sent_documents and the 3 other callers that persist that signature still ran it through base64.b64decode() before wrapping it in BinaryBytes (which already expects raw bytes, not base64). Decoding real XML as base64 only "works" by accident when the XML happens to contain a number of base64-alphabet characters that's a multiple of 4 after the invalid ones get silently stripped - otherwise it blows up with "Incorrect padding".

This got introduced by 41fe2ebdb9cc (fields.Binary return BinaryValue), which flipped a base64.b64encode() call to base64.b64decode() at these 4 spots instead of just dropping the base64 call entirely. A previous fix (0750ee145ae2) already fixed the sibling issue on the invoice's own attachment_raw but missed these.

Solution:
Drop the erroneous base64.b64decode around the signature's attachment_raw at the 4 call sites, and fix the tests that were mocking attachment_raw as base64-encoded instead of raw bytes

opw-6562123

# [FIX] planning: split gantt progress bar hours per resource

Issue:
----------------------------------------
On the planning gantt view, when a shift is assigned to several resources, the progress bar of each individual resource shows the sum of all resources' allocated hours instead of that resource's own hours.

Steps to reproduce:
----------------------------------------
- Give two employees working calendars with a different number of daily hours (e.g. 8h and 4h)
- Create one shift covering both calendars' full working hours and assign both employees to it
- Open the gantt view and check the progress bar of each employee for that shift

Cause:
----------------------------------------
`_gantt_progress_bar_group_by_field()` computes one duration per shift via `_get_duration_over_period()`, which already sums the working hours of every resource assigned to the shift. That same total is then added to the progress bar of each resource.

Solution:
----------------------------------------
Add `_get_working_hours_over_period_per_resource()` and `_get_duration_over_period_per_resource()`, which returns the results into a dict per resource.

`_get_working_hours_over_period()` then calls `_get_working_hours_over_period_per_resource()` and sums the values.

`_gantt_progress_bar_group_by_field()` now calls this per-resource breakdown when grouping by `resource_ids`.

# [FIX] planning_field_service: fix break_time computation

Issue:
----------------------------------------
When adding multiple resources to a slot, we can break the

Steps to reproduce first issue:
----------------------------------------
- Create a slot for a resource working 8 hours per day
- Add another resource working 4 hours per day
- Remove the resource working 4 hours
- The allocated hours show "9h 36m" instead of 8h

Cause:
----------------------------------------
`_get_in_schedule_break_time()` can return negative values, so it breaks the computation of `allocated_percentage` which then impacts the future allocated percentages.

Solution:
----------------------------------------
Add a `max(..., 0)` to `_get_in_schedule_break_time()`.

Steps to reproduce second issue:
----------------------------------------
- Create a slot for a resource working 8 hours per day
- Add another resource working 4 hours per day
- The break time is 0, it should be 4h

Cause:
----------------------------------------
The calculation of `break_time` with multiple resources was supposed to be fixed in 583ccb226970787b9dbd4cb03ccbfd43849fb8c7 but the value is never used.

Using it fixes the case for multiple resources having the same work schedule but not all case:
In our case it will output 12 allocated hours and 2 hours of breaktime instead of 4. This is because the breaktime hours are only from one resources but they still get divided by the number of resources.

Solution:
----------------------------------------
We should instead multiply the duration by the number of resources to get the correct number of break hours. This ensures that `allocated_hours + break_time` equals the total duration of the shift.

Same in `_get_in_schedule_break_time()`.

opw-6500685

Forward-Port-Of: odoo/enterprise#130429

Currently, when the user re-reserves a component and produces an MO for a lot-tracked product, putaway rules stop working.

## Steps to produce:
- Install the Manufacturing application.
- Go to Settings and enable Lots & Serial Numbers and Storage Locations.
- Create a product named 'Laptop' and set it to be tracked by Lots.
- Create a product named 'Graphics card' with some quantity on hand.
- Create a Bill of Materials (BoM) for the Laptop with Graphics card as a component.
- Create a location named 'Laptop Shelf' with 'WH/Stock' as its parent location.
- Create a putaway rule:
  - When a product arrives in: WH/Stock
  - Product: Laptop
  - Store to: WH/Stock/Laptop Shelf
- Create and confirm a Manufacturing Order (MO) for the Laptop.
- Unreserve the components, open Details, and re-add the Graphics card.
- Click Produce All and check the on-hand quantity list view of the Laptop.

## Issue:
The Laptop is stored in WH/Stock instead of WH/Stock/Laptop Shelf.

## Root cause:
When the user presses the unreserve button the finished move is passed to `_do_unreserve`
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L2407

which unlinks all the move lines on finished product moves if they are not picked:
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L1043

Now when the user presses the Produce All button, `button_mark_done` is called, which calls `_post_inventory` at:
https://github.com/odoo/odoo/blob/a51ca77c825d2dba326dd540e2b4c04ef6c2385d/addons/mrp/models/mrp_production.py#L2236

`_post_inventory` assigns `lot_ids` to the finished product moves at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L1928-L1930

This calls `_set_lot_ids` which creates a move line with quantity 1 at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L679-L683

After that, `_post_inventory` sets the quantity for the finished product moves at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L1935

Which calls `_set_quantity` and the  delta quantity is now zero at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L477-L483

Because `_set_lot_ids` has already created a move line that satisfies the move quantity, `_process_increase` is not called.

Since `_process_increase` is not called, `_set_quantity_done` is never called at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L463-L465

Since `_set_quantity_done` is not called, `_apply_putaway_strategy` is never called within that function at:
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L2565

As a result, the laptop ends up in stock instead of on the shelf.

This issue did not occur in lower versions because the feature to produce multiple lots was introduced in version 19.0 by the following commit: https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e

Before this commit, only `_set_quantity` was called. Since no move line was created because lot_ids were not set in `_post_inventory`, `_process_increase` was called, which then called `_apply_putaway_strategy`, so the putaway rules were applied correctly.

## Solution:
Apply putaway rules in the post-inventory function after the user manufactures a product, ensuring the items are placed in the correct locations and preventing products from being misplaced even when putaway rules are defined.

opw-6517324

Forward-Port-Of: odoo/odoo#288442
Forward-Port-Of: odoo/odoo#287390

## Problem

When rendering PDF invoices that contain **section** or **note** lines, the `l10n_gcc_invoice.arabic_english_invoice` QWeb template raises:

```
TypeError: argument of type 'bool' is not iterable
```

This happens because `account.move.line` records of type `line_section` or `line_note` have `name = False`. The template evaluates `arabic_name not in line.name` (and the same for `english_name`), which fails because Python cannot apply the `in` operator on a boolean value.

## Fix

Add a `line.name and` guard before each `not in` check:

```xml
<!-- Before -->
<span t-if="arabic_name not in line.name" .../>
<span t-if="(english_name != arabic_name) and (english_name not in line.name)" .../>

<!-- After -->
<span t-if="line.name and arabic_name not in line.name" .../>
<span t-if="line.name and (english_name != arabic_name) and (english_name not in line.name)" .../>
```

## Steps to reproduce

1. Install `l10n_gcc_invoice` on an Odoo 16.0 instance.
2. Create a customer invoice and add a **Section** line.
3. Print/preview the invoice PDF.
4. Observe `Internal Server Error` / `TypeError: argument of type 'bool' is not iterable`.

Forward-Port-Of: odoo/odoo#278887
Forward-Port-Of: odoo/odoo#267147

Opening a view whose search panel has a `select="multi"` field of type many2many crashes when a record is only linked to comodel records the user cannot see:

  File "/addons/web/models/models.py", line 1496, in
  _search_panel_domain_image id_, display_name =
  group_id_name(group[field_name]) TypeError: cannot unpack non-iterable
  bool object

Steps to reproduce:
- On a db with Social Marketing installed, social accounts are automatically created per website
- Open Social Marketing > Posts
- Create a new Post with an social account
- Open Settings > Social Accounts > the chosen social account
- Archive it
- Get back to the Post created above => crash

`_search_panel_domain_image` restricts the domain with `(field_name, '!=', False)`, which is evaluated on the comodel with sudo and active_test=False, while the group by of the same query joins the comodel through `_search`, which applies record rules and active_test. A record whose values are all archived or hidden by a record rule therefore passes the condition but ends up in a group with no value, which the image loop unpacks as a tuple.

This commit skips those groups: their values have no place in the range anyway.

Seen on runbot, where `runbot.build.error.trigger_ids` points at `runbot.trigger` records that are archived or restricted by the project group rule.

Forward-Port-Of: odoo/odoo#288503

### Issue:
When a bank account is manually set on a bill for a partner with multiple bank accounts, using the Auto-Complete feature could reset the manual selection even without a currency change

### Cause:
When `invoice_vendor_bill_id` is set, an onchange assigns `currency_id` unconditionally, even when it is the same value
This triggers `_compute_partner_bank_id`, which always recomputes the best matching bank account from scratch without considering the currently set value
If the currency did not change, this recompute is unnecessary and silently overrides the manual selection

### Steps to reproduce:
- Install `account`
- Create a Vendor with 2 bank accounts (keep default values to have equal priority on all accounts)
- Create and post a Bill for this vendor with at least one line
- Create a new Bill for the same vendor
- Set the Recipient Bank to the second account in the list
- In Auto-Complete, select the first Bill
 
Before the fix, the Recipient Bank is reset to the first account

opw-6210414

Forward-Port-Of: odoo/odoo#288386
Forward-Port-Of: odoo/odoo#283479

## Description of the issue

When an Argentinian invoice contains advance-payment deduction lines that exactly cancel the product lines (net taxable base = 0 for a given VAT aliquot), the invoice is rejected by the ARCA (AFIP) WSFE web service with:

> **Error 10018**: "Si ImpIva es igual a 0 el objeto Iva y AlicIva son obligatorios. Id iva = 3 (iva 0)"

This is the standard "100% down payment" flow: the customer is invoiced an advance for the full amount, and the final invoice deducts that advance, resulting in a $0 invoice that must still be validated against ARCA.

This is a forward-port to 19.0 of #270846 (same fix, targeted at 18.0, closed unmerged). The bug is still present in 19.0: `_get_vat()` in `addons/l10n_ar/models/account_move.py` evaluates its filter on the raw unrounded aggregated floats.

## Steps to reproduce

1. On a company with the Argentinian localization (`l10n_ar_edi`) configured for electronic invoicing (WSFE), create a sale order with one or more product lines taxed at IVA 21% (e.g. total $121,000).
2. Create a **down payment invoice for 100%** of the order and validate it against ARCA (this one succeeds).
3. Create the final invoice from the sale order: it contains the product lines (positive) and the down-payment deduction line (negative), both at IVA 21%. Total to pay: **$0.00**.
4. Confirm the invoice and send it to ARCA.
5. **Current behavior (bug):** ARCA rejects the request with error 10018. Inspecting the generated WSFE request shows `ImpNeto=0.0`, `ImpIVA=0.0`, `ImpTotal=0.0` and an `Iva` block containing an all-zero aliquot, e.g. `{'AlicIva': [{'Id': '5', 'BaseImp': 0.0, 'Importe': 0.0}]}` — instead of `Iva: null`.
6. **Expected behavior (after fix):** no zero-amount aliquot is sent (`Iva` is `null`) and ARCA approves the $0 invoice.

## Root cause

In `_get_vat()`, the positive product lines and the negative down-payment deduction line share the same VAT aliquot, so the aggregation by `vat_afip_code` nets the group to zero. However, floating-point accumulation in the aggregated tax details leaves a tiny residual (~1e-12) in `base_amount_currency` / `tax_amount_currency`. The filter condition checks the **raw unrounded** values:

```python
if grouping_key['vat_afip_code'] not in (False, '0', '1', '2') and (values['base_amount_currency'] or values['tax_amount_currency']):
```

The ~1e-12 residual is truthy in Python, so the aliquot entry is kept — even though both `BaseImp` and `Importe` are rounded to `0.00` two lines below when building the entry. The WSFE request therefore carries a non-null `Iva` block with all-zero amounts, which ARCA rejects with error 10018.

## Fix

Round `BaseImp` and `Importe` to 2 decimals **before** evaluating the filter condition, so an aliquot whose amounts cancel out is excluded from the `Iva` array (the same rounded values are then reused when building the entry, keeping the sent amounts unchanged for every other case):

```python
base_imp = float_round(amount_sign * values['base_amount_currency'], precision_digits=2)
importe = float_round(amount_sign * values['tax_amount_currency'], precision_digits=2)
if grouping_key['vat_afip_code'] not in (False, '0', '1', '2') and (base_imp or importe):
```

Behavior is unchanged for every invoice whose aliquots round to a non-zero base or tax amount.

---

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

Forward-Port-Of: odoo/odoo#286005

Steps to reproduce:
- Colombian company with DIAN electronic invoicing enabled in PoS
- On the company contact, set more than one obligation type (e.g. O-13, O-15 and O-23)
- Open a PoS session, sell a product and pay

Issue:
The order fails to sync with "Expected singleton:
l10n_co_edi.type_code(x, y, z)" as soon as the DIAN document is accepted, and the receipt cannot be printed. On 18.0 to saas-19.1 the same crash happens when the receipt data is generated for printing.

Cause:
`_compute_l10n_co_edi_pos_receipt_data` fills
`obligation_type_description` by reading `description` directly on `l10n_co_edi_obligation_type_ids`, which is a many2many. The read only works when the company carries exactly one obligation type, while a Colombian company commonly has several (they are all sent to the DIAN in `TaxLevelCode`).

Fix:
Join the descriptions of all obligation types, the same way the DIAN invoice PDF report already does.

opw-6576523

Forward-Port-Of: odoo/enterprise#131747

**Steps to reproduce:**
1. Upload a vendor bill with OCR digitization (pdf in ticket attachments)
2. Make sure the Bill Date field already has a value
3. Click into the Bill Date field so the OCR boxes appear on the attachment preview
4. Click on a different date box in the attachment to correct the value

**Issue:**
The field is not updated with the clicked box's value. Instead, the field simply loses focus and the OCR boxes disappear, as if the user had clicked outside the field. This only happens when the date field already has a value; it works fine when the field is empty.

**Cause:**
- When a date field has a value, the date widget renders it as a button and only swaps in the real `<input>` once focused [1]
- Removing the button triggers `onBlurFieldWidget`, and when the datepicker is focused, it triggers `onFocusFieldWidget` once again:
https://github.com/odoo/odoo/blob/89650a5f44b5835028dba57a9ff6fa30515bc5ec/addons/web/static/src/views/fields/datetime/datetime_field.js#L204-L214
- The datetime picker's popover uses `useClickAway`, which reacts to `pointerdown` on `window` to detect clicks outside itself and close the popover.
- Clicking a box in the attachment preview is therefore caught by this listener before anything else: it closes the popover, removing the currently focused DOM node and firing a `focusout`.
- `ExtractMixinFormRenderer` reacted to that `focusout` by resetting the active field and destroying the box overlay. Since the box's own value-selection ran on `click`, the last event in the `pointerdown → mousedown → mouseup → click` sequence, the reset had already been done, so the click was lost.

**Fix:**
- Apply the box's selection on `pointerdown` instead of `click`, so it runs synchronously in the same event dispatch that triggers the popover's close logic, guaranteeing it executes before any asynchronous re-render can remove the field's state.
- Remove the legacy `pointerdown` listener in `ExtractMixinFormRenderer.`. Because our box now listens to `pointerdown`, it was intercepting the event and breaking selection for images

[1] - https://github.com/odoo/odoo/pull/218387

opw-6511803

Forward-Port-Of: odoo/enterprise#130192

## Description

Changing an employee version's working schedule recomputes the internal dates of subsequent time off requests.

The `hr.leave` write override then mirrors these recomputed UTC values back to the request dates. For timezones ahead of UTC, midnight on a non-working day can therefore shift the requested date to the previous day.

This fix marks the schedule-triggered re-computation as an internal fast update, ensuring that the dates selected on the time off request remain the source of truth while still allowing the leave duration to be recomputed according to the new working schedule.

Regression coverage is added to ensure that changing an employee's working schedule:

* preserves the dates selected on existing time off requests;
* correctly recomputes the leave duration according to the new schedule.

## Steps to reproduce

1. Create an employee with timezone Europe/Brussels and a Monday–Friday working schedule. Before creating any leave, set the employment record’s effective date and contract start date to 3 March 2025.
2. Create a full-day time off request from 23 to 26 February 2026. Its duration is initially four working days.
3. Change only the employee’s working schedule to a duration-based Tuesday–Friday schedule, with 7.6 hours per working day and Monday off. Leave the effective date and contract dates unchanged, then save.

**Before the fix:** the request’s start date incorrectly shifts to 22 February.

**After the fix:** the dates remain 23–26 February, while the duration correctly decreases to three working days.

opw-6456107

Forward-Port-Of: odoo/odoo#281385

Steps to reproduce:
------------------------------------
1. Install Time off module
2. Create New Fully Flexible Employee
3. Click on the Time off smart button
4. Create time off for multiple days (eg. Mon - Friday)

Observation:
------------------------------------
Number of days still shows 1 Days.

Issue:
------------------------------------
Issue occurs because `work_time_per_day_mapped` returns one interval per day for
standard and flexible schedules in multi-day time off requests, so the interval
count correctly matches the number of leave days.
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/hr_holidays/models/hr_leave.py#L460-L461

However, for fully flexible schedules, it returns a single interval
containing the total hours across all days, causing the leave duration to
always be computed as 1 day regardless of the actual number of days requested.

Solution:
------------------------------------
For fully flexible employees, count the actual calendar days and subtract public
holidays when applicable.

opw-6060552

Forward-Port-Of: odoo/odoo#255826

*= sale_purchase_inter_company_rules

Step to reproduce:
- install `sale_purchase_stock_inter_company_rules` and pos with demo
- from setting :
       - enable Multi-Step Routes
       - enable all options for Inter-Company Transactions (for both companies)
- go to routes, un-archive MTO route
- create a product "A" with routes "MTO" and "buy"
- make the product available for pos (add into `Misc` category)
- create a attribute with custom attribute value and link it to "A"
- in vendor list, add "My Company (Chicago)" as vendor
- switch to Chicago company,  for same product add some other vendor
- switch back to "My Company (San Francisco)"
- for pos, in setting enable "Allow Ship Later"
- open Furniture pos, create a order with Product "A"
- go to payment page and select "Ship Later" and pay
- a RFQ is created for this pos order, open and confirm it
- switch to "My Company (Chicago)"
- open sale order (remove "my quotation" filter)
- notice a quotation created from company 1, confirm it.
- open linked delivery slip

Observation:
- the delivery slip will not have description (custom value for attribute for A
is lost)

Cause:
- when preparing vals for SO for inter-company transaction from
`_prepare_sale_order_line_data` we never considered order from pos
- hence in this case, order lines never had custom attributed linked to them
- the description is computed from the attributes from SO
- SO never had them to begin with

Fix
- we introduced a method `_get_pcavs_from_pos_order` which fetch such attributes from pos order too
- to accomplish this we introduce a new module  As there is no dependency with purchase and pos

opw-6213076

Forward-Port-Of: odoo/enterprise#131626
Forward-Port-Of: odoo/enterprise#119233