Before this commit, on Chrome browser, the page url input and the
visiblity password input were autocompleted with the user's login and
password in the page properties options.
After this commit, they are no longer.
Regarding the url input page, it seems to be because Chrome considers
that the first text input located before a password input in the DOM is
a login input.
task-2502747
closesodoo/odoo#84393
X-original-commit: 7f45822919f8ef5f070a40a4dd41d22757a9da76
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the framework's navbar uses the hamburger_menu in community too,
the `navbar_mobile.scss` code initially shared between frontend and
backend is now needed for the frontend only.
This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Prior to this commit the topbar responsiveness was exclusive to
enterprise.
This commit moves to community the mobile logic for navbar, burgermenu,
user_menu and company_switcher.
The design has been adapted to v16, reviewing font size/colors and
icons. This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
Before this commit the target of options and nested options tour steps
could be hidden under an opened palette.
After this commit the tips of options and nested options tour steps
require that no palette is opened.
An 'allowPalette' parameter can be used to remove this condition, for
example if 'changeOption' is used to select an option within the
palette during a test tour.
A step is added to close the color palette - which, while opened,
prevents the next `changeOption` step from being activated.
task-2728994 (was task-2675252)
closesodoo/odoo#84093
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With commit [1] (and the parent commit here which reviews it), we
move the scrollbar to the modal instead of the website content if the
modal has scrollable content even in the case there is no backdrop. An
exemple would be the cookie bar, configured in popup mode, with a tall
content inside.
This was however not enough: the computation which determines if the
modal should be scrollable or not was not re-done after an image was
loaded. So if the popup was around the height of the window, it could be
smaller than the window's height before images loading and taller after
which would result in having the scrollbar on the body instead of the
scrollable popup.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6closesodoo/odoo#84139
X-original-commit: b83b465dd98345afeca3844a4796e4a83d15f72b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Commit [1] was not coded defensively enough: after it, dialogs not using
a proper bootstrap structure triggered a traceback once they were opened
(this was discovered on odoo.com where such unconventional dialogs do
exist). Bad luck: there was actually a check to allow unconventional
dialogs but it was not done at the right location.
However, fixing this, it was found that more than this was not ok. There
is actually no need to consider the modal-content element at all. Just
using our `hasScrollableContent` method is enough and requires no extra
search in the DOM. This actually also properly computes if the modal
overflows or not while it was not the case before as it did not consider
the modal-dialog element's paddings.
Finally, the whole customized behavior of the modal scrollbar here was
only designed to affect our Odoo modals with the s_popup_no_backdrop
class (see original commit [2]). Indeed, only in that case we want to be
able to switch between body scrolling and modal scrolling while the
modal is opened. In custom cases and other Odoo cases, we want the
standard Boostrap behavior of only being able to interact with the modal
while opened. This commit cleans the code to restore that spirit
(hopefully this does not cause stability issues as [1] was introduced
only a week ago). Sorry for any inconvenience.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6
[2]: https://github.com/odoo/odoo/commit/e5a5f98819b3a70b3e2564fb91722cab415ceea9
X-original-commit: a2363337355ccf4363249657000cd85bfcb3ab4e
Part-of: odoo/odoo#84139
Since [1] when web was migrated to OWL, the cookies bar was considered
as a parent modal of any openend modal that got closed - thus preventing
scrolling the full page.
After this commit the cookies bar in the front end is not considered as
a remaining modal anymore, and therefore does not prevent scrolling on
the currently displayed website page.
[1]: https://github.com/odoo/odoo/commit/29731b404fe624b733d784cd4321113d6b0d27b7
task-2741894
closesodoo/odoo#84128
X-original-commit: c1aab97e6b4e8b916c7d79db5f278c746fd6b119
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Step to reproduce:
- Create a website form with its action set to 'create a task'
- Set a project for the task to be created in
- Submit the form while logged in as a portal user
Current Behaviour:
- Task is created but the data from fields is not take into account
This lead to the task not being linked to the project and ending as 'Private'
- Due to the changes of sudo in V15, authorized fields are not fetched
and thus cannot be set properly.
Behaviour after PR:
- The data is fetch via the SUPERUSER instead of sudo to ensure correct data
- The fields are correctly set and the task is created
in the corresponding project.
opw-2743065
closesodoo/odoo#84020
X-original-commit: de03ee2198e039e14d0852d2346cb8aaf3885b5b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Before this commit the phone fields inside forms did start in a blank
state.
After this commit the empty phone fields are pre-filled with "+" and the
country phone code.
The country is determined based on the IP address with the GeoIP
database. The phone code is obtained from `res.country` where it is
kept in cache.
task-2463563
closesodoo/odoo#78068
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
When selecting the text content of a link
the underline and italic commands were not working in Firefox.
We re-implement the Browser command to fix this.
task-2667950
X-original-commit: 52a5b2bb692ab6712d497492f4f2fbef3a9a7874
Part-of: odoo/odoo#83895
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
It was only used one time on a unused field.
We don't want to keep useless fields anymore,
the migration is done for that.
task-2735546
odoo/upgrade#3194closesodoo/odoo#82727
Signed-off-by: Raphael Collet <rco@odoo.com>
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When a user clicks on 'could be used in' in the page properties after
chaing the URL, a list is displayed in a popup. This popup was
not properly rendered:
- the content could not be scrolled through, it was thus truncated
- the popup appeared behind the technical modal that kicks in on small
screens
Now the popup is better positioned, a scrollbar is available to access
its content when it is too long and on small screens it is displayed on
top of the technical modal, making it visible on small screens.
task-2092269
closesodoo/odoo#83693
X-original-commit: e2f1f4967a2dd4d730895e924f0c7ca02e23a17b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Jitendra Prajapati <jpr@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
*: web_editor
Steps to reproduce:
- Activate the cookie dialog from the website settings
- Remove the backdrop from the cookie dialog
- Add some blocks to the cookie dialog in the website editor
until the dialog height is bigger than the page height.
Result:
The cookie dialog is not scrollable, so it's impossible to reach
the "I agree" button and close the dialog, leaving the user stuck
at the first page.
I check if the popup content is higher than the window. If it is, I
give priority to the popup scroll over the page one. I had to
overwrite the _showElement method to call _setScrollbar after
the content rendering, in this way I can get its correct height.
I also try to update the scrollbar each time a block in the cookie bar
has been changed and each time the window resize. This is optimize, so
if the overflow isn't changed from the last time I tried to update the
scrollbar no action will be taken. In this way you can always see the
whole popup without refreshing the page.
Also I have to set 'pointer-events' to none only if the popup is
smaller than the page itself (to interact with and scroll the
page behind), otherwise the popup won't be scrollable. I did
this by adding a class "s_popup_overflow_page" if the popup is
higher than the page and I adapted the pointer-events
property accordingly.
opw-2660786
closesodoo/odoo#83691
X-original-commit: 022a4486a99d855a3c6e2cef326bb3b0c5e66db9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the step about the slider to adjust the padding was
only consumed on click, which does not happen if the slider is used in a
drag'n'drop operation as expected.
After this commit this step is consumed on mousedown so that the
drag'n'drop operation is also taken into account.
task-2728994 (was task-2675252)
closesodoo/odoo#83692
X-original-commit: 42ce224fbe97f8d99ca5feec6d271412ce0647e1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
website{_*}: website, website_blog, website_sale, website_slides
Before this commit if several steps were referencing the same trigger
(e.g. "+New" button in website) only one was displayed, but all were
consumed when it was clicked.
Because of this the tour steps on "+New" were active even when its menu
was opened.
After this commit only the displayed step gets consumed if the step is
marked as 'consumeVisibleOnly: true'.
It cannot be done implictly on all steps because of [1].
This new marker is set on all steps referencing "+New".
The tour steps on "+New" now also require their menu to not be opened.
[1]: https://github.com/odoo/odoo/commit/5e888f8a6ccf9996b3231db6bf314d045619109e
task-2728994 (was task-2675252)
X-original-commit: 0fa40e37e596798665a098ee999f49749b6012a2
Part-of: odoo/odoo#83692
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Issue
-----
Via the field prefetch mechanism, when we need a value of one field
(not in cache of course), the ORM will prefetch all fields
(which has the attribute to `prefetch=True`, the default value of this
attribute is `True`) for all record ids in `_prefetch_ids`.
Then, for each translate fields (where translate is not a callable)
the ORM need to make a `LEFT JOIN` on the `ir_translation` to fetch the
translated value. For big model, it leads to a simple `SELECT` with
several `LEFT JOIN` on ir_translation but each LEFT JOIN have a cost
in the planner time (a small cost in the execution time) of PostgreSQL.
By example, for `product.template` (stock/sale/purchase installed),
there are 6 LEFT JOIN to get all translated fields (5 of this
fields are rarely used).
Proposed solution
-----------------
Deactivate the prefetch by default for all translate fields expect if
this field is the `_rec_name` of the model (which is more likely to
be used).
In the example on the `product.template`:
Without prefetching the translated fields, there is only one LEFT JOIN
(the name, which is translated but is the `_rec_name` of the model).
With the 6 translated fields to fetch, the
query takes 5 ms to plan and 2 ms to execute VS with 1 translate field,
it 1 ms to plan and 1.5 ms to execute.
Side change note
----------------
- All translate of fields of `website.seo.metadata` should be prefetch
to avoid lot of website errors (it is because, website put in cache data
in sudo before reading it without sudo)
- `description` (`mail.message.subtype`), `subject` (`mail.template`),
`body_html` (`mail.template`) should be prefetch to avoid lot of extra
query from mail module.
- `vat_label` (`res.country`) should be prefetch to avoid a extra query
for each website page.
- Increase some queryCount (when it is legit, due to `subtitle` of
`blog_post` or `description` of `event.type.ticket`, etc)
task-2738029
closesodoo/odoo#82896
Signed-off-by: Raphael Collet <rco@odoo.com>
Since [1] when web's owl services were made available to the frontend,
the navigation mixin does conflict with the hotkey service.
E.g.: navigation mixin consumes the 'alt' keyup event, which prevents
the hotkey service from cleaning up the hotkey overlay.
After this commit the old mixin is neutralized and hotkeys in website's
pseudo-backend layer are handled by the general hotkey service.
Also since [2] the menu items are inside `<div>` instead of `<li>`,
adapted the scss to take this into account.
Also added a CSS rule to neutralize the outline on website's menu
dropdowns which are `<a>` instead of the already handled `<button>` in
web.
[1]: https://github.com/odoo/odoo/commit/db7b485d984e50fae5a52308634166460e5fc908
[2]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-2738578
closesodoo/odoo#83529
X-original-commit: 88438fa9b363530aa4e5dec5599c1568fb7ccea0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when we selected a variant of a product and then
clicked on a share button, the changed variants attributes in the shared
URL were not considered.
This commit also takes the opportunity to convert the whole file to new
Odoo modules and stopped using jQuery. The code actually had to be
refreshed following the merge of [1] so it was a good occasion to do it.
[1]: https://github.com/odoo/odoo/commit/8f7c6997e8ab381563a9fa8d06feef4e89fff4aa
task-2122733
closesodoo/odoo#83503
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Those steps were removed with [1] to avoid a indeterminist timeout, but by
doing so that part of the feature was not tested anymore.
Sadly, it was broken by [2] without being noticed for a long period of time.
The error was discovered by fixing multiple lang issues in the website
configurator in master.
Note that by creating a new lang instead of using an existing one will avoid
the timout error that lead to the removal of those steps with [1]. Indeed, as
no .po files will be found for that lang, it won't spend time on processing
those files.
[1]: https://github.com/odoo/odoo/commit/a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
[2]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2aclosesodoo/odoo#83420
X-original-commit: 0b43f52116fd9a58fb0a123db576d822fd541043
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the redirection supposed to happen after a lang install from the
frontend was broken.
Indeed, the 'url_return' was moved and used before it is actually set.
[1]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2a
Cheers to @jke-be which did the same fix in another branch in parallel.
X-original-commit: 74a594bb2e68662b22477fcce24d9620b2dd0b2a
Part-of: odoo/odoo#83420
In order to anticipate an anomaly in the network to prevent
a save, wait for an rpc to finish.
task-2742008
closesodoo/odoo#83103
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, a traceback occured when trying to remove a popup
snippet, only if content inside was clicked on before (base case but
that last part was not covered by our main test which drags and drops +
removes all snippets).
The problem is complex and annoying to solve in stable. The cause is the
combination of [1] and [2]. Indeed, with [2] we solved the snippet
activation flow to ensure the onFocus and onBlur methods are called when
needed... but that new correct implementation relies on the fact that
the number of snippet editor instances does not change for the whole
async operation of activating a snippet. That should naturally be the
case but is not because of [1]: when we remove a snippet we first
trigger a snippet activation then destroy the snippet (and its editor
instance)... but the snippet activation is not awaited at the moment.
Thus making the snippet editor instance be destroyed *during* the
snippet activation flow. Of course a better solution than this commit
must be found but this fixes the traceback with a very minimal change
for the 15.0 stable version while waiting for that miraculous solution.
[1]: https://github.com/odoo/odoo/commit/ae219ec06baf0280c76ae09b1453cc1481eece30
[2]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2735663
closesodoo/odoo#83378
X-original-commit: da7c1b5757a7780897c5736ddecc014a7fb50bdb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When Jabberwock was introduced in [1], forms were not selected anymore
by clicking on the form fields.
That behavior got fixed when Jabberwock was removed in [2] but this
commit introducing a test about it was not attached to a task - and did
not get merged at the time.
Before this commit there was no test to verify if the form became
selected when clicking on one of its input field or textarea.
After this commit there is a test that makes sure that the form is
selected when the user clicks on either an input field or a textarea.
Also added the renaming of a field label followed by a blur to ensure
it triggers all UI events.
[1] https://github.com/odoo/odoo/commit/347f4413d1b1a2b1a6a9ecd6d9c20cf7f3ec5ff3
[2] https://github.com/odoo/odoo/commit/e5572c317a7775a58675ed73efc89b5c9f6c0c39
task-2729643
closesodoo/odoo#83379
X-original-commit: fe4000cd521b5e1426b9093f7671fa457ef45eb8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, since [1], when the cookies bar is opened, the pages'
animations would not work at all.
Animated images would not even be shown, remaining invisible.
This is because the s_popup when not using the layout 'popup' is still using
the modal/popup snippet structure but is not really a modal anymore.
As BS provide a built-in way to know if there is an open modal, which works
well with the cookies bar, use it instead.
[1]: https://github.com/odoo/design-themes/commit/e025296ccf5b8d8ea19bd354d9fbd52a12fc4d94
opw-2712755 (detected during migration)
closesodoo/odoo#83291
X-original-commit: 48bb9efee99d3bee2b4b60eec0f59ed2cb13a096
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
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>
This commit introduces a new social_media snippet that allows social
networks to be displayed. This snippet shares the same options as the
share snippet, but also provides a list to edit the URLs of the social
networks in the company data (social_facebook, ...). This list also
allows to manage links to custom social networks (which are not stored
in the DB).
Headers and footers now use this new social_media snippet instead of the
share snippet and in the settings, the urls to the DB social networks
are editable/visible only in developer mode.
task-2687447
closesodoo/odoo#80217
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Guillaume (gdi) <gdi@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
This commits introduces new behaviors on the we-list:
1. Possibility to add a placeholder on inputs
2. Possibility to make elements non deletable
3. Possibility to make element activated/toggled by default
4. Possibility to generate ID for new elements
task-2687447
Part-of: odoo/odoo#80217
Before https://github.com/odoo/odoo/commit/254d40ffcc21f56a80a1814da7f6355d44e5670b it was possible that when a user cropped an image
using the crop tool, a copy of the original image was created that
had both original_id and theme_template_id carried over, therefore
find could be multi-record. We strengthen that search by adding
original_id=False, which ensures we always fetch the record of the
original image and not also its copies. In addition, databases that
happen to have this issue of corrupted data will be fixed
during an upgrade with https://github.com/odoo/upgrade/pull/3110.
closesodoo/odoo#82725
X-original-commit: e4bb0cd4466404e2fba62ae2d3bbaebd831fbcb2
Signed-off-by: Christophe Simonis <chs@odoo.com>
website{_*}: website, website_blog, website_event, website_forum,
website_sale, website_slides
Since the generic search bar was introduced in [1] all text fields were
truncated in search results.
This caused problems for long URLs which were truncated as well, and
therefore could become invalid.
After this commit URL fields specify `'truncate': False` in their search
detail metadata, which informs the rendering to skip the text truncation
step for that field.
Also added previously missing controller-level tests of the
autocompletion.
Steps to reproduce:
- start odoo with website_forum and demo data
- go to the Help forum
- search for "configure" in the Help forum
- click on the auto-complete suggestion
- => redirected to a 404 page because the URL was shortened
To test the fix on other models, use a long enough name that causes the
problem. E.g.: "This product has such a long name its URL would have
been truncated without the fix contained in this branch".
Note that the problem did not occur on blogs because the URL does not
contain the name, but the same fix was applied for consistency.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2727788
closesodoo/odoo#82621
X-original-commit: 045f741be35e62f5e3a636490c6c1d475b5d78eb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Use theme_default instead of theme_common.
Instead, theme_common is not available when only website is installed as it
depends of the design-themes repository.
closesodoo/odoo#82587
X-original-commit: a10522c6509caf7f09f21e6da3224d5865f0ba6a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The record is read directly in sudo, the prefetch is in the sudo
environment. When reading the other information there is no longer any
need to make a request.
closesodoo/odoo#82475
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This restores a (basic) feature that was lost in 15.0 by mistake.
Allow the user to set a link on an image. The user can access this link
tool in the editor panel or via the CTRL+K shortcut. This tool is very
similar to the existing link tool for texts. This tool uses the
suggestion system already existing on the text link tool.
task-2666467
closesodoo/odoo#82512
X-original-commit: bfcd25c5d66765b7436114dba3316ac7331a4d97
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
First step to stream QWeb templates: removing the two post
processing operations applied on rendered templates. This
should slightly speed up the rendering of every page.
1/ Don't remove empty lines after rendering, but fix the root
cause of: view inheritancies and QWeb compilation that don't
add extra empty lines.
2/ handle page break in the two reports that uses it, rather
than processing every view produced.
closesodoo/odoo#82244
Related: odoo/enterprise#23328
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Header of XML files should not be translated.
Before this commit, some users may translate the XML header and get
invalid XML if translating words like "encoding"
Fixesodoo/odoo#82155closesodoo/odoo#82439
X-original-commit: aaac6fc04f4e5aa4c9ad68d9e844f3e786044800
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A mega-tour was introduced with [1] to test every single snippet.
This tour, despite being very useful as it tests the core behavior of the
website builder, is creating a lot of race conditions.
This commit should prevent one of those race condition:
When the step was removing the snippet, it was then clicking on the "Blocks"
tab to get ready to drag and drop the next snippet.
The issue was that in some cases, it would click on the "Blocks" tab before the
snippet removal process was fully done.
Basically, when the race condition happened, it was the same as doing:
```
$('we-button.oe_snippet_remove:first').click();
$('.o_we_add_snippet_btn').click();
```
which, when done in the browser console, will result in the same visual than
the screenshots on the failing runbot builds.
[1]: https://github.com/odoo/odoo/commit/460d5ecb926c13a79ba363f8f86442433d91bf6f
task-2726529
closesodoo/odoo#82214
X-original-commit: 49c7bd39826b428430c08c5faedca51dde9e2359
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A mega-tour was introduced with [1] to test every single snippet.
This tour, despite being very useful as it tests the core behavior of the
website builder, is creating a lot of race conditions.
This commit won't fix anything but will actually reduce the tour length,
hopefully also reducing the amount of race condition while those are fixed.
Indeed, some snippets were tested multiple times, as a snippet might include
another snippet in its DOM, the xpath query would return multiple times the
same snippet.
Duplicates: s_card (5), s_banner (2), s_donation_button (2),
s_dynamic_snippet_products (2), s_newsletter_subscribe_form (3),
s_searchbar_input (2), s_text_block (3), s_hr (2).
[1]: https://github.com/odoo/odoo/commit/460d5ecb926c13a79ba363f8f86442433d91bf6f
task-2726529
X-original-commit: 6f6ace0f0b09f6ad8b497f89e331e43a18e00471
Part-of: odoo/odoo#82214
Steps to reproduce:
- Install `website_hr_recruiment` module
- Go to `your_website.com/jobs`
- Activate Edit mode and add a "3 Columns" block
- Select one of the columns and set the shadow to `None`
Issue:
Shadow is not removed, and by default the "outset" mode is selected.
Cause:
When we check the state of the shadow with `css('box-shadow')`, it
will always be set because a custom css 'box-shadow' is set by the
module website_hr_recruitment on card element, and therefore the value
will always be either 'inset' or 'outset'.
Solution:
If widget value is set to '', replace `box-shadow` style to 'none'
(only if needed) so it will override the style from css file.
opw-2701512
X-original-commit: 212d8ec10bb48e8fd7de3d3ff7660447b968c62a
Part-of: odoo/odoo#81980
Co-authored-by: qsm-odoo <qsm@odoo.com>
Benjamin Vray