# How to reproduce
- Go to Sign > Templates
- Upload a PDF & click on Share
- Copy the link
- Go to a page with a EditInBackend systray item (e.g. a Product or Event page)
- In the editor, add the copied link to a button or some text
- Save
- While still in editor mode, click the link

# The issue
A traceback is shown

# Cause
The traceback is caused by the call to this function : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/services/website_service.js#L336

In our case, `this.currentWebsite.metadata.mainObject` is undefined, so trying to access `.model` throws. `mainObject` is undefined because the sign link opens an XML file, which does not have any metadata associated to it :
https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/services/website_service.js#L150-L155

The call to `getUserModelName` is done by the `EditInBackendSystrayItem` component which subscribes to the "CONTENT-UPDATED" event : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/edit_in_backend.js#L33

However, this method should not be called by the bus because the sign page does not have this systray item. The issue is, the display of the component is managed by the `WebsiteSystrayItem`, based on the `hasEditableRecordInBackend` getter :
https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/website_systray_item.js#L10 https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/website_systray_item.xml#L9

And the re-render of that component that would remove the `EditInBackendSystrayItem` component is triggered by a call to `renderAndAdapt`, which is also subscribed to "CONTENT-UPDATED" : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/components/navbar/navbar.js#L48

So the destroy of the `EditInBackendSystrayItem`, which should remove the listener that calls `getUserModelName` is trigerred AFTER the call to that function is already done

opw-6443794

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.

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

…heet history

Some spreadsheet can end up in a corrupted history state

Original Data ⮕ no revision (XX) ⮕ Snapshot ⮕ Active Revisions and where the original data differ from the snapshot.

XX: can occur after the script added https://github.com/odoo/upgrade/issues/6340. The migration script is supposed to rewrite the history of the spreadsheet when there are holes in the archived revisions continuity (eg. the history was original Data ⮕ rev **A** ⮕ rev **B** ⮕ rev **C** ⮕ snapshot ⮕ rev **D** and user deleted rev **B** for instance, the script deletes **A** and **C** and marks **D** as the very first revision).

Version history was designed with the idea to replay every single revision that existed since the creation of the spreadsheet and apply it to the original data, and in case of missing revisions, in our example, B is missing, we detect the lack of continuity, we start from the snapshot, and replay every single revision since that snapshot.

When the migration fixes the continuity, by deleting all the old revisions, and changing their order, we can no longer detect the lack of continuity and end up replay every available revision to the original data ,even though they are based on the snapshot.

In that scenario, since the revisions will be applied on the original data but since they are based on the state of the snapshot only, the final state of the spreadsheet will be corrupted since a part of the . If a user then decides to restore the spreadsheet to the version they see in the version history (which is corrupted as mentioned) and the last snapshot is overwritten with the corrupted state, effectively breaking the spreadsheet.

With this revision, we add a detection of this corrupted history state, in which case we enforce the history to be replayed from the snapshot and not the original data.

Task-6533708

Forward-Port-Of: odoo/enterprise#130812
Forward-Port-Of: odoo/enterprise#130649

## Steps to Reproduce:
- Install the Subscriptions module with demo data.
- Create a quotation containing a subscription product.
- Set a recurring plan and confirm the quotation.
- Create an upsell quotation or a renewal quotation.
- Cancel the original subscription.
- Remove the recurring plan from the cancelled subscription.
- Open either the upsell or renewal quotation and confirm it.

## Error:
`TypeError - '>=' not supported between instances of 'datetime.date' and 'bool'`

## Cause:
Since Commit https://github.com/odoo/enterprise/commit/315be581a4212b46191e0c4f82b02a2c3fde51dc#diff-07cf1dda5423f99452a763a54fb6e7fdbb861e19b1a9dca00cab093a832490a9, `plan_id` is no longer required when a subscription is in the cancelled state.

During the confirmation of an upsell or renewal quotation, the parent subscription's next invoice date is used for several date validations. However, if the parent subscription is cancelled and its plan is removed, the `next_invoice_date` is computed as False. Comparing a date object with a boolean value leads to an error.

## Fix:
This commit adds an extra check before using the next invoice date.

sentry-7661150764

*= 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#119233

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

### Steps to Reproduce:
1) Install `website_helpdesk_slides_forum` module
2) On a Helpdesk team, link 2 (or more) forums under `Commnity Forums`.
3) Click on website smart button and then click `Ask the community` button.

### Error:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
KeyError: '_forums'
Template: website_helpdesk_slides_forum.helpdesk_forums
```

### Root Cause:
https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_forum/controllers/website_forum.py#L18-L22

On clicking the "Ask the Community" button calls the `helpdesk_forums`
controller. A single forum redirects straight to it. Several forums get rendered
through `get_template_xml_id()`, with only `forums` in context.

`get_template_xml_id()` is overridden in `WebsiteSlidesForumHelpdesk`,
which points to :

https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_slides_forum/views/helpdesk_templates.xml#L3-L5

a primary copy of the inner partial `forum_all_all_entries`. That
partial needs `_forums` (and, once extended by website_slides_forum,
courses_discussions too), both only ever set by the page template's
own t-call:

[Reference](https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/website_forum/views/forum_forum_templates_forum_all.xml#L18-L19)

Since `helpdesk_forums` is rendered directly instead of going through
`website_forum.forum_all`, `_forums` is never set, hence
`KeyError` occurs.

The base `website_helpdesk_forum` module has the same root cause one
level up, surfacing as a different error:

https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_forum/controllers/website_forum.py#L24-L25

`website_helpdesk_forum.forum_all` does not exist anywhere in the
codebase. A team with multiple forums, without
`website_helpdesk_slides_forum` installed, hits
```
ValueError: View 'website_helpdesk_forum.forum_all' in website 1 not found
```
Instead of a listing page.

### Fix:
- Both `get_template_xml_id()` implementations now return the real,
  working `website_forum.forum_all` page template, which already sets
  `_forums/courses_discussions` through its own `t-call` and wraps the result in
  website.layout.

- `helpdesk_forums()`'s render values are now built through an overridable
  `_get_helpdesk_forums_render_values()` hook instead of a hardcoded dict,
  so subclasses can extend the context.

- `website_helpdesk_slides_forum` uses that hook to set
  `hide_forum_slides_link=True`, and adds one small non-primary view inheriting
  `website_slides_forum.forum_all_all_entries` that conditions the `/slides` promo
  link (not the "Course" badge, which doesn't navigate anywhere) on `not`
  `hide_forum_slides_link`. This targets the link element itself rather than a
  `t-call` site in `forum_all`, so it correctly applies whether `website_slides_forum`
  groups a given forum as "regular" or "course-linked".

**opw-6332175**

Forward-Port-Of: odoo/enterprise#131435
Forward-Port-Of: odoo/enterprise#124104