Somehow the already translated term `Save` in french was translated
again from `Sauvegarder` to `Sauver`.
We already faced that issue when forward porting the tour as that
translation was not the same between versions, see [1].
The tour should be adapted to create a new fake language and some
translations for it (the ones being checked in the tour) to make it more
robust and not impacted by the real translation from transifex.
It would also makes the test faster as it wouldn't have to load a real
language which has a lot of translations.
As this is blocking and preventing any r+ in saas-15.3 a day before the
saas-15.4 freeze/release, this quick fix is introduced in the meantime.
[1]: https://github.com/odoo/odoo/pull/84528#issuecomment-1041323974closesodoo/odoo#92938
X-original-commit: 594ac2c9651f27cc1623fcd5b916cb191241651b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
The `t-cache` directive allows you to keep the rendered result
of a template part. The supplied key must be a tuple. This tuple
can contain recordset in this case the zone will be invalidated
each time the write_date of these records changes.
The `t-nocache` directive makes it possible to force rendering
of a part even if it is in a `t-cache`. The values available in
the `t-nocache` are the one provided when calling the template
(and therefore ignores any t-set that could have been done).
Part-of: odoo/odoo#88276
Could not actually reproduce problem locally.
Looking at the logs, the randomly failing tests seem to be related to
the effects of some previous steps not having been applied even though
the test did proceed further.
This commit introduces intermediary checks to make sure that the effect
of each step is fully applied before proceeding to the next one.
runbot-3171
runbot-3172
runbot-3629
runbot-3630
runbot-3778
runbot-3779
runbot-3859
runbot-3860
closesodoo/odoo#92816
X-original-commit: 2d47b78e677f5046214cb2c8613eeb510753076d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
Before this commit, after the user installed the website_payment module,
the donation blocks were not well placed in the editor (after the
uninstalled modules). This commit solves the problem and permits to
place the installed snippets correctly in the editor.
Steps to reproduce the fixed issue:
- Install website
- Enter edit mode
- Click on "Install" for the "Donation Button" snippet
=>After install, the snippet still appears after uninstalled modules.
task-2767716
closesodoo/odoo#92413
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the carousels of dynamic snippets were only
initiliazed once the controls were interacted with, making the "speed"
option useless. Now, they are initialized just like any other carousels
via the related public widget. That public widget actually does more,
like ensuring all carousel slides have the same height. That last part
was actually fixed for the 15.0 version but by duplicating the public
widget code at [1], that duplicated code is removed here too.
Note: the carousels do not start on page load but still need to be
hovered first just like normal carousels.
[1]: https://github.com/odoo/odoo/commit/c2e3fdccd84a9077b50d2fcf0dd147026cbc613a
opw-2767903
closesodoo/odoo#92148
X-original-commit: aa8a45001eb60ed5816271b6a3b008e4df19c016
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] synonyms entered on IAP had to be lower-case to be matched by
the industry auto-complete.
After this commit the client-side of the configurator makes sure labels
and synonyms are matched without case sensitivity.
Steps to reproduce:
- Add an upper-case synonym on IAP
- Create a new website
- Search for added synonym
=> Industry associated with synonym did not show up.
[1]: https://github.com/odoo/odoo/commit/5d5d5d75d52a2a9e0d12bdb6442e006327ba9b0c
task-2835608
closesodoo/odoo#92419
X-original-commit: 1385a20c7ce22d2a68fa5d76ca8e34e4c679d402
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This Goal will help end user to find most 404 hits and fix the
legits one...
Fixing typo, creating missing redirect, or fixing code.
We need to cast the event-name since plausible only accept 'string'
as custom event name, so if we push 404 instead of '404' the event
crash.
closesodoo/odoo#92243
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Original 14.0 commit title:
Prevent deadlock on editor save when an option is focused
See [1].
In 15.0, the code worsened... but, by chance, fixed the deadlock bug.
See adapted version via the X-original-commit.
With this master version of the original commit, it is tried to clean
the code a bit... at least around the code that was originally touched,
without starting a big refactoring that is again needed. The deprecated
(and added by mistake) 'edition_will_stopped' and 'edition_was_stopped'
events are now gone.
Hopefully, we will continue to improve that editor hierarchy (and
ultimately converting to OWL?) in future updates.
[1]: https://github.com/odoo/odoo/commit/53a08b3470d7d18488abf93b7ea6551700650460
Related to opw-2767903
closesodoo/odoo#92321
X-original-commit: 483a2d6cac1be3b40a4d1878536baea9e6098ec1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Exclude non installable theme from the configurator suggested themes.
Also, exclude themes which are found in the database (sql) but not in
the manifest (files/sources). This was reported after migration where
`theme_beauty_sale` was still in the database but did not exists
anymore.
Note that in prior versions, this was causing a `KeyError`.
closesodoo/odoo#92167
X-original-commit: 6e4faeb136e123e09d74cde06c47f7c822b1fd19
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The conversion of background images for mass_mailing doesn't support the
conversion of shapes on them (limitation of html2canvas), and emails
should not contain videos. This removes these options for mass_mailing.
Since the video option was added in place by `website`, this adds an
option in its template so it can be disabled. A similar option was added
for shapes, which depends on images being enabled as well.
task-2856858
closesodoo/odoo#91314
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the user selects across several blocks, the link tools are supposed
to be hidden. This was however broken due to other mechanisms restoring
it after it got hidden.
task-2856858
Part-of: odoo/odoo#91314
Before this commit, the `<iframe/>` element of the `s_map` snippet would
be removed from the field value if the field was sanitized.
The map would then not be displayed, obviously.
The way that `s_map` snippet work is simple:
1. The snippet is defined with a hidden `<iframe/>` element
2. The snippet options are stored as data attributes on the `<section/>`
element.
3. When those options are changed, the iframe `src` is updated and it is
shown if needed.
The fix is simple, as we already have all the data attributes available,
we just need to recreate that iframe when the snippet is started without
one. It most likely means it got deleted through the sanitization during
the save.
opw-2844010
closesodoo/odoo#91866
X-original-commit: c2e9bd0e60014b6a42931cf300e0f89f8cf7c225
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, animated elements did not animate in a tab that just
opened. Exact same problem was also happening with the accordion block.
Steps to reproduce the issue (with the tabs block) :
- Create a tabs block.
- Add some content with animation on each tab.
- Save.
- When you refresh, the first animation loads.
- Switch tab to another animation and wait - it won't load.
- Scroll up or down -> animation will show up.
opw-2813435
closesodoo/odoo#91850
X-original-commit: 2c21d5a7b493a3c88962ad9185391b6d6c7fc010
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prevent edition on e-commerce products header bar.
Since we cannot save any change done in the header object anyway,
And some edition would trigger error.
We put the all bar in a read-only mode.
task-2745151
X-original-commit: e2f7b8fad76dc816b2f6864340d3740446117cdb
Part-of: odoo/odoo#91840
There is 2 issues regarding the responsiveness of the cookiebar:
==== Problem n°1: ====
======================
By default, `.modal-dialog` receive a O.5rem margin.
```css
.modal-dialog {
margin: 0.5rem;
}
```
But it only takes effect in small resolution, as starting from SM (576px,
see _breakpoints.scss), the margin is set to 0. `.modal-dialog` receive:
```css
@media (min-width: 576px)
.modal-dialog {
margin: 0 auto;
}
```
On top of that, the `.modal-dialog` has a `min-height` of 100%, which is
getting too big in XS, as there is a 0.5rem margin, which adds up on top
of the 100%
```css
.s_popup[data-vcss='001'] .modal-dialog {
height: auto;
min-height: 100%;
}
```
It results in a modal height bigger than the screen size, ultimately
creating a scrollbar for just a few pixels (2 * 0.5rem margin), making
the cookies bar partly hidden by the screen.
==== Problem n°2: ====
======================
The buttons from the cookies bar "discrete" template are simple `<a/>`
elements inside a `div.col`.
Those links have no bottom margin like a paragraph would have.
In LG screen, it is fine as the col containing those links is next to
the other col containing the paragraph which adds the margin bottom,
making elements not stuck to the bottom edge of the screen:
------------------------------
| COL-LG | COL-LG |
| <p/> | <a/> <a/> |
| | <-- bottom margin set on <p/>
------- screen edge ----------
But in lower resolution, as both col would be on top of each other, the
`<a/>` would be stuck to the bottom screen border.
--------------
| COL-LG |
| <p/> |
| | <-- bottom margin set on <p/>
--------------
-----------------
| COL-LG |
| <a/> <a/> | <-- Against the screen bottom edge
-- screen edge --
======================
Steps to reproduce:
- Install Website
- Enable cookie bar in the Settings
- Go on the Website with a mobile screen width
opw-2784233
closesodoo/odoo#91712
X-original-commit: 843e57694dd73ed4b7fca0460a4cf9b166820843
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Co-authored-by: thcl-odoo <thcl@odoo.com>
This is an attempt at fixing a runbot "race" condition.
A first attempt was done in [1] but the selector introduced to make
sure the page was reloaded after the assets were changed was wrong.
This commit fixes that selector.
During the investigation of the problem, it was also discovered that the
SCSS change could take quite a long time on a busy server becasue it
triggers the SCSS compilation each time.
To reproduce that problem locally, run the `stress` command while
executing the `test_html_editor_scss` test.
E.g.:
```sh
$ stress --cpu 32 --timeout 120
```
The error that shows up in that case is misleading because it makes it
look like the confirmation popup was not clicked on.
What is actually happening is the following:
- the Reset button is clicked on
=> the confirmation popup is shown
- the confirmation is clicked
=> the popup is closed and the RPC call is made
- the RPC does not respond within the tour step's timeout
=> the last step is not shown as succesful and the screenshot shows the
non-reset state since the server response did not arrive yet
To be safe on busy servers this commit also increases the timeouts
related to steps that follow updates of SCSS files so that they can be
recompiled on time.
[1]: https://github.com/odoo/odoo/commit/b35f127c86c1d271a76dae7186a96190e8558c73
runbot-3744
closesodoo/odoo#91725
X-original-commit: e04c4f06086ff4287ef4acfc65d5b3d957396ae7
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit add the way to specify the Plausible shared key auth token and
the plausible domain on your website to have the Plausible Dashboard integrated
in your Website > Dashboard > Analytics menu.
Some custom event are already pre-configured as:
Push an event 'Shop' on confirmation on ecommerce (with amount bucket +/- 50)
Push an event 'Lead Generation' on:
'Thank you' page of contactus
Confirmation of subscription for an event
From this way, the end user can just add a goal 'Lead Generation'
or 'Shop' on Plausible to have the Goal values visible.
closesodoo/odoo#91058
Related: odoo/documentation#2007
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, when searching something via the searchbar snippet
when it is in a mega menu, the dropdown that appears could not overflow
the mega menu dropdown and thus was mostly hidden.
opw-2779432
closesodoo/odoo#91512
X-original-commit: 4805b31e160493715f3c0647b6e8f2d5f6d50c0b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Configuring the email_to field on the contact us page was not working
anymore. The email was always sent to the company email whatever the
user chooses in edit mode. This was due to [1] which gave the priority
to the data-for and prefill system over default values. While this makes
sense in general (e.g. if the URL on the contact us page contains
?name=John, then the form is prefill with "John" whatever the value that
is set as default), it does not make sense for the email_to field which
is always prefilled with the company email.
The data-for/prefill system priority probably has to be reviewed in the
future. Meanwhile, this commit will make the email_to field as an
exception for this system and only use the data-for value if nothing
has been configured by the user.
This commit also handles another case. Indeed "if nothing has been
configured by the users" is currently kinda broken as just clicking on
the form and saving will force the value "info@yourcompany.example.com"
as the email_to value... thus making the form use it instead of the
company email. We will make that as an exception of the exception: use
the data-for value (company email) if what was configured by the user is
the dummy default value "info@yourcompany.example.com".
A test for each of those two exceptions has been added (only the first
test breaks before this commit as [1] made the second test pass by
chance).
[1]: https://github.com/odoo/odoo/commit/7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
opw-2842211
Original idea for the first exception:
closesodoo/odoo#91407
X-original-commit: a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Ivan Yelizariev <iel@odoo.com>
Currently, "Editor and Designer" can't edit the views which originate
from a theme (which are copies from the theme `theme.ir.ui.view`
records).
This error is caused by [1], which is preventing the `arch_updated`
field to be set to `True`, as this field is supposed to be set to `True`
only on manual user change, not during module update.
Indeed, restricted users don't have access to the themes records, making
the overide raising an error.
But there were actually no reason for this code to be executed outside
module operation.
Steps to reproduce:
- Create any view in a theme module.
For example: create a custom footer view.
- As a "Editor and Designer" user, edit this view through the website
builder.
- An access right error is raised.
[1]: https://github.com/odoo/odoo/commit/1eb7c577ecb31c2f0876b6dd76769e2b47802cb0closesodoo/odoo#91255
X-original-commit: d2be8dc99eb99321be1172af447d5f2536c17364
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- Show the Odoo version only in debug mode to logged in user, as we do
for the technical module name.
The purpose of this page is to generate some backlinks and improve
(does it really?) the SEO of Odoo.com.
The Odoo version doesn't bring any value and is another way to easily
retrieve DBs based on their version with a simple Google search.
While there is many other ways to do so, let's avoid this one.
- Prior to the introduction of `website.page` and the new page serve
mechanism, there could be template collision when an user would create
a page with the same key/name than the template of this controller.
This is not the case anymore.
We can remove the refresh meta tag.
See [1] and [2].
- The check to see if the template exists is useless, we don't do that
kind of check when rendering a controller, we just assume the view was
not manually deleted by the user.
I guess it was historically useful when people would not want that
/website/info page to be show. But now, there is a clean way to "hide"
this page by simply disabling it in the "Customize" option of the
website in the navbar.
[1]: https://github.com/odoo/odoo/commit/4cfd86edaa27d09f1066dd017bf466b8b30611e5
[2]: https://github.com/odoo/odoo/commit/7f6c669530ed7f9935de6516fadb7283ac00a9e4closesodoo/odoo#91131
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the l10n modules are displayed together at the bottom of the
page and redirect to the Odoo.com accounting page, regardless of the
localization author.
Now, if the localization was done by a third party, we use that author
website as link.
Note that this is already the case for the regular modules, like the
`payment_mollie` app for instance.
[1]: https://github.com/odoo/odoo/commit/562a2ac270ef8aac3afde05625008cef64f62f89
Part-of: odoo/odoo#91131
When the homepage was set to a different page than /, the resulting page
was blank.
The problem is related to a change of the rerouting algorithm, before
the httpocalypse it was re-dispatching the request itself, now it is up
to the called to do so. Here it is what `serve_path` does.
closesodoo/odoo#91034
X-original-commit: b00fefec2a26eb36be8a13cb845ee4f12f87d4eb
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A reroute in an internal redirection, the URL on the current request is
changed. The actual changes occurs on the "WSGI environment", a
dictionnary that is populated with the request information by the WSGI
server (werkzeug in our case). Among all the properties there are
PATH_INFO, RAW_URI and REQUEST_URI.
* PATH_INFO is the standard value, it contains a RFC-3986 path.
`request.httprequest.path` is based on that value.
* RAW_URI and REQUEST_PATH are two custom values set by werkzeug to
mimic other popular wsgi servers (gunicorn, uwsgi, mod_wsgi), they
also only contain a RFC-3986 path.
When rerouting only PATH_INFO and RAW_URI are updated. REQUEST_URI is
left as-is in order to keep the original path somewhere. When building
the cannonical path, one must use the original path instead of the
rerouted one.
X-original-commit: 779486c4dff23b946b4b14e3dca164ecca4f85a8
Part-of: odoo/odoo#91034
It may happen than the routing map is cleared while rendering a qweb
view. For example, if an asset bundle is regenerated, the previous one
is unlinked, which causes a cache clearing.
Previously-generated EndPoint objects aren't found any more in the new
routing map, so `request.endpoint` cannot be used any more after a cache
clearing.
This commit adds hash and comparison magic methods on http.EndPoint so
that EndPoint objects created by a previous routing map generation can
still be used after a cache clearing.
Two tests were added: one to test the comparison and hash methods, and
the other to test them in a real-case rendering.
Commit 80a04f7ebed fixed this bug too, but introduced another issue
which caused many OPW, so it was quickly reverted by deb23450f18 along
with its performance improvement 33167b3928c. This commit replaces
80a04f7ebed with another way to fix the issue.
A third test has been added in order to avoid reintroducing this other
issue.
By the way, this commit also removes the EndPoint.arguments attribute,
as commit 17f1992698 removed all usages of this attribute in Odoo 9.0,
but left this initialization here.
OPW-2834546
OPW-2834549
OPW-2834625
X-original-commit: bdc45422f5c715782b147eecda2403386ba7eb4a
Part-of: odoo/odoo#91034
Before this commit, it was possible to click on the "Create page" button
before the JS was loaded, as that button is a simple link with a href.
But that link is supposed to be handled by the JS which transform the
GET href link to a fake form submit to send a POST request to the
`/website/add` controller.
If the user clicks before the JS had the chance to handle that click and
do the "transformation", the controller will reject the GET request and
a raw 405 error page will be shown.
Now, we wait for the JS to be fully loaded before allowing user to click
on this button.
The fix is made globally as it should be the case of every link related
to this behavior.
Note that the `/website/add` controller was changed from GET to POST
with commit [1]. It most likely forgot to adapt the button from the 404
page which was later done with [2] by using the `post_link` util class
introduced with [3] (for need of website_blog at the time).
[1]: https://github.com/odoo/odoo/commit/714f0aa07f25e8a88a778e8b21c79b48e9801231
[2]: https://github.com/odoo/odoo/commit/2c85c1cb6ee0f6000cd2db182d5b8cfd3d040876
[3]: https://github.com/odoo/odoo/commit/0f2cada32319b3910d6ace6d412cfa94a646c9c7
task-2847785
closesodoo/odoo#91151
X-original-commit: d4a8ec96900c0e0923901bc2672f18aa51b1a9fb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, some images were never appearing on Chrome,
especially when using the 90% zoom.
Steps to reproduce (on a 1920x1080 screen and using Chrome):
1. Edit the homepage
2. Add a "Cover" block and setup a 50% min-height on it
3. Add 2 "Columns" blocks below the "Cover" block
4. Set the width of the first "Columns" snippet's first image to the
recommended size (690px)
5. Save
6. As a public user, set the browser zoom to 90% and go to the page
(you may need to reload the page again so images are in cache)
=> The first image of the second "Columns" block never appears.
opw-2731507
closesodoo/odoo#91075
X-original-commit: e9ef21b6cd5ae58322fa9102f9f34f06835f0485
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There is some classes that are technical and should not create steps.
Otherwise it compromise the ability to undo/redo or compromise the
ability to detect the dirty elements properly.
This commit prevent thoses classes additions and removals to create
history steps.
task-2836351
closes odoo/odoo#91074
Forward-port-of: #90064
X-original-commit: 41d8a0f246a134e2b5292da4db11e67aa9cfb4ed
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the modifications of the form were not saved if the
user had only clicked on the submit button of the form. Only elements
with the class o_dirty are saved, but since this commit [1], the
observer that adds this class was disabled. The resolution of the bug is
just to remove the fact that the link tool disables the observer that
adds the o_dirty class. This commit also adds a test to make sure that
this bug does not happen again.
Here are the steps to see the bug:
- Go to /contactus page
- Click on edit
- Click on the Submit button
- Change a Form option (eg: Recipient Email, Labels Width, URL, ...)
- Save
Edit again the see that the changes are not saved
[1]: https://github.com/odoo/odoo/commit/c29fe9fa8fc8ff4a5e6f042607ef9b3070d1d339
task-2812722
Forward-port-of: #90064
X-original-commit: 3b45ef633adbeebee4819c30808680644b85c5fc
Part-of: odoo/odoo#91074
*: website
Issue: from 15.0 onwards all image options are available on "/shop".
Details:
On 14.0, images options were removed for unsupported images (we had
a message "Quality Options Unavailable" - see [1]) and images related
options on old editor toolbar were hidden too.
On 14.4 and after [2], images options from the toolbar (crop, width,...)
were moved to a separate 'ImageTools' option and as a consequence, they
don't respect the same visibility rules as 'ImageOptimize'. Other
options were added in XML and they have the same issue, they are visible
as long as the target is an 'img'.
This is a list of options that should be available for unsupported or
partly supported images:
[A] For "t-field" images (shape & quality options are available only if
the image is supported for processing):
- Shape
- Filter
- Width (image width)
- Quality
- Transform (crop)
[B] For external images or images unsupported for processing:
- Description
- Tooltip
- Transform (crop, transform)
- width (CSS width)
- Alignment
- Style
- Padding
- Animate
[C] For illustrations:
- Same as [B]
- Dynamic colors
The goal of this commit is to fix this visibility issue on the JS code
of image options.
[1]: https://github.com/odoo/odoo/commit/84417a174bc2bb76730cc89783d3426a3a3b07d9
[2]: https://github.com/odoo/odoo/commit/d934b81aaae8d68b5579d1489b1fbe8ea347b4ed
task-2724946
closesodoo/odoo#90224closesodoo/odoo#90832
X-original-commit: 8e6ca51ed3ebf121acfc7cb1ab992984d0764c90
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1], that feature was lost because a `_computeWidgetVisibility`
was duplicated inside of the same class. The feature is now restored,
indeed the option does not make sense as animations will always launch
on every dropdown openings no matter the configuration.
[1]: https://github.com/odoo/odoo/commit/187acb938f70a2130d25fa76079221339c742f1e
X-original-commit: bde55751608b1679bd6599238a4da6279b8f74fa
Part-of: odoo/odoo#90832
Co-authored-by: xO-Tx <mou@odoo.com>
Before this commit, the animations were never launched in a mega menu
with the navbar option "sub menus = on hover" enabled.
Indeed the animations are launched when the element to be animated
appears in the viewport according to the scroll. But in the case of a
mega menu we just want the animation to start when the mega menu is
opened. For that we don't need all the code that checks the scroll, etc.
The animation starts by itself when the element inside the mega menu is
made visible in CSS.
A first attempt to fix this was made by this commit [1], but this fix
was wrong. Indeed, as explained above, animations in a dropdown do not
need to be triggered on scroll. And moreover, it didn't work properly
because the animations were never reset when the dropdown was closed.
[1]: https://github.com/odoo/odoo/commit/7a96557b839a69a9d44aac4242af2d21bc7f0e38
opw-2764895
closesodoo/odoo#90826
X-original-commit: bae04041a528e1a1fe97387ca5b75943c1d0fe97
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Currently, if a page is loading and someone quickly clicks exactly on
the input checkbox within publish management button of website navbar,
the checkbox (input) is toggled but the string does not change.
This happens because the checkbox is toggled before the click event on
`js_publish_btn` is bound. Ideally, the checkbox should be toggled only
based on the state of the object (whenever it's changed after a
successful RPC call) so that the information we see is correct.
This commit fixes the issue by disabling the input checkbox so that
it is toggled only after the state is changed by RPC call and not
when user simply clicks on the input. Apart from that, now we toggle
`css_published` and `css_unpublished` based on the state of RPC so that
the button strings are always consistent with the checkbox.
task-2819345
closesodoo/odoo#90550
X-original-commit: 86225a7f00ae90463570221e87ace5212fb71dba
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This is an attempt at fixing a runbot race condition.
It was executed succesfully without any error on Multi build around
200 times on runbot.
Since [1] the reset button could be clicked before the HTML editor was
reloaded.
The `MutationObserver` in `tour_service.js` is debounced. Because of
this the states used to detect tour steps triggers might differ between
executions.
With the Reset button of the HTML editor not being hidden in the
rendered template, it might be detected before it gets hidden during
the `start` of `ace.js`.
This commit makes sure the the editor is both closed then reopened with
the Reset button visible before clicking on it, and also makes sure the
Reset button is not visible by default upon rendering.
[1]: https://github.com/odoo/odoo/commit/d20468c3463927a54c34688769a22b3949c5c465
runbot-3674
closesodoo/odoo#90453
X-original-commit: b35f127c86c1d271a76dae7186a96190e8558c73
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The isDirty method of the wysiwyg was not very accurate
and was most of the time returning true
even if no changes were done in the editor.
task-2692125
closesodoo/odoo#90200
X-original-commit: bab673488e185ddd7792aedecc3870663290fed3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, some editor options could break the autocompletion
of form fields. This commit ensures that auto-fillable fields remain
auto-fillable when using the editor. In addition, this commit improves a
test to ensure that this bug does not reappear.
Steps to reproduce the fixed issue:
- Go to the "contact us" page or drop a form in a page
- Edit an auto-fillable field of the form ("Your Name" for example)
- Change the label position of the field
- Save
-> The field is no longer auto-fillable.
task-2715201
closesodoo/odoo#90103
X-original-commit: 455e0cc58c7fa1e02ebaa19dd2f99d829ca6e302
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit allows to give priority to auto-fill values and to values
coming from a data-for when in addition to one of these values this same
field has a default value. The form's test are also improved so that it
checks for this desired behavior.
task-2715201
X-original-commit: 7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
Part-of: odoo/odoo#90103
Some form fields are dynamically filled. As the inputs that hold these
values do not always have a value property, their HTML value attribute
can be modified. Before this commit, the form option had to remove these
values before saving so that these values wouldn't become default values
(see [1]). Sadly this system is problematic and can remove default
values set by the user. This commit ensures that only values from
auto-fillable fields and from data-for fields will be removed and from
now, the suppression of these values is done at a more appropriate time
than what is done in [1]. Test is added with this commit to verify that
the default values are not erased on later form edit.
Step to reproduce the fixed issue:
- Create a form, add a (required hidden) field with a default value
- Save, then enter edit mode again
- Add a new field and save again
The default values of the form are gone. Enter edit mode again to see
the hidden input, you will see there is no value.
[1]: https://github.com/odoo/odoo/commit/b637a5e32f767b62736241042f88fa0cecf9f10b
task-2715201
X-original-commit: 043e1fdf923d2037dd8da128ab99388f0c92e544
Part-of: odoo/odoo#90103
Romain Derie