Task 1843603
* src_model is redundant with binding_model_id
* multi -> binding_view_types (if empty => all views) (maybe should be
empty by default yo?)
* in convert, type => rec.get(type) but no @type possible on <act_window>...
* removed deprecated auto_refresh & auto_search (not used anywhere (?))
closesodoo/odoo#24738
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Create a model and extend this model using an inherits. Define a
constraint in the inherited model that uses a field of the parent model.
Create a valid element using the inherited model then write an invalid
value. This pass the constraint although it should raise an exception.
The problem resides in the `write` function of `models.py`. It first
write values on the inherited model then write values on the parent
model. The order is wrong, it should write on the parent model first
then on the child model.
The solution is to change the order fields are written: first we update
child references to their parents, then we update the parents, then we
update the child.
opw-1962705
closes#32919closesodoo/odoo#33003
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When 80f1ac3599 removed deferral of
parent store computations (the MPTT at the time), it also errornously
removed the computation during auto_init.
As a result, when adding a `_parent_store = True` and `parent_path`
field to an existing model (e.g. in an override, or when updating the
database) the column will be created but the column will be
False-filled, and hierarchical queries break as odoo will attempt to
perform string operations on `False` (either `False + '%'` or
`False.split('/')`).
Fix the issue by reintroducing the parent_store computation.
Note: uses the same gating as the old commit, the computation is only
performed if this is the install/update where the parent_path column
gets created.
We could alternatively gate on just _parent_store, but even the RCTE
can be expensive when executed on millions of records (at least when
it has to set all the parent_path) and while it could allow inserting
a bunch of records when calling -u to generate their parent_paths, it
feels like the caller could and would do so manually as they might
have shuffled the tree and need to update more than just the records
for which parent_path is null.
closesodoo/odoo#33034
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Checking access rules only makes sence if we have some records,
_filter_access_rules will always return a subset or current
recordset, and a subset or a empty recordset is an empty recordset.
closesodoo/odoo#32313
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This reverts the saas-12.2 commit as 112bd835d8 was merged in 12.0 and
now is forward ported.
The uninstallation is the only reason it is really problematic to keep
translations (as the id are reset after reinstall).
ba58888ce was slower
closesodoo/odoo#33169
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The activity view has been greatly improved to allow to customize it
more easily. It works quite similarly to the kanban view, defining
`<field>` tags at the top and using these fields in the `<template>`
section. The template name used to define the activity cards is
`activity-box`.
Note that these activity cards are rendered using `KanbanRecord` widget
(this has implied that ActivityView inherits from `BasicView`).
Also note that the view validation has been moved in base to include the
common grammar.
Task 1894990
When doing a copy, create the new translations directly in SQL and handle
potential conflicts.
Conflicts can occure in case of reinstallation as showed in opw-1955062 and
opw-1950117.
In case of "leftovers" of translations (e.g. remaining after the uninstallation
of a module), creating the new translations (when reinstalling the module) may
produce a conflict with (type, name, res_id, lang) and raise an error.
This is NOT a problem of reading .po file during installation (which handles
correctly conflicts) but of business code creating new records and linked
translations (e.g. website copying website.menu records).
Removing old translations during uninstall is handled in a previous commit in
ir.model.fields _drop_column method.
This commit fixes the reinstallation on instances with leftover translations
and fixes the issue without needing a manual intervention (i.e. delete the old
translations manually).
Closesodoo/odoo#32056
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30357
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30356
Reverts 2b1d3ff82d introduced in 10.0 via
It was relatively useful in Odoo 10.0 because in Python 2 the exception
was missing a root cause traceback. But Python 3 includes exception
chaining by default, so it comes for free.
See [PEP3134](https://legacy.python.org/dev/peps/pep-3134/)
On top of being redundant in P3, it can also break some testcases
by causing an extra ERROR log entry, even when the final exception is
expected and caught. So it's simpler to remove it.
closesodoo/odoo#31699
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit introduced a regression in web_studio, discovered at opw-1947380
A fix in web_studio will be integrated too but the regression is the proof this
commit should not have been integrated in 11.0.
While the new behaviour introduced at d855e3911f makes more sense, it is still
a change of behaviour that should not target a stable version.
For the problem raised at opw-1887162 that d855e3911f was trying to fix, a
workaround should be used instead.
For instance, setting a widget='html_frame' allows to translate in the website
editor that handles this correctly.
In master, the new behaviour can be maintained and eventual regressions will be
investigated there.
closesodoo/odoo#31585
Signed-off-by: "Martin Trigaux (mat)" <mat@odoo.com>
[FIX] models: do not erase master version
For a translated field with a callable method (e.g. xml_translate), when
modifying the value of this field in another language than en_US, the master
version was lost.
Before this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Titre</h1>"
>>> record.arch
"<h1>Titre</h1>" # lost English version
After this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Title</h1>" # write had no effect
>>> record.arch
"<h1>Title</h1>"
When modifying a translated HTML field in English, a matching to detect the
difference and avoid losing the translations is done.
This is not supported for update in another language.
The main reason is the difficulty to detect changes in the architecture.
To update translations, the supported way is to go to the list of translations
and update them there.
Before this patch, the given value in another language was given to the SQL
query and made an update in database:
if single_lang or not (has_translation and field.translate is True)
-> True or not (True and False) -> True
If a field is callable, it should also be ignored, the same way than
translate=True fields
opw-1887162
closesodoo/odoo#31451
This commit has been backported in 11.0 [1] and then reverted [2],
because it introduced a regression in web_studio, discovered at opw-1947380
As no forward-port has been done between the backport and the revert,
the forward-port of the revert also contains the patch itself, resulting
in a noop.
Actually revert 06d73eab62 in branch `12.0`.
[1] d855e3911f
[2] 1748b46718closesodoo/odoo#31637
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this patch, any exception raised by a constraint method that
were not of type `ValidationError` were hard to debug, because the
origin line was never logged.
Explicitly logging the error (with traceback) when we catch it
ensures proper contextual info, even in the absence of exception
chaining.
closesodoo/odoo#28612
When an access error bubbles through a related field (aka the user
doesn't have access to the delegate or the delegate's field), append
the "intermediate step" so that it's easier to understand e.g. that
the access error to a partner really comes from accessing a user or
somesuch.
In debug mode, if an access fails due to access rules, try to provide
a clearer error message & include a list of the rules which fail for
the record-set.
Note: for read() operations it'll be a bit misleading as failed
records will get a list of all the rules failing for the recordset,
only some of which might apply to that specific record.
Same logic as for the mail.message or ir.attachment, when a record is deleted,
drop the ir.translations linked to it as well.
Fixesodoo/odoo#25105
Co-authored-by: Raphael Collet <rco@odoo.com>
closesodoo/odoo#30721
Yannick Tivisse