Good Job, I know ypou are working so hard on it, and i trust we will have solved all issues.
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").
A real use case is in our Mexican Localization where we need more field to comply with our electronic invoice.
Hello Oliver.
Good Job, I know ypou are working so hard on it, and i trust we will have solved all issues.
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? FIELDS. append( "myfield" ).
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_
A real use case is in our Mexican Localization where we need more field to comply with our electronic invoice.
Example here:
http:// bazaar. launchpad. net/~openerp- mexico- maintainer/ openerp- mexico- localization/ 6.1/view/ head:/l10n_ mx_partner_ address/ partner_ address. py#L33
WE use them with access rules only in our multi-localization enviroments, with this variable you use, it will be a lot more complicated i think.
I will put comment by comment to avoid big mails with very big complicated/missing important points.