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>
Since [1], an attribute is added on all snippet contents, on the main
node, to be able to identify them and better support them. This is
added thanks to the t-snippet or the t-snippet-call instruction. The
problem was this was not working if the first node of the snippet
definition is also a t-call to another sub template. This now works.
[1]: https://github.com/odoo/odoo/commit/11c60739e4f4379a61581ed179bc7debbb5e91f9
task-2276740
PR #53175
*: website
Since [1], the thumbnails of the saved snippets were not right anymore,
all fallbacking to the default image. This is because snippets thumbs
now use svg files instead of png and the snippet saving feature did not
allow it. This commit fixes that and makes the feature more robust.
- Allow to use any original thumbnail, and not only for website app.
- Remove useless defaut image, a fallback for when the feature is broken
is useless.
- Identify snippets by key instead of by main class (possible since
the new `data-snippet` attribute on snippets).
[1]: https://github.com/odoo/odoo/commit/b7fe2bdae2f45372c0d538767a226a413b806f3fclosesodoo/odoo#55896
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In #45174, the original_id field was added on ir.attachment, so that
derived images in the web-editor (cropped, resized, optimized, ...)
could keep a trace of the original, such that if the user wanted to
revert it or change the crop/size/optimization parameter, we could do it
from the original again so that for example the quality can be increased
or the crop region made bigger.
The addition of this self-referencing many2one from ir.attachment to
itself however will cause DELETE queries on ir.attachment to do a
sequential scan on the table to update potential records referencing the
deleted record in their original_id field. As the ir.attachment table
tends to be one of the biggest tables in production databases (millions
of records), this scan can take multiple seconds per DELETE operation,
and since attachments are used everywhere in odoo to represent files,
DELETE operations on them are frequent.
Adding an index on the original_id field should make these DELETE
operations substantially faster (scaling with the log of the number of
filled original_id fields, which will be very small, instead of scaling
linearly with number of records)
closesodoo/odoo#54676
X-original-commit: 2b5064a00b7a5c8dc66429869287386f244b1257
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since dd139948f0 when saving oe_structure for the first time, for eg.
a `<div class="oe_structure" id="oe_structure_part_1"/>` structure, when
edited we will create an inheriting view that fills it.
But this inheriting view would contain branding data and "data-note-id"
which would make this use case erroneous:
- edit page and fill oe_structure => data-note-id="1" saved on view
- edit page and add link in other oe_structure => error
This happen because the data-note-id refers to the editor of the
element currently being edited, since we saved it previously we get two
elements with `data-note-id="1"` and the code will just get the first
one which in reality could have not been in editing.
With this change, we strip the branding data on the parent element.
Without the change, added test failed with:
AssertionError: '<div class="oe_structure" data-test="1"
id="oe_structure_test" test="2">hello</div>' not found in
'<t t-name="dummy"><div class="oe_structure" data-test="1"
id="oe_structure_test" data-oe-id="55" test="2">hello</div>
</t>' :
saved element attributes are saved excluding branding ones
opw-2268836
closes#53321closesodoo/odoo#53346
X-original-commit: 855438be92ee71d8f8d5afedd52459e149ec49f7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The _view_get function is a recursive function used to retieve all the
views related to a view (inherited or t-called).
The issue is that by an odd set of circumstances it is possible to have
a loop in the view graph. Resulting in the recursive function being
called until a "maximum recursion depth exceeded" error occurs.
Example of a loop: A t-call B and A inherit from B
This is possible on an update of a view that has been forked by website:
If the view A was doing a t-call on B and is has been duplicated with
the arch modified.
When we update with the changes A now inherit from B instead of t-call B
Since the arch was modified it will not be updated so A will still
t-call B but the inherit_id of A is unchanged so it will be updated to
reference B resulting in a loop.
closesodoo/odoo#51620
X-original-commit: 63e1e84ebd7e609d6e06d83dc0f0092688b013eb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
The method fields_view_get should be the only way to retrieve the view
content. This method is executed in a super-user context.
To avoid retrieving views for a model a user does not have access to
(as it may reveal some informations like name of fields), add a
verification of 'read' rights before retrieving the view content.
Execute _postprocess_access_rights with sudo(False) as this method is
used to evaluate which buttons should be displayed.
Remove the su flag to avoid misleading the user and displaying a
button they won't be able to use.
Retrieving the database id from an view key is not considered as a
sensitive information and get_view_id and viewref can be left as a
public methods.
Add missing sudo when needed
Change _handle_visibility in website to avoid increasing the query
count: Checking the visibility (to fail most of the time) to retry in
sudo was making unecessary queries.
* = mass_mailing, web_editor, website_crm, website_event, website_form,
website_forum, website_hr_recruitment, website_mail_channel,
website_mass_mailing, website_sale, website_slides
When an outdated snippet's option are activated we display a warning
in the left panel that inform the user about the potential
malfunctions.
To do so the snippet's template key is added to the snippet as
data-snippet.
If a snippet is "t-call" inside another snippet, it will need to use
t-snippet-call instead of t-call to have the key on himself.
Those unique keys are used on snippet selection to retrieve the
snippet's version in the left panel and compare it with the currently
selected snippet's version. Versions are describe with data-vcss,
data-vjs and data-vxml. If a snippet's key is not in the left panel we
consider that snippet as outdated.
Added some tests to ensure that t-snippet and t-snippet-call really have
their template key as data-snippet
Adapted the views to the data-snippet changes adding
data-snippet="tmpl_key".
Part of: https://github.com/odoo/odoo/pull/44569
task-2189669
closesodoo/odoo#50254
X-original-commit: 28a6cd49b6e87b75c2e70771e241c41778bf9e87
Related: odoo/enterprise#10236
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If for some reason someone wanted to develop a textarea using the
editor which is supposed to work as a public user (like we are trying
to do on Odoo.com), it was not possible. The code was "designed" to
allow it but there was one problem: the lazy loading of the editor
assets required a `render_template` call to the server... which cannot
be done from a public user.
This commit solves the issues by allowing the lazy loading of assets
to use a custom route if required. That route is then used by the editor
"root". That route performs the render_template as a superuser provided
that the view's xmlid is whitelisted.
Note: there was another unauthorized call for public user: the
colorpicker. This was solved by disabling the colorpicker template rpc
for public user, they will still get the default summernote one.
Part of https://github.com/odoo/odoo/pull/48981closesodoo/odoo#48981closesodoo/odoo#49398
X-original-commit: e84a0bfdc99c21406861b88c02b11c925d92f927
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In a recent commit, we decided to change the image url format generated
by the media-dialog to leverage browser caching using unique.
Unfortunately, when saving an img tag to a binary field, the url parsing
did not support this new url format, causing a traceback when changing
the website logo and attempting to save.
closesodoo/odoo#48914
X-original-commit: 9c618c7f903f1a0b32e067cfd713cd39762250f9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website, web_unplash
The html alt attribute is supposed to contain a description of an
image's content (an alternative to the visual representation), a lot of
snippets contained alt attributes that were not descriptive of their
content, and would as such be counter-productive in terms of
accessibility. This commit removes those.
Previously, the alt attribute on img tags had to be set manually by the
user through the editor. This commit makes use of the description field
on ir.attachment to store image description, and sets the alt attribute
on images to that description when choosing an image from the media
dialog.
task-2091417
closesodoo/odoo#45174
Related: odoo/enterprise#9520
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, image urls did not contain the unique parameter, this
resulted in all browser caching for images being dependent on etag
headers. This commit changes the url format used by images in the
web_editor to use the /id-checksum/ format instead of only the id, this
in turn makes it so that the 'Max-age' header is set to 1 year. This
also solves some browser caching issues when changing the optimization
level of an image in place in the media-dialog.
For binary attachments with an url (eg, unsplash images) the unique is
added as a search parameter (?unique=checksum) as a cachebuster
mechanism, but currently doesn't set the max-age header, which may or
may not be done at a later date.
task-2091417
Previously, when selecting an image, the user could optimize their
images by clicking a little cog icon in the media dialog. They would
also be prompted to optimize their images when uploading them. In most
cases, it makes a lot more sense to always save the original in the
database, and optimize the original whenever it's dropped in the page
automatically.
A second problem is that when using the optimization feature, optimized
images would be displayed along the originals by default, resulting in a
lot of duplicates while browsing the media dialog.
This commit changes both of these things:
- By default, when uploading an image, the original uploaded image is
used. The user can still optimize their image manually through the
media-dialog by using the cog icon. When choosing an image in the
media-dialog, if it's not already an optimized image, an optimized copy
is automatically created and used instead.
- Optimized images are now hidden by default, in the media dialog, and
can be shown by clicking a checkbox at the top of the modal when in
debug mode
task-2091417
closesodoo/odoo#45174
Before this commit, each module override _get_translation_frontend_modules_domain
from ir.http to add its own translation in website if needed and that module
is not starting by website_. Updating the domain from the super() call.
Since we know in most of the case the name, it is useless to do a:
select name from module where name = 'name1' or name = 'name2'...
Now we support a new override of _get_translation_frontend_modules_name that will
allow to add the known module name directly in the list instead to make a search.
In case nobody override _get_translation_frontend_modules_domain, we don't need to
make an extra rpc to find the module.
Related to #47257
task-2211013
X-original-commit: 0dc54814161ab55c34dd2242f65dea23d19fdfca
This issue was introduced with commit 251b880de1caeeef1f27447d4ad69e1abeffde19 : in case current user has no langage,
we should have a fallback case by retrieving the first langage installed in the database.
closesodoo/odoo#46487
X-original-commit: 67cf1150507b8092c32bf745e4c8620409fdc238
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Before d00c0e317, `Datetime` fields would be editable in frontend but would
have unexpected results, especially in non-English languages, for when the
english lang format had been changed.
It would also crash when saving non-English strings, such as `Lundi`.
For more details, see https://github.com/odoo/odoo/pull/44484#issuecomment-586850490
Since d00c0e317, only date displayed in lang format would be editable, which
case is Event page in Odoo 12.0. Everywhere else, the format is changed for a
nicer layout, either with `widget=XXX` or `t-options=YYY`, such as:
`<time t-field="record.date" t-options='{"format": "MMM d, yyyy"}'/>`
`<time t-field="record.date" t-options="{'time_only': 'true', 'format': 'short'}"/>`
When a date parsing crashes during editor save, the problem is not only that
the date can be saved, but the whole changes of the page are lost, as they
won't be saved either.
This commit attempts to fix every languages cases, regardless of the website
lang or user lang.
To do so, we store the date in the user lang format in a data attribute of
every date field in the DOM. Once the field is clicked (to edit probably),
that value will replace the one displayed according to the widget/options.
That way, dates will always be sent to the server in the user lang format,
avoiding any possible mismatch.
This whole fix apply to `Datetime` and `Date` fields.
opw-2183055
Closes#44484Closes#45555Fixes#44047closesodoo/odoo#45725closesodoo/odoo#45997
X-original-commit: c0db9bb8027ff926c619aebe6e0a5cdd05808232
Original-signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Denis Ledoux