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

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.
by Pedro M. Baeza - 12:20 - 18 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