The tag remapping was running in pre-migrate, before the module's data files are loaded. This caused the tag swap to be silently skipped for any new tag that didn't exist yet, and the subsequent cleanup to fail with a FK violation on account_account_account_tag.
```py
 File "/home/odoo/src/odoo/saas-19.2/odoo/sql_db.py", line 417, in execute
    self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_account_tag" violates foreign key constraint "account_account_account_tag_account_account_tag_id_fkey" on table "account_account_account_tag"
DETAIL:  Key (id)=(356) is still referenced from table "account_account_account_tag".
```

Moving to post-migrate ensures all new account tags are present in the database before the remapping and cleanup run.

upg-[4341331]

[4341331]: https://upgrade.odoo.com/odoo/upgrade.request/4341331?debug=1


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

Forward-Port-Of: odoo/odoo#269809

Steps to produce:
---
- Install the `Rental and eCommerce `modules.
- Create a rental product and configure a rental price for it.
- Add an optional product from the Sales tab.
- Publish the product on the website.
- Open the product page on the website and click` Add to Cart`.

Issue:
---
- In the product configurator, the rental price is displayed without the `/` separator between the price and the rental duration period.

Cause:
---
- The string used to generate the rental duration label does not include the `/` separator.

Fix:
---
- Add the missing `/` separator to the rental duration label so that rental prices are displayed correctly.

Before:
---
<img width="974" height="185" alt="image" src="https://github.com/user-attachments/assets/64a88a60-bcc0-4657-97fd-584da57d0aff" />

After:
---
<img width="967" height="188" alt="image" src="https://github.com/user-attachments/assets/b4d50019-1db4-4817-a8ce-446cc3c55df4" />


opw-6293015

Forward-Port-Of: odoo/enterprise#121246
Forward-Port-Of: odoo/enterprise#120223

Steps to reproduce:
-------------------
- Create a Purchase Order with an expected Arrival date in the past
- Confirm the Purchase Order
- Validate the receipt partially and create a backorder
- Cancel the generated backorder
- Open the Purchase Orders list and check the 'Late Receipts'

Issue:
------
The Purchase Order still appears in the 'Late Receipts' filter even
though there is no remaining receipt to process.

Cause:
------
The 'Late Receipts' filter relies on the computed search field
`is_late`:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/views/purchase_views.xml#L439

The search domain for this field is generated by
`purchase.order._search_is_late()`:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/models/purchase_order.py#L176

In `purchase_stock`, `_get_domain_is_late()` extends the base domain to
identify Purchase Orders that still have receipts pending:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase_stock/models/purchase_order.py#L264-L267

After a partial receipt:
- the original receipt is in state `done`,
- a backorder is created and linked to the Purchase Order,
- the backorder is later cancelled and moves to state `cancel`,
- the Purchase Order line still has `qty_received < product_qty`.

The existing domain excludes only `done` pickings when determining
whether a receipt is still pending. As a result, a cancelled backorder
is still treated as an unfinished receipt, causing the Purchase Order
to remain visible in the 'Late Receipts' filter.

Fix:
----
Exclude both `done` and `cancel` pickings when determining whether a
Purchase Order has pending receipts.

A cancelled backorder indicates that the remaining quantity will not be
received through that transfer. Therefore, once all related pickings are
either completed or cancelled, the Purchase Order should no longer be
considered late.

---
opw-6266046

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

Forward-Port-Of: odoo/odoo#268488

The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one.

### **Steps to reproduce:**
1) Install time off app.
2) Create a simple time off type.
- Create Allocation A (10 days, 01-01-2024 to 31-12-2025)
- Create Allocation B (10 days, 01-01-2025 to 31-12-2026) 
3) Create a leave of 1 day on 01-01-2026
4) Open the Balance report

### **Observed Behavior:**
The report shows 20 remaining days.

### **Expected Behavior:**
The report should show 19 remaining days (20 allocated - 1 taken).

