The context was containing a dictionary under the key `install_mode_data`,
which was informing about the model, xml_id, module, filename. Actually only
the module and filename were necessary, and the others were slowing down the
import because of generating artificially different environments.
The context now has two entries `install_module` and `install_filename`.
The `position='move'` has been introduced to move an element in an inherited
view.
It's used as
<xpath expr="//@target" position="after">
<xpath expr="//@node" position="move"/>
</xpath>
or also
<field name="target_field" position="after">
<field name="my_field" position="move"/>
</field>
The xpath with a position `after`, `before`, `inside` or `replace` can thus now
have another xpath as *direct* child with position `move`.
Before this fix, the _convert method use the context of the qweb rendering
instead of use the record context.
'date' and 'company' are automatically set as option for the field. The
template who use t-esc with the widget monetary must define the options.
The bug is introduce by https://github.com/odoo/odoo/commit/7a282c99655d4f154ac1808fcb8a70339dc70930
The use of id and model reference was inconsistent for this variable, depending on the content of the context. Doing this caused a failure when trying to load some financial reports (> Balance Sheet, Spanish reports, ...) of accounting in multi company, if both companies had not the same currency.
An active user could not see messages in its inbox if his partner is
archived. With this commit, we cannot archiving a partner linked to an
active user anymore.
In the opposite way:
-if we deactivate a user, warning message is given saying the related
partner will stay active. A link to the related partner is also given
if we really need to archive it;
-if we activate a user, the related partner will be set as active;
This commit is linked to task ID 46158. Closes#24628.
Endpoints can be explicitly marked as `save_session=False` (default is
true across the board). In that case they will have an in-memory session
(either the existing one or a brand new one) but the session won't be
persisted to disk.
Currently used for non-browser RPC endpoints: the APIs don't use
cookies/sessions and we can't assume the RPC libraries keep cookies
across calls. This means a new session is created and saved to disk for
each RPC calls, for no useful reason.
Before this patch, early connections made to a 11.0 Odoo server running
on Python 3 and deployed in threaded mode with socket activation would
generate invalid registries.
With this patch it is now possible, when this deployment mode is used,
to opt-out addons preload by setting the following environment variable:
ODOO_PRELOAD_ADDONS=no
Note: this environment variable is only available for v11.0 as later
versions does not preload anymore (cf: 1a39c9b)
* export benches for m2o
* tag benches instead of requiring editing the source to enable them
* dump the profiling stats intead of saving to disk (less convenient
for complex analysis but way more so for simple overview)
* add M2O benching in addition to the existing integer-based one in
order to expose problematic behaviour when exporting significant
numbers of non-shared relational records (& quantify impact of
creation v read)
Following odoo/odoo#22493 the performances of exporting XIDs was
greatly improved by batching XIDs and avoiding the ~3 SQL queries per
xid/record when no xid exists yet.
*However* the batching was done per call of _export_rows and to handle
relational fields _export_rows calls itself recursively leading to
sub-standard xid batching:
* for M2M and O2M fields, some batching would happen on a
parent-record basis, each M2M or O2M field (in a parent) would be
xid-batched, but two parent records wouldn't see their children
xid-batched together
* for M2O, there would be essentially no batching with a call to
__ensure_xml_id per record and while less queries than before in the
worst case more complex ones in fact
Change: rather than ensure XIDs exist when performing the export, add
XIDs export as a post-processing of the exported records table. This
way, each involved model can be entirely batched and exporting 10000
records's (id, value_id/id) 2 calls instead of 10001.
Also rename _export_rows's recursion parameter for clarity, it has
clearly outgrown its use as a batch invalidation flag and the name
is now less than clear.
Furthermore _-prefix & mandate kwarg usage to make it clearer it's not
really a "public" parameter, and is intended as an internal recursion
flag.
* store hashed passwords in the `password` column but gate it behind a
computed field
* make the password field essentially write-only (SQL aside)
* add a "plaintext" hash type so it's possible to set the password in
SQL directly & be able to login & have it automatically updated
Task 34211
Purpose
=======
The method _name_search and _search add support to search as another user.
All the overrides of name_search and search redefine the behavior of the search.
This bring inconsistencies as the result of a call to _name_search and name_search
could differ on certain modules, which is not acceptable.
Specification
=============
Example:
~~~~~~~~
If the name_search method is overridden to search also on the driver name,
then calling name_search with a label 'JF' will return all the cars with a name containing
'JF' or all the cars with a driver name containing 'JF'. Let's say that we have a ir.rule
preventing a user to read the cars of another company. Then the call to name search only returns
the cars satisfying the previous condition AND belonging to his company.
Now, we want to overpass this constraint. We call _name_search with the attribute name_get_uid=1.
Then the call to _name_search returns all the cars from all the companies with a name like 'JF',
but nothing is done about the driver_name.
Example of wrong search redefinition on a model
-----------------------------------------------
@api.model
def name_search(self, name, args=None, operator='ilike', limit=100):
domain = args or []
domain = expression.AND([domain, [('name', 'ilike', name)]])
partners = self.env['res.partner'].search([('name', operator, name)])
if partners and name:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partners.ids), ('driver_id', '=', False)]])
rec = self.search(domain, limit=limit)
return rec.name_get()
Example of correct search redefinition on a model
-------------------------------------------------
@api.model
def _name_search(self, name, args=None, operator='ilike', limit=100, name_get_uid=None):
domain = args or []
domain = expression.AND([domain, [('name', operator, name)]])
partner_ids = self.env['res.partner']._search([('name', operator, name)], access_rights_uid=name_get_uid)
if partner_ids:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partner_ids), ('driver_id', '=', False)]])
rec = self._search(domain, limit=limit, access_rights_uid=name_get_uid)
return self.browse(rec).name_get()
The same logic should be applied on the overrides of the search method.
We want to break the dependency between stock and purchase
for our furtur developpement. For more modularity, a new
bridge module 'purchase_stock' is created.
This commti move part of business code, views, data, ...
related to stock management from purchase into purchase_stock
without changing any feature.
Task #47927
Starting with the 1000th user, the kanban view returns the id value
as '1,001', which, for some reason, does not go well when trying to
find the attachment by url...
Use `raw_value` instead, which does not format the id value.
Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.
Backported from fd4939dc78
Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.
When the runbot spawns an Odoo instance, a CPU TIME limit is set.
When this limit is reached, the kernel kills the Odoo instance and no
message appears in the logs leaving the dev in a deep smoke cloud.
With this commit, the signal sent by the kernel when the soft
limit is reached (SIGXCPU), is intercepeted and Odoo shutdown gracefully with a
nice message for the dev.
qdp-odoo