*: base, web_editor
The Many2oneUserValueWidget does not allow the user to reset it
to blank if it already contains a selection. This commit makes it
possible to select an empty value by specifying a `null_text` option.
task-2406626
Part-of: odoo/odoo#67913
Before this commit an ir_assets generated automaticaly by the web editor
will generate an url ending with ...custom.addon.bundle_name.ext
After this commit the url will start with /_custom/addon.bundle_name/...
This will make it easier to spot at immediately if it is a custom asset
and thus it is useless to apply the glob. Actually, it will fail on the
/_custom when trying to glob, making it faster.
This is mainly useful to clarify and debug but in a case with mainly
customised ir_asset for one bundle, it may have an impact on speed.
An upgrade script was created for this change.
closesodoo/odoo#120699
Related: odoo/upgrade#4636
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
*: mass_mailing, website_blog, website_event, website_mail_group,
website_mass_mailing, website_payment, website_sale, website_twitter
The names of snippet blocks are not translatable because their name is
obtained from a their template name which is not a translatable item.
For markets that use a non-latin alphabet this is a no go.
This commit makes it possible to specify a `string` attribute in the
`t-snippet` blocks that makes their name inventoried by the translation
process.
closesodoo/odoo#118530
X-original-commit: a501d226d8674ed0c9b183c69a9e754c79682237
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since [1] when the Dynamic Snippet was first introduced, it also
introduced a concept of "inherited" snippets. Specific snippets would
all `t-call` the same template for their rendering.
A mechanism was introduced to deduce the `data-snippet` from the caller
template, but it stored the obtained value in the `t-called` template
itself. Because of this if several "specific snippets" that used that
template had to be rendered, they would all have the `data-snippet`
value of the first one that got compiled.
We could compile the snippet template into something having a
dynamically obtained `data-snippet` value, but then that would be
equivalent to just using a `t-attf-data-snippet`.
All specific snippets already do set a `snippet_name` in the context
because it needs to be added in the classes.
This commit therefore adds a `t-att-data-snippet` attribute on the
base template, and populates with that same value in `onBuilt` for
stable versions.
During forward ports across stable versions, each new caller must be
patched as well - and all patches must be removed in master.
[1]: https://github.com/odoo/odoo/pull/53175
task-2922635
closesodoo/odoo#115566
X-original-commit: 73d2c9f87bf9a1a792f4318325c2e52fc81db5f2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The following basic case has been broken in website forever since [1] in Odoo 8:
```html
<p><span>a</span><span>b</span></p>
```
Saving the above html results in:
```html
<p>
<span>a</span>
<span>b</span>
</p>
```
Which, when re-rendered back in the DOM renders equivalent to:
```html
<p><span>a</span> <span>b</span></p>
```
Note the space between "a" and "b". That is because etree will pretty print
nodes with indentations as long as they do not have text content, and that
indentation is collapsed into a single visible space by the browser when
inserted in the DOM. This is not limited to span nodes as the same applies to
any inline node. This is very easily reproduced in website on any version:
- Drop a Text snippet.
- Replace all the content of the snippet by "ab".
- Put "a" in bold and "b" in italic.
- Save.
- Notice that the saved version is now "a b" instead "ab".
The user has no way of removing this space easily because even if they manage to
do it by any mean, the server will pretty print the html again and the space
will reappear. The only way to circumvent this is to have some text content as
sibling of the inline nodes.
Consider this:
```
>>> etree.tostring(html.fromstring('<p><span>a</span><span>b</span></p>'), pretty_print=True)
b'<p>\n <span>a</span>\n <span>b</span>\n</p>\n'
```
Which is incorrect, while this:
```
>>> etree.tostring(html.fromstring('<p><span>a</span><span>b</span>c</p>'), pretty_print=True)
b'<p><span>a</span><span>b</span>c</p>\n'
```
Is correct.
We could fix it using a heavy hack that would leverage this behavior by
inserting one of the few unicode control characters that etree considers to be
actual content, and therefore preventing pretty printing for this node. The
server would then remove the control character to avoid polluting the actual
views. This would have the side-effect of forbidding this control character to
ever be used in a view however, and would obviously be an extremely ugly hack.
The alternative which was chosen in accordance with Antony (al) and Xavier (xmo)
is to disable pretty printing altogether, since the original commit [1] seem to
have introduced it as a fix for an old version of the editor rather than for the
intrinsic qualities of having pretty printed views.
If we ever want to re-enable pretty printing in the future, I suggest it be
implemented in JS because the browser is the only one able to assert whether a
node is going to be treated as a block or as an inline with respect to the
current CSS rules in application.
task-3142796
opw-3122373
opw-3186250
[1]: https://github.com/odoo/odoo/commit/6b857b6eeb59137a71385f98c82c440ac82cd45dclosesodoo/odoo#115159
X-original-commit: 3c6b9249482454a931f384ffc66ceec64dffbcfc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, only the immediate parent of a selected node was
checked for HTML content support in order to determine the toolbar's
visibility. This led to incorrectly displaying the toolbar for fields
like the 'list-price' on an e-commerce product page, whose text content
is wrapped in an extra 'span' element inside the field's span element.
This commit fixes it by checking all of the node's ancestors up to the
editable root for the attributes that determine if a field supports HTML
content.
This commit also prevents a server error if the user somehow styles the
product's price (with ctrl+B for example. It's worth noting that such
style would not be kept in the saved version of the page).
lxml.HtmlElement's `text` property has `None` value if the span element
does not contain any text before its first child element
(see https://lxml.de/apidoc/lxml.html.html).
Therefore an element like `<span><strong>42.00</strong></span>` would result
in `None` when reading its `text` property.
The `text_content` method is more suitable for such task as it returns the
text content of an element and its children.
task-3188550
opw-3171669
closesodoo/odoo#114867
X-original-commit: 524ba7f89286aa03ed6a4da30177c9ce7018c59a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, this flow was broken:
- Install website
- Create a new website of your own (not using the one created
automatically from XML data)
- Choose another color palette for that website
- Uninstall the website app
- Reinstall the website app
- Try to choose another color palette for any website
=> It does not work
Indeed, after the uninstallation, the DB is left in an invalid state:
the SCSS customizations attachments of the website that was created by
the user are not removed, they just have their website_id field emptied.
Some code made at [1] was already there to remove those attachments. The
problem is that it only worked for websites which were created by XML
data (at website installation), not by the user. Indeed, the `unlink`
method is not called during uninstallation to remove records that were
created by the user, thus the `unlink` override was not called either.
See [2] for some details.
This fixes the issues by moving this attachment cleaning code in a
dedicated method, called in `unlink` but also in the `uninstall_hook` of
the website app.
This also takes the opportunity to refactor the code involved, in
particular to not even consider customized attachments which do not have
a website_id.
[1]: https://github.com/odoo/odoo/commit/2f361bec36dff09181b96d140d62c477cdf013a1
[2]: https://github.com/odoo/odoo/pull/97852#pullrequestreview-1067851656
opw-3127531
closesodoo/odoo#110338
X-original-commit: 988eafa03b57be3b3a7f110650c61ce8fda88e31
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In commit [1] it was decided that the Snippet Menu would have its UI in
the user's language, while the Snippets' Content would be in the
language of the website they are currently editing. To do so, a new
context key was added: Snippet Lang.
Unfortunately, while Odoo handles the compilation according to a
language, website_id and more, it does not do so according to the
snippet lang.
It would not be an issue if the Snippets were compiled only in edit
mode, as a Website only has one default language. Unfortunately the
Snippet Content is also rendered in translate mode (Since the
SnippetMenu is one big XML template), therefore it can be rendered in
different Snippet Lang (though it's useless).
This commit fixes that by adding Snippet Lang as a cache key so that if
the key is present, it will re-compile the template.
Steps to reproduce:
- Create a new language
- Translate a snippet (e.g. search s_cover view and translate contact
us)
- Create a new website with 2 languages, the new language as default and
english
- Enter translate mode
- Leave it
- Enter edit mode via the "Edit master" button
- Drop the translated snippet
- It will not be translated because the Snippet Menu was rendered in
English first.
A commit introduced after this one will test these steps.
[1]: https://github.com/odoo/odoo/commit/55a978aa86967581956f855a1c5db33b7425bd15
X-original-commit: 6eba6203e9f1b8a730ab53f80fea8e7b78818bc7
Part-of: odoo/odoo#108643
Before this commit and since commit [1] which introduced
`SUPPORTED_IMAGE_EXTENSIONS` on top of the existing
`SUPPORTED_IMAGE_MIMETYPES` there would be 2 lists which were holding
related values which a strong link between the two: one was holding the
image extensions while the other was holding the images mimetypes.
It was a bad idea as it was not robust and no relation between the two.
It's an issue as some WIP code was then trying to retrieve the extension
based on a given mimetype which was not possible to do in a reliable
way:
```py
ext = SUPPORTED_IMAGE_EXTENSIONS[SUPPORTED_IMAGE_MIMETYPES.index(mimetype)]
```
The chance is then taken to merge those 2 lists in a single dict that
will strengthen the link between the mimetype and its related extension.
[1]: https://github.com/odoo/odoo/commit/9dab9ffce297dcfc89f0ec7efc4c8f8b43104220
Part-of: odoo/odoo#98801
Prior to this commit, when using a background video on the cover of the
website_slides homepage (/slides), after saving, a traceback would
occur and the video would not be displayed.
Steps to reproduce:
- Install website_slide
- Go to /slides
- Enter edit mode
- Change the cover of the page by a video
- Save
- Traceback
The reason for that is that the cover snippet used on the homepage of
elearning is the root of an XPath instead of its own oe_structure. (This
was changed in 16.0)
[1] made it so that the style and class attributes are saved but did not
save any data attributes needed for the background-video widget to work.
This commit adds those data attributes.
[1]: https://github.com/odoo/odoo/commit/5b252215dc375526af87c31a32256dd1a9582f02
opw-3063043
closesodoo/odoo#107577
X-original-commit: 86dc4d4349d033c95c0e04e8c173f63e5e2044ed
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The model terms translations assume the number of terms in each language of a
model_term translated field should be the same.
However, sometimes the assumption cannot be promised for sake of bad
translations
This commit
1. drops illegal model term translations while translating
2. drops mismatched terms at run-time in case the database has been contaminated
closesodoo/odoo#107373
X-original-commit: f9ab5ca3e99b2883ada18a8f6deb12d45608b43f
Signed-off-by: Raphael Collet <rco@odoo.com>
A MissingError traceback that occurs in `_build_bus_channel_list` was
caught by Sentry. This error has been seen 1.3k times in the last 30
days from several customers.
The fix simply consists in checking if the document exists before
checking the rights on it.
Traceback:
```
MissingError: Record does not exist or has been deleted.
(Record: project.task(83,), User: 6)
File "addons/bus/websocket.py", line 879, in _serve_forever
req.serve_websocket_message(message)
File "addons/bus/websocket.py", line 752, in serve_websocket_message
service_model.retrying(
File "odoo/service/model.py", line 134, in retrying
result = func()
File "addons/bus/websocket.py", line 767, in _serve_ir_websocket
ir_websocket._subscribe(data)
File "addons/bus/models/ir_websocket.py", line 38, in _subscribe
channels = set(self._build_bus_channel_list(data['channels']))
File "home/odoo/src/enterprise/16.0/spreadsheet_edition/models/ir_websocket.py", line 13, in _build_bus_channel_list
return super()._build_bus_channel_list(channels)
File "addons/web_editor/models/ir_websocket.py", line 33, in _build_bus_channel_list
document.check_access_rule('read')
```
SAAS-K22 (sentry code)
opw-3086292
closesodoo/odoo#106982
X-original-commit: 9e4c5e427285b76000398476e9d923e7ea036a65
Signed-off-by: Achraf <abz@odoo.com>
* web_unsplash, website_forum
With [1], the access errors when a portal user were using the media
dialog got fixed. It also came with the unsplash capability for portal
user in the media dialog.
Still, there was a remaining problematic point: an internal user can't
upload an unsplash image in the backend through the media dialog. It
doesn't really make sense for an internal user to have less right than
the portal user.
This commit corrects that part.
Note that only unsplash images were problematic, not regular uploaded
image as the difference was that unsplash images attachment are saved
with an `url` property, which was triggering due to [2].
Finally, it was chosen to make that "bypass" more robust and opt in, so
forum and unsplash are allowing their use cases to go through, it's not
done in a generic way anymore.
Also fixing a small issue about the res_id not being sent when editing a
forum post, because it was assuming that the URL would end with the ID
which is not the case when you edit your answer.
[1]: https://github.com/odoo/odoo/commit/e10493711879c7f0cc8832db3f1936c622ea605c
[2]: https://github.com/odoo/odoo/commit/bfffe39f1376a56226572295b945a2cc73ba50ce
task-3007844
closesodoo/odoo#103138
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Avoid having multiple tooltips. We keep only one "t-field"
in the template. The other are replaced by a "t-out".
We also add a specific message when the datetime format is not
respected.
task-2942617
X-original-commit: a99d684507782cd0d9ff700dc7a12f7a46442403
Part-of: odoo/odoo#102545
When the ACE editor was introduced in [1], it relied on the already
existing `_views_get` to obtain the list of views that could be edited.
When the `mode` of `ir.ui.view` was introduced in [2], no mechanism was
introduced in `_views_get` to avoid fetching primary views that have
nothing in common with the current view.
This commit adds a parameter to `_views_get` to request the
exclusion of unrelated primary views.
Since even before it appeared in [3], `_views_get` relies on the
following approach:
- consider the top-most parent of the `t-call`ed views
- consider the views that inherit it
I.e.: reach each node of each view hierarchy tree by starting from its
root.
Because this starts from the top-most parent, simply preventing the
call to each primary child view is wrong, because any child on the
parent path must be considered - be it primary or not.
We therefore introduced a `skipped` list that keeps track of those
"later to be processed" views - so that the filtering of primary
children does not remove them.
[1]: https://github.com/odoo/odoo/commit/7c45e5976e6caf3d7b9eb508f728062704232261
[2]: https://github.com/odoo/odoo/commit/434be479f97a32987d0817bf329183fc2bbe3bf5
[3]: https://github.com/odoo/odoo/commit/bff6e04e9536d7b80916987eb123de98b1b689b1
task-2898555
closesodoo/odoo#100625
X-original-commit: 34ac97ce96019573a6a0af968d9c90b9d0d89ae8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Instead of fetching all field attributes sent with the field list
to the web client,
restrict the attributes to the ones actually required by the web client
This allows, for instance,
to gain 44,75KB on each call on `get_views` for `account.move`,
from 208.78KB to 164.03KB,
with only `account_accountant` installed.
closesodoo/odoo#99660
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
See previous commit(s) for more details about the new sanitize feature.
This commit implement a solution in the website builder to warn
restricted users when they can't edit a field due to the sanitizer
restriction.
Long story short: a HTML field can be flag as `sanitize_overridable`
which will allow users with the `base.group_sanitize_override` group to
not go through the sanitize process.
It means that such users can write some content which is not sanitize
friendly. A restricted user trying to add content in such fields would
then break the original content as the sanitizer would remove part of
the DOM.
In such cases, the field in the website builder is not detected as an
editable part and clicking on it will warn the user about it.
closesodoo/odoo#97398
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Add the possibility to flag a HTML field as `sanitize_overridable`.
The sanitizer will then be bypassed if the user doing the operation is
part of the new group `base.group_sanitize_override`.
The "Settings" users are part of that new group.
If such a user wrote some HTML that would have normally been removed by
the sanitizer, then users without the right to bypass the sanitizer
won't be able to write on that field anymore.
Otherwise, it would sanitize the previously written data.
Such cases are detected, and the modification prevented by the system,
which will warn the user about it.
For instance, with a `field.html(sanitize_overridable=True)`: one being
part of `group_sanitize_override` could write `<script></script>`.
Then, someone not part of the group trying to add an element inside that
field like appending a `<p/>` -> `<script></script><p>New Content</p>`
would not be able to because it would go through the sanitizer and
ultimately, removing part of the original value:
`<p>New Content</p>` (`<script></script>` would be removed).
== Real use case ==
In the website builder, there is 2 editor rights:
- group_website_publisher: restricted editor
- group_website_designer: editor & designer
The designer editor can edit pages and views, while the restricted
editor can't do anything unless he is part of other groups.
In edit mode, the restricted editor will only be able to edit fields of
record he has access to.
For instance, being a sales manager allows you to edit a product
description on the website.
Being an event manager -> edit event. Slide manager -> Slides etc.
As those restricted editor are able to edit those fields, they are
(almost) always sanitized to prevent them to introduce malicious code.
Since those fields are sanitized, even admins / designer editor are not
able to fully use the website builder in such fields.
Some clients don't really care about that sanitation, they'd prefer to
avoid it as they trust their manager and would prefer to have the full
builder capability instead.
This is typically the case in small project (butcher, hairdresser,
reseller etc) and in SMEs.
With the new `sanitize_overridable` feature, they will be able to do
that, as the "Designer & Editor" group now also receive the group
`base.group_sanitize_override` (done in next commit).
Part-of: odoo/odoo#97398
*: hr_presence, web_editor.
This commit is part of the websocket integration in Odoo.
It focuses on adapting the bus to support websockets:
- last notification id is now kept on the server
- channel list is built by overriding the `_build_bus_channel_list`
method of the `ir_websocket` model instead of overriding the `_poll`
method of the bus controller.
- The bus presence was updated during polls, since there is no more poll,
bus presence update will be the responsability of the client.
- The `/websocket/peek_notifications`, `/websocket/update_bus_presence`
routes will be available so that odoo sh can access notifications/update presence
from http requests.
- /longpolling routes are now prefixed with /bus thus won't be redirected to the
gevent worker anymore except for `/longpolling/health` which is the
health check route of the gevent server.
Since websocket now handle incoming messages, a way to manage authentication
have been introduced :
- The session is retrieved from the HTTP handshake.
- When a websocket message comes/leaves the session is retrieved
on the file system so that we're sure it still exists and that
it is up to date.
- The session is checked
- If no session is found on the file system or `check_session`
fails, the websocket connection is closed with the `SESSION_EXPIRED`
close code (which is a custom close code: 4001).
- Note that websocket connections are closed every `KEEP_ALIVE_TIMEOUT`
seconds to ensure no websocket connection will stay open if the user
clears its cookies.
- Note that a wsrequest object is available when processing incoming
messages. It is similar to the http request and contains various
useful informations (session, env, ...).
Part-of: odoo/odoo#75510
*: website, website_mass_mailing, website_payment
When an unsafe snippet is dropped into a sanitized HTML model field, its
unsafe content gets removed on save.
We need a way to mark snippets as being (in)compatible with
sanitization. It cannot be automatic, as, for example, the snippet
introduced at [1] contains an iframe but is compatible with
sanitization.
In 13.0, we will temporarily set up an automatic mechanism that marks
existing snippets containing forms as being incompatible with
sanitization.
In 14.0 a distinction between full sanitization and form-tolerant
sanitization introduced at [2] is added with this forward-ported commit.
This commit prevents unsafe snippets from being dropped into sanitized
HTML model fields.
The "Form Builder", "Product Search" and "Product Search Input" blocks
are now prevented from being dropped or moved into form-sanitized HTML
fields.
To do this, this commit introduces a new `t-forbid-sanitize` attribute
on the `t-snippet` tag. It can have the value `true` to prevent it from
being dropped into any sanitize fields, or `form` to specifically limit
to form-sanitized fields.
Steps to reproduce (in 13.0):
- Go to a product page
- Drop a "Product Search" snippet into the product-specific section of
the
product
- Save
=> The form was removed.
[1]: https://github.com/odoo/odoo/commit/c2e9bd0e60014b6a42931cf300e0f89f8cf7c225
[2]: https://github.com/odoo/odoo/commit/388c222c6c4bb7e2fe3e67009b248359ae0fd3db
task-2829961
closesodoo/odoo#96812
X-original-commit: 9eaba23781766730b06e936dbd9c5d0c28c909c6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When editing database fields via the web editor, their value are not checked.
Thus, stack traces can come up to the front-end user.
Step to reproduce the issue:
1) Install the E-Learning module and connect to the website
2) On the main website (not the backend), go to Courses > Edit
3) Edit the Next Rank treshold with any non integer string (e.g.: coucou)
A stracktrace will be shown upon save.
Solution: The issue is that there are no validation on the submitted fields,
this can cause stacktraces. A try-catch was used around the parsing of the
input value to catch and properly raise these exceptions to show clean errors.
On top of this, integers were not properly parsed, they were not taking into
account the `thousands_sep` of the user lang (e.g.: 35,000 for 35000).
NB: Generic fix of the following PR [1].
[1]: https://github.com/odoo/odoo/pull/85535
opw-2819392
closesodoo/odoo#96187
X-original-commit: edf76dbb0880c9b08354563a3c77e7c06a604802
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Prior to this commit, when an exception occured during the save of an
ir.ui.view, the traceback was shown to the user and an alert directly
asks the user to reload or cancel the page.
While reloading, the changes that produced the traceback were not saved
and the other modifications were saved.
If the user choose to cancel the reload, the web editor UI was freezed
and there couldn't be any edition anymore.
This commit adds correctly the popover to target the invalid element and
shows the error rather than reloading the page.
The element which caused the error can still be edited. The other are no
more editable.
task-2700198
closesodoo/odoo#87350
X-original-commit: 10b97f37ab5d78b3a2b0f63fa019ee95bb78ea7d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
- Three controllers were actually useless as the relevant public methods
of the web_editor.assets can be called directly via RPC in the related
usecases.
- Review the web_editor.assets model methods organization in the model
declaration.
closesodoo/odoo#85392
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When working on qweb fields it is difficult to find some custom override as
they are never in the right file. Finding them is always a bit of random pick.
Task-2607416
Part-of: odoo/odoo#74171
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
Since the refactoring done on ir.qweb at [1], directives are more
autonomous, so `t-att`, `t-options`, etc are no longer evaluated by
other directives. These directives are also ordered.
Before this commit, when directives such as `t-snippet`, `t-install`,
etc were called, the other attributes had already been consumed. Indeed,
at the end of the compilation, tags should no longer have attributes,
`t-att` removes all statics ones. So relying on the `string` attribute
in `t-install` was broken and so the snippet names for the snippets to
install from the editor panel in edit mode were gone.
This commit fixes that by evaluating those specific directives earlier.
[1]: https://github.com/odoo/odoo/commit/e830953570d5f28aee9bdcdf97af18d3e3246030
task-2762377
closesodoo/odoo#84752
X-original-commit: f40b9522f20d5fbfe62c3718566c1d92ccfad75b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
QWeb is the primary templating engine used by Odoo. It is an XML
templating engine and used mostly to generate XML, HTML fragments and
pages.
To create new XML template, please see :doc:`QWeb Templates documentation
<https://www.odoo.com/documentation/15.0/developer/reference/frontend/qweb.html>`
In **input** you have an XML template giving the corresponding input
etree. Each etree input nodes are used to generate a python function.
This fonction is called and will give the XML **output**.
The ``_compile`` method is responsible to generate the function from the
etree, that function is a python generator that yield one output line at a
time. This generator is consumed by ``_render``. The generated function is
orm cached.
In the graphic below you can see theresume of the call of the methods
performed in the IrQweb class.
Odoo
┗━► _render (returns MarkupSafe)
┗━► _compile (returns function) ◄━━━━━━━━━┓
┗━► _compile_node (returns code string array) ◄━━━━━━━┓ ┃
┃ (add technical directives: t-inner-content, t-tag) ┃ ┃
┣━► _directives_eval_order (defined directive order) ┃ ┃
┃ ┃ ┃
┣━► _compile_directives (recursive) ◄━━━━┓ ┃ ┃
┃ ┣━► _compile_directive ┃ ┃ ┃
┃ ┃ ┗━► t-if ━━► _compile_directive_if ━┫ ┃ ┃
┃ ┃ ┗━► t-foreach ━━► _compile_directive_foreach ━┫ ┃ ┃
┃ ┃ ┗━► t-* ━━► ... ━┛ ┃ ┃
┃ ┃ ┗━► t-inner-content ━━► _compile_directive_inner_content ◄━━━━┓ ━┛ ┃
┃ ┃ ┗━► t-tag ━━► _compile_directive_tag ━┫ ┃
┃ ┃ ┗━► t-call ━━► _compile_directive_call ━┫ ━━━┛
┃ ┃ ┗━► t-out ━━► _compile_directive_out ◄━┓ ━┫
┃ ┃ ┗━► t-field ━━► _compile_directive_field ━┛ ┃
┃ ┃ ┃
┗━━┻━► _compile_static_node ━┛
Part-of: odoo/odoo#81024
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
For email design in the context of Microsoft Outlook, we want to keep
some magic Microsoft comments (Outlook conditional comment), which -
until this commit - were skipped by QWeb. These allow us to change the
rendering exclusively for Outlook so as to overcome some of its
limitations. This commit introduces a qweb rendering option
(`preserve_comments`) for when - like in mass mailing and digest - we
want to keep comments.
Part-of: odoo/odoo#80621
* Remove AST in favor of pure Pyhon. This should make it easier for
developers to understand and create new directives because they do not
need to know AST.
* Remove `t-call-options` as it has been merged into `t-options` for more
consistency. Support for t-call-options is retained.
* Use generators for lists. This increases performances as the rendering
can be sent directly without having to wait for the creation of the
entire list.
* Optimize expressions runtime computation by pre-computing the static
parts.
Example:
'<' + 'div' + '>' + '<' + dynamic_value + '>'
Now compiles as:
'<div><' + dynamic_value + '>'
Rationale:
The majority of cases where an ir.asset is manually declared
outside of manifest files is to specifically add a single asset file.
This means developers are specifying a single asset *path*, and not a
glob expression. In this context, it seems better to name the filepath
field `path`, and document that it can be specified with a glob
expression when (seldom) needed, rather than making the exception appear
to be the norm - possibly puzzling many developers (What's a glob and
why do I need one?)
The doc is updated as well, and some spell-checking and wording
improvements were done too.
This required some adaptations to the existing `ir.asset` declarations:
- odoo/enterprise#17465
- odoo/design-themes#459closesodoo/odoo#68695
Related: odoo/upgrade#2348
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit changes the way assets are declared in Odoo modules.
Before: assets were declared in template files. Template bundles were
generated from primary templates, so technically any qweb template could
have been called as an asset bundle, with the 't-call-assets' directive.
Being standard qweb templates, they had access to standard HTML tags
(script, link, with or without raw scripts or style definition), qweb
directives (t-call, t-raw, etc.) and could be inherited by other
templates.
Now: assets are defined in the module's manifest and generated by the
't-call-assets' directive.
More information on the new system can be found on the updated user
documentation (see the "JavaScript Reference" section).
Task: 2352566
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
We only support .gif, .jpe, .jpeg, .jpg, .png, .svg
This commit won't let the code go though if we know the image format is not
suported.
Part of https://github.com/odoo/odoo/pull/65828
task-2345082
When you save your custom snippet you probably won't give it a
specific name.
Before this commit several custom snippets name was specified on save
and there was no way to modify their name afterwards
After this commit custom snippets are assigned a generated name but they
can be renamed afterwards
task-2374802
closesodoo/odoo#61483
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- add a new language with locale code KUR (for Kurdish)
- print any report with a datetime on it (RFQ for example)
Cause
Babel (version < 2.7.0) does not handle locale "KUR".
Solution
If wrong locale or not managed by Babel, try to fallback
on server default locale.
If still wrong locale or not managed, then fallback on "en_US" as locale.
opw-2416482
closesodoo/odoo#64304
X-original-commit: e6ccdb397792db62c3b08d96435b3c1667c1aa9d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The normal flow to render a template is now to use `render_public_asset`
which bypasses the read access rights if the user matches the groups
the view declares.
For public users, we still cannot use that as they do not have access
to calling model methods at all. The route `public_render_template` is
thus still needed, but it should use the `render_public_asset` util.
Related to task-2412544
closesodoo/odoo#64167
X-original-commit: 3fd40ba2030fef7dccf4046a932e3b3a172dc53f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit only the first default palette color was configurable
on illustrations
After this commit all 5 default palette colors are configurable on
illustrations
task-2368585
closesodoo/odoo#60503
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In order to allow modifying background images, we need information on
the image, this is done by creating a placeholder img and calling the
loadImageInfo function on it. However this function did not account for
the case where an image had not src attribute, which causes an
unnecessary rpc. Other problems could arise from this as an attachment
that doesn't have the correct mimetype but has a matching src could be
returned, causing its image_src field to be false, which we would then
attempt to load as a valid image, causing crashes.
This commit fixes that by not trying to load image infos when the src of
an image is empty, only looking for attachments of the supported
mimetypes, and also checking that we actually did receive an image_src
before setting it as the original src of the image, which will prevent
accidentally trying to load a falsy src as an actual image.
closesodoo/odoo#60982
X-original-commit: b0993370b6fcec1f966e4bf2994eee7f31da82d5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue occurs due to the way we compute the default value in base ir ui view.
The method _compute_defaults don't set extention mode under some condition
even if we provide an inherit_id view.
This commit double fix it, we use now self.env['ir.ui.view'] to create the
new view and so always compute the mode based on 'if inherit id or not'.
Second fixes is to explicitely set mode manually as 'extention'.
before commit:
when you drop snippet to blog sidebar and click save button.
The changes of user is not visible in sidebar because view created in mode
'normal' and not 'extention'
task-2311520
closesodoo/odoo#55908closesodoo/odoo#59318
X-original-commit: a944ce9beaaf984a7b1282785d03d4bfc8220f18
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: jpr-odoo <jpr@openerp.com>
Benoit Socias