The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
Changed render_att_att to return an iterable of pairs instead of a pair, and
dispatched t-att on whether its result is a Mapping.
Also changed qweb test runner so it uses ordereddict for JSON mapping in
params, otherwise iteration order (and thus order of attributes in output) is
unpredictable and results don't/can't match expectations (as both are
strings).
Note that this relies on JS implementation details wrt iteration order of
mappings. Tests would probably be somewhat less brittle if rendering output
was parsed to XML... if that's possible (?)
In t-field, datetime fields (formatted and not formatted versions) are
converted to the context/user's timezone (through
fields.datetime.context_timestamp) when displayed, but were saved without
converting back so the next display would go forward (or back) of the user's
tzoffset.
Fix that by applying context_timestamp's conversion backwards, from the
context/user's timezone back to UTC, before saving the field's value.
We always want to escape quotes (") as part of the process of
generating HTML output. This option (quote=True) turned into
an implicit flag with a DeprecationWarning in werkzeug 0.9.0
It is likely to disappear in a future release of werkzeug too.
A wrapper avoids this warning without loss of compatibility
Instead of doing a name_get on the edited value and trying to find out
an m2o to assign back (which there's pretty much no chance of given
there's no autocompletion or anything), alter the m2o record in-place
by setting the provided edited value to its _rec_name.
Ideally, both features could be supported via more advanced m2o
edition widgets which would allow selecting an existing m2o, creating
a new m2o record from scratch or (maybe) editing the existing m2o's
display_name if possible, somewhat similar to what the form view
provides.
Without these though, the only action which makes any sense is to edit
the user-visible "value" where it is found, as with more normal
fields.
bzr revid: xmo@openerp.com-20131218140917-4eo2o55yfcumzhov
A placeholder is looked up:
1. in the field's options ("placeholder")
2. on the t-field node itself (@placeholder)
3. on the field's column (.placeholder)
The first one found is used as the @placeholder of the resulting node
(in-HTML), and displayed when the field is empty and unfocused.
If no placeholder is found, an empty field just gets a small padding
in order to be easier to see & focus.
bzr revid: xmo@openerp.com-20131218114901-xi3ye11x5pysq2a2
Raphael Collet
Denis Ledoux
Xavier Morel
Fabien Meghazi
Olivier Dony
Richard Mathot
chm@openerp.com
Christophe Simonis
Simon Lejeune
Christophe Matthieu
Fabien Pinckaers