[IMP] base: safer locking at user login
When a users connects, a lock is taken on the res_user table to modify the last login date. If another running transaction uses a foreign key to res.users (e.g. write_uid column), postgres may detect the update as a concurrent update and rollback the transaction.
In pg 9.3, the lock_strength parameter 'NO KEY' allows a weaker lock which is less likely to break another transaction.
Fixes#552
These revs. introduced an API change in the _name_search method.
Indeed, the 'operator' attribute used to have 'ilike' as default value.
This cannot be changed, as every modules overriding this method
overrided it using the signature with operator='ilike'
For instance, _name_search method of addons/base/ir/ir_model.py
expects having 'ilike' as operator.
As it was not anymore the case,
it leaded to a crash when performing a name_search call on the model ir.model,
like when adding a new custom field to a model, from the web client.
opw-626161
Fix kanban:
Move invisible user_id field outside the kanban-box.
Since jQuery migration (1.8 -> 1.11), the function append has not the same behavior.
$([undefined]).append() will crash, so when Odoo whas trying to render the user_ids m2m field in kanban, that crashs.
Anyway, moving the code outside this kanban-box, will avoid to render an invisible m2m_tag.
Misc:
Escape html
concat with %s
This log line is only useful when debugging registry
loading, a limited use case now that Odoo 8 is stable.
It makes the debug log more difficult to read and causes
a small performance penalty when debug[_rpc] is on.
(+0.2s i.e. 10% extra time for loading a registry with 47
modules on a core i5-4200U machine)
[IMP] models: speedup registry loading (25% less time)
The field setup on models is improved: only new-api fields are determined when building the model's class; the final _columns dict is derived from the fields once they are set up. This avoids setting up fields and columns at the same time, and finally overriding columns with the result of field setup.
This branch also fixes the model setup in general: with the former code, a model could be introspected while it was only partially set up, and not all its fields were known.
It incidentally fixes the "loss" of parameter partial that is necessary when loading custom fields. And during a partial setup, one2many custom fields are not introduced if their counterparts (model and many2one field) are not ready.
The model setup sometimes misses entries in _inherit_fields and _all_columns.
This is because those dictionaries are computed from parent models which are
not guaranteed to be completely set up: sometimes a parent field is only
partially set up, and columns are missing (they are generated from fields after
their setup).
To avoid this bug, the setup has been split in three phases:
(1) determine all inherited and custom fields on models;
(2) setup fields, except for recomputation triggers, and generate columns;
(3) add recomputation triggers and complete the setup of the model.
Making these three phases explicit brings good invariants:
- when setting up a field, all models know all their fields;
- when adding recomputation triggers, you know that fields have been set up.
The field setup on models is improved: only fields are determined when building
the model's class; the final _columns is computed from the fields once they are
set up.
1. Remove the mass mailing install checkbox from marketing and sales settings
2. Show the mass mailing settings only when the module is installed
3. Remove the marketing campaign install checkbox from marketing settings
4. Move the marketing_crm module into marketing_campaign
5. Merge the *.po files from marketing_crm with marketing_campaign
a many2many field can open a pop up dialog with different views, such
as form view and list view. when the user click on the create button,
it should hide the list view and display the form view. apparently,
this behavior was hardcoded in the pop up dialog, and broken at some
point between v8 and master.
A proper fix would be to abstract the
view manager behavior as a mixin and use it for the selectcreatepopup
widget, for the one2many view manager and for the viewmanager. But this
will take too much time for now, so a quick fix will do it. (however a
task has been created)
myself.cal_client_id could be False, when not filling in the according field in the general settings screen.
Therefore, trying to strip it won't work, as boolean do not have such method.
Regression introduced during rev. faee926f1b
RPM packages did not pass the tests because the centos prompt changed
and thus did not match the regexp anymore. We now explicitely specify
the prompt in our Dockerfiles to prevent such issues.
Martin Trigaux