* 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
based on v10 terms and saas-15
add the new languages
Much noise due to the different softwares that do not indent the terms the same
way. Merged the po files with --no-wrap option which makes long lines.
opw-751014
* 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.
If the website default language is not en_US, qweb fields are not
translatable in en_US (and thus can't be translated) because:
- the code expected en_US to be the default language.
- there was a error in website _dispatch
opw-746776
closes#17939
Before 036ccbef when writing on qweb field with default language mi_SC:
- writing in mi_SC: wrote on the current res.user language (wrong)
- writing in en_US: wrote on en_US translation (right)
- writing in de_DE: wrote on de_DE translation (right)
but after 036ccbef:
- writing in mi_SC: wrote on mi_SC (right)
- writing in en_US: wrote on mi_SC (wrong)
- writing in de_DE: wrote on mi_SC (wrong)
With this commit, this drawback is also solved by keeping the lang in
context if present.
opw-746776
closes#17917
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.
Steps to reproduce the bug:
-Change the default lang on the website to be different than en_US
-Edit the name of a product in the website
Bug:
The name of the product is changed in en_US and not in the language
set on the website. The lang is in fact removed from the context in
function saveElement(in addons/web_editor/static/rte.js).
opw:747084
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
qsm-odoo