**Current behavior:**
Setting up an automation rule which attempts to clear an m2o field on a record can result in an exception occurring on rule trigger.

**Expected behavior:**
The targeted field is cleared.

**Steps to reproduce:**
*Concrete example: `-i stock,web_studio`
1. Go to the form view for lots/serial numbers

2. Activate studio, add a new Boolean field and a M2o field (on res.partner for sake of example) in the view

3. Create a new automation rule which runs on `stock.lot` like:
* Trigger: `On save`
* Before Update Domain: `Match all records`
* Apply on: `[('x_studio_new_boolean_field', '=', False)]`

4. Add an action to the rule like:
* Type: `Update Record`
* Action Details: `Update x_studio_new_m2o_field to <blank>`

5. Open a lot record, set the new boolean field to True and enter a partner in the m2o field -> save

6. Set the boolean to False then save again -> web error

**Cause of the issue:**
Setting the field to False is actually evaluated as setting it to 0 -> we write `res.partner(0,)` instead of clearing it. At the conclusion of the automation rule being triggered, there is a `web_save()` which returns a `web_read()` on the (in this instance) `stock.lot` record being written on.

Here, once we see the `x_studio` m2o field in the specification, there is a dict comprehension:
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/addons/web/models/models.py#L116-L119 Which calls `cleanup()` on the result of a recursive`web_read()` on `res.partner(0,)` which here is returning {'id': 0}. In `cleanup()`: `vals['id'] == 0 == False` -> Try to access `vals['id'].origin` which, of course, raises an exception.

**Fix:**
For m2o fields, evaluate Falsey expr values in `_eval_value()` to explicit `False`.

opw-4252864

When the user clicks on the checkbox of ``Valuation by Lot/Serial number``,
a traceback will appear.

Steps to reproduce the error:

- Install ``stock_account`` module
- Create a product(type : Goods) > Track Inventory: ``By Unique Serial Number``
- Create one variant of that product
- Now, Open the product in one tab and open the product variant in another tab
- Click on the checkbox of ``Valuation by Lot/Serial number`` in both tabs

Traceback:
```
UnboundLocalError: cannot access local variable 'products' where it is not associated with a value
  File "odoo/http.py", line 2364, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1891, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1954, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1921, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2168, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 517, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/sale_project/models/product_template.py", line 137, in write
    return super().write(vals)
  File "addons/stock_account/models/product.py", line 82, in write
    impacted_templates[tmpl] = (products, description, products_orig_quantity_svl)
```

https://github.com/odoo/odoo/blob/09fa1db600c31d2d04f0504f0412cbbc85ff7e3d/addons/stock_account/models/product.py#L77-L82
Here, the ``products`` variable is referenced before the assignment,
So, it will lead to the above traceback.

sentry-5991310335

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

A traceback occurs when the user tries to close a register having the draft orders.

To reproduce this issue:

1) Open a `furniture register` in the POS
2) Add a `combo product` and close the register
3) Click on Review Orders and delete the existing orders 
4) Now click on the `Back` button and repeat steps 2 and 3 
5) An error occurred in the terminal

Error:-
 ```
IndexError: list index out of range
```

In the `_prepare_combo_line_uuids` the `order_vals['lines']` contains multiple lines. 
For each line, there are two data possibilities of data.

If line[0] contains 0 or 1, the data should be like `[0, 0, {.......}]`, 
if the line[0] doesn't contain 0 or 1 the data should be like `[3, 4]`.

Clearly, it leads to a traceback when the filter is used in `order_vals['lines']` 
and tries to access 2nd index through lambda.

https://github.com/odoo/odoo/blob/82867bc13ea2beb50234ad6e23717ad61d047e7c/addons/point_of_sale/models/pos_order.py#L133-L140

Adding an extra check in the filter will resolve this issue.

sentry-5990190061

When there are no journals and the user tries to open the balance sheet report,
a traceback will appear.

Steps to reproduce the error:
- Install ``account_reports`` module without demo data
- Remove all journals
- Go Reporting > Open Balance sheet

Traceback:
```
StopIteration: null
  File "odoo/http.py", line 2364, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1891, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1954, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1921, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2168, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 728, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 517, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/18.0/account_reports/models/account_report.py", line 1914, in get_options
    initializer(options, previous_options=previous_options)
  File "home/odoo/src/enterprise/18.0/account_reports/models/account_report.py", line 379, in _init_options_journals
    options['journals'].extend(next(iter(company_journals_map.values())))
```

https://github.com/odoo/enterprise/blob/302eb1052609462fe607f77fcc934690f9abbe5a/account_reports/models/account_report.py#L379
When there are no journals ``company_journals_map`` will be empty,
So, it will lead to the above traceback.

sentry-5993507281

The query count in single module build is higher than the one with all modules installed.
- test_mail_enterprise
![image](https://github.com/user-attachments/assets/f77c8725-3899-4e4b-9753-29cc2b742b7d)
![image](https://github.com/user-attachments/assets/fb8005ac-82a0-410e-826f-26ef7a245d3d)
- test_mail_enterprise + documents_project
![image](https://github.com/user-attachments/assets/20e3734f-de2c-4f8b-ae76-6da09b9e73c3)
![image](https://github.com/user-attachments/assets/9dbab0e3-bde5-40c2-af52-e138a8c7b696)

In summary, a one2many fields document_ids on document_projects triggers an [orm optimisation](https://github.com/odoo/odoo/pull/111651/files) leading to 10 less queries.

In 16.0 the query count adapted in an all-enterprise build fails in single module
In 17.0 a regression of performance was missed because a margin is added on a bunch of query count that didn't break in the all-enterprise build

This pr proposes to add a field with the corresponding optimization in the test module in stable, to have reliable query counter. 
This field will be moved to the document module in master. 

RunbotError-65777

Forward-Port-Of: odoo/enterprise#72598