### **Cause:**
In the taken_per_allocation CTE at [1], each leave is joined to every allocation it overlaps. The [fifo_balances] CTE then uses the formula:
```
GREATEST(alloc_days - GREATEST(taken - prior_cumulative_alloc, 0), 0)
```
This subtracts the prior allocation capacity (A = 10 days) from the taken count (B = 1 day). Since 1 - 10 = -9, GREATEST(-9, 0) = 0, so zero days are deducted from B. The formula wrongly assumes that prior allocations can absorb leaves that do not overlap with them.

[1]- https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L126-L142

[fifo_balances]: https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L145-L164

### **Fix:**
Ensure that leaves are only deducted from allocations they actually
overlap by calculating the balance using the delta of cumulative leaves
within an overlap group. This prevents earlier allocations from absorbing
leaves that occur outside their validity period.

**opw-6150161**

Forward-Port-Of: odoo/odoo#271596
Forward-Port-Of: odoo/odoo#263029

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product P with MTO buy and a set vendor
- Create and confirm a sale order for 1 unit of P
- Confirm the assocaited PO and change the pol quantity from 1 to 10
> the associated receipt is updated from 1 to 10
- Change the pol quantity from 10 to 7
#### > The quantity on the receipt is updated from 10 to 16.

### Cause of the issue:

Changing the quantity of the POL will adapt the picking related quantity via these lines:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L115-L117 https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L342-L349 by creating new stock moves to be merged:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L220-L251 Now, the issue is that this flows relies both on a negative `qty_to_attach` of `1 - 10 = -9` and a positive `qty_to_push` of `7 - 1 = 6`. However, the `qty_to_attach` is only used if is positive: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L243-L251 The receipt is therefore updated by a `+6` move to push but not by the `-9` move to attach. Leading to a 10 -> 16 rather than 10 -> 7 result.

opw-6218307

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

Forward-Port-Of: odoo/odoo#270547
Forward-Port-Of: odoo/odoo#264994

Steps to reproduce:
===================
1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates
2. Open /customers
3. Open the map and zoom in a few times

=> stale blue cluster bubbles remain on the map

Cause:
======
On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level.

`ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map,
https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation.

Solution:
=========
Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon.

opw-6128531

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

Forward-Port-Of: odoo/odoo#270733

Steps to reproduce:
1. Install CRM, Calendar, and Contacts.
2. Create a contact with an email address you can receive emails on.
3. Configure an outgoing email server.
4. Open a CRM lead and create a meeting activity using the calendar.
5. Add the created contact as an attendee of the meeting.
6. Return to the lead and click the Reschedule button on the activity.
7. Select the same meeting and change its start date to a future date.

Issue:
- Attendees receive the meeting date-change email twice.

Root cause:

- When a calendar event linked to an activity is rescheduled, the event write syncs the new start date to the related activity through `_sync_activities`. That activity write was not marked as calendar-originated after commit https://github.com/odoo/odoo/commit/bc090486bd7810b1b0af1bae398255a2d6615f09, so `mail.activity.write` treated the updated deadline as an activity-originated change and wrote back to the same calendar event.
https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/calendar_event.py#L779
https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/mail_activity.py#L24-L33
- This created a nested calendar event write. Both the nested write and the original write then triggered attendee date-change notifications, resulting in duplicate emails.

Solution:
- Pass the existing `calendar_event_meeting_update` context flag when syncing calendar event changes to linked activities. This prevents the activity sync from writing back to the event while preserving activity-to-event rescheduling.

opw-6209956

Forward-Port-Of: odoo/odoo#269950
Forward-Port-Of: odoo/odoo#266675

Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views

Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").

Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.

Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.

Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999

opw-6238765

Forward-Port-Of: odoo/enterprise#119707

The tag remapping was running in pre-migrate, before the module's data files are loaded. This caused the tag swap to be silently skipped for any new tag that didn't exist yet, and the subsequent cleanup to fail with a FK violation on account_account_account_tag.
```py
 File "/home/odoo/src/odoo/saas-19.2/odoo/sql_db.py", line 417, in execute
    self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_account_tag" violates foreign key constraint "account_account_account_tag_account_account_tag_id_fkey" on table "account_account_account_tag"
