- adapt the html field and mass_mailing_widget to be owl components
- adapt the mass mailing view to be an owl view
task-2898432
closesodoo/odoo#94875
Related: odoo/enterprise#30915
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This was introduced alongside the introduction of the cookies bar in
odoo with [1].
It's not something we wanted but for some internal reason, we were not
allowed to introduce the cookies bar on the website without that warning
when enabling the settings (which also comes with Cancel button as
primary button..).
The compromise was accepted as having a cookies bar was something we
really needed.
It has now been accepted to get rid of it.
While some internal people still think we should educate people about
GDPR and cookies law, I doubt that this settings was the right place to
do it.
Indeed, it was more leading to bad UX as most people just clicked on
"activate anyway" without realizing they still had to save the settings
afterward.
[1]: https://github.com/odoo/odoo/commit/3028e9a8649ae5d9b23a1bdb989b903645ede5feclosesodoo/odoo#99917
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since the button must be rendered when its text changes, the variable
that holds its text must be stored in the component state. The button
already had the right text before a bit by chance because the new name
was computed before the component was rendered. Now we make sure that
the component will be rendered when the name is recomputed. The problem
is visible if we slow down the getUserModelName function and go to a
forum.post from a forum.forum.
task-2889929
closesodoo/odoo#99599
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, only a website.page could be used as a custom
homepage ('custom' meaning other than '/').
But it is a real use case and requirement for our users to be able to
select a controller as homepage.
For instance, an ecommerce would want its homepage to be the shop and
not a regular page from where you then have to navigate to the shop.
Right now, this can (almost) be achieved by doing some technical
advanced operations:
- Move the 'Shop' menu first in the menu navbar of the website
- Delete the specific '/' website.page for the website
- Delete the generic '/' website.page (no website_id)
That way, the system will redirect `/` to `/shop`, which is not ideal as
it should remain `/` in the URL.
That's because, until now, the homepage (`/` controller) serve order
was:
- Serve the website.page set as homepage (`website.homepage_id`),
happens when one did select another page as homepage through the page
properties dialog
- Serve the website.page having `/` as URL (default)
- Serve the first accessible menu if there no `/` page or other page set
as homepage, it acts as a last resort attempt to not serve a 404 and
to try serving relevant content (the first menu of a website is most
likely always better than a 404)
- Serve 404
This commit allows to introduce an URL as homepage, instead of only a
website.page. It can be done through the website settings in the
backend.
There is 2 main points to keep in mind about serving the homepage:
- make sure we don't serve a 404 as the website homepage. This is the
website entry point, serving a 404 is terrible. That's why we have
some fallback mechanism like serving the first menu.
- We need to serve / before fallbacking to the first menu, as a lot of
site just remove the 'Home' first menu since it is a duplicate of the
logo, which also redirect to the homepage. In such cases, it doesn't
mean that the user want his first menu to be the homepage. We
shouldn't rely on such a behavior, it should just be used as a last
resort.
With this commit, the homepage serve order is now:
- If homepage URL is set (empty by default), serve the website.page
matching it
- If homepage URL is set (empty by default), serve the controller
matching it
- If homepage URL is not set, serve the `/` website.page
- Serve the first accessible menu as last resort. It should be relevant
content, at least better than a 404
- Serve 404
Most DBs will just have a website.page with '/' as URL and keep the
homepage_url setting empty.
task-2969683
closesodoo/odoo#99100
Related: odoo/upgrade#3876
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit changes the indentation of the redirect_field template to be
more in line with the rest of the template in the website module.
closesodoo/odoo#99150
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit will adapt ThemePreview views to OWL.
Those views use custom components to achieve the desired layout and
functionality.
Part-of: odoo/odoo#99150
Co-authored-by: Younn Olivier <yol@odoo.com>
It is not common, but we sometimes need to modify translation components
in place. The goal is to have a mechanism to change translation
components and all future/present instances
closesodoo/odoo#99719
X-original-commit: 87f98e6bb82cb2319d7f923b838085befd823f72
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website_event, website_sale
The "Site" menu will now be organized in 3 sub-areas, the last two being
named "Content" and "This page". The first area contains a link to the
website iframe and the menu editor. The "Content" area will contain
menus to list all contents of the website (page, products, events, ...).
This commit only moves the "page" one, the others will be created by
other commits of this PR. The "This page" area contains elements
specific to the page (html editor, page properties, ...).
task-2889981
Part-of: odoo/odoo#98937
After [1], the frontend website page manager was replaced by a custom
'website.page' list view and, with following commits on this PR, this
view will be used with other website content models records (blog,
event, forum, ...) too.
The goal of this commit is to adapt the pages list code to the new Owl
view system.
Other changes (related to the view's behavior) were added in this
commit:
- "Page list action buttons" are removed, we keep only the action that
triggers the form view of 'page.view_id' in debug mode. Page properties
and SEO dialog can be accessed via the website iframe after clicking on
the page entry in the list. The clone button should be later restored as
part of the main website backend menu, still when viewing the iframe.
Meanwhile, it is accessible in page properties. The 'delete' button is
still accessible via page properties too but the standard "delete"
button when selecting records in the list view will later be improved to
act the same way.
- The "website switcher" on top of the list view (to filter records
which impact one website, generic + specific records) is added as part
of the search view. Limitation: it will only be shown for pages at the
moment.
- A standard "Create" button is added and displays the form view dialog
to create a new content record as with "+ New". Known bug: it only
allows to create on the first website at the moment.
- The click on page/content record should redirect to the corresponding
url/website_url in iframe. This is now achieved via the new possibility
of defining an action on the <tree> tag in the view definition. Known
bugs/inconsistency: depending on the model, this opens in edit mode, in
a new tab, ... behavior to unify in a future update.
- The 'PagePropertiesDialogManager' is removed since the code is in Owl
and we don't need page properties dialog on the list view anymore.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2889981
Part-of: odoo/odoo#98937
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: website_slides
After [1], the website "new content" dialogs were replaced by formView
dialogs of targeted content (blog, slides, product,...).
The goal of this commit is to restore the "course layout image preview"
on the "New Course" dialog for the "channel_type" field (as on the old
frontend dialog).
Remarks:
- The field was added on 'website' module so it can be used on other
website related modules if needed.
- Some CSS related to the old form was removed in this commit too.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
closesodoo/odoo#96346
Related: odoo/enterprise#29922
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides, website_slides_forum
The goal of this commit is to adapt the website "new content" form
views to OWL.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
Part-of: odoo/odoo#96346
This commit adds an "on scroll" option for animations. In addition to
being triggered when they appear in the viewport, animations can now
also be triggered based on page scroll.
Animations are also improved in this commit, we add "intensity" option
and the dropdown with the list of animations has been split by adding a
new dropdown to choose the "direction" of the animations.
task-2862761
closesodoo/odoo#94119
Related: odoo/upgrade#3858
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the height of the element to be animated was
calculated without the padding of the element. That was wrong as the
padding needs to be considered part of the element.
task-2862761
Part-of: odoo/odoo#94119
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
Before this commit, the /website/add was always redirecting the requests
to the newly created pages. This way, the controller could be called
from a frontend 404 page (when clicking on the "Create page" button),
and from the WebsitePreview client action's "new content" modal,
introduced in [1].
This commit adds a "redirect" parameter to the controller that will be
used by the 404 page, to keep the same behavior for this use case. But
when called from the webclient, it will return either the id of the
created view (for *.js, *.xml, ... urls), or the new page url, so that
the webclient is not fully reloaded when it is not necessary.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#97408
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, following this flow on enterprise:
- Go to the webclient, on the homepage: '/web'
- Click on the website
- Click on the "contact us" menu
- Click on the browser's back button
=> The back navigation happens in the iframe, it's normal
- Click on the back button again
=> The url has changed for the webclient "homepage" one but the
WebsitePreview is still displayed.
This happens because the router service listens to the hashchange events
to communicate the webclient which component to display.
But with [1] it was decided to replace the regular webclient's router url from the
WebsitePreview client action with the frontend's url. As a result, the
'hashchange' is never fired when navigating back from the client action
to another webclient route.
To fix that, the 'popstate' event is listened at the client action
level. If the new url is a regular webclient's router one, an
'hashchange' event is triggered to continue the flow as if the browser's
url was never changed.
The same hook is used to revert back the original webclient route
/web#action=website.website_preview... when leaving it, so that the
router can replay it correctly when navigating back from another route.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#97408
Before this commit, clicking on the back button in edit mode would
reload the page, but keep the editor open and lead to bugs.
Now, the WysiwygAdapter handles back navigation with an empty history
state. On the popstate event, triggered by a back navigation request,
the WysiwygAdapter will leave the edit mode with the leaveEditMode
method introduced earlier.
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#97408
Before this commit, the BlockIframe component was managing its
visibility based on the 'BLOCK'/'UNBLOCK' events. Also, it was possible
to continue to interact with the SnippetsMenu when the iframe was
blocked.
With the previous commit modifications, it is needed to block the clicks
and prevent interactions with the SnippetsMenu when reloading the
iframe. For that, the BlockIframe component is reworked: a specific
state for this component is added at the WebsitePreview level. This
allows to add a o_is_blocked class on the container which prevents the
clicks on the client action when it is blocked. Therefore, it is not
blocking only the iframe anymore, but the whole preview. It is renamed
accordingly.
The 'loaderDelay' parameter is dropped, as it was used only to show the
loader after the snippets menu transition. As now the snippets menu is
removed after the reload, it is not useful anymore.
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#97408
This commit reworks the way the edit mode is left, from the client
action. It does 2 things:
1/ It keeps the SnippetsMenu as long as the iframe is reloading. Once
everything is ready, the SnippetsMenu is removed with a transition.
2/ It prompts the "Discard your changes" modal when switching language in
edit mode.
1/ Before this commit, the WysiwygAdapter was dismounted before
reloading the iframe. It was simpler this way, because the OdooEditor
has set some listeners on the editable document, which will crash during
a reload of the iframe.
Now, in a leaveEditMode method, the WysiwygAdapter will make a copy of
the snippet's menu html element, and display that skeleton while the
editor is destroyed.
It will also check if the editable is dirty and prompt a
modal to the user if needed, as it was before.
Some of the code to display that "fake" snippets menu is shared with the
Editor component which uses it to unmount and remount the WysiwygAdapter
while reloading the iframe (in a _getDummySnippetsEl method).
2/ With that, the quit method, passed as a prop to the WysiwygAdapter,
and played in the new leaveEditMode method, is updated with two
parameters: an onLeave function that will be played when the component
is unmounted, and a reloadIframe boolean.
As the WysiwygAdapter listens to a new 'LEAVE-EDIT-MODE' event using
these parameters, it allows for any website component to request leaving
the edit mode, with a reload or not, and execute an action after that.
This fixes [1], which was leaving the edit mode without going through
the WysiwygAdapter, and so, without checking if the editable was dirty
or not (i.e. without prompting the "Discard your changes" modal).
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[1]: https://github.com/odoo/odoo/commit/11429329b8dea2dd0b2496dc8c1c8627751cccff
task-2687506
Part-of: odoo/odoo#97408
Before this commit, when saving a page website would fail (for a
validation error, for example), the "Save" and "Discard" buttons of the
SnippetsMenu were not re-enabled, and the edition was lost.
This was visible following this flow:
- Go on a job form view,
- Duplicate it,
- Go to its website page,
- Edit the title to remove "(copy)",
- Click on save,
=> There is a validation error (there cannot be two jobs with the same
title), the page was not saved and the user cannot access the
"Save" and "Discard" buttons to continue the edition anymore.
To fix that, the "after" callback of the SnippetsMenu _buttonClicked
method (which will re-enable the buttons) is added after or as the
onFailure callback of the "request_save" event.
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#98352
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
[1] added a way to detect a replayed action, and returns early the
effect that parses the action's params to ignore them.
This implementation is an error, as the return value of the effect was
not consistent: for a replayed action, it was not returning the cleanup
function that resets the pageDocument, websiteRootInstance and
currentwebsiteId.
This was leading to such behaviour, with enterprise modules:
- Go to the website,
- Click on the top left 'home' button,
- Click on the top left arrow to replay the action,
- Click on the top left 'home' button again,
=> The website systray is still there.
To fix that, the cleanup function is moved to an onWillUnmount hook.
Also, blocking the iframe until its first load event is called in an
onMounted hook, as it is the same as using a useEffect hook with no
dependency and no cleanup function, but it is clearer.
[1]: https://github.com/odoo/odoo/commit/83501e38a338cabd5a064dd0db9f70df08a3aadc
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#98352
This commit partially reverts https://github.com/odoo/odoo/pull/98254/
in which we use the correct toggle attribute.
The problem is that this part is customized and the DOM is not as
expected by Boostrap (BS5 seems more strict than before).
Because of this, we consider that we shouldn't use Bootstrap's dropdowns
(the js part) for this case but we want to keep the same design.
To do so, we simply replace the class name by a custom one to prevent
BS from accessing it and we apply an @extend to keep all the css rules.
Because @extend could be costly in terms of performance, we did some
analysis:
* +3kB for the css frontend assets bundle.
* No significant change for the bundle Generation time:
[1.66sec - 2.93sec] vs [1.71sec - 3.31sec]
(quite difficult to analyse due to the number of variation)
Note that we already have this @extend in the backend and we could have added
this in asset common but we didn't as it will soon be deleted from the backend
(we will use our own dropdowns).
Steps to reproduce:
Go to shop page.
Type "desk" in the search input.
The suggestion popup appears.
Click outside the field. (e.g. to the left of it)
Click on the search field.
=> An error popup was displayed.
closesodoo/odoo#98756
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, when you double-clicked on an image in the Images
Wall block, the modal appeared twice. This commit ensures that for the
block Images Wall, only one modal can be present at a time.
Steps to reproduce the problem:
- Drop the block Images Wall on a page
- Save
- Click twice quickly on the same image
-> Two modals are open (one on top of the other)
task-2937538
closesodoo/odoo#98857
X-original-commit: e21ff31c429a8bc339f527a2e4eacc0f1b2f6d7d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In Bootstrap 5 the `.col-X` classes don't have position relative anymore
and the button use position absolute (relative to its parent) to
position themselves.
> Columns no longer have position: relative applied, so you may have to
> add .position-relative to some elements to restore that behavior.
Ref:
https://getbootstrap.com/docs/5.1/migration/#grid-updates
Note: we have set the position relative in CSS to avoid doing a
migration script.
closesodoo/odoo#98768
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
With the conversion of the views to owl, we added an extra div around
fields that represents the whole field, and wraps potentially multiple
elements that may be rendered by a field widget. This changes the DOM
structure, and to allow concrete fields to control everything about the
way they are displayed, we decided to use the css rule "display:
contents" for that div. As it turns out, while this does give more
control to the field widget, it breaks a lot of existing css rules, and
also prevents classes that are applied on that div from the arch from
affecting any css property related to layout (such as margin, position
or padding).
Because of that, we decided to revert this change, and set this div's
display property to inline-block (the same as legacy field widgets) and
adapt the few fields where this does not work out of the box, which
fixes many issues.
Part-of: odoo/odoo#98711
See previous commit(s) for more details about the new sanitize feature.
This commit implement a solution in the website builder to warn
restricted users when they can't edit a field due to the sanitizer
restriction.
Long story short: a HTML field can be flag as `sanitize_overridable`
which will allow users with the `base.group_sanitize_override` group to
not go through the sanitize process.
It means that such users can write some content which is not sanitize
friendly. A restricted user trying to add content in such fields would
then break the original content as the sanitizer would remove part of
the DOM.
In such cases, the field in the website builder is not detected as an
editable part and clicking on it will warn the user about it.
closesodoo/odoo#97398
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This method name, while being not specific enough to ease grepping,
leads to have `data-slide` in the option XML declaration. This was
actually confusing with the BS4 data-slide of carousel elements. Here,
in master, this leads to even more confusion as BS5 uses data-bs-slide
thus making it unsure if the option's `data-slide` has to be converted
or not during the current BS5 bug fixing.
Indeed, it was converted by mistake with the original BS5 merge at [1]
and later fixed with [2] but it could be matched by regexes again and
be re-broken by mistake.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/c6524ee9d60888bb147b77db5e394af8beda05abclosesodoo/odoo#98362
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when a ListViewHeaderButton was clicked, the view
context wasn't sent to the server.
As ListViewHeaderButton shows, the onClickViewButton API is not correct.
It expects a record in params but this is not correct in the case of
ListViewHeaderButton. So we decided not to pass a record but a getParams
callback that allows us to calculate the params when we need them.
Part-of: odoo/odoo#97558
The attribute aria-labelledby was used erroneously and was misspelled.
This commit corrects that by replacing it with the aria-label attribute.
task-2937538
closesodoo/odoo#98401
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since the merge of Bootstrap 5 at [1], a background-color and an opacity
are added on the `<hr>` elements. That way the <hr> now follows the
color of the surrounding text but are faded a bit. The BS4 behavior was
to use a lightgray (transparent black).
With the adaptation at [1], it was chosen to be compatible by forcing
that opacity to 1 and re-forcing the previous transparent black. This
commit chooses to instead keep the nice auto behavior of BS5, at worst
this will thus change lightgray <hr> to the color of the surrounding
text (faded a bit), it should not be a breaking change. The separator
snippet however keeps its full compatibility as we want to let users
choose the exact color they want so we cannot add a default opacity (we
may want to improve the UX later on).
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
Part-of: odoo/odoo#98028
*: hr_org_chart,l10n_gcc_invoice_stock_account,mail,point_of_sale,
purchase,website,website_sale,website_sale_autocomplete,
website_slides_survey
Some commit have added old Bootstrap 4 classes after the merge of
Bootstrap 5.
Note that it's not possible anymore as the merge bot is now able to
detect it.
closesodoo/odoo#98349
Related: odoo/enterprise#30551
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the logo height scrolled option was displayed even
if there was no logo.
It was because the condition to display or not this option (in the
"_computeWidgetVisibility") had not been updated correctly when the DOM
of the navbar was refactored.
task-2800680
closesodoo/odoo#98321
X-original-commit: 2b2ff732914e6c491e48540958bec967a3acfe33
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, we had a crash when a user types something in a
searchbar in the website (on /shop eg) and do keydowns:
"Cannot read properties of undefined (reading 'nextElementSibling')"
BS dropdown doesn't use JQuery anymore and is therefore less permissive
with empty arrays. Also note that the logic is different between BS4
and BS5.
To fix this, we need to make sure that all elements are in the DOM
before BS dropdown instanciation.
It's why we have to render the 'dropdown-menu' before the dropdown
constructor is triggered.
We also had to add the 'data-bs-toggle' attribute to let BS find it
to set '_element' (which must be the previous sibling of the dropdown-menu).
This data attribute was probably not set before because in this case
the BS dropdown is not used on a button or a link as documented;
we use it as an autocomplete functionnality.
closesodoo/odoo#98254
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Since the bootstrap 5 merge at [1], when you click on an image in the
Image Wall block, the modal no longer opens. This commit restores that
and adds a test to make sure this problem does not happen again.
Steps to reproduce:
- Drop the "Image wall" block in a page
- Save
- Click on an image
-> The modal does not open
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2937538
closesodoo/odoo#97053
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue:
1- Go to page properties > change the URL of a page.
2- A list of dependencies appears on a popover.
3- Click on a dependency > you are redirected to the related object
but the URL change for your page was "saved".
The changes on form views are automatically saved when the view is left
using a "beforeunload" handler.
The goal of this commit is to fix this behaviour by making website page
dependency links "_blank".
task-2687506
closesodoo/odoo#98180
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website
The goal of this commit is to tweak props on 'FormViewDialog' component
to be able to change dialog size (since 'props.size' is already used
by its 'Dialog' sub component).
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b
task-2687506
Part-of: odoo/odoo#98180
This adds commands to convert the current text into 2, 3 or 4 columns,
and to remove said columns.
task-2901585
closesodoo/odoo#95359
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since updating page properties means updating fields on the
'website.page' record, a 'page form view' was used to replace the
frontend page properties dialog at [1].
The goal of this commit is to update the fields used for website page to
work with the new OWL form views.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#97343
After [1], the frontend 'page properties' dialog was replaced by a 'form
view dialog' of the current 'website.page'.
The dialog structure in [1] was based on a 'PagePropertiesDialogWrapper'
component that handles a 'legacy formViewDialog' widget of the page.
Since 'FormViewDialog' is available as OWL component (starting from [2]),
we can now simplify the current code from:
A- 'PagePropertiesDialogWrapper': creates & opens a legacy FormViewDialog.
to:
B- 'PagePropertiesDialog' (the page formViewDialog): can simply be added
using 'dialog service'.
Remark: a wrapper ('PagePropertiesDialogManager' component) is used
temporarily by the legacy 'website.page' listView to add
'PagePropertiesDialog','DuplicatePageDialog' & 'DeletePageDialog'.
This component should be removed after the update of the listView to OWL
and components will be added using 'dialog service' as in the website
navbar menu code.
Follows the merge of the 'website in backend' task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/48ef812a635f70571b395f82ffdb2969ce99da9e
task-2687506
Part-of: odoo/odoo#97343
Whenever an error happens during the website creation after the last
step of the website configurator, it is displayed as an notification
popup, but it keeps the UI blocked, preventing the user from retrying
the operation.
The usually observed error is about not being able to install the module
or theme because a cron is in progress. The message actually asks the
user to retry later.
This commit does the following upon errors happening during the website
creation:
- silently retry after 5 seconds, up to 3 times
- after all attempts failed, display the error and release the UI and
allow for manual retry.
task-2809434
closesodoo/odoo#98124
X-original-commit: 2afdbc7181de3c87c1021f1e06d059ffe059ede0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
- Make the animation smoother and less prompt to bad UX:
1. The animation duration of the closing part is now slower. Somehow
it looked like the closing animation was faster than the opening.
2. The animation delay of the closing part is now bigger. It will
prevent some weird UX issues when the cursor is moving out of
the window by mistake (eg moving a bit too far in the bookmarks
bar or the Ubuntu left panel for instance). In those case, despite
the user wanting to open and click inside the navbar, it would
directly close it.
- Make the edit button only visible for editors
- Make the go to backend button only visible for internal users (not
portal anymore)
- Restore a behavior that was lost during the frontend > backend task
[1]: clicking on the app switcher in community should show the list of
apps so you can directly access where you want to go in the backend.
It improves the usability in community where you otherwise have to
click twice every time as the first click always brings you to the
discuss module from where you have to click again on the app switcher
to select the app you wanted to land on.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#97745
Related: odoo/enterprise#30218
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Nicolas Bayet