- Mailing Lists
- Contributors
- Partner Types: refactor partner_firstname and introduce partner_type_base
Contributors mailing list archives
contributors@odoo-community.org
Browse archives
- By thread
-
By date
- November 2024 103
- October 2024 121
- September 2024 62
- August 2024 70
- July 2024 104
- June 2024 160
- May 2024 40
- April 2024 63
- March 2024 104
- February 2024 111
- January 2024 75
- December 2023 46
- November 2023 94
- October 2023 101
- September 2023 91
- August 2023 103
- July 2023 64
- June 2023 92
- May 2023 69
- April 2023 47
- March 2023 106
- February 2023 49
- January 2023 93
- December 2022 50
- November 2022 39
- October 2022 152
- September 2022 73
- August 2022 38
- July 2022 141
- June 2022 87
- May 2022 59
- April 2022 31
- March 2022 68
- February 2022 77
- January 2022 98
- December 2021 75
- November 2021 74
- October 2021 66
- September 2021 68
- August 2021 50
- July 2021 123
- June 2021 86
- May 2021 90
- April 2021 73
- March 2021 146
- February 2021 87
- January 2021 38
- December 2020 159
- November 2020 100
- October 2020 277
- September 2020 193
- August 2020 94
- July 2020 85
- June 2020 158
- May 2020 50
- April 2020 172
- March 2020 121
- February 2020 210
- January 2020 58
- December 2019 35
- November 2019 97
- October 2019 165
- September 2019 118
- August 2019 86
- July 2019 56
- June 2019 124
- May 2019 77
- April 2019 84
- March 2019 64
- February 2019 53
- January 2019 80
- December 2018 64
- November 2018 31
- October 2018 55
- September 2018 69
- August 2018 28
- July 2018 52
- June 2018 34
- May 2018 81
- April 2018 98
- March 2018 47
- February 2018 77
- January 2018 70
- December 2017 64
- November 2017 159
- October 2017 118
- September 2017 161
- August 2017 18
- July 2017 41
- June 2017 56
- May 2017 106
- April 2017 110
- March 2017 112
- February 2017 69
- January 2017 94
- December 2016 115
- November 2016 132
- October 2016 264
- September 2016 124
- August 2016 143
- July 2016 44
- June 2016 137
- May 2016 84
- April 2016 80
- March 2016 130
- February 2016 98
- January 2016 109
- December 2015 140
- November 2015 189
- October 2015 335
- September 2015 136
- August 2015 208
- July 2015 43
- June 2015 64
- May 2015 8
Partner Types: refactor partner_firstname and introduce partner_type_base
byHi,
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
-
Re: Partner Types: refactor partner_firstname and introduce partner_type_base
byTecnativa. S. L., Pedro M. Baeza