DETAIL:  Key (id)=(356) is still referenced from table "account_account_account_tag".
```

Moving to post-migrate ensures all new account tags are present in the database before the remapping and cleanup run.

upg-[4341331]

[4341331]: https://upgrade.odoo.com/odoo/upgrade.request/4341331?debug=1


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

Forward-Port-Of: odoo/odoo#269809

### Issue
`l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises:

```
TypeError: Model 'certificate.certificate' does not exist in registry.
```

### Cause
`models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`.

### Notes
- Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op.
- Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first.

Forward-Port-Of: odoo/odoo#271827
Forward-Port-Of: odoo/odoo#271496

The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one.

### **Steps to reproduce:**
1) Install time off app.
2) Create a simple time off type.
- Create Allocation A (10 days, 01-01-2024 to 31-12-2025)
- Create Allocation B (10 days, 01-01-2025 to 31-12-2026) 
3) Create a leave of 1 day on 01-01-2026
4) Open the Balance report

### **Observed Behavior:**
The report shows 20 remaining days.

### **Expected Behavior:**
The report should show 19 remaining days (20 allocated - 1 taken).

### **Cause:**
In the taken_per_allocation CTE at [1], each leave is joined to every allocation it overlaps. The [fifo_balances] CTE then uses the formula:
```
GREATEST(alloc_days - GREATEST(taken - prior_cumulative_alloc, 0), 0)
```
This subtracts the prior allocation capacity (A = 10 days) from the taken count (B = 1 day). Since 1 - 10 = -9, GREATEST(-9, 0) = 0, so zero days are deducted from B. The formula wrongly assumes that prior allocations can absorb leaves that do not overlap with them.

[1]- https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L126-L142

[fifo_balances]: https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L145-L164

### **Fix:**
Ensure that leaves are only deducted from allocations they actually
overlap by calculating the balance using the delta of cumulative leaves
within an overlap group. This prevents earlier allocations from absorbing
leaves that occur outside their validity period.

**opw-6150161**

Forward-Port-Of: odoo/odoo#271596
Forward-Port-Of: odoo/odoo#263029

Steps to reproduce:
===================
1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates
2. Open /customers
3. Open the map and zoom in a few times

=> stale blue cluster bubbles remain on the map

Cause:
======
On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level.

`ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map,
https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation.

Solution:
=========
Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon.

opw-6128531

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

Forward-Port-Of: odoo/odoo#270733

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product P with MTO buy and a set vendor
- Create and confirm a sale order for 1 unit of P
- Confirm the assocaited PO and change the pol quantity from 1 to 10
> the associated receipt is updated from 1 to 10
- Change the pol quantity from 10 to 7
#### > The quantity on the receipt is updated from 10 to 16.

### Cause of the issue:

Changing the quantity of the POL will adapt the picking related quantity via these lines:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L115-L117 https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L342-L349 by creating new stock moves to be merged:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L220-L251 Now, the issue is that this flows relies both on a negative `qty_to_attach` of `1 - 10 = -9` and a positive `qty_to_push` of `7 - 1 = 6`. However, the `qty_to_attach` is only used if is positive: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L243-L251 The receipt is therefore updated by a `+6` move to push but not by the `-9` move to attach. Leading to a 10 -> 16 rather than 10 -> 7 result.

opw-6218307

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

Forward-Port-Of: odoo/odoo#270547
Forward-Port-Of: odoo/odoo#264994

Steps to reproduce:
-------------------
- Create a Purchase Order with an expected Arrival date in the past
- Confirm the Purchase Order
- Validate the receipt partially and create a backorder
- Cancel the generated backorder
- Open the Purchase Orders list and check the 'Late Receipts'

Issue:
------
The Purchase Order still appears in the 'Late Receipts' filter even
though there is no remaining receipt to process.

Cause:
------
The 'Late Receipts' filter relies on the computed search field
`is_late`:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/views/purchase_views.xml#L439

The search domain for this field is generated by
`purchase.order._search_is_late()`:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/models/purchase_order.py#L176

In `purchase_stock`, `_get_domain_is_late()` extends the base domain to
identify Purchase Orders that still have receipts pending:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase_stock/models/purchase_order.py#L264-L267

After a partial receipt:
- the original receipt is in state `done`,
- a backorder is created and linked to the Purchase Order,
- the backorder is later cancelled and moves to state `cancel`,
- the Purchase Order line still has `qty_received < product_qty`.

The existing domain excludes only `done` pickings when determining
whether a receipt is still pending. As a result, a cancelled backorder
is still treated as an unfinished receipt, causing the Purchase Order
to remain visible in the 'Late Receipts' filter.

Fix:
----
Exclude both `done` and `cancel` pickings when determining whether a
Purchase Order has pending receipts.

A cancelled backorder indicates that the remaining quantity will not be
received through that transfer. Therefore, once all related pickings are
either completed or cancelled, the Purchase Order should no longer be
considered late.

---
opw-6266046

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

Forward-Port-Of: odoo/odoo#268488

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.

Enterprise PR: https://github.com/odoo/enterprise/pull/112654

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

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

Forward-Port-Of: odoo/odoo#271191
Forward-Port-Of: odoo/odoo#256932

Module: l10n_it_pos

Steps to reproduce:
- In the POS settings, enable "Automatic Receipt Printing";
- Enable "ePos Printer" to make the "Skip Preview Screen" option appear;
- Disable "Skip Preview Screen";
- Disable "ePos Printer";
- Set up an Italian Fiscal Printer;
- Open a POS session and process a first order.

Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required.

Cause:
When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of  `renderService`, permanently blocking the printer queue.

Solution:
Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option.
UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured.

Community PR: https://github.com/odoo/odoo/pull/256932

[opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212)

Forward-Port-Of: odoo/enterprise#121257
Forward-Port-Of: odoo/enterprise#112654

Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views

Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").

Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.

Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.

Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999

opw-6238765

Forward-Port-Of: odoo/enterprise#119707

The tag remapping was running in pre-migrate, before the module's data files are loaded. This caused the tag swap to be silently skipped for any new tag that didn't exist yet, and the subsequent cleanup to fail with a FK violation on account_account_account_tag.
```py
 File "/home/odoo/src/odoo/saas-19.2/odoo/sql_db.py", line 417, in execute
    self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_account_tag" violates foreign key constraint "account_account_account_tag_account_account_tag_id_fkey" on table "account_account_account_tag"
DETAIL:  Key (id)=(356) is still referenced from table "account_account_account_tag".
```

Moving to post-migrate ensures all new account tags are present in the database before the remapping and cleanup run.

upg-[4341331]

[4341331]: https://upgrade.odoo.com/odoo/upgrade.request/4341331?debug=1


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

Forward-Port-Of: odoo/odoo#269809

Steps to reproduce:
-------------------
- Create a Purchase Order with an expected Arrival date in the past
- Confirm the Purchase Order
- Validate the receipt partially and create a backorder
- Cancel the generated backorder
- Open the Purchase Orders list and check the 'Late Receipts'

Issue:
------
The Purchase Order still appears in the 'Late Receipts' filter even
though there is no remaining receipt to process.

Cause:
------
The 'Late Receipts' filter relies on the computed search field
`is_late`:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/views/purchase_views.xml#L439

The search domain for this field is generated by
`purchase.order._search_is_late()`:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase/models/purchase_order.py#L176

In `purchase_stock`, `_get_domain_is_late()` extends the base domain to
identify Purchase Orders that still have receipts pending:
https://github.com/odoo/odoo/blob/324df67c099ab18c6fe7c8f77212cf809debf383/addons/purchase_stock/models/purchase_order.py#L264-L267

After a partial receipt:
- the original receipt is in state `done`,
- a backorder is created and linked to the Purchase Order,
- the backorder is later cancelled and moves to state `cancel`,
- the Purchase Order line still has `qty_received < product_qty`.

The existing domain excludes only `done` pickings when determining
whether a receipt is still pending. As a result, a cancelled backorder
is still treated as an unfinished receipt, causing the Purchase Order
to remain visible in the 'Late Receipts' filter.

Fix:
----
Exclude both `done` and `cancel` pickings when determining whether a
Purchase Order has pending receipts.

A cancelled backorder indicates that the remaining quantity will not be
received through that transfer. Therefore, once all related pickings are
either completed or cancelled, the Purchase Order should no longer be
considered late.

---
opw-6266046

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

Forward-Port-Of: odoo/odoo#268488

1. The `m160` and `m161` mutations for `sign_copy_sale` test didn't set the `l10n_be_short_signature` field on the order, so the `TicketScreen.print` override would fail the check and the `blackbox.signCopy` would not be called, causing the test to fail.
2. The `l10n_be_pos_blackbox_urban_piper` tests would crash on `undefined id` on the prep display path of `pos_enterprise`, where the data service will try to load up the prep display data, but it's not loaded in the test bundle. So I created a special setupEnv method for blackbox with urban piper which unpatches the prep display (same mechanism as pos_enterprise)
3. After removing the path for the tests, they would fail for the `expectGeneralProperties` step. By default it expects the `ticketMedium` to be `PAPER`, but there is no printer configured on the tests, so the actual medium is `DIGITAL`.
4. The tests expect the cost center to be `PLATFORM`. There was a patch on `InputGenerator`, which would return platform if the order has a `delivery_provider_id` set. But the patch never fired. I moved the patch directly on the order model, which is where the cost center value is computed.
5. The `test_l10n_be_pos_blackbox_sign_sale_backend_offline` test would endTour prematurely before the orders finished syncing, then check that all the orders are synced. I added an extra isSynced() step to ensure the orders are synced before ending the tour

Task-[6320705](https://www.odoo.com/odoo/1737/tasks/6320705)

Forward-Port-Of: odoo/enterprise#121455

### Issue
`l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises:

