Message 22081

Author
albertca
Date
2015-08-10.10:47:25
Message id
22081

Content

2015-08-10 10:35 GMT+02:00 Cédric Krier <issue_tracker@tryton.org>:
>
> Cédric Krier <cedric.krier@b2ck.com> added the comment:
>
> On 2015-08-10 10:00, Albert Cervera i Areny wrote:
>> >> Regarding the API I must say that like Raimon I also see it a little bit complex to have a class per field.
>> >
>> > I never said it is a rule.
>> >
>>
>> That's why I said that maybe it's me that doesn't fully understand how
>> you intend to use the proposed API...
>>
>> Do you intend to have a:
>>
>> class ConfigurationAccounting(_ConfigurationValue, ModelSQL, ValueMixin):
>>     'Party Configuration Accounting'
>>     __name__ = 'party.configuration.accounting'
>>
>> Which would store all party accounting parameters or something like that?
>
> Yes probably.
>

Alright, now I see the database structure is similar in your proposal
and my idea. It also easily supports the creation of a
"Company-dependen fields tab" if that is necessary for some
installations, while keeping standard behaviour as it currently is.

>> >> After all, in the Party model we'll have several fields that depend on company but probably no fields that will depend on warehouse or other parameters.
>> >
>> > So what?
>> >
>> >> Also, probably working on the party module is not a very good example because IMHO both properties should be replaced by simple Many2One fields.
>> >
>> > They can not.
>>
>> What I mean is that I think that default language should not be
>> company-dependent so a simple Many2One on the configuration would be
>> enough.
>
> But this will break the migration path.
>

You're right but still it makes sense to me to remove that behaviour,
and warn users of the change.
History
Date User Action Args
2015-08-10 10:47:26albertcasetrecipients: + ced
2015-08-10 10:47:26albertcalinkissue2349 messages
2015-08-10 10:47:25albertcacreate

Showing 10 items. Show all history (warning: this could be VERY long)