2015-08-10 10:35 GMT+02:00 Cédric Krier <firstname.lastname@example.org>: > > Cédric Krier <email@example.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.
|2015-08-10 10:47:26||albertca||set||recipients: + ced|
|2015-08-10 10:47:26||albertca||link||issue2349 messages|
Showing 10 items. Show all history (warning: this could be VERY long)