Steps to reproduce:
----------------------------------------
1. Install `industry_fsm_sale` and `base_automation` modules
2. Create a product with:
    * Type: Service
    * Create on order: Task
    * Project: Field Service
3. Create an automation rule with:
    * Model: Sales order
    * Trigger: Incoming message
4. Create and confirm a sale order with this product
5. Add another product to the SO via the catalog view:
    * Change the quantity to 2 or more

Observation:
----------------------------------------
Traceback occurs:
```
  File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post
    message_sudo = message.sudo().with_context(active_test=False)
AttributeError: 'bool' object has no attribute 'sudo'
```

Root Cause:
----------------------------------------
* Catalog qty change calls `set_fsm_quantity()` method
* Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise
https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83
* `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order
* FSM's `message_post` override sees the context flag and returns `False`
* When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False`

Solution:
----------------------------------------
Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on

opw-6276916

Forward-Port-Of: odoo/enterprise#123010
Forward-Port-Of: odoo/enterprise#119542

The Download PDF option of an article prints the page with the browser. On screen, the article body is inside .o_scroll_view_lg, which scrolls when the content is longer than the screen:

https://github.com/odoo/enterprise/blob/79f8defa04476e1b939dc8bb5449a775137aed62/knowledge/static/src/scss/knowledge_views.scss#L170-L177

The print stylesheet used to force overflow: visible on every div, so this container did not scroll when printing. It also hid every child of the body except the action manager, so the navbar and open dropdowns were left out of the print. Commit https://github.com/odoo/enterprise/commit/69612c80ea0aec5ccf2c2857449da03e61273457 rewrote knowledge_print.scss to scope its rules to the Knowledge view and removed both rules. The scroll container now keeps its fixed height and its scrollbar when printing, so the scrollbar is drawn in the print preview and on every page of the PDF. The dropdown opened to reach Download PDF is printed on top of the article when it overlaps the page area, which happens when the browser is zoomed in.

Add overflow: visible to the print rule of knowledge_print.scss that already targets .o_scroll_view and .o_scroll_view_lg with position: static. That rule exists to undo the screen positioning of the scroll containers when printing, so the overflow reset belongs there. Its selector is also more specific than the screen one, so the value applies without !important, like position: static already does. Restore the rule that hides the body children other than the action manager, scoped to the Knowledge view like the rest of the file since the print stylesheet is now loaded on every page.

Before:
<img width="497" height="703" alt="image" src="https://github.com/user-attachments/assets/44aa3366-3fc8-4382-8aa2-84625fa4b6d8" />

After:
<img width="497" height="703" alt="image" src="https://github.com/user-attachments/assets/8b6eb2bc-37a3-4666-b871-0e6149c41fea" />

Steps to reproduce:
1. Open the Knowledge app and create an article
2. Paste enough text in the article to fill more than one PDF page
3. Zoom the browser to 200%
4. Click the three dots in the top right corner, then Download PDF
5. Check the print preview or the saved PDF

=> A scrollbar is drawn on the right edge of every page and the dropdown menu is printed on top of the article

