Version: --------- - saas-18.4+ Steps to reproduce: ---------------------- 1. Install `stock` and `purchase` module 2. Create a storable and tracking product with a vendor. 3. Create a reordering…

Version:
---------
- saas-18.4+

Steps to reproduce:
----------------------
1. Install `stock` and `purchase` module
2. Create a storable and tracking product with a vendor.
3. Create a reordering rule: Route = Buy, Min Qty = 10, Max Qty = 20 
and Trigger `manual`
4. Create a receipt for 10 units from the vendor and confirm it.(Mark as todo).
5. Observe the Order button is hidden in reorder rule(expected—incoming qty covers the minimum)
6. Delete the receipt move line.
7. Open reordering rule and check order button

Issue:
------
After deleting a confirmed incoming move, the Order button on the reordering rule
does not reappear, even though there is no longer any incoming quantity to cover
the minimum threshold.

Cause:
-------
https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/views/stock_orderpoint_views.xml#L55-L56

The Order button visibility is driven by `qty_to_order > 0` on the orderpoint.
`qty_to_order` itself resolves to `qty_to_order_computed` (a stored field) when no
manual override is set:

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L317-L319

 ``` 
 qty_to_order─depends─>qty_to_order_computed  (stored)
                                      │
                                      └─ reads qty_forecast  (non-stored, computed)
                                              │
                                              └─ depends on product_id.stock_move_ids.
 ```

`_compute_qty_to_order_computed` checks whether `qty_forecast < product_min_qty`.
If so, it calculates how much to order to reach `product_max_qty`. When a confirmed
incoming move exists, its quantity is included in `qty_forecast`,

https://github.com/odoo/odoo/blob/adabd8cc47b1c5992f0f92631da73977be8beaca/addons/stock/models/stock_orderpoint.py#L347
This return False.
So, `qty_to_order_computed = 0` → button hidden.

To avoid recomputing `qty_to_order_computed` for all orderpoints on every stock
move change severe performance issue — see [Commit](https://github.com/odoo/odoo/commit/6f2d1b26b34129cfbd62d2fe44f306bfe89794b5
), 
`qty_forecast` is intentionally excluded from
 `@api.depends` on `qty_to_order_computed`. Instead,
`_update_orderpoints()` is called selectively from `create()` and `write()` to
schedule a targeted recompute via `env.add_to_compute()`.

However, `unlink()` never called `_update_orderpoints()`, so deleting a move left
`qty_to_order_computed` stale at 0 — the Order button stayed hidden permanently.

Solution:
---------
- `_update_orderpoints()` now returns the found orderpoints recordset.
- `unlink()` calls `_update_orderpoints()` before deletion to capture the affected
  orderpoints (product_id / location data still accessible), then calls
  `_compute_qty_to_order_computed()` immediately after `super().unlink()`.

opw-6174454


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

Forward-Port-Of: odoo/odoo#275119
Forward-Port-Of: odoo/odoo#264039

`_add_manual_models` builds Python model classes for custom ("manual") `ir.model` records with a raw `SELECT *` on the `ir_model` table, then hands each row to `_instanciate_attrs`, which reads a fixed list of expected columns (`model`, `name`, `abstract`, `transient`, `order`, `fold_name`, `info`) via dict subscription (`model_data['xxx']`).

This assumes every one of these fields is always backed by a real database column. That assumption breaks whenever a field originally declared as stored on `ir.model` gets redeclared as non-stored (`store=False`) by another module inheriting the same model: Odoo correctly drops the now-unneeded column during that module's `_auto_init()`, but any code still doing `SELECT *` on the table no longer gets that key in the result row, and the subscript access raises a bare `KeyError`. This aborts the *entire* registry load, for every model in the database, not just the one whose field changed -- because `_add_manual_models` runs once per registry load and any database with at least one manual/custom model exercises it.

This is exactly the scenario introduced by 267bec440d56 ("[IMP] base: add IrModel.abstract field"): it added a new, plain stored `abstract` field on `ir.model`. `web_studio` has independently defined its own `abstract` field on `ir.model` since 2016 (ac1129f6577), as a computed, `store=False` field. Once both are loaded together, Odoo's field- merging logic settles on the `store=False` definition, so `_auto_init()` drops the `abstract` column -- and any database that also has at least one manual model (built through Studio, or via a module that dynamically generates SQL-view-backed models) then fails to boot its registry at all:

    File ".../odoo/orm/model_classes.py", line 554, in _add_manual_models
        attrs = env['ir.model']._instanciate_attrs(model_data)
    File ".../odoo/addons/base/models/ir_model.py", line 487, in _instanciate_attrs
        '_abstract': bool(model_data['abstract']),
    KeyError: 'abstract'

