Steps to reproduce the bug:
- Let's consider a new instance with default installed language 'en_US'
- Install CRM
- Activate a second language (e.g. en_GB)
- Set that language in all users
- Inactivate default language 'en_US'
- Reset the language of your current user (no value)
- Go to contact and try to create a new one
Bug:
A traceback was raised because the lang en_US did not exist.
PS: Forcing the user to set a language ensures that this fallback
will never occur anymore.
opw:2267711
closesodoo/odoo#53375
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
We want to create a XMLID for every first exhibition of a field in a
model. That is, we just want one XMLID by field by model and not one
XMLID by field by class. Previous implementation was determining the
"first field exhibition" by making sure the field was created and used
as part of the same module.
This assumption is invalid when we consider mixins. A mixin is an
abstract model that define fields and methods to be included in other
models. As it is abstract, it does not exhibits the field by itself. The
field will only be exhibited when included in a concrete model via
inheritance. When it is included in another module, the XMLID creation
is discarded.
Take a module M1 that defines a model A, take another module M2 that
defines a mixin X with a field X1. In a third module M3, extend A to
inherit from X. While M3.A is the first model module to exhibit the
field X1, the XMLID creation was discarded because `"M2" != "M3"`.
See https://github.com/odoo/odoo/issues/49354#issuecomment-614093767
Task: 2235368
Closes#49354closesodoo/odoo#53435
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit sets attribute sample="1" in a bunch of list and
kanban views, to enable the new sample data feature when views are
empty.
Task 2232801
X-original-commit: 5471309b35619f307242c2704c7681ba63d2be42
* code *must* have an eval_context, `None` would blow up as soon as it
looks for the `'action'` key
* [accidentally quadratic] eval_value returns a value per line, seems
silly to evaluate all lines for each line when we can evaluate all of
them once, then map results to field names
* eval_value doesn't break inside the loop, so every id gets a value
by construction, `dict.fromkeys` is completely unnecessary (and
provides no performance benefits)
closesodoo/odoo#53110
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Taking a self and a separate action seems unnecessary given self *is
an action*.
Only do this change for the "new" naming scheme, so the old one keeps
working as-is.
There is no reason to call these directly, in fact it's not really
possible to do so as they expect an `action` object as first
parameter.
* warn against the presence of rpc-public runners
* move runner selection outside of ``run``
* improve doc a bit maybe
`state` was special cased in `copy_data` such that it would always be
reset to its default value if it had one.
While this special case can be useful (maybe) and is certainly
ingrained in odoo, having it not be overridable can be
problematic. Move the special case to the fields, so it's possible to
explicitly mark state fields as copy.
closesodoo/odoo#53113
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The attribute has been lost during a previous commit e6695c72d8.
This commit avoid that you can create an ir.ui.view without arch.
Before this commit, if you try to create an ir.ui.view with type but no
arch, the code will raise an exception in _check_xml:
/odoo/addons/base/models/ir_ui_view.py, line 377, in _check_xml
view_arch = etree.fromstring(view.arch.encode('utf-8'))
AttributeError: 'bool' object has no attribute 'encode'
Now, the user will have a warning on create, to say that View Arch field is required.
Could be backported if reported
X-original-commit: 4877bb4b650f5d1c52fefb06dec2fa568afcb121
On ir.property model, do get the field_id using the cached result from
ir.model.fields _get() method instead of issuing a direct SQL query
OPW-2067461
closesodoo/odoo#53351
X-original-commit: 24fff41d02fc7469d563f732a607db5c9a150e1e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Wrong usage of self in for loops makes some apparently multi-friendly
methods not work correctly when called with a recordset of len > 1.
This commit replaces those references by the correct unique record
reference which should be used at this iteration of the loop, avoiding
potential exceptions or wrong behavior in the concerned methods.
closesodoo/odoo#53320
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose of this commit is move 'Helpdesk' under the 'Services'
section on res.users form view instead of 'others'.
closesodoo/odoo#52043
Taskid: 2253481
Related: https://github.com/odoo/enterprise/pull/10821
Related: odoo/upgrade#1351
Related: odoo/enterprise#10821
Closes: #52043
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In the PDF, `DictionaryObject` can be wrapped in `IndirectObject`. For nested
dictionaries, using `get` on a `DictionaryObject` will unwrap the result if it's
an `IndirectObject`, but not `__getitem__` so when trying to futher call `get`
on the result will cause an error: we need to unwrap the object first.
Instead, we patch `DictionaryObject.get()` for it to unwrap the object in case
it's an `IndirectObject`.
This is a follow-up commit of fece5ab1bf2fef043b131f1bd0886f0841116103
closesodoo/odoo#53269
X-original-commit: 189a0b28ec7fdb7472f936450cfd7b4bfd6912ed
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Until version 13.0, ir.ui.view:postprocess_and_fields returned a tuple
of a string and a dict of field information.
With aae1d57829, it now returns a
defaultdict instead of the dict.
This dict comes from NameManager.available_fields, which is initialized
as a defaultdict. There is no apparent reason to have a defaultdict in
this place, apart from the usage in has_field.
Furthermore, using a defaultdict has a side-effect in the search_view
computed field of all the ir.actions.act_window. On a database, if you
access env.ref('base.paper_format_action').search_view it will contain
a stringified dict, and the string default_dict(<class 'dict'>, {...})
is used in place of just {...} under the fields key.
closesodoo/odoo#53235
X-original-commit: 4586d0fbf0bdd5959b274611c58df911e50f4ef2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Since a recent commit[1], we have a utility method in tools named
'is_html_empty' that checks whether the given html content is
void(containing only formatting tags) or not. However, the re from
this method does not consider the case of self closing tags, fox ex
`<br/>`. In such cases, the method returns Falsy value even if the
content is void.
This commit fixes the issue by considering self-closing void tags
in the regular expression.
commit[1] - https://github.com/odoo/odoo/commit/974f512f5f5d3b9f80a8c3fcde290e4f55cf1230
Task - 2267689
closesodoo/odoo#53167
X-original-commit: 0fd6c9388dc959a9b6b7828850683175edb05b9d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
ACLs on the wizard lines should match that of the wizard, otherwise
ERP managers can see the action but get an error as soon as they open
the wizard.
Since ERP managers have write access on arbitrary users, that's
probably the right group to use.
Task 2275134
closesodoo/odoo#53007
X-original-commit: 657d44f08c402bc0547b7cbb01c2d447e641d062
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit introduces a new attribute 'limit' for search panel fields
that allows to avoid performance issues. That integer attribute (with
default 200) allows to fix a maximal number of values to display for the
fields. When the number of field values to display reaches the limit,
no values will be displayed. Instead, a warning message will be shown
in the corresponding search panel section.
Note it is possible to have no limit using limit="0" on a field.
This commit reintroduces in a better way the principle brought by the
fix 8d57153b34c04952a85f6642951cb2697016da84.
Task ID: 2154749
The commit introduces two new attributes for search panel fields:
- hierarchize: boolean attribute (default True) available for
many2one fields with select="one". It allows to choose whether
to hierarchize the field values using the _parent_name (if set)
on the field comodel.
Note that a sanitization of the parent hierarchy takes place.
Basically, it ensures that parent chains are
completely in the domain (on comodel) accessible by the user.
See _search_panel_sanitized_parent_hierarchy documentation for
more information.
- expand: boolean attribute (default False) available for many2one
and many2many fields. If set to true, all field values are fetched
and displayed in the search panel. If set to false, only the
values that have at least one corresponding value in the field
model (and in some domain) are fetched.
An exception in the case of an hierarchized field
(hierarchize=True and _parent_name set): more/less values can be
displayed in order to have a good representation of the parent
hierarchy. That means we complete and sanitize the set of initial
field image values.
Note that the fix 8d57153b34c04952a85f6642951cb2697016da84 bringing the
notion of limit in search panel has been reverted in the present commit.
An upcomming commit will reintroduce the limit principle in a better way.
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Odoo cloc is a tool to count the number of relevant lines written in Python,
Javascript or XML. This can be used as rough metric for pricing maintenance of
customizations.
It has two modes of operation, either by providing a path:
odoo-bin cloc -p module_path
Or by providing the name of a database:
odoo-bin cloc --addons-path=dirs -d database
In the latter mode, only the custom code is accounted for.
Both modes can be used simultaneously.
Files that cannot be parsed are shown at the end of the report.
Parsing can fail due to syntax errors or excessive file size.
closesodoo/odoo#52635
X-original-commit: ae858c3ac66267b4726db459032b91a6be1cc1d6
Related: odoo/enterprise#11018
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Co-authored-by: Thibault Francois <tfr@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
Things to know about specific views:
Since the introduction of website specific views, we can have multiple
views that are related to a website (specific views). These views have
no xml_id as it is only set on the original view (generic view).
We rely on the view's key to identify related views as it is the same
for all specific views of a generic view. Also the key is equals to the
xml_id.
When a generic view is updated, we will check if the specific views have
the same values as the generic view. If it is the case, the value that
are the same are considered updatable and are updated on both the
generic and specific view. Else these are considered as noupdate.
When a generic view is created we will check if the potential parent
generic view has specific views. If it is the case we will create a copy
of the created view for each specific view.
The issue:
The method that checks if a created/updated view has specific views is
located in website. When we update a module, each modules are
initialized and updated in a specific order. If a generic view that has
specific views located in a module loaded before website this view's
specific views will not be updated/created as the method does not exist.
This issue is mainly affecting portal views at the moment.
The solution:
For write:
We now COW(copy on write) the views in base module, meaning this will
apply to all qweb views that are duplicated and not only the website
specific ones.
For create:
We will create the generic view as before but wait until we have
updated all the modules to gather all generic views that are supposed
to have a specific view but don't and create the specific views.
This will result in a change of behavior being that if a specific view
that have a parent is deleted it will be recreated on update
(same behavior as a generic view).
closesodoo/odoo#52629
X-original-commit: b1a90ee2bb441aa52e3cf4607c43fb464b55b1d7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: fja-odoo <fja-odoo@users.noreply.github.com>
Issue
- Create a second company
- Create user with access to main and second company
- Go to "Contacts" app
- Edit contact of the new user, and under the "Sales & Purchases" tab,
ensure that the company field is set
- Create a new contact with same email of the new user
- In list view, select both contact related to new user
- Click on Action->Merge Selected Contacts, then merge contacts
User has no more access to both companies, only company related to
merged destination Contact/Partner.
Cause
All related companies are unliked from user, and instead overwrited
with one company related of the merged destination Contact/Partner.
Solution
Instead of unlink all companies, we will only add the contact company
to the allowed companies of the user.
opw-2269397
closesodoo/odoo#52620
X-original-commit: e00b23b73f00fb24b2771ea8894031b35204e65e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
*: base
Previously, cropping an image was done inside of a modal window, turning
it into an inline widget makes the editor feel more integrated and
allows you to better see the result of cropping directly in the page,
it's also less intrusive to the user's edition workflow.
At the same time, the way cropped images are saved was refactored to use
the new original_id field on ir_attachment, as the old system was
creating problems.
Part of https://github.com/odoo/odoo/pull/51517
task-2192755
Part/Fix of commit #e579642
Issue
The condition `default_type not in self._fields['type'].selection`
always evaluate to True as the selection is list of (key, value)
tuples.
Solution
Replace the tuples by a list of possible values.
opw-2256905
closesodoo/odoo#52501
X-original-commit: 1b21c674c6de3ef96d7938c3e99b36d7cb2f2b6e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Commit bca2926b01 introduced a fix for
ir.ui.view unlinks during uninstall but forgot to return the result of
the super() call to unlink which broke behaviour downstream.
This commit restores the proper behavior of returning the result of the
call to super.
Closes#52364closesodoo/odoo#52435
X-original-commit: a3d91cc8691794d8f93ef416830b09fabcf08b66
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Similarly to server actions, searching and viewing the model on which a
scheduled action is defined is useful for administrators.
closesodoo/odoo#52239
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Issue
Step done with "CRM" since main kanban view can be
grouped by 'res.partner' model:
- Install "CRM" app
- Go to crm and group by "Customer".
- Add a Column.
Traceback is raised.
Cause
Wrong "default_type" in context ('opportunity' in this case)
when creating new kanban stage and grouped by "Customer".
Solution
On "default_get" for "res.partner", if "default_type" is in
context and not in 'type' selection choices field; then
remove it from context.
Cherry-pick of #47723 in 12.0
opw-2256905
closesodoo/odoo#52282
X-original-commit: e5796429c8adcbb929cb032cdfd2cbaba835b086
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit d5d2c5524c improved the UrlWidget s.t. it automatically
prefixes the url with 'http://' if no protocol is specified (except
for own website paths).
In addition, it removed a logic specific to model res.partner that
automatically prefixes the saved website values with 'http://'.
However, the second part should not have been done: those urls can
be displayed without UrlWidget (e.g. on the website), and in this
case, the protocol wouldn't be set, meaning that it would behave
like a relative link.
closesodoo/odoo#52113
X-original-commit: 5a8690bb64cb3dc01ee8d4f9af3a6ab91eee8b99
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
By default importing is batched (or at least attempted to), however
because the import is functionally sequential it's possible for a
record to refer to a previously imported record of the same batch.
When records are referenced by xid this is easy, we can just keep
track of all the xids we *should* have created so far and when trying
to look up a xid if it's one of those flush all pending
creations (otherwise assume it's some other unrelated xid which
already exists in the system).
For "name_search" lookups however this is more complicated, so we'd
just flush the entire thing.
This, then, is an issue when importing records with an m2o which
is *generally* looked up by "name" rather than xid e.g. when importing
partners it's more likely the "state" will be specified by
name (e.g. AZ or Arizona) than xid (base.state_us_3 lol), because it
means more or less every line will be flushed, defeating all batching
and slowing down the import.
To fix this, allow passing *model names* to flush (not just xids), and
try to collate all the models we could be creating (or updating)
records for in the process of importing. If we see a name_search on
one of these models flush, otherwise don't because we couldn't have
impacted the search.
Task 1951307
While at it, f2a1618758 removed all
usage of model_load_save, but left the creation of the savepoint
itself.
The InternalError check should be left in place to catch things like
conversion issues which put the tnx in an invalid state (only invalid
states should trigger an InternalError according to psycopg's errors
documentation).
closesodoo/odoo#49289
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Only system users can access ir.property records.
This PR is part of the long-term task id 8203 that plans to remove all access to
ir.* models
"Official" methods to interact with `ir.property`:
- `_set_default(name, model, value, company=False)`
- `_set_multi(name, model, values, default_value=None)`
- `_get(name, model, res_id=False)`
- `_get_multi(name, model, ids)`
Done in this PR:
- remove ACL on ir.property (only system users can access directly)
- make all getter/setters private with sudo
- use these methods everywhere instead of CRUD calls
- add sudo where needed
closesodoo/odoo#51658
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Apparently some "core objects" used to have a pair of
fields (date_init, date_update) which predate the current access
fields (hopefully anyway, the genesis of both is lost to time so we
can only speculate).
odoo/odoo#34988 removed them on constrains & relations and left them
on ir.model.data, but they do seem redundant with the regular access
fields which *are* enabled on ir.model.data.
* removes the date_init/date_update fields
* converts the one bit of code which did set those to set
create_date/write_date
* add a default value on the columns, to ensure create_date is
properly set even from SQL queries
* use create_date/write_date in the view
* adds setting those columns to a bunch of raw SQL queries which were
missing them (also updates the queries some to merge the literal
values into the queries as it seems unnecessary to interpolate
e.g. a boolean literal)
Builds on and closesodoo/odoo#50516 as that's why I started looking
into it, and that fix is in this branch as well.
closesodoo/odoo#50661
Related: odoo/upgrade#1213
Related: odoo/enterprise#10772
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Add sudo in base to allow a unpriviledged user to interact with
ir.property in a safe way usingsetters and getters.
By making them callable without sudo, we encourage to use these
methods instead of making CRUD requests on ir.property directly
For other specific search where no native method exists, add sudo
Only administrators can access properties and configure them.
ir.property may contain sensitive information and should only be
accessed via code call to specific methods
Before this commit, when retrieving a property, the res_id had to be
in the format <model>,<id>. This was redudant with the model already
present in the arguments of the method.
This way a property can be retrieved with the more concise form
`Property._get("ref", "res.partner", 42)`
Replaces the auto_join scheme which is pretty fast but doesn't quite
work (it's *completely* broken for read_group) by a subquery which is
slower but has the same semantics as the ORM version.
Ideally we'd use `EXISTS (select 1 from ...)` but that has no support
inside the SQL compiler right now, so use `id in (select inverse_field
from ...)`.
Here are some measures of a `read_group` on a simple object with lines
filtered on line values, similar to
read_group([('order_line.product_uom', '=', xxx)],
fields=['total_amount'], groupby=['user_id'])
+-------+-------+-------+--------+
| | ORM | join |subquery|
+-------+-------+-------+--------+
| large | 160 | 10 | 20 |
+-------+-------+-------+--------+
| many | 36000 | 50 | 180 |
+-------+-------+-------+--------+
* values of data fields (filtering, grouping and aggregating) randomly
picked between 10 different values
* "large" is 1000 objects with 1000~15000 lines each
* "many" is 1000000 objects with 1~40 lines each
closesodoo/odoo#48494
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Instead of merging Query objects (main domain and access rules domains),
which requires renaming aliases in query strings, make `expression` push
its result in an existing Query object. This removes tricky code.
This also avoids using `IrRule.domain_get()`, which has become unsafe,
since it returns a list of tables (for the FROM clause) which does not
include the joins from the generated Query object.
closesodoo/odoo#49999
Related: odoo/enterprise#10126
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Use a LEFT JOIN on table `ir_translation` instead of a subquery, by
using the same implementation as the one used for ordering by a
translated field. In particular, this avoids having both the LEFT JOIN
and subquery when searching and sorting on a given translated field.
This fixes some cases where search results are actually missing. For
instance, searching with a domain like
['|', ('parent_id.name', '=', 'foo'), ('name', 'like', 'foo')]
where `parent_id` is auto-joined, misses results where `parent_id` is
NULL, because the actual query makes cartesian products for auto-joins:
SELECT "res_partner".id
FROM "res_partner", "res_partner" AS "res_partner__parent_id"
WHERE ("res_partner"."parent_id" = "res_partner__parent_id"."id")
AND ("res_partner__parent_id"."name" = 'foo' OR "res_partner"."name" == 'foo')
Using LEFT JOIN instead of cartesian product above, the query includes
all results where `parent_id` is NULL:
SELECT "res_partner".id
FROM "res_partner"
LEFT JOIN "res_partner" AS "res_partner__parent_id" ON
("res_partner"."parent_id" = "res_partner__parent_id"."id")
WHERE ("res_partner__parent_id"."name" = 'foo' OR "res_partner"."name" == 'foo')
The management of the join contexts now relies on the `Query` object,
that has all the necessary logic to do so. The refactoring also removes
the class `ExtendedLeaf`, which is no longer necessary: the join
contexts are all managed by a single `Query` object, and the parsing
stack now only contains triples like (leaf, model, table_alias).
Also inline directly the SQL translation made in `_to_sql`, which
overall simplifies the management of SQL parameters in the domain
compilation. The algorithm is illustrated in the code itself.
Goffin Simon