| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Before this commit, the code that was supposed to close the dropdown in the
navbar when scrolling was not working anymore.
Indeed, it would removes the `show` class from the `nav-item dropdown`
(dropdown menu entry) but not from the `dropdown-menu` (dropdown content).
Fixes #35320
closes odoo/odoo#36069
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Since https://github.com/odoo/odoo/pull/29442, "Animations" became
"Public Widgets" (even though the Animation class still exists as an
extension of standard PublicWidget).
Since that refactoring an error was introduced which made the code
modify the prototype of the 'events' key each time a public widget with
a 'read_events' or 'edit_events' was instantiated (while the goal was
to modify the widget's own 'events' key, not from the prototype). This
was the cause of very ununderstandable errors...
closes odoo/odoo#34600
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
|
|
|
|
|
|
|
|
Facebook snippets' related widgets must be instantiated in edit mode.
This was broken when the feature which disables the widgets in edit mode
by default was introduced with https://github.com/odoo/odoo/commit/335a505d1f9b6a978c0fe0f6ea760a45b0d0a67f.
closes odoo/odoo#32921
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Facebook API does not accept float values for height and width
parameters anymore.
closes odoo/odoo#32970
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
|
|
Javascript is responsible of showing the menu, potentially with some
parts regrouped in an extra dropdown, on page load (this is what we
call the "autohide" feature). This was done on both the menu and the
affix menu. It worked on the affix menu because the affix menu widget
was initialized before (by luck: alphabetical order).
Since the jQuery 3 update https://github.com/odoo/odoo/commit/bb004e3d7f3df5a5af6b2e994ec0af79e2da890f
deferred are always delayed (even if their resolve condition is met on
creation). This made the animations to be initialized in the same order
as before but their 'start' method to be delayed (as the willStart was
delayed). So what happened before was:
1) Find menus to enable affix
2) Enable affix on found menus (duplicate the menus to do that)
3) Find menus to enable autohide
4) Enable autohide on found menus (both the menu and the duplicated one
were found)
And since jQuery 3:
1) Find menus to enable affix
2) Find menus to enable autohide
3) Enable affix on found menus (duplicate the menus to do that)
4) Enable autohide on found menus (the duplicated one was not found at
step 2 since it did not exist yet)
In fact, widget starting should never have relied on alphabetical order.
The fix only consists of starting widgets on the duplicated menu once it
is ready. This is what this commit does.
However, doing this revealed another bug: if the widgets are started
only for a DOM portion like a '.a' element, a widget with a multiple
parts selector like a '.a .b' selector will not be considered, as
searching inside a '.a' element will not allow to match elements with
a selector containing a '.a'. This is in fact not really a "bug" but a
limitation, so unless we get problems because of this in stable
versions, we can only "fix" this for the current saas. This is fixed
thanks to `dom.cssFind` which already existed. This commit however
improves it to try making it more efficient.
closes odoo/odoo#32465
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Before this commit, the object used by Optimize SEO 'wizard' was always the
main object, without any possibility to change that (except by changing the
main object but that would cause a lot of other issue, eg edit in backend).
This commit add the possibility to explicitly set a seo object on the html data
attribute.
If set, this one will be used instead of the main object.
This is useful for event.event where all the event pages (with website menu
enabled) would share the same SEO since the main object would be the
event.event.
With this commit, the seo object is now the website.page, thus giving the
possibility to have a separate SEO for every event pages.
(Required for Odoo.com website for OXP)
closes odoo/odoo#33194
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
|
|
|
|
|
|
|
|
If destroy is called before start, there will be a crash before this commit.
At the time of this commit, this can be reproduced in master by dropping the
image gallery snippet, clicking on add images (double click, which opens the
media dialog twice for some reason), selecting 2 images to add on the
media dialog, and clicking on add. The error will be in the JS console.
closes odoo/odoo#33440
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Example where the issue occurs:
- Publish an event
- Go to the website, register for that event
- At confirmation, when the email address is requested, click quickly
several times on the 'Continue' button
Several registrations are created since nothing prevents multi-clicks.
The stateful button feature of the `button.js` jQuery plugin has been
dropped in Bootstrap 4 (see [1]).
[1] https://getbootstrap.com/docs/4.1/migration/#buttons
opw-1958580
closes odoo/odoo#32571
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
Now that the logo can be resized, the affix menu had to be adapted to
handle tall headers.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
|
|
* web, website_blog, website_sale, website_twitter
Before this PR, all website widgets were named 'Animation'. Now that
they are 'Public Widgets', we can at last stop using the confusing
'animation' name.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
* website_blog, website_crm_partner_assign, website_event,
website_event_track, website_form, website_forum, website_links,
website_mail, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_stock, website_sale_wishlist, website_slides,
website_twitter
While using the 'Animation' class of website instead of the frontend
'Widget' class leads to the same behaviors, this refactoring is done for
two reasons:
- Stop using the confusing 'Animation' name for non-animated behaviors
- Instantiation of 'Widget' is slightly faster than 'Animation'
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
* portal, sale, web, website_blog, website_crm_partner_assign,
website_forum, website_event_track, website_links, website_mail,
website_slides, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_wishlist
The `editableMode` option and its related options in public widget
should only be part of website, this commit moves them there. This is
also the occasion to implement something that is long overdue: stop
creating 'animations' / public widgets in edit mode by default. Indeed,
lots of 'animations' were defined by beginning with 'if not edit mode'.
Now, if a public widget should be considered in edit mode, it must be
defined explicitely through a property at *definition* of the widget.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
* account, auth_signup, payment, portal, project, sale, sale_management,
web_unsplash, website, website_mail, website_rating, website_sale
This commit does probably not do what is stated for all non-website apps
but it is a first step. It also uses the system in apps which could have
already used it but did not.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
Not sure this one is still useful but best to integrate it as a
public widget.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
* im_livechat, survey, website_forum
When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This commit moves part of website JS to web, so that it can
be used by all 'frontend' apps whose only common dependency is web
(portal, survey, auth_signup, ...).
This PR also questioned several other similar issues which will be
handled later like:
- website should maybe not depends on portal but only on http_routing
- part of portal should be moved to http_routing and http_routing
should be renamed (especially for frontend layouts, etc) so that apps
like survey can reuse some common code
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
In preparation to future commits, the WebsiteRoot instantiation is moved
in an other file than its definition.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
|
|
|
|
* website_forum, website_gengo, website_mail_channel, website_sale
Retrieving the global context is now the root's job, this will prevent
problems when trying to extend the values the context has.
See upcoming improvements with https://github.com/odoo/odoo/pull/29442
closes odoo/odoo#30816
|
|
|
|
Also secure the anchor creation to only allow valid names, that is
letters, digits, underscores and hyphens.
task-1913458
closes odoo/odoo#30701
|
|
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
'web_editor.BodyManager' stopped being used by the editor and the
related file was moved to website without being renamed or considered.
Hopefully, the editor replaced it by something else so the `BodyManager`
makes no sense on its own anymore. This commit merges its features
with the only other component which still used it: `WebsiteRoot`
See upcoming improvements at https://github.com/odoo/odoo/pull/29442
(related to task-1932066)
closes odoo/odoo#30740
|
|
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes #30567
|
|
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes #30564
|
|
Now forum only allow to post message of type 'question'.
New 'modern' UI with Bootstrap 4
New moderation modal for bulk spam
Co-authored-by: qha <qha@odoo.com>
Co-authored-by: qsm <qsm@odoo.com>
Co-authored-by: jke <jke@odoo.com>
Thanks to @qha-odoo for UI
Thanks to @qsm-odoo for reviewSsss
closes odoo/odoo#29235
|
|
closes odoo/odoo#29219
|
|
* web
This commit introduces helpers for async handlers, especially for button
clicks. Those helpers are now used automatically for website widgets
(animations) if the 'async' word is placed in front of a handler name
in the `events` key definition.
|
|
* website_event
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
'web_editor.ready' was moved to website without being renamed.
Following https://github.com/odoo/odoo/pull/30409, this will remove
that 'web_editor.ready' module.
See upcoming improvements with https://github.com/odoo/odoo/pull/29442
closes odoo/odoo#30548
|
|
* website_forum
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the website 'animation' system was 'extended' to vaguely use a
'Registry' instance instead of an object. This was however left
undocumented, with a require in the middle of a file, restarting all
animations when used, only used by website_forum... with more code for
no reason at all, ...
This commit restores the system to the way it was before and re-adapts
website_forum:
- No need to check if website_forum is in the DOM as it is already
checked by the animation system (on top of that... the new code was
checking the DOM before it was ready...).
- No need of a dynamic add on a registry, this is always done before the
DOM is ready, so before the animations are started.
- No need to know the root instance in website forum, just use the
animation as the Wysiwyg instance's parent.
The goal of this commit is also to avoid useless conflicts with
https://github.com/odoo/odoo/pull/29442 (that should not have had any
conflict at all as totally independent of the editor task...)
closes odoo/odoo#30478
|
|
* website_forum, website_gengo, website_mail_channel, website_sale
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the web_editor.context module was moved to website without being
renamed. This commit renames it to website.context but also merge the
website extension that was made to that context directly within its
definition.
closes odoo/odoo#30409
|
|
* auth_password_policy_signup, auth_signup, website, portal, survey,
web_unsplash, website
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775
web_editor.base has been moved to website while it was still used by
frontend pages which do not depend on website (especially portal).
This commit moves web_editor.base to portal while waiting for
https://github.com/odoo/odoo/pull/29442. It also removes the unnecessary
dependencies to it in non-portal pages (in survey for example).
|
|
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
|
|
The refactoring of the wysiwyg editor and 'html' field allows us to
move some of the code that was in web_editor but only used in website or
in mass_mailing. Some parts are still in web_editor but will be
moved at a later time.
|
|
* portal, web_editor
Anchor Link:
- Some visual improvements of the link dialog.
- New 'Page Anchor' field.
- System by default: top and bottom.
- Shows existing anchors.
Creation of the anchor:
- New option 'Anchor Name' to be able to create an anchor.
task-1913458
closes odoo/odoo#29150
|
|
The previous code made sure we wait for images to be fully loaded before
initializing the auto more menu. But in some cases, it is not enough, we
also have to wait for fonts or even extra scripts. Those will have no
impact on the feature in most cases though, so we will only update the
auto more menu at that time, not wait for it to initialize the feature.
closes odoo/odoo#28684
|
|
Some code is in charge of setting the same min-height for all items of
a carousel to the natural height of the tallest item, once the page is
loaded. This code was not working correctly in the case the natural
height of this tallest item depends on the height of one of its inner
image, as we have to wait for the image to be loaded in that case.
closes odoo/odoo#28159
|
|
The animation that made all the carousel items have the same height
automatically was broken. This commit fixes it and improves its behavior
during edition.
closes odoo/odoo#27801
|
|
|
|
|