Fix `_instanciate_attrs` to fall back to a sane default instead of assuming the column exists. This doesn't just patch the `base`/ `web_studio` collision -- it hardens `_add_manual_models` against any future field made non-stored by an inheriting module, which is otherwise a silent, whole-database-breaking failure with no visible relation to whichever module actually changed the field.

A companion fix removing web_studio's now-redundant override (the actual root cause of the collision) is proposed separately.

Steps to reproduce:
1. Install `base` and `web_studio` together (or in either order) --
   Odoo's field-merging settles on web_studio's `store=False`
   definition, but leaves the `abstract` column physically in place;
   it is not dropped automatically.
2. Have at least one manual model in the database (`state='manual'`
   on `ir.model`, e.g. created through Settings > Technical > Models).
3. Actually remove the now-orphaned `abstract` column -- e.g. via the
   OCA `database_cleanup` module's column-purge wizard
   (`cleanup.purge.wizard.column`), which explicitly targets exactly
   this kind of column (computed + non-stored fields are excluded
   from its "keep" list, so `abstract` gets flagged and dropped).
4. Restart Odoo / reload the registry: it fails to boot entirely with
   a KeyError on that field name, for every model, not just the one
   whose owning module changed.


Related: odoo/enterprise#123572



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

Forward-Port-Of: odoo/odoo#275092

**Steps to reproduce:** - Install Accounting and l10n_ar_withholding - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Create a 0% Payment Withholding tax: * Tax Type: Customer…

**Steps to reproduce:**
- Install Accounting and l10n_ar_withholding
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Create a 0% Payment Withholding tax:
  * Tax Type: Customer Payment Withholding
  * Amount: 0.00 %
  * Add an account for the tax distribution lines

- Create an invoice with a tax
- Confirm the invoice
- Pay the invoice:
  * Withholdings:
       - Add a line with the created 0% Payment Withholding tax
       - Add a line with another Payment Withholding tax
- Create Payment
- Go to the payment

**Issue 1:**
When clicking on the first withholding line, a JS error is raised due to a missing index (i.e. currency_id).

**Cause 1:**
One of the fields has an aggregate sum function applied on it (i.e. amount_currency).
As it is a monetary field, the corresponding currency field is required in the view.

**Issue 2:**
When resetting the payment to draft, the withholding line with the 0% tax is deleted.
As the withholding table is not editable, it is not possible to add the line again.

**Cause 2:**
When the payment is reset to draft, the state of the associated journal entry is also set to draft and a "_sync_dynamic_lines" is triggered, which remove tax lines having a zero amount during the process.

**Solution 2:**
Keep all the lines with a Customer Payment Withholding tax as it is not possible to add a withholding line in the payment afterwards.

opw-6298058




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

Forward-Port-Of: odoo/odoo#274604
Forward-Port-Of: odoo/odoo#271555

**Steps to reproduce:** - Install the `l10n_it_edi` module and switch to an IT Company. - Create and confirm an invoice for a non-Italian customer. - Send the invoice, making sure that only `by…

**Steps to reproduce:**
- Install the `l10n_it_edi` module and switch to an IT Company.
- Create and confirm an invoice for a non-Italian customer.
- Send the invoice, making sure that only `by Email` is enabled.
- Attempt to send the invoice again.

**Issue:**
- In `18.0`, the XML file is not generated when re-sending an invoice that 
was previously sent only by email.

- Starting from `19.0`, attempting to `Send to Tax Agency` raises an error:
`UnboundLocalError: cannot access local variable 'attachment_name' where it is not associated with a value`

**Root cause:**
At [1], `_get_alerts` method does not check whether the invoice was previously 
sent only by email. As a result, the warning banner is not displayed, and 
allows the user to `Send to Tax Agency`.

**Fix:**
Restore the expected behavior by preventing `Send to Tax Agency` when 
the invoice was previously sent only by email. Instead, display the 
appropriate warning message instructing the user to delete the 
PDF attachment before sending to the Tax Agency, matching the 
behavior in `17.0` (confirmed with PO).

[1]:
https://github.com/odoo/odoo/blob/c0d8d36481e106f0209521bbb127cb3b1ad1059a/addons/l10n_it_edi/models/account_move_send.py#L27-L33

opw-6293519

Forward-Port-Of: odoo/odoo#269547