```
TypeError: Model 'certificate.certificate' does not exist in registry.
```

### Cause
`models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`.

### Notes
- Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op.
- Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first.

Forward-Port-Of: odoo/odoo#271827
Forward-Port-Of: odoo/odoo#271496

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#121563
Forward-Port-Of: odoo/enterprise#120967

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121536
Forward-Port-Of: odoo/enterprise#119525

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121536
Forward-Port-Of: odoo/enterprise#119525

This commit improves the layout of quantity buttons in barcode in both cases of physical inventory and transfers.

### Before this commit:
1- The fulfill button disappeared if `quantity done == demand - 1` which causes the increment and decrement buttons to shift their positions, that caused confusion to the user.

2- The delete button (red trash button) in case of physical inventory count was used to set the count of the product to 0 and remove the line from barcode view.

3- The "?" button (to mark the quantity as not set yet while inventory count) appeared whether the quantity on line was set to a number >= 0.

4- The button for registering components was among the lower buttons (increment, decrement, and fulfill).

### After this commit:
1- The fulfill button still disappears when `quantity done == demand - 1` but an empty spacer replaces it, which causes other buttons to hold positions.

2- The delete button now only appears when the user adds a product by themselves using the form or scanning the product (not while the product is in an inventory request). Also the functionality is of the button is now different, it just removes the line from the barcode view without affecting the inventory count at all.

3- The "?" button now only appears if the quantity = 0.

4- The button for registering components is no next to the edit button.

Upgrade PR: https://github.com/odoo/upgrade/pull/10224
Task-6095725

see: https://github.com/odoo/odoo/pull/252766

