A Dijous, 15 de desembre de 2011 14:32:36, Cédric Krier va escriure:
> Reviewing the issue2345 [1], I came to the conclusion that we must
> remove the Property fields. The design is wrong as Albert pointed and we
> can replace it by something more explicit and efficient.
>
> All the current Property fields are used for multi-company only.
> So my idea is to replace them by Function field that will use a table to
> store the value (with the company if needed).
> For the default value, I think depending of the cases we could use the
> same design as on product when it must use the category values, so
> simply a check box and store it on a Singleton.
> For the search, we will be able to reuse the ORM of Tryton and for now
> it will use a clause "id IN" (could be done with the SQL query). But I
> think once we will have python-sql intergrated we will use a python SQL
> clause.
>
> This work can be done incrementally by changing Property fields one by
> one. So if you plan to help on this, please fill an issue before
> starting and link it to issue2349 [2].
Don't know if I understood this correctly, but given how usual this need is it
may be worth to create a new field type (inheriting Function, possibly) that
encapsulated that work?
For example, I think translations should also be handled with the same
mechanism. So you'd have a field type in which you say that the given value
depends on the context:
name = fields.Property(fields.Char('Translatable Name'), context_key='lang',
model='ir.lang')
or
value = fields.Property(fields.Many2One('Company Dependant Value'...),
context_key='company', model='company.company')
I mean, we may end up with a hundred of those fields so it may be worth
encapsulating that work somehow. What do you think?
> [1] https://bugs.tryton.org/issue2345
> [2] https://bugs.tryton.org/issue2349
--
Albert Cervera i Areny
http://www.NaN-tic.com
Tel: +34 93 553 18 03
http://twitter.com/albertnan
http://www.nan-tic.com/blog
--
[email protected] mailing list
