[FIX] util/orm: Fix non store field issue

[sagu-odoo]

Since 18.3, domain resolution goes strictly through _search

    domain.optimize_full(model)
    if not domain.is_true():
        query.add_where(domain._to_sql(self, self._table, query))

optimize_full() leaves a leaf untouched when the field has no search= defined, so _to_sql() calls field.to_sql() directly. For non-stored fields this now raises:

   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5256, in _order_to_sql
    term = self._order_field_to_sql(alias, field_name, sql_direction, sql_nulls, query)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5315, in _order_field_to_sql
    sql_field = self._field_to_sql(alias, field_name, query)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 2930, in _field_to_sql
    sql = field.to_sql(self, alias)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields_textual.py", line 395, in to_sql
    sql_field = super().to_sql(model, alias)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1216, in to_sql
    raise ValueError(f"Cannot convert {self} to SQL because it is not stored")
 ValueError: Cannot convert photovoltaics.installer.name to SQL because it is not stored

Previously (pre-18.3), such leaves were treated as always-true instead of raising:

https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/odoo/osv/expression.py#L1180-L1187

Since we don't always know if a custom/third-party field is stored or searchable, assign a dummy search= returning an always-true leaf (e.g. [(1, '=', 1)]). This makes optimize_full() resolve the domain to is_true() before _to_sql() runs, restoring the old behavior and avoiding the ValueError.

[robodoo]

[sagu-odoo]

upgradeci retry with always base in all versions

[KangOl]

upgradeci retry with always only base

[sagu-odoo]

same goes with orderby
https://github.com/odoo/odoo/blob/48966d10d6d7d478be2bfaffaf060c0e11201c6f/odoo/models.py#L5256

[KangOl]

Not sure that it should be handled here. It looks like it can be handled by a specific script.
Either the field should be stored, or it should not be used in domains.

[sagu-odoo]

@KangOl FYI here is tbg https://upgrade.odoo.com/odoo/tbg/2822

Either the field should be stored

The thing is, we cannot be sure whether the client’s fields are searchable or not, as this entirely depends on their custom code.

I think we should fix this generically by patching the same behavior in mock_crawl or here. Since we cannot reliably determine whether a field is searchable, and marking the field as manual is what causes the issue here, it would be better to handle it at this level. This was not the case previously, as mentioned in the description.

It looks like it can be handled by a specific script.

that's already being managed by adding the failing menus to env variable skip_menus