ERROR: Subtest TestAiCrmLivechatTools.test_create_lead_tool_from_livechat (login='public_user') Traceback (most recent call last):
  File "/data/build/odoo/odoo/tools/safe_eval/evaluation.py", line 431, in safe_eval
    return unsafe_eval(c, globals_dict, None)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "ir.actions.server(272,)", line 1, in <module>
  File "/data/build/odoo/odoo/tools/safe_eval/runtime.py", line 659, in safe_call
    return callee(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/ai_crm/models/crm_lead.py", line 16, in _ai_create_lead
    self.create(self._ai_prepare_lead_creation_values({
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/enterprise/ai_crm_livechat/models/crm_lead.py", line 21, in _ai_prepare_lead_creation_values
    if 'website' in self.env and (visitor := channel.livechat_visitor_id):
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'discuss.channel' object has no attribute 'livechat_visitor_id'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 2949, in with_users
    func(self, *args, **kwargs)
  File "/data/build/enterprise/ai_crm_livechat/tests/test_ai_crm_livechat_tools.py", line 17, in test_create_lead_tool_from_livechat
    tool.with_context({'discuss_channel': livechat_channel})._ai_tool_run(None, {
  File "/data/build/enterprise/ai/models/ir_actions_server.py", line 288, in _ai_tool_run
    self._run_action_code_multi(eval_context=eval_context)
  File "/data/build/odoo/odoo/addons/base/models/ir_actions.py", line 1012, in _run_action_code_multi
    safe_eval(self.code.strip(), eval_context, mode="exec", filename=str(self))
  File "/data/build/odoo/odoo/tools/safe_eval/evaluation.py", line 437, in safe_eval
    raise ValueError('%r while evaluating\n%r' % (e, expr))
ValueError: AttributeError("'discuss.channel' object has no attribute 'livechat_visitor_id'") while evaluating "ai['result'] = record.sudo()._ai_create_lead(name, contact_name, description, email, phone, team_id, tag_ids, priority, country_id, state_id, city, zip_code, street, job_position)"

Steps to reproduce:
-
1. Install `website` and `planning_field_service` (so `website_planning_field_service` auto-installs).
2. Open Settings and click Save.

Issue:
-
An "Uninstall modules" wizard pops up offering to remove `website_planning_field_service`.

Cause:
-
Since the module is now `auto_install` with its `post_init_hook` removed, it is installed alongside `website` and
`planning_field_service` while the setting remains disabled by default.

On Save, `set_values` re-derives the `module_website_planning_field_service` field from a company `search_count`, setting it to False when no company has the feature enabled, even though the module is installed. Base `execute()` then sees `module_* = False` on an installed module and re-offers the uninstalls.

Fix:
-
Make `set_values` install-only: enabling the setting still installs the module, but disabling it no longer attempts to uninstall it. The module is now also used to show or hide Field Service information in the portal, so it must remain installed even when the Website Form feature is disabled.

task-6330718

Version:
- 19.0

Steps to reproduce:
- Create a sign template with a readonly sign item linked to an auto field.
- Use a reference record where the linked field value is empty or False.
- Send the document for signing.
- Complete the signing flow.

Issue:
- Readonly sign items linked to auto-filled values could not properly handle
  falsy values. Empty values could trigger the error "Some required items are
  not filled" and completed sign requests displayed the sign item placeholder
  instead of the actual auto-filled value.
- completed document generation could fail when rendering falsy values for
  textarea sign items.

Cause:
- Falsy auto-filled values were ignored during constant item population and
  replaced by the sign item placeholder. Additionally, readonly constant items
  were included in required field validation and completed sign requests
  continued to display placeholders when the stored value was empty.
- document rendering assumed sign item values were always strings for textarea
  sign items but when auto field is empty it value can be False.

Fix:
- Preserve falsy values when populating readonly constant items, exclude
  constant items from signer validation, and hide placeholders for empty
  auto-filled constant items when displaying completed sign requests.
- Normalize falsy values to prevent crashes and allow completed documents
  to be generated correctly.

Forward-Port-Of: odoo/enterprise#121299
Forward-Port-Of: odoo/enterprise#121009

Replaced `useLayoutEffect` with `useEffect` (OWL3) because `useLayoutEffect` is deprecated in OWL3.

The single `useLayoutEffect` was reacting to `this.props.actionName`: when `actionName === 'manage-booking'` it makes an async `data.call` to open the booking gantt view, then dispatches `doAction` / `switchView`. This is not derived state and does not load data into component state — it dispatches an action, making OWL3 `useEffect` the correct replacement. OWL3 `useEffect` auto-tracks reactive values read in its body, so `this.props.actionName` is tracked automatically without an explicit dep array.

The `useLayoutEffect` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- `@pos_appointment/unit/screens/action_screen/ActionScreen => useEffect`: Expected gantt view action, received null
- `FAIL: TestFrontend.test_appointment_kanban_view_date_filter`: Tour failed at 'Go to kanban view' step
- `FAIL: TestUi.test_pos_restaurant_appointment_tour_basic`: Tour failed at 'Check that the booking gantt view is shown'
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2596700/build/114854622

## Steps to reproduce:

- Open the restaurant and the linked preparation display
- Send a single product to the kitchen
- On the preparation display, click on the line
- In the backend go to the order
- The Preparation Time field will be empty

## Why the fix:

With the current implementation, we only update the **preparation_time** on the orderline if we still have some orderlines to make, and if we don't, we change the state to the next stage in the preparation display
https://github.com/odoo/enterprise/blob/a14d1b8ed84aae4e274a674c6aa24130a378bef5/pos_enterprise/static/src/app/components/order/order.js#L112-L116

This means that if there is a single orderline on the order, clicking on the line will only move it to the next stage, and won't trigger the backend calculation to update the preparation_time.

We now always trigger the calculation of the preparation_time when a line is clicked, as it is weird for it to be triggered only when we have multiple lines waiting.

It needs to be done in an asynchronous manner, as concurrent database calls would cause wrong values if we called **syncStateStatus** and **changeStateStageAnimation** at the same time.

opw-6283017

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#121563
Forward-Port-Of: odoo/enterprise#120967

## Summary

- Enable outbound CDV 211 (`payment_sent`) from purchase invoices in `l10n_fr_pdp`.
- Wizard exposes `payment_sent` for purchase documents with MPA payload and payment date.
- Cron sends PD for sales and `payment_sent` for purchases; lifecycle residual computed separately per type.

## Multi-repo issues

- odoo/odoo#268018 — CDV 211 `payment_sent` on purchase bills

## Related PRs

- *(Odoo CE only — no Akretion/OCA changes for this campaign)*

## Test plan

- [ ] `odoo-bin -d test --test-tags=/l10n_fr_pdp:TestPdpMessages.test_purchase_payment_sent_lifecycle --stop-after-init`

## Merge order

1. Merge this PR on `odoo/odoo` 18.0 when approved.

## Reviewers & code owners

- Requested review: @smetl @chklop
- PDP / lifecycle context: @malb-odoo @baje @videc @sveaw

---

## Résumé

- Émission sortante du CDV 211 (`payment_sent`) depuis les factures fournisseur dans `l10n_fr_pdp`.
- Assistant : `payment_sent` sur les achats avec charge MPA et date de paiement.
- Cron : PD pour les ventes, `payment_sent` pour les achats ; résidu de cycle de vie calculé séparément.

## Issues multi-dépôts

- odoo/odoo#268018 — CDV 211 `payment_sent` sur factures fournisseur

## PR associées

- *(Odoo CE uniquement — pas de changement Akretion/OCA)*

## Tests

- [ ] `odoo-bin -d test --test-tags=/l10n_fr_pdp:TestPdpMessages.test_purchase_payment_sent_lifecycle --stop-after-init`

## Ordre de fusion

1. Fusionner cette PR sur `odoo/odoo` 18.0 après revue.

## Revue & auteurs du code

- Review demandée : @smetl @chklop
- Contexte PDP / cycle de vie : @malb-odoo @baje @videc @sveaw

Fixes #268018

Currently, the GT Document Type field is required when creating 
vendor bills for non-Guatemalan vendors.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a GT Company.
- Create a new vendor bill for a vendor whose country is not Guatemala.

**Observation:**
The `GT Document Type` field is required even though the selected vendor 
is not based in Guatemala.

**Root Cause:**
At [1], `_compute_l10n_gt_edi_available_doc_types` only checks the company 
country and ignores the vendor's country, causing GT available document types 
to be computed for foreign vendors as well. As a result, `l10n_gt_edi_available_doc_types` 
is populated and the view at [2] incorrectly makes `l10n_gt_edi_doc_type` required.

**Fix:**
This commit ensures the GT Document Type field is only required for Guatemalan vendors.

[1]:
https://github.com/odoo/enterprise/blob/7a80db5b5550bf75e4ce5337e869c42386c8a71c/l10n_gt_edi/models/account_move.py#L144-L171

[2]:
https://github.com/odoo/enterprise/blob/7a80db5b5550bf75e4ce5337e869c42386c8a71c/l10n_gt_edi/views/account_move_views.xml#L27

opw-6315872