On 2018-02-12 10:03, Sergi Almacellas Abellana wrote:
> > If we want to use this feature, yes the fs_values must reflect the sum
> > of what was written by the module.
> I'm not sure if it's worth to implement it. Let me explain: Currently we
> are forced to update a record definition of the same module because the
> new kind is not defined on the same module but on another one. The
> problem is that account_es doest not depend on account_deposit and we
> don't want to add the dependency. Normally this is fixed by adding the
> code on a third module that depends on both modules.
I think there are use cases where it will be useful just like the
"depends" attribute on record because it increases the modularity.
Indeed I think we could extend the "depends" to the "field" tag and have
something like this:
<field name="kind" depends="account_deposit">deposit</field>
The parser should use the latest value matching the condition.
> I don't think there are so much uses cases for defining the same record
> (with different values) on two different modules. Indeed I can not see
> any other usage that fixing this issue.
No because it is an hack but having values depending on the modules is a
> For me it will be simpler to define the deposit kind on the account
> module (so CoA modules can define accounts with the deposit kind). I
> don't see any drawback of allowing this kind on the account module.
I think it is a too simple solution which does not scale.
On another point of view, the kind attribute is maybe the problem. A
selection field is maybe too limited and we may need a multiselection.
But using a Many2Many field will not be good for performance so we may
need to find a way to create MultiSelection fields.
Cédric Krier - B2CK SPRL
Tel: +32 472 54 46 59
You received this message because you are subscribed to the Google Groups
To view this discussion on the web visit