Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: Partner Types: refactor partner_firstname and introduce partner_type_base

Archives

Contributors

RE: Partner Types: refactor partner_firstname and introduce partner_type_base

Re: Partner Types: refactor partner_firstname and introduce partner_type_base

Touching to have that 3 level hierarchy is not recommended, as other things depend on that hierarchy, and you won't obtain the desired partner on the corresponding parts.

Regards.

El dom, 24 nov 2024 a las 16:26, Christopher Rogos (<notifications@odoo-community.org>) escribió:

Hi Pedro,

 

I understand your intension regarding a partner_name_split module, but I am not sure if merging partner_firstname, partner_second_lastname, partner_middlename into one module would make the module to complex. The partner_firstname tests are already complex. Adding more configurable  cases could make the module very complex in development, if there is not a very clear definition how the splitting should work in each case.

 

Maybe we could add a partner_name_split module, which adds some configuration options and controls the installation of these existing modules?

 

But this is all going a lot further than the change I like to make at this point. I just want to add different address types like “partner_address” (contact with firstname/lastname but editable address) order “service” (only name and no editable address). The idea is to have better filter options and more control, when we have firstname/lastname and when we have only name.

 

There is also a lot of inconsistencies in Odoo. e.g. you can add a subcontact to a individual, but you cannot select an individual as a parent. Therefore another attribute like “can_be_parent” would be nice, because we use “other address” to track addresses of offices, and want to add the employees to each office. But therefore “other_address” needs to be selectable in “parent_id”, but currently only is_company is selectable in standard.

 

Best Regards

 

From: Pedro M. Baeza <notifications@odoo-community.org>
Sent: Montag, 18. November 2024 12:24
To: Contributors <contributors@odoo-community.org>
Subject: Re: Partner Types: refactor partner_firstname and introduce partner_type_base

 

Yeah, I also feel that we should refactor into a "contact name splitting" module, for parameterizing which fields to show and with which goal. For example, having first name and second name, initials, and so on. This can depend on the country or other. I think this also fits with your use case.

 

Regards.

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Pedro M. Baeza - 08:16 - 25 Nov 2024

Reference

  • Partner Types: refactor partner_firstname and introduce partner_type_base

    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

    by Christopher Rogos - 01:56 - 16 Nov 2024