* website_forum
Summernote is instantiated as a simple text editor for 'simple' HTML
backend fields and in website_forum. In those cases, the user was not
able to open editor dialogs anymore as their opening was now handled
by the RTE widget in web_editor since the recent website refactoring.
The goal was to use `this._rpc` in these dialogs (and this required the
dialogs to be attached to the widget parenting system).
As a fix, a new component was implemented to handle these dialog
openings and this component is thus created by the RTE widget and the
other places that need the feature. The right fix would be a better
integration of the summernote editor in the parenting system but this
requires a lot more work than this commit, this will be the goal of the
future editor refactoring.
In saas-15, the LESS editor was introduced alongside the use of the
select2 library to style the <select/> element which allows to choose
the view / less file to edit. The problem is that the default behavior
of the select2 library is to open a dropdown with a max-height of 200px
and a width equals to the <select/> element (with no regards to the
dropdown content). In most cases, the dropdown was then displaying
only a few results, broken over multiple lines.
Now, the dropdown is restyled so that it has no maximum height, no set
width and more readable content.
When starting the HTML editor, the first view that is shown is supposed
to be the main one of the page by default. This was not the case for
custom pages as the 'xml_id' of the page was considered instead of its
'key' value.
When an image is added thanks to the media dialog, the URL that is used
was '/web/image/<id-of-the-attachment>'. Now the name of the image will
be added for SEO purposes ('/web/image/<id-of-the-attachment>/<name>').
Also protect URLs with quotes to allow spaces.
* 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.
A form view record may be saved even if the record is displayed in
readonly (e.g. when a button in the form view is clicked). When
this happened, if there were an html field with html_frame widget
in the form, it crashed (e.g. in Email Marketing > Mass Mailings >
open one > click on Test Mailing).
* web_editor
Odoo extends jQuery to add some utility functions. The 'prependEvent'
one add the possibility to add an event handler on an element (like
the jQuery built-in 'on' function) but to be executed before the
already binded ones.
This function was however incomplete and did not allow to use jQuery
namespaced events.
* web_editor, web_tour
jQuery has the built-in ':visible' selector. This is however not enough
as this only checks if the element and its parents have a visible
'display' property. Ironically, if the element has the 'visibility'
property set to 'hidden', it will be considered ':visible' by jQuery.
This commit creates the ':hasVisibility' and ':hasOpacity' selectors
which respectively check if the element and its parents have a visible
'visibility' property and a visible 'opacity' property.
Before this commit, the session object was responsible for loading the
translations in the backend only. There was then ugly code in web_editor
(which is also loaded in backend...) which was doing "if frontend then
load translations by myself". This code was also translating templates
while this is the qweb object's job. Now session is always responsible
for loading translation.
Note: the session object should be refactored/split.
* web_editor, web_planner, website
The 'Dialog' class is used in both backend and frontend. Also, lots of
actions can be done without the use of any modal. It thus makes sense
to lazy load its related xml only when a first modal is opened.
This change also allows to get rid of the "base_common.xml" file as the
dialog template is the only remaining one in there and, in the future
website update, it will allow to not load any static XML file on website
page loadings.
Uppercase style shouldn't be applied to all btns by default.
The usage should be set progressively, following an importance criteria.
If we design everything as important (uppercase), nothing will be
perceived as important anymore.
- Cleaner design
- Reduce element size
- Use LESS variables to simplify maintenance.
- Switch from ‘em’ to ‘ex’ measure units.
- Remove :hover state (not useful).
- Clearly show margins' size on editing
- Top margin icons/cursors: by an user point of view, adding a
margin-top will move the content 'down', so change handler's icons
and cursors accordingly
- Highlight handles during editing and if previously edited
- Vertically center handle's icon if enough room is available
There was a lost promise which made website_form loaded before the
languages informations (such as date format) was loaded.
The server expect the format of the client thus that could lead to wrong
or invalid dates.
opw-749544
closes#18074
web_editor can be installed without website, thus missing needed CSS
causing e.g the widget sidebar to overlay and hide the mass mailing
content if website is not installed.
This fix implement a simple middle ugly solutions, but doing something
more in stable would be an hassle (for example in 88c2b684 the #wrapwrap
CSS is included in report module).
opw-748975
closes#18005
* mail_channel, mass_mailing, twitter, event
- t-install attribute holds the technical name of the module that
needs to be install to use a particular snippet.
- Disable the drag & drop feature for these dummy snippets.
- Move some images to website module.
- Installed snippets display at the top of the list.
- Hide not-installed module snippets if user don't have rights to install module.
The translate feature of widgets html and html_frame had been
broken by the new views refactoring. This commit restores it for
the html widget, and removes it completely for html_frame as it
wasn't working correctly before the new views anyway (moreover,
it had already been disabled for mass_mailing: de403dc1ab).
This commit also ensures that the changes are correctly saved for
the html_frame widget. Note that this widget still needs to be
converted to our new coding guidelines.
* web_editor, web_tour, website_event_track
Before this commit, one JS file was responsible for all the library
extensions and fixes. There were two main problems with this system:
- The file was only available in the backend (as some extensions are
made on backend-only libraries).
- Some other modules were doing library customizations.
This commit creates one file per library to regroup their associated
customization and adds them in the right asset. These are placed in
the web module and every other module should avoid doing customizations.
This allows to have libraries consistency accross all modules and
between the backend and the frontend.
Creating and editing mass mailing in multiple language is managed with
the change 05daa15.
But currently the language the mass mailing is sent in, is the language
of the "Process Mass Mailing Queue" (root user if not changed) so all
the recipients will receive the mail in the root user language has at
the time the given batch of mails is sended.
So this is different from what someone could expect by it being
translatable. In any case the recipients list could be based on a lead,
a partner a mass mailing contact or other and a language could not be
determinable in stable (a mass mailing contact does not have a language
for example).
If the system worked, there is also a usability downside in the meaning
that someone could duplicate a mail and not check all translation and
not be aware that the mail he see is maybe not the mail that will be
received (if translations have not all been completed).
In stable to have the same behavior in any case and lessen the usability
burden of users thinking erroneously the mass mailing may be sent in
several languages depending on a not-existing heuristic, this changeset
remove the translatability of mass mailing content.
This has the following effect:
no translation editing appear,
the mass mailing is edited and sent in one and the same language,
If someone want to send a mass mailing in several language, currently in
Odoo it would then require to:
duplicate the mass mailing,
change the domains of recipients base on choosen heuristic,
edit the duplicated mass mailing in the choosen language
opw-746445
opw-746776
closes#17718
Christophe Simonis