Message 22081

Message id


2015-08-10 10:35 GMT+02:00 Cédric Krier <>:
> Cédric Krier <> 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.
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)