This commit adds a new attribute mode for position 'replace' to the xpath feature.
This mode can take 2 values:
- 'outer' (default mode if not provided) that will replace the sibling target
- 'inner' that will preserve the sibling target
If base arch is:
```html
<p>
<field name='x'>yyy</field>
</p>
```
`<field name='x' position="replace" (mode="outer")>zzz</field>`
```html
<p>
zzz
</p>
```
`<field name='x' position="replace" mode="inner">zzz</field>`
```html
<p>
<field name='x'>
zzz
</field>
</p>
```
Mode inner is useful for theme or render flat content, but not recommanded to
be used in page editable since we ignore the inherit-branding part until now.
task-2172208
closesodoo/odoo#48679
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Okan SUMER (osu) <osu@odoo.com>
Co-authored-by: Jérémy Kersten <jke@odoo.com>
`load_views` calls `get_bindings` to render Action and Print menu. Before this
update, it read all action fields, including heavy computed fields
like `search_view` (which calls fields_view_get). But in fact just few fields
are used.
This slighly improves response time and data size.
closesodoo/odoo#73983
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, the implementation crashes when the ancestors of a
record contain non-accessible records. This fixes the code to avoid it
to crash.
We also make the semantics of hierarchical searches more consistent in
this case: searching with operators 'child_of' and 'parent_of' returns
the subset of accessible records that satisfy the hierarchy operator.
We actually make it coincide with the results of the search when using
the "_parent_store" optimization.
closesodoo/odoo#73962
X-original-commit: 3e1b960acf3f6a726338476ba9e62e5ef5c84ef9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, some tests were indirectly using demo data.
For example `env['res.partner'].search([])` would return demo data in
addition to the partners created for the tests.
This commit changes that by ensuring that the records used are limited
to the records made for the tests. Some values have been adjusted to
account for the lower amount of available records.
closesodoo/odoo#72553
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
It seems quite easy to have a void content in the currently new editor
that actually holds a lot of undesired information, notably a font
tag. This is annoying when having behavior based on an html field
being empty or not. In this commit we therefore improve definition
of an 'empty' html field.
Task ID-2532529
PR odoo/odoo#71793
Domain terms of the form `('field', 'not in', [...])` generate incorrect
queries for translated fields, example (model `res.country`, field `name`):
```
psycopg2.errors.SyntaxError: syntax error at or near "ARRAY"
LINE 1: ...M "res_country" WHERE "res_country"."name" not in ARRAY['No ...
```
The root cause is that the right part of the term is not converted to
tuple.
Observed during the upgrade request 16639
opw-2525553
closesodoo/odoo#73030
X-original-commit: 7c4db97e21f74a429e56f6cae4d4786ee74f7e22
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With commit odoo/odoo@83ffe8b we ensured that while creating a child contact, it
takes language from its parent by default if any, otherwise falls back to DB
lang.
The fix was done with help of `default_get` method. However after merge of
odoo/odoo#55995 `default_get` is now called through the onchange for o2m
fields. Now we don't get the default value of `parent_id` here which
re-introduced the bug.
This commit fixes the behavior by setting the language from onchange
while creating the child contact and thus (once again) making the
language from parent contact prevail on DB lang.
We also re-use default_lang coming from parent in form view, which partially
reverts odoo/odoo@83ffe8b .
TaskID-2416922
closesodoo/odoo#72960
X-original-commit: 4d9b85bd07e487e7843dc458332dede36c2889c2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit: when partner is only created with name(i.e. without
address) and when 'address_inline' is passed in context then partner name shows
with unnecessary commas.
After this commit: partner name will not have unncessary commas, as we removes
unncessary '\n' in case of 'address_inline' passed in context.
task-2502597
closesodoo/odoo#72869
X-original-commit: c08082d89782b7675e8e649cba15ca9e03e40077
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
The commit e123aa2f30 optimizes the call
to fields_get() made in the NameManager to post-process the combined
arch of a view. The optimization consists in avoiding translations,
with the assumption that the result is only used for validations. It
turns out that the regular post-processing actually returns the field
descriptions as part of the result of fields_view_get().
We fix this mistake by keeping the optimization only when the flag
'validate' is true, so that the regular post-processing of a view
returns field descriptions with the expected translations.
closesodoo/odoo#72216
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The `mode` field in used in `_combine` to distinguish `primary` views
from `extension` ones. The field has been retrieved as part of the query
done in `_get_inheriting_views` and manually placed in the cache so the
ORM doesn't perform an extra query just to retrieve the mode.
Using our benchmark (render_all_views test tag, website_sale, mrp,
contacts, crm and timesheet installed), the reported time was 18.46s
with 17890 queries performed without this improvement, it is 17.82 with
17340 queries with.
Closes#72096closesodoo/odoo#72127
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The view methods `get_inheriting_views_arch`, `apply_view_inheritance`,
`_apply_view_inheritance` and (previously `read_combined`)
`_get_combined_arch` were complicated and not optimal performance-wise.
The previous approach to retrieve views and combine them was to perform
it recursively, one primary view at a time. This new approach retrieves
in a single SQL query the whole tree of views to combine. The order of
view combination has been reproduced to be fully backward-compatible.
We also introduced various optimisations such as pre-fetching and
caching.
**get_inheriting_view_arch**
The method have been renamed `get_inheriting_views` as it returns a
recordset of views instead of the xml architecture of each view.
During an upgrade, only the views that have been fully upgrade already
are safe to be used. The views returned by the query are filtered to
remove any not-upgrade-yet view. Because this part is highly specific,
it has been isolated in a dedicated private method.
View extensions can be discarded according to user groups. The
retrieval of groups on views is also made by the same query. This
reduces the number of SQL queries, and makes the filtering faster.
**apply_view_inheritance**, **apply_view_inheritance**
The functions were responsible to build a hierarchy of views and to
iterate it to combine the views.
The hierarchy building have been moved to `_get_combined_view` and the
actual combination have been moved to a new method `_combine` and
documented.
Task: 2541579
Meta task: 2463632
Co-authored-by: Fabien Pinckaers <fp@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The method read_combined() has been deprecated in favor of explicit
calls to read() and get_combined_arch().
There are places where we call _get_combined_arch() instead, in order to
avoid parsing the XML that has just been serialized. This saves useless
serialization-deserialization.
Task: 2541577
Meta task: 2463632
Co-authored-by: Fabien Pinckaers <fp@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
A test that calls fields_view_get() on all models while measuring its
performances. Use it along with py-spy and load the generated file in
<https://www.speedscope.app/>
py-spy record -F -r 200 --format speedscope -o speedscope.json -- \
python3 odoo-bin -d <db> --test-tags render_all_views --stop-after-init
Task: 2463632
Co-authored-by: Raphaël Collet <rco@odoo.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
In this commit we replace report_footer and report_header field of
"base.document.layout, res.config.settings" model as
they are related fields of res.company models field
report_footer, report_header.
Task Id: 2499504
X-original-commit: 4c474d0d2055efe81fdc21502aa5957fe80af7ef
Before this commit there were few cases in which
is_html_empty method was not working as our expectation.
In cases such as "<p class=""><br/></p>", "<p id=""><br/></p>"
and many other cases.
In this commit we improves regex of is_html_empty method.
Mow from this commit all kind of attributes will be consider
in this method.
In this commit we also have added is_html_empty in mail template, portal
values and in report values also for rendering templates.
Task id: 2499504
X-original-commit: fd0a05f2955b9f7e9ae7233afebfd6240c9244dd
This commit adds tooling to profile performance and save execution by
saving stack traces and queries to a file/database in specific format.
----------
Collectors
----------
For now, three different profiling modes (aka Collectors) are available
even if a last once should be introduced by @Gorash to profile qweb
execution.
- SQLCollector (or 'sql'): Saves the current stack trace and the query
every time Cursor.execute() is called. Any query executed on the thread
will be collected, no matter the cursor.
- PeriodicCollector (or 'traces_async'): Saves the stack trace every
'interval' seconds using a parallel thread to profile the caller thread.
The python implementation was optimized to minimize impact on
performance while remaining portable and easy to enable/disable
inside a odoo execution. Higher the frequency (lower the interval),
more impactful the profiling will become on the execution and increase
memory usage. From last experiments, 1ms looks to be a good minimum for
short executions.
- SyncCollector (or 'traces_sync'): Saves the stack trace every function
call/return. This collector is obviously quite impactful on performance
and can quickly overload the memory for long executions, but this is
quite useful to understand the precise path followed by some short
executions. Any time related information will be almost irrelevant with this
collector.
A base Collector defining minimal collectors features can easily be
extended to create custom collectors if needed.
----------------
Profiler & Usage
----------------
Collectors are not supposed to be used by themselves, but should be
given to a Profiler. The Profiler will synchronize collectors starts and
stop, and manage saving them to a file of in a ir_profile in the
database.
Exemple of usage:
```
with Profiler():
do_stuff()
```
This simple example will use the default collectors (sql and
traces_async) and save them to the database. The database is defined
automatically from current_thread 'dbname' if available.
Example of usage:
```
with Profiler(collectors=['sql'], db=False, path=/home/user/logs/do_stuff_profile/{time}):
do_stuff()
```
This more complex example disable the default behavior consisting
to save to the database, gives a path where the profile will be saved
and specify to only use the 'sql' collector. Note that
collectors=[SQLCollector()] would have the same behavior since
Collectors can be either a Collector instance or a string describing the
desired collector. This allows to define custom params for the
collectors and use custom collectors if needed.
Note that it is always possible to get results after execution without
saving it since they are available on the profiler.
```
with Profiler(collectors=['sql'], db=False) as p:
do_stuff()
print(len([None for entry in p.collectors[0].entries if ...]))
```
Profiler will also save the stack below the profiler start point, and
collectors will only collect the part of the stack over this stack.
This is a good way to reduce collectors CPU and memory usage.
Collected entries will be saved as follows:
```
[{
'start': 2.0,
'context': {},
'stack': [
['path_to_file', lno, 'func_name', 'line_content'],
...
],
},
...
]
```
SQLCollector will add three additional keys on each entry:
- query (query without parameters)
- full_query (mogrified query with parameters)
- time (the 'exact' execution time of the query)
----------------
ExecutionContext
----------------
A last tool, ExecutionContext, allows to define some context on some block of code:
Example of usage:
```
def process_modules(modules)
for module in modules:
with ExecutionContext(module=module): # note the 'not linter frienldy but still convenient' 2 spaces indentation
do_stuff(module):
```
This context will automatically be added in the stack as a virtual frame between
process_modules and do_stuff in order to split do_stuff from one single frame to
one frame per module.
----------
Speedscope
----------
The saved data are in a simple json format easy to analyze, but can't be visualized in
speedscope as they are. A utility class `Speedscope` can be used to generate a format
readable by speedscope. The used format is actually the format defined by speedscope,
meaning that all features should be available using it.
The output format is evented, meaning that we need to transform a list of samples
(a list of stack) to a list of event (going in/out a frame).
This is the main task of the Speedscope, as well as combining samples from different
sources, to display SQLCollector and PeriodicCollector results mixed together.
When stored on an ir_profile, the default speedscope generation can easily be generated
with the speedscope computed field.
This class can be used as it is but will mainly be useful for the next commit.
Special thanks to @rco-odoo for the in depth review and @Gorash for support.
The method filtered_domain() is broken for domains with hierarchical
terms ('child_of'/'parent_of').
To see *one* of the ways the implementation is broken, let `A` be a
model with `parent_id` pointing to `A`, and `a1` a record of model `A`
without parent (`a1.parent_id` is `False`), then this fails:
assert a1 in a1.filtered_domain([("parent_id", "child_of", a1.id)])
The reason it fails is that on
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5377-L5380
`data` is empty since `a1` has no parent, thus
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5403-L5404
fails, therefore the result of `filtered_domain` is empty.
Note: the implementation of the hierarchical operators is full of quirks
that are hard to emulate otherwise than by reusing the original code.
As a consequence, the current implementation may be broken in more than
one way.
Let's see another way the implementation is broken: let `B` be a model
without a `parent_id` field and with a `friend_id` field pointing
to `B`, and let `b1` be a record of model `B`. Then
b1.filtered_domain([("friend_id", "child_of", b1.id)])
throws an exception of the form shown below:
ValueError: Invalid field 'parent_id' in leaf "<osv.ExtendedLeaf: ('parent_id', 'child_of', 1) ...
Meanwhile the following code is still valid and returs b1:
B.search([("friend_id", "child_of", b1.id)])
closesodoo/odoo#71237
X-original-commit: e7a5ba95d8b7df5bbf545ef8afe0a1f5d0f70272
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Make the email body take the entire space to avoid having some wasted space,
this will also make the user have more focus when designing an email.
Revamp the settings notebook page in order to give more clarity to the user,
and move some fields from the main form have been moved to this section to
have more space in the bottom for the email body.
In the mailing form, when the mailing is sent or is being sent, set fields
which are no longer useful for the user to change to readonly mode.
Add a wizard that enables the user to schedule a mailing, the schedule field is
still kept in the form for the user to be able to change the date when the
mailing is in the queue (if they want to send it sooner).
Display an action helper-style content when the email is empty, because,
currently, the user is left with a big white screen when the email has no
content which is not desirable.
Update the html_empty function to take into account style attributes to better
match the editor's void content.
Hide A/B testing fields from SMS mailing form view as these are not supported
for SMS marketing.
Task-2469409
closesodoo/odoo#68882
Ent-pr: https://github.com/odoo/odoo/pull/68882
Related: odoo/enterprise#18391
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.
Specifications
==============
This is done with 2 system parameters.
If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.
If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.
Otherwise we do not encapsulate the email (same behavior as before this
commit).
Task 2367946
See odoo/odoo/pull/61853
closesodoo/odoo#70980
X-original-commit: 08a561505b92d23c4c4ec4094b0cee209ece8753
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Also speed up the basic setup of fields that are always duplicated
top-level (on the model's registry class). This saves time and memory,
as we also discard field.args and field._base_fields on toplevel fields
(those values are no longer useful after setup).
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
* QWeb bodies should be markup-safe so `0` should always be
markup-safe.
* `head` is qweb-rendered so the same.
* The `json` pseudo-module in qweb templates is `json.scriptsafe`,
which should be markup-safe.
`markupsafe.escape` always escapes single and double quotes, and
escapes them to their numeric values rather than symbolic
According to pallets/jinja@f35e28154f,
this is for compatibility with HTML 3.2: the only named entities in
the HTML 3.2 DTD are `amp`, `gt`, and `lt`.
Update tests to match.
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
Before this, when making a partner without any country_id, any VAT could be set to it, which was inconsistent with the module's purpose.
closesodoo/odoo#68815
X-original-commit: 72606f14d0c1d86d7a205fd29aec8d66d3e98678
Related: odoo/enterprise#17505
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
A domain with a negated thruty leaf raises an exception here
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L614
due to
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L670
and the fact that `FALSE_LEAF != (1, "!=", 1)` and `TRUE_LEAF != (0, "!=", 1)`
Current wrong behaviour:
```
>>> distribute_not(['!', TRUE_LEAF])
[(1, '!=', 1)]
>>> is_leaf((1, '!=', 1))
False
```
This issue was noticed when adapting domains for fields that have been
removed during migration. Example (extract of) traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/13.0/odoo/http.py", line 624, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
...
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 677, in __init__
self.parse()
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in parse
self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in <listcomp>
self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 562, in __init__
self.check_leaf(internal)
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 618, in check_leaf
raise ValueError("Invalid leaf %s" % str(self.leaf))
ValueError: Invalid leaf (0, '!=', 1)
```
closesodoo/odoo#68665
X-original-commit: e20c23658d15a135e5f35b0e8dec6e3202cecaab
Signed-off-by: Christophe Simonis <chs@odoo.com>
add mail_tz to calendar_attendee model in order to make it easier to change the
timezone displayed in the mail template so that we can use it to make the
appointment time shown on the email reminder sent to the attendees consistent
with the time shown on the website page.
Change the invitation mail template and use the mail_tz field to display time
field instead of using the partner's timezone in order to make the time shown
in the invitation consistent with the time shown on the website page.
Remove the get_interval method in the calendar_event model and use standard
formatting tools instead, as this is more conveniant than having a custom
method for formatting dates, For this reason the format_time function located
in tools/misc.py has been modified to be capable of handling timezones in
order to be able to display time in the correct timezone, furthermore, this
function has been added to the rendering context provided in the
mail_render_mixin file to be used in email templates.
see: https://github.com/odoo/enterprise/pull/16204
Task-2451154
closesodoo/odoo#65729
Related: odoo/enterprise#16204
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As this backport already exists in saas-14.2 and master, only the
`lxml.html.Element` part is kept in this commit which is a safer way to
build the widget.
closesodoo/odoo#68483
X-original-commit: c891d61802018a14944c22d01316872427a40284
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When testing cron triggers, it is common to get the newly created
triggers in order to validate they exist and are scheduled are the right
moment.
This new helper is a context manager that capture all triggers or
triggers created for a specific cron. The created triggers are
accessible via the context's object `records` attribute.
The various tests have been updated so they use that new helper.
closesodoo/odoo#68163
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
The former algorithm was recreating a full etree from scratch, while
parsing the content to translate. Instead, we parse the etree and
update only the content that to be translated.
Before:
| In [2]: %timeit views.invalidate_cache(); views.mapped('arch_db')
| 578 ms ± 7.83 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
After:
| In [2]: %timeit views.invalidate_cache(); views.mapped('arch_db')
| 208 ms ± 2.79 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
Reading a view is 2.63x faster: from 504 ms, to 191 ms (sum of all the
1345 views, when installing website_sale). Large views, like web pages
goes up to 3x-4x faster; small views are ~2x faster.
As views are cached, it only impact the loading to put in cache, but all
XML/HTML fields get the same performance gain.
closesodoo/odoo#68182
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
- Remove legacy arguments (`subdir`, `pathinfo`) of `file_open()`,
they were not used anymore and made the code more complicated
- Drop the long-deprecated support for files inside zip archives,
considering that zipped modules were discontinued a long time ago:
278ed718e9
- Remove the redundant `_file_open()` method, that should never have been
called directly anyway
- Add the possibility to filter allowed file extensions, in order to
avoid opening up access to arbitrary addons files, such as .py files,
depending on the context of use
- Split up the verification of the file path, to make it accessible
without actually opening the file, as a separate `file_path()` function.
closesodoo/odoo#68043
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before this commit ir_filter tests were calling model.search() with an
array as order. It was not a problem because none of the tested filters
was actually using the sort and the falsy empty array was therefore
ignored by model.search().
After this commit ir_filter test calls model.search() with a string as
order.
task-2453416
See https://github.com/odoo/odoo/pull/65554closesodoo/odoo#68036
X-original-commit: f326ba2d14e4fdd811426c6381b7e5bc3c1d657b
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee introduced a change that
allowed field_triggers to be computed lazily per registry, this change
introduced a behavioral change that is not easy to notice, in order to
explain the behavioral change I will use the following example which was
the original bug reported:
- Install studio
- Create an app (create a new custom model M)
- Uninstall studio
-> Uninstall fails because field display_name of the custom model M
depends on field M.x_name which has been removed due to the
uninstall process.
To understand why it didn't happen before the aforementioned commit, we
must first understand what happens with said commit applied:
- We trigger the uninstall of studio, this triggers the uninstall of
any modules that depend on it, namely studio_customizations which is
the module in which all customizations done with studio live in.
- We gather all data belonging to the studio_customization and we
start deleting in the following order: ...,
ir.model.fields.selection, ir.model.fields, ..., ir.model
- During the unlink process, we first remove the actual fields from
the model instances before deleting their database reflections, this
is done in the ir.model.fields._drop_column() method, it is this
method that will delete the x_name field but **not** the
display_name field, since it is a base field and not a custom one.
- After the deletion of the fields in memory, we call modified() to
mark fields that might've depended on the fields we just modified so
that they can be recomputed later.
- The call to modified will in turn access field_triggers, but since
we're in a new registry and field_triggers is a lazy property, it
will be computed right at this moment, this means that it will call
resolve_depends on the display_name field which still exists, and
this field has a dependency on the x_name field that we just
deleted! This is what will trigger the crash.
With that context, we can now understand how it didn't crash before
commit 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee:
- Before the aforementioned commit, the field_triggers attribute was
computed during the registry's setup_models(), in the case of an
uninstall this call to setup_models was done way before the
uninstall step of the registry (Step 3 is the last to call
setup_models before Step 5).
- This means that the old behavior was technically a bug, because
right after removing x_name from the model, the field_triggers still
contained a dependency from display_name to x_name, the former being
no-longer present in memory.
With this commit, we simply reset the _rec_name and the dependencies of
the display_name if the x_name field is being removed, this ensures that
the computation of field_triggers won't crash and burn.
opw-2452498
opw-2478589
closesodoo/odoo#67823
X-original-commit: e6d22a43ff9f40e5fc7b8c84cd4dfe43f926d872
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
* Add a new error message upon deleting the partner linked
to an active user.
* Improve the error message wording upon archiving the partner
linked to an active user. Add the linked users names at the end of
the message.
* If the user has 'write' access on res.users, raise a RedirectWarning
instead of a ValidationError, to offer an easy access to the related users :
- If there are multiple Users, redirect to a list view.
- If there is only one User, redirect to the form view.
* Adapt the test_access_deleted_records from test_orm.py to use a more
basic model : `res.partner.category` (with less business logic), because the
new unlink error message is dependent on a condition that will throw an error
in case of multiple unlinks of the same record (MissingError).
* Force close the frontend archive confirmation Dialog since _toggleArchiveState
may be interrupted by another Warning/Error Dialog. If the new Dialog was the
redirectWarning, and the user chose to be redirected, the first Dialog would
stay open even thought the context already changed.
* Modify the placeholders for a partner Name/Company
-> placeholders will change according to an Individual or a Company.
* Adapt the main_flow tour to correctly select the partner name field on
mobile (tested in enterprise).
Task ID : 2410217
PR : https://github.com/odoo/odoo/pull/63370
Before this commit:
When merging the contacts, chances are there that the name of records being
merged are exactly same, and so we might not be able to distinguish them
and so can not tell for sure that which records are being merged to which
destination record.
After this commit:
In the 'Destination Contact' field, now we also show ID of the partner
along with the name, so that end user can easily distinguish between
them. For this, we pass 'partner_show_db_id' on the context for that field from
view, allowing us to get expected result from the name_get by using this
context key.
Task ID-2323060
closesodoo/odoo#66026
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The field that supports inheritance should be auto_join=True. This
guarantees that searching on an inherited field (X) or its explicit
related expression (foo_id.X) gives the same query.
Note that adding auto_join=True on that field does not weakens the
model's security, since searching on the model automatically injects the
parent model's security rules into the query (see _apply_ir_rules).
closesodoo/odoo#66925
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Adapt some query counts to their optimal value, in order to measure the
effect of the following commits on queries.
In module test_performance, some query counts were actually not correct:
the initial flush() done by the context manager assertQueryCount() may
prefetch some data to the cache, and that prefetching is not accounted
for in the query count. This is very true when assertQueryCount() is
preceded by a cache invalidation. We have to move the invalidation
inside the context manager, so that the prefetching is now counted.
In a previous fix [0], the call to exif_transpose was kept to allow
rotation of images format different than `JPEG`.
After a small test, it appeared that the call would crash if the image
in another format had the same `LensInfo` tag.
So it's safer to not call this method at all.
With this commit, the rotation tag is retrieved disregarding the file
format by using the `getexif` method if available, falling back to the
private method for Pillow < 6 support.
As a bonus, a test is also added with a small embedded `JPEG` image,
crafted with an `Orientation` exif tag and, for reference, the
`LensInfo`tag that caused so much trouble.
The fix referenced in [0] was not forward-ported as it was only moving
the code the is completely removed in the present.
[0] b83c48d5c48954193
closesodoo/odoo#65823
X-original-commit: bfd3f857b44f31f8077182d10cab869f42076464
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Filling the new column in SQL is dramatically faster than doing it via
the ORM, which iterates over all the records in the table.
The test case is creating a related field for 100+ records with distinct
values. Setting the field's value was taking more than 100 queries. It
now takes 3 queries.
task-2449313
opw-2380445
opw-2389376
https://github.com/odoo/enterprise/pull/15910closesodoo/odoo#65432
X-original-commit: d66652b4aa514546356306e3eb48eaecaba07c33
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The call model.browse('xxx').exists() should not return the record.
Instead, it should fail as the string 'xxx' is not a valid ID.
closesodoo/odoo#64783
X-original-commit: 824a6515a528cd2b682c3d3504c0d27ed9427cdb
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
cache_value could be empty string rather than None. I'm not sure why it was
different before.
STEPS:
* install an app that adds menu Products (e.g. Sales)
* activate second language and switch to it
* create new product, set some value to field description ("Internal Notes"),
save
* click edit, remove description, save
closesodoo/odoo#64752
Before: the value is not removed
After: value is empty, translations are removed
X-original-commit: 3ef5e63f62f0f84d6e92cb55eb112ab2f2924faa
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When printing barcodes for a large amount of records, wkhtmltopdf will
make the same amount of http requests to the server in order to retrieve
barcodes. This can lead to performance issues or wkhtml to crash.
Fortunately, an already existsing qweb widget exists that include
barcodes images as inline base64.
With this commit, the web widget is a bit improved to accept attributes
for the generated image tag. Each option dictionary key starting with
`img_` will be converted into a tag attribute with the corresponding
value.
e.g.: `'img_alt': 'Barcode'` will result in `<img alt="Barcode"...`
The `alt` img attribute now defaults to `'Barcode %s' % value` with the
barcode value.
Also, the `quiet` reportlab option is also avalaible in the widget
options, as well as the `mask` option.
Finally, if the `symbology` option is not given, the widget defaults to
`Code128`. If `symbology` is set to `auto`, the action report will try
to guess the barcode type, based on the len of the value.
Steps:
- Install accounting
- On the dashboard, try to upload an "encrypted" PDF like this one https://launchpadlibrarian.net/24827090/DS-0157.pdf
Bug:
Traceback:
PyPDF2.utils.PdfReadError: file has not been decrypted
Explanation:
In 13.0, these errors were caught in a catch all `except` as shown here: https://github.com/odoo/odoo/blob/4e089041252c25cc197a30f9e285d82f7162d809/addons/account_facturx/models/account_move.py#L303-L328
From this SO comment: https://stackoverflow.com/questions/52047944/pdfbox-extracting-blanks-from-pdf-encrypted-with-no-password#comment91054285_52047944
> A PDF can be encrypted with two passwords: a user password and an owner password. When a PDF is encrypted with a user password, you can't open the document in a PDF viewer without entering that password. When a PDF is encrypted with an owner password only, everyone can open a PDF without that password, but some restrictions may be in place.
From time to time, we get a PDF encrypted with an owner password. The
content is still readable, but PyPDF2 fails because it thinks the PDF is
encrypted. With this fix, we try to unwrap the PDF by providing an empty
user password. This way, PyPDF2 thinks the content is now decrypted.
However, PyPDF2 only supports decrypting versions 1 and 2 of the
encryption implementation. If the version is different, we skip reading
the attachments and carry on to allow the user to upload the document.
opw:2375993
closesodoo/odoo#64320
X-original-commit: 851fe64f7789bb398383c22e3ebbaebb051791f6
Signed-off-by: backspac <backspac@users.noreply.github.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The call to reset() when simulating requests during HttpCase tests
leaves the test class into an inconsistent state. Indeed, the test
environment is no longer into Environment._local, and this may trigger
record cache errors, because new environments use a record cache that is
different from the test's environment.
As this issue only occurs in the context of unit testing, it is not
worth fixing on a stable release, because of the involved risk.
Instead, we modify the test so that the failing operation is made in
method setUpClass(), before any environment reset.
closesodoo/odoo#63730
X-original-commit: c8604df6e3eab4090ffcb4c3f311e72c8bceac7c
Related: odoo/enterprise#15439
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When installing/upgrading a module with broken xml views, the module
installation fails with an error message that should help the developer
locate and correct the error.
Before this commit, a 3-level traceback was thrown at the developer:
1. The initial ValueError containing the original error message and some
view context information.
2. The noisy re-cast of the ValueError to a ValidationError with no
additionnal information.
3. An additionnal re-cast of the exception to add the original source
file path plus the entire XML source code that failed to be parsed.
We argue the error contains too much noise as developers are mostly
interrested in correcting their erronous tag of their view, they are not
interrested in `ir_ui_view` internals.
The new exception report is much less talkative, the two tracebacks from
`ir_ui_view` are logged at the `DEBUG` level. The new exception still
contains the original error message with some context on the view record
and the original source file path but it only show 5 lines of XML around
the erronous tag.
closesodoo/odoo#62757
Task: 2366612
Related: odoo/enterprise#15104
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This is a minor issue, but determinism is better than non-determinism.
closesodoo/odoo#62904
X-original-commit: 1b0869554d8755f8fdeb73dd2aa2ae7426522e84
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Steps:
- Install Contacts
- Have Multi-Companies enabled
- Go to a Contact of type "Company"
- Click "Sales & Purchases"
- Assign it the company you're on
- Save and Edit again
- Remove the assigned company
- Go to a contact of type "Individual" linked to this company
- Click "Sales & Purchases"
Bug:
The company has not been deleted on the linked Individual
Explanation:
When we delete the company of a contact, the value of `vals.get('company_id')` is `False`.
This is why it didn't enter the propagation process.
This fix makes sure we can still remove a company from a contact linked to a user.
Related: https://github.com/odoo/odoo/pull/62418
opw:2391464
closesodoo/odoo#62591
X-original-commit: 59413ad88a97b3221526c2b560178a0f94ddee05
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
