| Age | Commit message (Collapse) | Author |
|---|
|
Now we only support tour in edit mode already.
We win a click on onboarding., and after the install of a theme
It avoid to have 2 tips on the same page that can be confusing
|
|
- Apply the style of drag&drop zones (.oe_structure.oe_empty) even when
it is a descendant of the editable element, not the editable element
itself. This change allows to add a visible drag&drop zone in any
snippet.
- Add the editor messages (data-editor-message) on drag&drop zones when
a snippet is dropped (not only on editor start as before).
In preparation of task-2152185
closes odoo/odoo#43358
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
In a80775ce3c7d, some code was refactored to stop using the confusing
'animation' denomination, as in reality they were just public facing
widgets that did many things, such as loading data based on
data-attributes and other things that were not always animation related.
One instance of the animation_stop_demand event was not renamed in the
_onSnippetWillBeCloned method, which creates some problems, one of which
being that the facebook snippet's iframe wouldn't be destroyed on clone,
but since the animation was started after the clone, this would result
in one facebook page snippet with two iframes with the facebook page,
for a total of 3 instead of 2, and one of these was unconfigurable.
This commit renames the event to restore the proper behavior.
closes odoo/odoo#42311
X-original-commit: 2a671f47f87e2bb52a5fade11ea6b79070516694
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
The wysiwyg abstraction layer was introduced in saas-12.2 by
commit f2969923. Its goal was to provide an external interface
for other modules that wanted to use the editor feature such
that the editor core itself could be changed without requiring
extensive changes in the other modules.
This commit is adapting the wysiwyg interface to instantiate
the 12.0 editor below it rather than the saas-12.2 one, thus
reverting the "new editor" part of f2969923 itself.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
|
|
|
|
|
|
|
|
|
|
Before this commit, when a snippet was cloned, its animation was not destroyed
first. The flow was:
1. Clone the snippet (DOM) - web_editor trigger `snippet_cloned`
2. Start cloned snippet animation - website listen `snippet_cloned`
This was causing bugs, eg facebook snippet for which the animation is to create
an iframe containing the facebook widget.
When cloning this snippet, its iframe would be cloned to, then its animation
would be started, creating another iframe.
To fix such flows, the snippet cloning flow should be:
1. Strop the snippet animation
2. Clone the snippet (DOM) - web_editor trigger `snippet_cloned`
3. Start cloned snippet animation - website listen `snippet_cloned`
4. Restart the original snippet animation
task-1951466
closes odoo/odoo#35029
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
|
|
issue: 'enable_editor' and click on 'edit' before loading edition, or
double click on 'edit'
|
|
|
|
Part of https://github.com/odoo/odoo/commit/f4ba72a7593b67595852fc52ec0997d3276dbc67
became useless after forward-port in the new editor. Indeed, that
commit handled what happened with data-editor-message attributes on
save but as the new editor can discard changes without reloading the
page, the forward-port of that commit made the code handle the attribute
removal on editor *close*.
closes odoo/odoo#31143
|
|
Issue: wysiwyg asset slow down the loading of the website, error
inadvertently introduced: https://github.com/odoo/odoo/pull/29775
The assets are now loaded assynchroneously, when the editor is needed,
its assets will be loaded.
closes odoo/odoo#30700
|
|
|
|
|
|
* 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
|
|
When the edit mode is entered, some elements receive
data-editor-message attributes. These were not removed on save which
could in some cases make the attributes be saved in the database. For
this to happen it would require an `.oe_structure.oe_empty` element to
be put *inside* an editable element (instead of being the one which is
editable). In that case the `.oe_structure` content would be saved in an
inheriting view but the parent view would also be COW'd for no reason
because of that attribute.
Difficult to say if such a case exist in the current views but as it
technically possible and that some of our tests use that configuration,
it is worth fixing.
Note: this fix was in fact done in the new editor in master and allowed
to detect that one of our test was not testing a feature correctly
because of that. This will be adapted in a different commit of this PR.
closes odoo/odoo#30834
|
|
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the website 'edit.js' file received mistakes / useless code.
https://github.com/odoo/odoo/pull/30839 fixes one of them. Hopefully
this commit will solve the remaining ones.
- https://github.com/odoo/odoo/blob/12.0/addons/website/static/src/js/menu/edit.js#L43
was moved for no reason at all at the bottom of the method alongside
its comment which broke the feature and made the comment wrong.
- Changed a '.a' selector into a '.a:not(.b), .a.b' selector...
https://github.com/odoo/odoo/blob/b6db6b878c5d329c19262d829e13726c3a3a1d25/addons/website/static/src/js/menu/edit.js#L136
- For the same selector, a 'FIXME' comment was removed while it was not
fixed (this restores it as a 'TODO' instead of a 'FIXME' though).
- On edition stop, removed all the data-editor-message, even the
specific ones that were not added by the editor (note that it was not
a problem for the current ones in Odoo as they were by chance on the
main editable elements which made them not saved in the database):
https://github.com/odoo/odoo/blob/b6db6b878c5d329c19262d829e13726c3a3a1d25/addons/website/static/src/js/menu/edit.js#L177
closes odoo/odoo#30870
|
|
Every new page was being considered an empty homepage with "Welcome to
your Homepage! Let's start designing." shown. Now only an empty homepage
shows that message.
closes odoo/odoo#30839
|
|
* 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
|
|
|
|
* web_editor
When an user saves its website, all the animations are destroyed so that
a clean DOM is saved. This is particularly important for snippets like
the latest post one that would crash the page if not cleaned before
saving.
Two cases were found where animations were not cleaned before saving and
this is what this commit fixes:
- When an user used the undo/redo system, all animations were lost as
the DOM is recreated.
- When an user duplicated a snippet, animations were not restarted on
the cloned element.
closes odoo/odoo#29159
|
|
|
|
|
|
Before this commit, the placeholder was hardcoded:
'Drag building blocks here'
Now you can customize the placeholder using a data-editor-message attribute.
|
|
On save, the editor will ask to parent widgets if something needs to be
done first. The website navbar will receive that demand and asks to its
action-capable components to do something. For example, the content menu
handles page-related options saving. However, some users with limited
access rights do not have the content menu... but the website navbar
expects that the save action is performed. So, this empty action is
defined here so that all users have an 'on_save' related action.
This was only happening since 12.0 as 'on_save' actions were introduced
there to save page-related options.
closes odoo/odoo#28810
|
|
* 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
|
|
* 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>
|
|
This commit fixes a bug introduced with https://github.com/odoo/odoo/pull/28251:
When opening the ace editor on page load thanks to the #ace-view-editor
URL hash, a JS error occurred preventing the editor to open.
This was due to the way actions were executed on page loading:
- Menu elements are initialized and can handle actions
- On initialization, the ace menu tried to launch the editor
- First, it asked that all widgets are closed (see mentioned PR)
- The website handled that action demand by asking everyone to close
their widget
- The 'new content' menu tried... and failed as referenced a variable
which would only have been created in the start method.
Conclusion: before handling actions, all action-capable widgets should
be started. This is what this commit does: when receiving an action
demand, we first wait for the action handler to be fully started. This
implied another change: before, many menus were waiting for the result
of an action to notify that their start method is finished... this
would cause a deadlock in the new system so those were removed, this did
not make much sense anyway (if the result of that starting action has to
be known, a dedicated event/method should handle that).
closes odoo/odoo#28364
|
|
Before this commit, the message was always displayed.
Now we only show into the default homepage the message "Follow all the tooltip"
when there at least 1 tooltip in the current page.
task-1878245
|
|
Use CSS style with a translated text instead of an image.
|
|
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
|
