Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Avatar

Partner Types: refactor partner_firstname and introduce partner_type_base

by
glueckkanja AG., Christopher Rogos
- 16/11/2024 13:52:28

Hi,

 

I would like to promote/discuss a small res.partner refactoring I’ve done on partner_firstname.

 

We are currently unhappy that invoice or shipping address has a firstname. Shipping addresses sometimes needs only a department name, but not necessary Firstname/Lastname.

Therefore I would like to make the UI more flexible and add an overloadable attribute is_individual, where you can control whether firstname/lastname should be visible or not. Other modules could overload the _compute_contact_type method to control the behavior of the different address types.

I also changed the invisible attributes of the UI elements to is_individual and is_address_readonly instead of using directly the address type in the xml views.
The is_address_readonly can be used to control whether the address information is editable for each type. We e.g.  added another address type "contact_address" (e.g. for homeoffice addresses) which is is_individual == True, but also has an editable address like address type "other". We use "other" for office addresses of a company and therefore changed the classification to is_individual == False. With the change of this PR, we just need to adapt the _compute_contact_type method and all the UI fields are rendered accordingly.

With this change, it is also easier to add additional types like “service” which we use for “support@” addresses. They usually don’t have an address (is_address_readonly== True, is_individual==False) and by configure these attributes, the UI adapts correctly.

 

What do you think of these changes? Feedback highly appreciated.

 

[17.0][ADD] partner_type_base by CRogos · Pull Request #1891 · OCA/partner-contact

 

Best regards,

 

Christopher

Follow-Ups