I think it is better to remove the default configuration than adding so much code to deal with property (which should be removed).
Also it is probably better to manage default language of party at the company level or system level.
The issue for me is the fact that the language field on party is a property field: i don't understand the need: do we want a party to have different language according the company (i don't see the need).
If we come back to the previous model where lang was a many2one (initialized with the default method) there will be no issue and we keep the functionnality to define default language per company (configuration language will still be a property field)
It is normal that the language on party depends on the company because this field is a compromise between the languages the party spoke and the languages the company spoke.
Any way, the odds of default value will be fixed when #2349 (closed) is resolved.
But still I think a default value doesn't really make sense for this field, and it is better to leave the language empty and to choose a default language dynamically depending of the context like for printing an invoice we take the company language etc.
Cédric Krieradded 1 deleted label and removed 1 deleted label
"It is normal that the language on party depends on the company because this field is a compromise between the languages the party spoke and the languages the company spoke."
I was thinking that language on party is the language to use to communicate with this party and for me this language is independant of the company (or could be dependant if is a subset of companies available languages)
"Any way, the odds of default value will be fixed when #2349 (closed) is resolved."
Yes but in 3.8 you annonced: 'The language of the party depends on the company now.' But this is not working. At least you need to fix it in 3.8 until a better implementation
"But still I think a default value doesn't really make sense for this field, and it is better to leave the language empty and to choose a default language dynamically depending of the context like for printing an invoice we take the company language etc."
I don't agree: that means that tryton user has to know the default value for each company??? and only set the value if it's different. It's better to always set the value: explicit is better than implicit.
On 2016-01-27 11:31, FLangevin wrote:
> "It is normal that the language on party depends on the company because this field is a compromise between the languages the party spoke and the languages the company spoke."
> I was thinking that language on party is the language to use to communicate with this party and for me this language is independant of the company (or could be dependant if is a subset of companies available languages)
No it could depend on the company because you don't have necessary one
people in each companies that speak all the languages.
> "Any way, the odds of default value will be fixed when #2349 (closed) is resolved."
> Yes but in 3.8 you annonced: 'The language of the party depends on the company now.' But this is not working. At least you need to fix it in 3.8 until a better implementation
For me, there will be no fix on 3.8. It is a behaviour issue that could
be overruled by setting manually a value.
> "But still I think a default value doesn't really make sense for this field, and it is better to leave the language empty and to choose a default language dynamically depending of the context like for printing an invoice we take the company language etc."
> I don't agree: that means that tryton user has to know the default value for each company??? and only set the value if it's different. It's better to always set the value: explicit is better than implicit.
No that's not at all what I mean. I mean if the user doesn't know which
language to set, it is better to leave it empty than putting a value.
"For me, there will be no fix on 3.8. It is a behaviour issue that could
be overruled by setting manually a value."
Ok but in this case how you explain that there is a default_lang in party configuration that is doing nothing. This is the bug. Users will not understand that settings this value is not initializing the party lang.
On 2016-01-27 14:33, FLangevin wrote:
> "For me, there will be no fix on 3.8. It is a behaviour issue that could
> be overruled by setting manually a value."
>
> Ok but in this case how you explain that there is a default_lang in party configuration that is doing nothing. This is the bug. Users will not understand that settings this value is not initializing the party lang.
I will explain that there is a bug and it will maybe be fixed in the
next version.