On 2013-04-09, Nhomar wrote:
> Some comment regarding the extensiveness for localization.
>
> In line :
> 19 +ADDRESS_FIELDS = ('street', 'street2', 'zip', 'city', 'state_id',
> 'country_id', 'type')
>
> This variable will be able to change in what way?
> It is a tupple, and it can not be used in multi-localization enviroments, I
> think a List is a best approach, in this case we can make in our localizations
> a simple ADDRESS_FIELDS.append("myfield").
Good point! The idea for localizations is to instead inherit the _address_fields() method that was added in this merge proposal on the res.partner model. The ADDRESS_FIELDS is meant to be an implementation detail of res.partner, and I'd rather not change its type. I've just fixed _address_fields() so it returns a proper list, to make inheriting easier, and updated _display_address() to use it.
This is very similar to what Julio's merge proposal does (as mentioned by Moisés, thanks!), so I updated the corresponding bug report as well.
On 2013-04-09, Nhomar wrote: FIELDS. append( "myfield" ).
> Some comment regarding the extensiveness for localization.
>
> In line :
> 19 +ADDRESS_FIELDS = ('street', 'street2', 'zip', 'city', 'state_id',
> 'country_id', 'type')
>
> This variable will be able to change in what way?
> It is a tupple, and it can not be used in multi-localization enviroments, I
> think a List is a best approach, in this case we can make in our localizations
> a simple ADDRESS_
Good point! The idea for localizations is to instead inherit the _address_fields() method that was added in this merge proposal on the res.partner model. The ADDRESS_FIELDS is meant to be an implementation detail of res.partner, and I'd rather not change its type. I've just fixed _address_fields() so it returns a proper list, to make inheriting easier, and updated _display_address() to use it.
This is very similar to what Julio's merge proposal does (as mentioned by Moisés, thanks!), so I updated the corresponding bug report as well.
Thanks for spotting this!