Related and function manual fields may not be loadable during initial
setup (partial=True) due to dependencies being not loaded. Ignore
theses fields during partial loading.
This reverts commit a206114d4c.
This commit breaks several of our long standing and widely appreciated policy
- one commit for one feature; do not forget to put the correct impacted addon
- commit message should explain why the change is performed
- a bug fix in master seems weird, why not in stable. If not applicable to
stable the commit message should explain why
- a bug fix in the ORM should come with a test case
- code is not clean
When only a message argument is given to the crash manager, the popup display
"Error while validating constarint" and "None" with the warning message
which does not make any sense for the common user.
* ensure groupby domains are normalised, that's significantly more
convenient for subsequent manipulations and combinations (e.g. OR-ing
domains of multiple groups)
* split off "raw" groupby which provides ISO-8601 date and datetime
ranges[0] (half-open) as values for grouped date/datetime fields
for instance when grouping weekwise on a date field, the group
including May 11th, 1930 would have the following value for
the (grouped) date field: `("1930-05-05/1930-05-12", "W19 1930")`[1]
this means callers can access the programmatic date range value
* fix website_mail_channel and website_blog to *not* go and randomly dig
into the domains assuming a bunch of unspecified stuff about its
formatting (such as it not being normalized)
[0] https://en.wikipedia.org/wiki/ISO_8601#Time_intervals
[1] actual week number turns out to be locale-dependent...
- add or fix decorators on methods
- fix most compute methods (wrong dependencies)
- revert changes in `eval_context` of `ir.actions`
- various code simplifications and improvements
- migrate methods that were not
- ir_qweb: modify `QWebContext` to take an environment instead of `cr`, `uid`, `context`
- ir_qweb: convert `AssetsBundle` to use new API `env`
- ir_ui_view: use decorator `multi` on method `read_combined`
- ir_ui_view: ensure that method `render` is never called with an xml_id
- ir_ui_view: factor out part of the `ormcache` key of method `_read_template`
Introduction of 'data_manager' service which handles meta-data related to
actions and views (fields_views, fields and filters). Ideally, all RPCs to
get that kind of information should go through data_manager, as it holds an
internal cache.
Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.
Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.
The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.
Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
heavy processing.
- Remove view_type attribute from views as it was used to call
fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
lifecycle of widgets (init -> willStart -> start -> destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
action buttons to wrap handlers to ensure that they are executed only if
the form_view is the current active view. This is not useful anymore as
from v9, views and their control panel are appended in the DOM
simultaneously, so one can't click on a button of a view which is not the
current active view.
Upgrading a module in the presence of computed custom fields can fail, if a
computed custom field depends on another field from a module that is not loaded
yet. The patch simply prevents custom fields with dependencies from being
loaded in partial mode.
In Odoo 7.0 & 8.0, this was possible to translate
a field label, from `en_US` to `en_US`. It was
used as an easy way to change the fields label,
instead of creating an inherited view changing
the string attribute of the field everywhere it was needed.
This was no longer the case in 9.0,
following the revision 9593a29.
The translated terms for `en_US` have been
excluded, for performance reasons
as it was considered not possible to have
translated terms for the `en_US` language.
The fact is, this is very possible: Nothing
prevents to add a translated term
in `en_US` for a translate-able field,
as this is the case for the fields label,
as mentioned above. This field is then
used as the display value instead of the source
term when being in the `en_US` language.
Besides, the above revision was mainly to
give the possibility to sort a model records
on a translated field, using a join on the translations
table. It was then considered that the join could
be avoided, in the case where the user language was `en_US`,
for performance reasons, but, as this is possible
to give another value to the field value trough
the translations, it should actually be done, even
for the records sorting.
opw-670814
In the case of a `raw_data` export, a boolean which has the value
`False` will not be exported correctly.
The fix handles the `False` value as a valid value for a field.
opw-666142
When generating SQL queries, `column._symbol_c` must be used as placeholder as
for the method 'set' of the column itself. Otherwise it is not possible to
define specialized columns.
Those cases can now appear, since a model inheriting (with `_inherit`) from
another model can observe those extra fields from its parent model's class.
With this subclassing, the MRO of the model class will always traverse `Model`
before `AbstractModel`. This guarantees that inheriting from an abstract model
does not make the current model abstract.
When a model B inherits from model A, any extension of model A should be
visible in model B. We achieve this by:
- making B inherit from the class of A in the registry;
- making model extensions modify the model's base classes.
Christophe Simonis