As we have a team dedicated to work on analysing tracebacks
with sentry, and to takedown all tracebacks occuring on the saas,
we do an effort to avoid unecessary warnings and tracebacks
for both sentry and the runbot.
closesodoo/odoo#112101
Signed-off-by: Rémy Voet <ryv@odoo.com>
Before this commit, we only support rgba(xxx,yyy,zzz,v.www)
Now we support also rgba(xxx, yyy, zzz, v.www)
How to reproduce:
Edit theme color secondary, chose a color with transparency.
Go to a 404 page and the pinky will be not loaded.
closesodoo/odoo#114486
X-original-commit: e418c912509999e44bcfc5325f3df6844af9bfe6
Signed-off-by: Jérémy Kersten <jke@odoo.com>
When record does not contain any value for a field being checked by
`ensure_no_history_divergence`, prevent the check as there is no version
to check againts.
task-3196592
closesodoo/odoo#113767
X-original-commit: 7e32b645b28164038e13393867a79672d69e4d17
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
we don't necessarily need an error type logger here, a warning is enough.
In addition, it is reported on sentry because we receive all error type logs.
sentry-3931144637
closesodoo/odoo#113765
X-original-commit: 358a85103476d25ea507f210d0fae4eef9853669
Signed-off-by: Achraf <abz@odoo.com>
Using a lazy `?` quantifier lead to poor matching performances and
was not needed technically.
Using `*` instead of `+` lead to a lot of false positives when trying
to write records with an empty value for `data-last-history-steps`.
It is currently unclear how to reach such a case but in the meantime
it is better to allow people to write the record as such rather than
being completely locked with no possibility of saving.
closesodoo/odoo#113540
X-original-commit: 0a370758972e6a0c399471f9982f3898da92ef68
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Olivier Dony <odo@openerp.com>
*: base, http_routing, mass_mailing, web, web_editor, website_slides
In some situations `werkzeug.wrappers.Response` are used instead of
`odoo.http.Reponse` that extends it.
This is a problem because since [1] the calls to `set_cookie` expect it
to accept the `cookie_type` parameter, which is not the case in the base
werkzeug implementation.
This commit replaces the `werkzeug.wrappers.Response` by
`odoo.http.Response`.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8closesodoo/odoo#112827
X-original-commit: 28da08292b7028575e628c5ad846fc05d30498f2
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This commit add a mechanism to ensure that someone could never save
changes from an history that diverge (in case there is a partition in
the RTC network or a person A was disconnected while another person B
saved changes that were not transmitted to person A).
task-3002163
closesodoo/odoo#112099
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when the user tried to update a checklist, there
was a traceback in `handle_history_divergence` because the `value` is a
byte sequence instead of a string.
opw-3158660
task-3165844
closesodoo/odoo#112112
X-original-commit: e3900dfe51cb294ad139395cb402c9f13dd067c5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: mass_mailing
When images are dropped from outside the browser into a website page
text paragraph, they are stored as an inline base64-encoded source.
This commit marks those images to be saved as attachments when it
happens in website. The save happens upon page save similarly to what is
done when images are transformed.
This commit also applies this behavior for pasted images.
task-2928495
closesodoo/odoo#98801
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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
Website themes make customizations to the default snippets. In
particular, some are applying shapes on default images. To do that, the
customization is not applied on the image directly but by changing its
src to a special web_editor route in charge of automatically adding the
shape on whatever default image the configurator chose for this snippet.
Typically, in a snippet with an image whose src is:
/web/image/website.my_snippet_default_image
The src is replaced by the theme with:
/web_editor/image_shape/website.my_snippet_default_image/website/some_shape.svg
That controller/route crashed since [1], making those images blank
areas in pages generated by the configurator. Indeed, the image from
the filestore was accessed via `file_open` which only allows reading
inside the addons_paths.
[1]: https://github.com/odoo/odoo/commit/da8def8e410de68256ba4ab09ebf7a8b699355acclosesodoo/odoo#105421
X-original-commit: d536e0a23cf0aa06c3ee13fb2c105e83201434e0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Julien Castiaux <juc@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>
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>
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
*: 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_forum
Portal users cannot insert images in the WYSIWYG, eg in a forum post.
Steps to reproduce:
- Install website_forum
- Connect as portal
- Go to the forum and create a new post
- Type '/image' and try to insert an image
- An Access Error is raised preventing the portal user from inserting an
image
History:
- It was possible in version earlier than 15.0 before the new editor, as
it was using a base64 inplace image upload to bypass the access rights
and avoid creating an attachment.
- It was broken in 15.0 with the new editor which doesn't have such a
mechanism. The image upload was then disabled for those users in 15.0
with [1] to avoid that bad UX with those errors/tracebacks.
- It was decided to implement a clean solution in master and see from
there was will be done with 15.0 (as being able to upload an image on
a forum seems quite critical).
Solution here in master to be able to use the media dialog:
- First issue, about opening the media dialog:
It fetches attachments, which is raising some access errors. We now
catch the error silently and return an empty list.
- Second issue, about upload an image (and thus creating an attachment):
We now create attachments with sudo to allow access to portal users,
but only if he has write access on the model.
[1]: https://github.com/odoo/odoo/commit/e453d4c119a69f285d9a014babe485492bbe9c40
opw-2648770
task-2811325
closesodoo/odoo#82612
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Merlin (megu) <megu@odoo.com>
Loading assets for Odoo Editor's tests was a problematic matter since
some were in the lib folder while others were in src. This solves that
issue by finally creating a route for these tests, like web has one for
QUnit tests.
Part-of: odoo/odoo#94516
Since [1] the attachments are not found by `get_image_info` anymore
because the search based on the id only does not specify the model.
Because of this the mimetype of uploaded images is not put in the DOM
image's dataset. This lack of mimetype prevents the Shape, Filter, Width
and Quality image options from being used.
This commit defaults the model to `ir.attachment`.
Steps to reproduce:
- Drop a "Text - Image" snippet.
- Replace the image by uploading one.
=> The Shape, Filter, Width & Quality options did not appear anymore.
[1]: https://github.com/odoo/odoo/commit/da8def8e410de68256ba4ab09ebf7a8b699355ac
task-2883695
closesodoo/odoo#94288
X-original-commit: 99fda1024ff7d809f13523acd13770c02a49d1e1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
Rationnals
----------
Web servers can serve some resources (e.g. static files) right away
without any interaction with the web application. The network model of
most web servers makes them capable of handling thousands of
simultaneous requests when it comes to intensive IO operations such as
streaming data from a file. The network model of Odoo is different: it
is capable of a lot of processing power but can only serve a handful of
requests at a time, i.e. Odoo (with some help from postgres) is
optimized for CPU operations, not IO.
Some users don't configure their web server, they use a basic
configuration that relay all requests to Odoo. The result is that many
Odoo HTTP Workers can be busy streaming static files instead of
processing other requests. This can lead to a worker starvation, i.e.
all workers are busy streaming files and cannot process new requests.
X-Sendfile
----------
In this work, we add the support for the [X-Sendfile] header family,
they are multiples http headers that can be used by the web application
to communicate with the web server in order to delegate the delivery of
files stored on the file system. Odoo still receives the request but it
does no more stream the file content from within its HTTP worker,
instead it skips the response body altogether and sets the `X-Sendfile`
special header with the path of the file on the filesystem. The web
server intercepts that special header, open the file and stream it.
Using those headers, we can use the best of both the web application and
the web server. The web application is still responsible to locate the
resource and verify the access rights, the web server is still
responsible of streaming the content.
Using X-Sendfile is opt-in via the `--x-sendfile` CLI flag. We set both
`X-Sendfile` (apache) and `X-Accel-Redirect` (nginx). If you are using
apache, make sure `mod_xsendfile` is enabled. If you are using NGINX
you have to add the following location block:
location /web/filestore { # custom path, hardcoded within Odoo
# Prevent access from the outside world, i.e. makes this
# route only accessible via X-Accel. MANDATORY!!!
internal;
# Give access to the filestore using this server's
# permissions. Odoo is in charge of verifying the access
# rights.
alias /path/to/odoo/data-dir/filestore;
}
The Odoo [deployment documentation] has been updated accordingly.
[X-Sendfile]: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
[deployment documentation]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachments
Changes to the API
------------------
To benefit most from X-Sendfile, all APIs related to streaming content
over HTTP has to be adapted. They are: (1) `request._serve_static`,
(2) `ir.http._serve_fallback`, (3) `/web/content` and (4) `/web/image`.
Each used it own way to deliver content: (1) `_serve_static` was using
`send_file` (flask's send_file that as been vendored with odoo 10
years ago and not maintenained since then), (2) _serve_fallback was
handcrafting a `werkzeug.wrappers.Response`, (3) /web/content-image were
using the "binary server" `ir.http.binary_content` API.
I has been decided to remove all 3 APIs and to merge the code inside of
the new `http.Stream` object and the `ir.binary` helper model.
A Stream wraps what is going to be sent to the browser, it can be a path
to a file on the locale filesystem, a blob of raw data or an URL to an
external resource. The Stream also holds various metadata that are
mainly used for caching. The preferred way to create a Stream is via one
of its three factories so that all the metadata are set. The factories
are: `from_path`, `from_attachment` and `from_binary_field`. A stream
instance exposes a single method `get_response()` used to create the
corresponding HTTP response object out of the stream.
Inside of `ir.http` were a few methods that were not related to the http
routing and formed what was called the "binary server". All those
methods have been removed and the feature have been refactored inside of
the new `ir.binary` model. The removed methods are:
- `_xmlid_to_obj`
- `_get_record_and_check`
- `_binary_ir_attachment_redirect_content`
- `_binary_record_content`
- `_binary_set_headers`
- `binary_content`
- `_response_by_status`
- `_get_content_common`
- `_content_image`
- `_content_image_get_response`
- `_placeholder_image_get_response`
The new `ir.binary` abstract model exposes the following utilities:
**`_find_record`**
Find an attachment or a record with a binary-field out of an xmlid or
out of a pair record-model/record-id. Check the access rights and the
access token.
**`_get_stream_from`**
Create a Stream from an attachment or a record with a binary-field.
**`_get_image_stream_from`**
Same as `_get_stream_from` but adapted for images. It sets a sensible
ETag on the stream and has image resizing support.
**`_placeholder`**
Get the image placeholder blob.
Testing
-------
It is possible to test the web server configuration using the
`test_http` module. Install the module then run the unittest using the
`webserver` test-tag. By default it attempts to connect to a web-server
running on `http://localhost:80`, you can change this URL by setting the
`WEB_SERVER_URL` environment variable.
odoo-bin -i test_http --stop-after-init
WEB_SERVER_URL='http://localhost:80' odoo-bin --test-tags webserver --stop-after-init
closesodoo/odoo#88134
Task: 2801675
Related: odoo/documentation#2083
Related: odoo/enterprise#26191
Signed-off-by: Julien Castiaux <juc@odoo.com>
Model pattern was too permissive, separator is the literal `.`
character, not any random thing.
Also remove unnecessary bracket expression, it's unnecessary when
matching a single item.
OPW-2836106
closesodoo/odoo#90107
X-original-commit: 320cdb4e85cb86915fa25cfda8f17e0a372e765e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Since [1] illustration shapes are only obtained from their slug. Before
they were obtained from their URL.
After this commit the old behavior is restored as a fallback in case the
illustration shape cannot be found from its slug.
This is needed to allow importing shapes into the system from data
files.
[1]: https://github.com/odoo/odoo/commit/bde8abcfeb57c74438943e44215a7c8cb822329f
task-2793073
closesodoo/odoo#86858
X-original-commit: 91f2a989ddd7961f92a377b1bf74cc741dcbd3d0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] non-image documents uploaded in web editor were stored as
received in base64 without being decoded.
This led to downloading them as they were stored in base64.
After this commit uploaded documents are base64-decoded before being
stored.
Steps to reproduce:
- edit a web page
- drop a "Text - Image" snippet
- replace the image
- upload a document (PDF, TXT...)
- save page
- download document
=> received document was base64-encoded
[1]: https://github.com/odoo/odoo/commit/6b8752604898bf2b583b7f5334e35f6a1583595e
task-2782269
closesodoo/odoo#86812
X-original-commit: b0218b8ff50c7cea2a018d20a62e63510bfdd01e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- 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>
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
export_icon_to_png sometimes failed because PIL's getbbox returned None.
This fixes it by not using a default color of (0, 0, 0, 0) when creating
the image but using the actual color of the image instead.
Also, the size of the image was wrong because of using the default size
when width and height are defined.
task-2761098
closesodoo/odoo#84638
X-original-commit: efcb432f4c459b2d2d819c3aed7d63d53fc93809
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
This commit "forks" fontAwesome into `src/libs` in order to allow
further customization.
Part of v16 overall restyle (task-2704984).
task-2745275
Part-of: odoo/odoo#83501
When fonts with a round border were converted to images, the dimensions
often ended up slightly off, and most visibly a little bit cropped by
the border.
Note that this also removes the "alpha" argument of the font_to_img
route since it wasn't used anywhere and transparency is not supported in
emails anyway.
Part-of: odoo/odoo#83233
Avoid to base64 encode, then decode to process assets and images for a ~25% speed improvement.
Change image processing tool to work on images, rather than base64 encoded strings.
Performance is ~25% faster on assets & images:
/web/assets/...frontend.min.css: 13ms to 7ms, base64 enc/dec: 2 -> 0
/web/image/XML_ID: 10ms to 8ms, base64 enc/dec: 3 -> 0
/web/image/res.users/2/avatar_128: 40ms to 20ms, base64 enc/dec: 6 -> 2
closesodoo/odoo#82851
Related: odoo/enterprise#23537
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
The random ids of checklists and stars are preserved in the dom, which
is needed for their readonly check features to work. However, it
complicates testing. This systematically removes these ids in tests.
It also removes the ids when they are not needed anymore (the node is
not a checklist anymore for instance).
closesodoo/odoo#83137
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Similar to checklists, this allows the user to click the powerbox stars
widget even in readonly mode, so as to change a rating without going in
edit mode.
task-2575449
Part-of: odoo/odoo#81920
When a checklist is present in an html field, there is a feature that
allows us to check/uncheck its boxes without going through edit mode.
That feature was broken due to a dead callback in wysiwyg.js, which is
hereby restored.
Meanwhile, the behaviour of checklists had changed but the python code
handling the readonly checking/unchecking hadn't so this brings it up to
date[1].
Finally, the code managing checklist ids was unnecessarily complicated
as it was trying to keep the ids consecutive for no particular reason.
This refactors it to simply use unique ids based on date stamps.
[1] It used to be that checking a box checked all the children of that
box but it was in the meantime decided not to do that anymore.
Part-of: odoo/odoo#81920
The http.addons_manifest is a map {module: manifest_dict} that is
populated upon the first http request. This map is basically a module
manifest cache with an extra `addons_path` key, the path of the module
on the file-system. This cache is eagerly populated upon the first http
request, the map is empty in non-http contextes (e.g. cron) which have
been a source of bugs (e.g. 50c8eb1).
A manifest cache is necessary because reading and parsing python files
from the file-system is not that cheap but there is no reason that cache
is located in `odoo.http`. A thin cache layer now wraps
`load_information_from_description_file()`/`load_manifest()` and is
lazily populated.
The `http.addons_manifest` have been removed. The extra `addons_path`
key is now present in the "normal" manifest. The `read_manifest()` was
hardly used so it has been deprecated. The only way to retrieve a
manifest is now `load_information_from_description_file()` which was
renamed `load_manifest()` (no cache) and `get_manifest()` (cache).
Side note about performances, the cache is necessary. Addons manifest
are read-only and reading + parsing python files from the file system is
not a cheap operation. Running the e-commerce tour
`@website_sale.test_04_admin_website_sale_tour` without cache on
`load_manifest()` requires 68,29 secs to complete on my laptop,
exceeding the default 1-minute time frame allowed in tests. Using a
cache the time is down to 36,53 secs. The performance impact is huge.
Part-of: odoo/odoo#79977
*: web_editor, website_sale
This commit adds the abibility to get an image thumbnail based on the
video provider URL and to avoid duplicating the regexes. It also
improves those URL regexes.
All the regexes are kept in a python tools file and are called in JS
using an RPC.
task-2154812
closesodoo/odoo#44537
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: ras-odoo <ras@odoo.com>
Co-authored-by: bbh-odoo <bbh@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This brings a series of improvements to the mechanism in place to
convert the output html of mass mailing into html that is more compliant
with the main mail clients' requirements.
The biggest change is the automatic conversion of Bootstrap grids into
table structures. Currently all templates in `mass_mailing` are designed
with tables so they work in mailings as is. That has limitations though
as it makes it less easy to edit with snippets such as those used in the
website builder. This new automatic conversion from Bootstrap grid will
allow us to adapt the mailing and snippet templates and be more free
within `mass_mailing`.
Note: Because of the limited support of media queries in emails, this
doesn't support the mixing and matching of column options
(e.g., `"col-4 col-sm-6"` and `"col col-4"` aren't supported).
Other changes include:
- The conversion of Bootstrap cards to table structures
- The conversion of Bootstrap list-groups to table structures
- The conversion of snippets (.o_mail_snippet_general) and mailings
(.o_layout) into table structures
- The conversion of all rgb colors to hexadecimal
- The conversion of all "rem" sizes to "px"
- Various small corrections to the output styles
task-2554899
X-original-commit: e2e00939e09220051f6f4ecfb7bb3276105387bf
Part-of: odoo/odoo#77724
This commit allows to use the editor collaboratively for any html
field in peer to peer using webRTC.
task-2497931
closesodoo/odoo#75768
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Regarding previous commit, the option parameter can be removed
from _get_asset_content api, followed by a nice snowball effect.
Part-of: odoo/odoo#75248
Since 3765ac1f1f16, uploading an image not recognized as such by PIL would not
behaves as it should.
Step to reproduce:
- Enter edit mode, drag & drop a snippet with an image
- Double click on the image to open media dialog
- Upload a local image of type `.webp`
- 2 toaster are shown:
1. A progress bar toaster with a generic message "File could not be saved"
2. A generic warning toaster on top of the previous one with the correct
error message "[..] format is not supported. Try with: .gif [..]"
Instead, only the progress bar toaster should be shown, and the error message
should be displayed in it.
task-2607393
Closes#74122
X-original-commit: c143e7d27ce25c88854fc3c2980f399add848cb3
The goal of this commit is to add a "Python version" of the
shape-on-image feature using a controller.
Since the whole logic to apply shapes on image is JS-based, we need
to use this URL (just like for background shapes) when we want to add
a shape by default on images in themes. When the configurator replaces a
snippet image (which the theme defines to have a shape), the shape
option should still be applied on the new image.
On the JS side, loadImageInfo() is overridden in order to mark
images (with theme default shapes) with corresponding attachment
data (original-id, original-src, mimetype).
Here is an example of the minimum xpath required to add a shape on a
snippet image in a theme:
```
<template id="s_image_text" inherit_id="website.s_image_text">
<xpath expr="//img" position="attributes">
<attribute name="src">/web_editor/image_shape/website.s_image_text_default_image/web_editor/solid/blob_1_solid_rd.svg?c2=o-color-1</attribute>
<attribute name="data-shape">web_editor/solid/blob_1_solid_rd</attribute>
<attribute name="data-original-mimetype">image/jpeg</attribute>
<attribute name="data-file-name">s_image_text.svg</attribute>
<attribute name="data-shape-colors">;o-color-1;;;</attribute>
</xpath>
</template>
```
task-2593454
closesodoo/odoo#73938
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: tools
The ImageOptimizer option can now set shapes on images to use those
shapes as clip path and background. It uses a flexible path so that the
shape will always fit the image proportionally. We also added an html
file alongside a javascript file to semi-convert the shape from
illustrator into a usable shape for this usecase (the clip path must
have values between one and zero therefore we must do some computation
before the shape is ready to use).
Thanks to Samuel for this specific shape-converter tool and other
technical points about svgs and clip-paths.
Thanks to Mehdi for remaining development post-testing and post-reviews
and for the many fixes.
Thanks to Brieuc for the actual shape SVG files.
Part of https://github.com/odoo/odoo/pull/69179
task-2327045
closesodoo/odoo#69179
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: xO-Tx <mou@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
We check if the mimetype is supported when uploading an image.
task-2523574
closesodoo/odoo#71839
X-original-commit: 3765ac1f1f1644c919456246f1a3791c47c45a83
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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
Since the image util method `image_base64()` is converting BMP images to PNG
automatically[1], there would be a mismatch between the attachment content type
and the attachment mimetype.
- Content type: retrieve with `base64_to_image(data).format` -> return PNG as
the image data was converted from BMP to PNG
- Mimetype: set on `write()` and `create()` with `_check_contents()` which
call `mimetypes.guess_type(file_name)`.
BMP image `my_file_image.bmp` would have a mimetype set to BMP
The computed field `image_src` would return `False` since the image.mimetype
would be BMP, making the dialog picker not showing the image but loading
`http://localhost:8069/false` instead.
[1] https://github.com/odoo/odoo/blame/097f29d0f6a5b295c81fd074665dbd261eaf12fb/odoo/tools/image.py#L124
task-2345082
Coming from #65828Closes#68326
X-original-commit: ef5b108b781df73342bb99342a1116fad86d3b58
Previously, when clicking on an illustration in the editor, the image
options would be unavailable with a message saying that it was due to
technical limitations, and that the user should reselect the image in
the media-dialog for quality options to become available. This was
caused by the fact that in order to support more than one customizable
color in illustrations, they are now saved inside the database with an
url containing which colors are customizable inside the url's query
parameters. Since the endpoint that finds which attachment corresponds
to which image src was looking for an exact URL match, but query params
are trimmed on the client side before talking to the endpoint, they were
no longer matching.
This commit fixes that by searching for attachments whose URL matches
the provided one with or without any extra query parameters.
closesodoo/odoo#67625
X-original-commit: b26319c3c9409e8724fadeec80e63ea94dc8d599
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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>
bve-odoo