[18.0] partner_firstname: Observations

[CRogos]

Module

partner_firstname + odoo base

Describe the bug

There are currently several limitation extending the partner form. There are also some inconsistencies and limitations in odoo base which makes it hard to extend res.partner form multiple times.

1. Firstname and Lastname is added invoice/delivery/other address
   In Odoo, only the contact type has Tital and Job Position available. Therefore firstname/lastname should only be added to contact?

2. There are modules, which add contact types:
   account_followup (EE)
   l10n_es_edi_facturae (CE)
   Both should not have a firstname/lastname in my opinion.
   But there might also be modules, which should have firstname/lastname. e.g. We have a custom module, which adds a type "Contact Address" which has should be a "Contact" but with an editable address. But I do not want to add a dependency to partner_firstname, because this module can also be used on databases without firstname/lastname.

3. Limitation to extend view_partner_form from multiple modules:
   If you want to adapt the visibility of an field. e.g. function, because it should also be displayed on "Contact Address", you can overwrite it with an xml view from one module, but if you have another module, which needs to overwrite the same value again, this is not possible.

4. Required Fields is not working
   Doesn't matter which setting I choose, setting firstname or lastname is sufficent, evenn First Name and Last Name is required.

Even worse, the visibility of function is not consistent within the odoo code view. (nightmare)
In the main form it is:
<field name="function" placeholder="e.g. Sales Director" invisible="is_company"/>

and further below it is:
<field name="function" placeholder="e.g. Sales Director" invisible="type != 'contact'"/>

To Reproduce

Affected versions:
18.0 and other

Expected behavior
We should add a base cleanup module, which introduce calculated fields, that can be overloaded. All views should only link to one attribute.
If we can find/agree on a solution, I could do the coding.

Additional context
Of cause part 3 should be best fixed in odoo base, but no success so far...
odoo/odoo#209101
odoo/odoo#231581

cc: @legalsylvain , @remi-filament

[CRogos]

Could someone please reopen this issue, because only Part 1 is (partly) solved by the PR.

The validation works, but there are now two different error messages, depending if you leave firstname or lastname empty, when both are required.

cc: @chetan137

[legalsylvain]

Configuration :

Test 1 :

Test 2 :

did'nt reproduced your bug.
(tested on runboat, removing second last name module).

[CRogos]

@legalsylvain I've tested it also on the runboat database, but only installed firstname_lastname and contact module.

@pedrobaeza do you have the right to reopen this issue?

[chetan137]

Yes, validation is working as expected. The point raised is about UX consistency: since firstname and lastname are required together, it would be better to show a single, consistent error message instead of field-specific ones. That can be improved in a follow-up if needed.

[remi-filament]

Issue / RFC is not related to above PR and should be reopened.

Thanks @CRogos for raising this as an issue / RFC after the discussion we had about your v18 implementation and rollback.

As already stated, I understand your point, and it for sure make it simpler to overwrite views using computed booleans to determine whether address should be editable or not, name should be split in first and last name or not, etc.

As reported by Odoo in the first PR you list above, you can still override an invisible / domain using separator and add (cf odoo/odoo#209101 (comment))

The question for me is whether updating these views happens a lot or not (because depending on the frequency, it is big burden or not). It is for sure necessary every time you would add a new contact type or want to modify the default behavior for existing contacts. In my experience this does not happen so often (maybe 5% of our integrations so far).

I think we could have a base module computing a few variables but it should ends up with the same default configuration we have without this module installed, and could then be overriden to change default behaviour.

Potentially using such a module would become a dependency of many other in partner-contact repo, like partner_address_street3, partner_contact_*

[CRogos]

I think we could have a base module computing a few variables but it should ends up with the same default configuration we have without this module installed, and could then be overriden to change default behaviour.

Potentially using such a module would become a dependency of many other in partner-contact repo, like partner_address_street3, partner_contact_*

This is the exact intention of https://github.com/OCA/partner-contact/tree/18.0/partner_type_base . Because we now reverted the is_indivisual attribute conflict in partner_firstname, we could also keep partner_type_base and change this module to work "transparent" in default. Meaning that the behavior of Odoo does not change when installing this module. I thought I've also implemented it this way, but maybe I've missed something?

Regarding the separator attribute in views, I don't think this is flexible enough. I think the result of the two additional conditions would depend on the installation order?
If module A needs to add a condition or type=='custom'
And module B needs to add a condition and country_id==1

=> base_condition or type=='custom' and country_id==1
vs. base_condition and country_id==1 or type=='custom'

(Maybe it is possible, but my brain got twisted to much on thinking this to the end, and I loved partner_type_base)

The question for me is whether updating these views happens a lot or not (because depending on the frequency, it is big burden or not). It is for sure necessary every time you would add a new contact type or want to modify the default behavior for existing contacts. In my experience this does not happen so often (maybe 5% of our integrations so far).

New types are introduced in enterprise/account_followup, odoo/l10n_es_edi_facturae, OCA/partner_contact_type_end_user.
In our DB we introduced type "service" for external helpdesk contacts, "contact_address" for individuals with another address as the parent, and we use the type "other" like an address of a branch of the parent company. Therefore other can also be selected as parent of a contact.
When you have a look on the contacts from the mass_mailing perspective, you want to ensure that you don't send mails to addresses like info@..., support@..., invoice@... . Therefore you contacts need to be classified correctly, which is easier with more types.

[CRogos]

@NL66278 can you reopen this issue? It was automatically closed and I cannot reopen it.

[CRogos]

@OCA/partner-contact-maintainers are you able to reopen this issue?

[NL66278]

As a base for discussing I reopen this issue.