Can be defined to False in any model to completely
disable translations for this model, when they are
irrelevant. This is useful e.g. for test classes
that use attributes that would normally be translatable.
This was added in master-apiculture at f1f16a8 to
permit special function fields that return
structured JSON-like data.
This is unnecessary and caused typing problems, for
example for the type field of ir.model.fields, or
when you decide to store them.
It is simpler to explicitly declare these fields
as fields.Char and have them serialize their results
to JSON strings, or to declate them as fields.Binary
and return any opaque data they want.
element.{text,tail} are either ascii-compatible `str`, or `unicode`
when non-ascii-compatible. This could force the implicit decoding
of utf-8 encoded contents when joining template bits, breaking
the rendering.
Fixes#1085, and related to #1130
function start, line 783, filters_ready waits for fields_view_get deferred to be resolved before calling prepare_filters, which prepare the view filters.
The thing is that, at line 416, if this.headless boolean is true, the searchview is marked as ready (by resolving the this.ready deferred), and the fields_view_get deferred will never be resolved, as it is resolved in the else case, where the this.headless boolean is false.
Therefore, in this.headless true case, this prevents the deferred $.when(this._super(), filters_ready) to be resolved, as the deferred filters_ready will never be resolved. Therefore, the deferred returned by the start function is never resolved, and the searchview will never be regarded as ready neither.
In views.js, the ViewManager is marked as ready when the deferred manager_ready = $.when(searchview_loaded, main_view_loaded, this.view_completely_inited) is resolved. In the this.headless true case, as the searchview is never marked as ready, the manager isn't neither.
This leaded to some issues, like the action buttons in form views being disabled on click, and never re-enabled once the action/wizard executed. See opw-610723
Users don't care for the backorder picking precisely because they can't process it, whereas they may have to do some more things on the picking they processed: invoice it, print delivery orders or transportation stickers..
Refresh the browse record after changing the name to avoid the need to rebrowse.
Fixes#1372
When creating a new message, we need to reset the default_type key to avoid context propagation (e.g. invoice menu).
However we used to compare the key in context (char) with the list of selections (tuple) so it was never matching and always reset.
An ir.value without condition should not match when searching with a condition.
When a field with change_default on it is modified, the method get_defaults is called with the new value. This means that manually modifying a field with this trigger would put back the default value (opw 611193).
of switching back to default screen.
This is used by the soon to be merged restaurant addon to create new orders
and display them at a particular screen. However, this behaviour is more
confusing in the other cases, so I'll think of a better way to solve this.
[FIX] Temporary disable addons subcommand auto discovery
The problem with the current approach is that it imports all modules in
order to discover which one exposes a subcommand by subclassing
openerp.cli.Command. At that time, the arguments are not parsed in order
to setup the config because a subcommand could potentialy alter the
command line arguments (which is the case of start)
This behavior causes the modules to be imported with the default config and all
the modules using some config keys at startup won't have to value they
are supposed to have when considering the shared command line switches.
Long story short:
$ odoo --workers=6
is ok, but
$ odoo start --workers=6
is not for code that checks the config value at startup (eg: report module)
As the automatic subcommands are not used yet, we temporary disable it
until as proper solution is found.
The goal is to avoid any kind of prefetching
of other fields when copmuting the default
company, as this will sometimes happen in the
middle of a database update, when the default
company is used for setting the default value
of new columns. In that case the db schema
may not fully match the in-memory model, leading
to an SQL error.
Olivier Dony