[19.0][MIG] partner_property: Migration to 19.0#2358
Open
dnplkndll wants to merge 22 commits into
Open
Conversation
…r Company partners TT49480
…ner_property.properties_definition_person) Related to OCA@d3e2fe8 TT49480
Currently translated at 100.0% (7 of 7 strings) Translation: partner-contact-16.0/partner-contact-16.0-partner_property Translate-URL: https://translation.odoo-community.org/projects/partner-contact-16-0/partner-contact-16-0-partner_property/it/
Before this commit, the field properties marked as "Display in Cards" were not displayed in the kanban view. After this commit, the field properties marked as "Display in Cards" are displayed correctly in the kanban view.
…operty field definitions TT56823
Steps to reproduce:
1. Go in the partner or users list view
2. Select a few records
3. Click on Actions > Export
Expected:
The Export wizard should open.
Result:
```
File "/odoo/src/odoo/addons/web/controllers/export.py", line 400, in get_fields
exportable_fields.update(self._get_property_fields(fields, model, domain=domain))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/addons/web/controllers/export.py", line 321, in _get_property_fields
field_to_get = Model._field_to_sql(Model._table, definition_record, self_subquery)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/odoo/src/odoo/odoo/models.py", line 2976, in _field_to_sql
raise ValueError(f"Cannot convert {field} to SQL because it is not stored")
ValueError: Cannot convert res.partner.properties_company_id to SQL because it is not stored
```
Originally attempted to fix it here: 36b93fa But that fix only worked for res.partners due to not properly using the alias in the `_field_to_sql` method. Then, when trying to export res.users (or any model that inherits from res.partner), we'd get the following error: ``` File ".../odoo/addons/web/controllers/export.py", line 324, in _get_property_fields definition_records = target_model.search_fetch( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File ".../odoo/odoo/models.py", line 1781, in search_fetch return self._fetch_query(query, fields_to_fetch) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ".../odoo/odoo/models.py", line 4240, in _fetch_query rows = self.env.execute_query(query.select(*sql_terms)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ".../odoo/odoo/api.py", line 993, in execute_query self.cr.execute(query) File ".../odoo/odoo/sql_db.py", line 582, in execute return self._cursor.execute(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ".../odoo/odoo/sql_db.py", line 357, in execute res = self._obj.execute(query, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ psycopg2.errors.AmbiguousColumn: column reference "company_id" is ambiguous LINE 1: ...TRUE) AND ("res_company"."id" IN (SELECT COALESCE(company_id... ```
…by computed field
Currently translated at 100.0% (7 of 7 strings) Translation: partner-contact-18.0/partner-contact-18.0-partner_property Translate-URL: https://translation.odoo-community.org/projects/partner-contact-18-0/partner-contact-18-0-partner_property/es/
dnplkndll
force-pushed
the
19.0-mig-partner_property
branch
6 times, most recently
from
18345b9 to
20a88c3
Compare
Signed-off-by: Don Kendall <dkendall@ledoweb.com>
dnplkndll
force-pushed
the
19.0-mig-partner_property
branch
from
20a88c3 to
a319fbd
Compare
Author
|
@ivantodorovich @pedrobaeza @victoralmau — this is ready for review. |
Member
|
On 19, there's already properties in the contacts. Why migrating this? |
Author
is adds per company. I could not find any real specific cases to know if that was of value. just getting back into practice doing MIGs will close if there is not a use case for the partner property in company context. |
Member
|
Well, the value of this module is to have different properties per contacts of type company and of type contact, so if that's not respected upstream, then please go ahead and continue with the migration, but add in CONTEXT.md the reason of this module. |
dnplkndll
force-pushed
the
19.0-mig-partner_property
branch
3 times, most recently
from
d3344b3 to
6011a5c
Compare
Author
added the verified impact in CONTEXT.md |
dnplkndll
force-pushed
the
19.0-mig-partner_property
branch
2 times, most recently
from
37f495a to
79bf6c7
Compare
BhaveshHeliconia
suggested changes
Jun 2, 2026
Contributor
BhaveshHeliconia
left a comment
BhaveshHeliconia
left a comment
There was a problem hiding this comment.
In Odoo 19, properties added from the Contacts form are displayed on all contact records, regardless of any other criteria.
This module extends that behavior by allowing properties to be associated with a specific company_type. As a result, a property created for contacts with company_type = 'company' will only be displayed on contacts of that type and not on contacts with a different company_type.
Possible enhancements
- The Contacts form currently shows two Add Property buttons: the standard Odoo button and the one introduced by this module. Making them more clearly distinguishable would improve usability.
- Likewise, properties created through the module-specific button could be visually differentiated from standard Odoo properties to make their origin and behavior more obvious to users.
dnplkndll
force-pushed
the
19.0-mig-partner_property
branch
2 times, most recently
from
f8f290a to
8e183fd
Compare
| <field name="model">res.partner</field> | ||
| <field name="inherit_id" ref="base.view_partner_form" /> | ||
| <field name="arch" type="xml"> | ||
| <notebook position="before"> |
Contributor
There was a problem hiding this comment.
Can we add a new notebook tab for this?
- `_search_partner_properties_definition_{company,person}`: refactor to a
shared fallback helper. The 19.0 Domain optimizer normalises
`('field', '=', False)` to `('field', 'in', {False})` before reaching the
search method, so the helper accepts both shapes. Also avoids the
`Domain.TRUE.__bool__` sentinel trap (`cond and Domain.TRUE or
Domain.FALSE` always picked `Domain.FALSE`).
- `_search_properties_company_id`: accept the `in` shape post-optimizer
normalisation in the implicit-match branch.
- `_field_to_sql`: drop the `flush` keyword arg and rename `fname` ->
`field_expr` to match the 19.0 signature.
- Replace `from odoo.osv.expression import FALSE_DOMAIN, TRUE_DOMAIN` with
`from odoo.fields import Domain` (19.0 osv.expression deprecation).
- Add tests for the fallback helper and for the compute/inverse/
web_search_read round-trip on the definition fields.
Signed-off-by: Don Kendall <dkendall@ledoweb.com>
…texts In Odoo 19.0 the web_search_read method is layered onto BaseModel by the web addon at server-startup; direct invocation from a test (no web service mounted) leaves super() without that method, raising AttributeError on the override's super().web_search_read() call. Wrap the super() invocation in getattr(super(), 'web_search_read', None) and fall back to an equivalent search() + read() shape when the web layer isn't present. The domain-rewrite logic above (selecting the current company when filtering by partner_properties_definition_*) runs identically in both paths. Fixes test failure: ERROR: TestResPartnerProperty.test_definition_field_roundtrip_and_web_search
dnplkndll
force-pushed
the
19.0-mig-partner_property
branch
from
8e183fd to
e632163
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Port of
partner_propertyfrom 18.0 to 19.0. Follows the OCA migration guide.Non-mechanical adaptations worth flagging
_search_properties_company_id— 19.0's Domain optimizer normalises(field, '=', value)to(field, 'in', {value})before reaching the search method, so theoperator == '='guard never fired and partners without an explicitcompany_idwere silently excluded from the implicit-match branch. Now accepts both shapes._search_partner_properties_definition_{company,person}—Domain.TRUEis falsy in bool context (sentinel:__bool__returnsnot self.is_true()), socond and Domain.TRUE or Domain.FALSEalways evaluated toDomain.FALSE. Rewrote with an explicit ternary + XOR on(empty, negate). Also accepts thein/not inshapes post-optimizer-normalisation.19.0 relevance
res.partnernow inheritsproperties.base.definition.mixin(single globalpropertiesfield). This module adds per-companyproperties_type_{company,person}fields keyed offenv.company, plus the person/company-type split — distinct from core. Open question for reviewers: expose all three properties fields, or hide the core one.