*: website_mass_mailing (tests)
- Web Editor facts:
Since the refactoring of the editor done at [1], the cookies bar popup
is receiving a `contenteditable=true` attribute, making it receive the
chrome default `height` style for such elements.
The problem is that if this cookies bar's modal is hidden, the bar will
be shown as a thin empty white bar.
- Website Builder / Popup Snippet / Cookies bar facts:
A popup element is composed of a `.s_popup` parent containing the actual
`.modal` BS modal. Our internal logic and events are hiding and showing
this inner `.modal` modal element without considering its `.s_popup`
parent. It means that when the `.modal` is hidden, its `.s_popup` parent
is not touched and kept visible.
It might looks like it's not an issue as it would just be an empty
element (its only child is hidden) but it leads to some issues as
explained just above: an ugly white bar is shown.
Note that the cookies bar is nothing more than a `.s_popup` snippet.
- Web Editor facts 2:
During the mentioned refactoring [1], they actually added some code to
hide this bug once you were playing with the edit mode (mainly for when
you clicked on the invisible panel element or before saving).
But this code was actually not fixing the case when you just entered
edit mode.
This commit simply remove that "edit only" web editor logic and add a
new one in charge of simply synchronizing the `.s_popup` snippet
visibility with its `.modal` BS modal in a public widget (which is
obviously also executed in edit mode).
Finally:
- note that if there is no way through regular flow to arrive to the
same result with a normal popup snippet, it is still concerned by this
issue and you can reproduce it by moving it somewhere else in the DOM
and/or simply adding it the `contenteditable=true` attribute.
- we already fixed that issue a few months/years ago, I couldn't find
a commit related to that so I don't know if it was due to the same
root cause
- in case one is wondering why we simply couldn't do that in the already
existing `_onHideModal` of the `PopupWidget`, it is because that
`hide.bs.modal` is not called when entering edit mode, because the
`destroy` is destroying it before hiding the modal. The event is thus
not fired. And we can't move the hide part before the destroy's super
because otherwise, it would go through the normal hidden process which
is creating a "seen" cookie for the popup as if it was closed
manually.
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
task-2754108
closesodoo/odoo#105553
X-original-commit: 21a5e7000f08fbd1936173937c7d90b152a5414f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: test_website, website_blog, website_crm, website_event,
website_forum, website_hr_recruitment, website_mass_mailing,
website_sale, website_sale_wishlist, website_slides
- Make sure that all website tours reaching the website preview before
their first step use the related website util to register their tour.
- Rename the website util to register a tour starting on the website
preview from `registerEditionTour` to `registerWebsitePreviewTour`.
Having a method using "Edition" in its name and having a boolean
parameter named `edition` was a bit... strange.
- For both non edit mode and edit mode as a first step, ensure the util
sets a high timeout for the first step. Indeed loading both the
backend and the frontend (in the iframe) and potentially starting the
edit mode can take a long time in automatic tests. We'll try and
decrease the need for this high timeout of course.
- Review the implementation of those utils to be more consistent and
also fix one or two mistakes in them.
closesodoo/odoo#100024
Related: odoo/design-themes#588
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
PURPOSE
This commit adds a template selection to the newsletter block snippet to
allow one to switch between email, mobile (added with a new module) or
form template.
LINKS
Task-2672194
Part-of: odoo/odoo#79582
*: website, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Before this commit the "Thanks" button of the newsletter block could be
saved as visible. This meant that a visitor who did not subscribe to the
newsletter would see the "Thanks" button on loading before it
disappeared. This commit solves this problem by:
1. hiding the "Thanks" button before saving
2. having an option to show/hide the "Thanks" button in edit mode
3. hiding the "Thanks" button before switching to edit mode
Steps to reproduce the fixed bug:
- Drop a newsletter block.
- Save and register to the newsletter.
- Edit
- Change anything in the newsletter block.
- Save and Logout.
- Now the Thanks button appears and disappears when the page is loaded
opw-2802139
closesodoo/odoo#94002
X-original-commit: 57793ff912ac5aab8f3d3e014992965d06290bf0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website, test_website
Since [1], a race condition seems to have become more dominant. It is
actually due to a tour not properly awaiting the editor to be loaded
before using it.
This commit fixes all occurrences of such 'trigger' selectors, even in
tours were it could actually be not a problem. That will prevent devs to
copy paste the problematic trigger.
[1]: https://github.com/odoo/odoo/commit/57793ff912ac5aab8f3d3e014992965d06290bf0closesodoo/odoo#94000
X-original-commit: 38f3a94263b9cf48e9f5a8de553b8602310bcddd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_mass_mailing
Before this commit, some types of buttons were not managed by the
editor, only the primary, secondary and link buttons were supported.
However, if there is another type of btn in the DOM, the editor must be
able to handle it. This commit allows to manage all types of buttons in
the editor. This commit also adds a test so that the bug does not come
back.
Steps to reproduce the fixed bug:
- Drop a block with a <a> with the btn-success class
- Click on the button to edit it
- The link tool part in the editor does not work properly
or
- Drop the newsletter block
- Save and register to the newsletter
- Edit the new "Thanks" button
- The link tool part in the editor does not work properly
opw-2802139
closesodoo/odoo#92325
X-original-commit: 4c68b3e923610e1d573b4bd2b241b2fc5923c412
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_mass_mailing
Useful for debugging: launching the homepage/theme tours automatically
allow to build the pages if you cr.commit() after running the test. This
will also allow to make those official test tours if we ever want it at
some point.
Part of https://github.com/odoo/odoo/pull/68336
task-2491890
X-original-commit: 71f30a4dcc59d4c7f4b5a2ab4c8be44218edf4b0