Ticket [link](https://www.odoo.com/odoo/project.task/6279174)
opw-6279174

Forward-Port-Of: odoo/enterprise#120249

The following use case has been observed:

0. Customer start a payment from /shop/payment.
1. We received the webhook that notifies that the payment succeeded.
2. The payment post-processing cron start (it gather all the transactions that need to be processed, including the customer new transaction)
3. Meanwhile, the customer is redirected back by the payment provider to Odoo, which then redirect to /payment/status and start the payment post-processing for that specific transaction
4. The customer initiated payment processing finishes, he is redirected back to /my/orders/... page.
5. The payment post-processing cron finally start processing the same customer transaction and process it (a second time).

In that case, as the transactions to be post-processed backlog was quite high, there is consequent time between the time we gather all the TXs to post-process and actually process the customer transaction.

Also we don't end up with a `SerializationError` as the cron do commit after each transaction post-processing.

This commit force invalidate individual transaction cache values and recheck if it effectively still need to be post-processed before doing it.

opw-6332192

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

Forward-Port-Of: odoo/odoo#274725
Forward-Port-Of: odoo/odoo#274010

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#274832
Forward-Port-Of: odoo/odoo#264039

Description of the issue/feature this PR addresses:
Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This allows public users to potentially use emails that belong to registered accounts.

Current behavior before PR:

Users could subscribe to stock notifications for products that don’t exist or cannot be added (no stock).
Public users could use emails already associated with registered accounts, allowing them to subscribe on behalf of another user.
No validation is enforced, leading to potential security issues.
Desired behavior after PR is merged:

Adding a subscription for a non-existent or unavailable product raises a ValidationError.
Public users trying to subscribe with an email that belongs to a registered user receive an AccessError prompting them to sign in first.
Backend validation prevents misuse of registered user emails and improves security.




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

Forward-Port-Of: odoo/odoo#274555
Forward-Port-Of: odoo/odoo#271880

When computing taxes for the order, we group the base lines based on a grouping key. One of the components of this key is `is_refund`, and reward lines where considered as refund lines, which caused them to be grouped separately. This caused a discrepency between the tax amount computed in the frontend and the one computed in the backend.

Steps to reproduce:
-------------------
* Change the rounding method to globally
* Create a 21% tax not included in price
* Create a product with a price of 76.01 and the tax created above
* Create a loyalty program with a 10% discount
* Create a POS order with the product above and apply the loyalty program
* Validate the order and generate the invoice
> Observation: The invoice states that 0.01$ is still due

Why the fix:
------------
In `round_tax_details_tax_amounts`, we try to detect any delta with the expeced tax amount. To do that we group the base lines based on a grouping key. The grouping key `is_refund` was incorrectly set to `true` for reward lines, which caused them to not be grouped. The delta was then not detected and tax amounts were not adjusted. We now make sure not to consider reward lines as refund.

opw-6052112

Forward-Port-Of: odoo/odoo#274175
Forward-Port-Of: odoo/odoo#271577

In the bubble layout, the `name="company_address"` div was inside an unconstrained `<td>`, causing percentage-based widths set in `company_details` (e.g. `width: 25%` on a image) to resolve against the full table cell width, resulting in oversized content compared to other layouts.
**Without fix:**

<img width="1127" height="411" alt="withoutfix" src="https://github.com/user-attachments/assets/244c3407-1dbb-4b83-95d9-ebaba2b2b13c" />

For e.g, The folder layout wraps the same block in a `w-50` div, so percentage widths resolve against ~half the page width.

<img width="1111" height="410" alt="folderexp" src="https://github.com/user-attachments/assets/ee72712a-94da-483c-9a8e-cb3a850dac8e" />

Added `w-50 ms-auto` to the `name="company_address"` div in the bubble layout to align its sizing context with the other layouts, ensuring consistent rendering of user-defined styles in `company_details` across both layouts.

**With fix:**

<img width="1119" height="413" alt="wfix" src="https://github.com/user-attachments/assets/6b1caf24-3a8e-450f-865e-cce2b9788fe9" />



Commit which made the bubble layout in table: https://github.com/odoo/odoo/commit/8eb61a245cd3b650e309fdb55d24654c34d785cd

opw-6287230



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

Forward-Port-Of: odoo/odoo#270725

Guests never receive any bus notification when the websocket is not handled by Odoo itself but by a proxy that forwards subscriptions through `/websocket/peek_notifications` and dispatches the notifications on its own (which is how Odoo.sh serves databases).

The peek controller calls `ir.websocket._prepare_subscribe_data()` directly, bypassing `_subscribe()`, the only method decorated with `@add_guest_to_context`. The guest cookie is present on the request but never read, so the returned channel list only contains the anonymous channels (broadcast, res.groups) and lacks the guest's personal ones: ("mail.guest", id), ("discuss.channel", id) and presence. The proxy therefore never registers those channels, and every notification targeted at the guest is silently dropped.

Before this commit, discuss calls with a guest are broken: a 2-person call never connects (p2p offers/answers/ICE are delivered over the bus); in a 3+ person call, any guest who joined before the SFU threshold stays stuck in dead p2p (they never receive the `sfu_hot_swap` notification) while a guest joining as 3rd+ participant works, since the join RPC returns the SFU credentials synchronously.

We override `peek_notifications` with `add_guest_to_context` so the route is aware of guests.

opw-5490739

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

Forward-Port-Of: odoo/odoo#274743

SurveyResult binds a click listener on each .filter-add-answer icon when it starts. The response tables are rendered by a separate interaction, SurveyResultPagination, which swaps the tbody through a t-out directive on every page change and on Show All. Those new rows are nodes SurveyResult never bound, so their filter icon does nothing and the page reloads on the unfiltered view.

The direct binding comes from https://github.com/odoo/odoo/commit/dfc1c742e35f75f2c386c4ef50d5584537ac1ed4, which replaced the jQuery delegated handlers that used to survive re-renders. https://github.com/odoo/odoo/commit/c2f0f681714fcb936ce058e8dd4f1b1e9fa7448c reattaches them on tab change but not on pagination or Show All, so only the first page works.

Bind updateContent on .pagination_wrapper, which holds the page links and the Show All button and stays outside the re-rendered tbody. A click on either bubbles up and rebinds .filter-add-answer on the rows that were just rendered.

Steps to reproduce:
1. Install survey
2. Create a survey with a Date question
3. Share it and record more than ten responses so the responses table spans several pages
4. Open the survey results page and click the list icon on the date question to show the User Responses table
5. Move to page 2 and click the filter icon on any row

=> The page reloads on the unfiltered view and the selected date is not applied

Ticket [link](https://www.odoo.com/odoo/project.task/6238514)
opw-6238514

Forward-Port-Of: odoo/odoo#268569

Problem:
When creating a product from an invoice form view, the list price set on the product is not saved on the product template. After creating the product, when checking the product from the products list, the set list price is not shown.

Steps to reproduce:
1. Go to Accounting > Customers > Invoices
2. Create a new invoice
3. Create and edit a new product from the invoice line and set a new list price for the new product
4. Go to Sales > Products and open the created product
5. Check the list price of the product
6. Notice how the set list price is not shown on the product form view

Cause:
Product variants show lst_price while product templates show list_price on their form views. When creating a product from the invoice line, the shown form is for the product variant. When setting the list price on
the product variant form (lst_price in that case), the inverse method of llst_price, which sets the list_price in return, is called during the creation of the variant, after the template has been created and saved. As a result, editing the list price does not trigger a write on the already saved product template, causing the list_price of the variant to
be different than the list_price of the template.

opw-6272825

Stacktrace during Peppol file generation when creating downpayment from POS
- activate peppol (and set system parameter to peppol demo)
- create a sale order
- on the pos, select order, choose downpayment
- pay (for example by card)
-> error: 
<img width="461" height="276" alt="image" src="https://github.com/user-attachments/assets/aadc9467-04e5-413a-97ea-8378252a56a0" />


When an invoice line has no description (name=False in Odoo ORM), base_line.get('name', '') returns False because the key exists. Using `or ''` ensures we always get a string before calling .replace().

Reproduces when generating Peppol XML for a POS down-payment invoice with no line description.

Description of the issue/feature this PR addresses:

Current behavior before PR:
stacktrace:
```
2026-07-03 12:19:39,347 46424 ERROR bsr odoo.http: Exception during request handling. 
Traceback (most recent call last):
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2856, in __call__
    response = request._serve_db()
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2331, in _serve_db
    raise self._update_served_exception(exc)
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2329, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/service/model.py", line 188, in retrying
    result = func()
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2384, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File ".../lib/python3.13/site-packages/odoo/http.py", line 2599, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File ".../lib/python3.13/site-packages/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
    result = endpoint(**request.params)
  File ".../lib/python3.13/site-packages/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File ".../lib/python3.13/site-packages/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File ".../lib/python3.13/site-packages/odoo/service/model.py", line 97, in call_kw
    result = method(recs, *args, **kwargs)
  File ".../lib/python3.13/site-packages/odoo/addons/pos_sale/models/pos_order.py", line 59, in sync_from_ui
    data = super().sync_from_ui(orders)
  File ".../lib/python3.13/site-packages/odoo/addons/pos_enterprise/models/pos_order.py", line 25, in sync_from_ui
    data = super().sync_from_ui(orders)
  File ".../lib/python3.13/site-packages/odoo/addons/point_of_sale/models/pos_order.py", line 1271, in sync_from_ui
    order_ids.append(self._process_order(order, False))
                     ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/pos_online_payment/models/pos_order.py", line 78, in _process_order
    return super()._process_order(order, existing_order)
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/point_of_sale/models/pos_order.py", line 151, in _process_order
    return pos_order._process_saved_order(draft)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/point_of_sale/models/pos_order.py", line 161, in _process_saved_order
    self._generate_pos_order_invoice()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File ".../lib/python3.13/site-packages/odoo/addons/point_of_sale/models/pos_order.py", line 1196, in _generate_pos_order_invoice
    invoice.with_context(skip_invoice_sync=True)._generate_and_send()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File ".../lib/python3.13/site-packages/odoo/addons/account/models/account_move.py", line 6770, in _generate_and_send
    wizard.action_send_and_print(allow_fallback_pdf=allow_fallback_pdf)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_peppol/wizard/account_move_send_wizard.py", line 78, in action_send_and_print
    return super().action_send_and_print(allow_fallback_pdf=allow_fallback_pdf)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account/wizard/account_move_send_wizard.py", line 397, in action_send_and_print
    attachments = self._generate_and_send_invoices(
        self.move_id,
        **self._get_sending_settings(),
        allow_fallback_pdf=allow_fallback_pdf,
    )
  File ".../lib/python3.13/site-packages/odoo/addons/account/models/account_move_send.py", line 833, in _generate_and_send_invoices
    self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account/models/account_move_send.py", line 723, in _generate_invoice_documents
    self._hook_invoice_document_before_pdf_report_render(invoice, invoice_data)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_move_send.py", line 132, in _hook_invoice_document_before_pdf_report_render
    ._export_invoice(invoice)
     ~~~~~~~~~~~~~~~^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py", line 46, in _export_invoice
    document_node = self._get_invoice_node(vals)
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_21.py", line 21, in _get_invoice_node
    document_node = super()._get_invoice_node(vals)
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py", line 142, in _get_invoice_node
    self._add_invoice_line_nodes(document_node, vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py", line 240, in _add_invoice_line_nodes
    self._ubl_add_invoice_line_nodes(sub_vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_ubl.py", line 1716, in _ubl_add_invoice_line_nodes
    self._ubl_add_invoice_line_node(sub_vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py", line 222, in _ubl_add_invoice_line_node
    vals['line_node'].update(self._get_invoice_line_node(sub_vals))
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py", line 415, in _get_invoice_line_node
    self._add_invoice_line_item_nodes(line_node, vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py", line 205, in _add_invoice_line_item_nodes
    self._ubl_add_line_item_node(sub_vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_ubl.py", line 1092, in _ubl_add_line_item_node
    self._ubl_add_line_item_name_description_nodes(sub_vals)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File ".../lib/python3.13/site-packages/odoo/addons/account_edi_ubl_cii/models/account_edi_ubl.py", line 929, in _ubl_add_line_item_name_description_nodes
    description = line_name.replace(name, '').strip()  # Remove the redundant product's name from the description.
                  ^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'replace'
```

Desired behavior after PR is merged:
PEPPOL file is generated



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

Forward-Port-Of: odoo/odoo#274034

`_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