* 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.
* 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
- Change the info message "Add Images from Customize menu" to
"Add Images" and make it clickable
- Reorganize snippet options menu
- Improve the image dialog to be able to select/unselect
- Make sure previews are adapted when changing gallery images
Before this commit, when clicking on an image which is in a link, both
the link edition dialog and the image edition dialog were opened. Now
only one opens.
When cloning a snippet section thanks to the editor, the associated
snippet options' `on_clone` methods are called. Now these methods
receive a new argument `options`. The option this commit introduces
is the `isCurrent` one. It allows the method to know if the snippet
section it is associated to is the one that was cloned or if it is a
child of the one that was cloned.
This is useful to solve a known bug when cloning elements which have
bootstrap columns:
- When one column is cloned we want it to lose its col-*-offset-*
classes so that the offset is not duplicated (only the column).
- When a container with column children is cloned we do not want
these column' offsets to be removed (we want the whole cloned
container to be the same).
In carousel snippet, the target element for background snippet option is
being changed manually. So for the new target, we have to rebind the
associated events that were bound in `start` function of the snippet
option. For that, some code is extracted from the `start` function and
is used to rebind necessary events for new targets.
In particular, this was preventing the carousel slides' backgrounds to
be automatically removed when a background-color was selected.
Backport of 10.0 commit: 5331a87f81
The snippet options are attached to `closest`, `all` and `is` functions
to be able to find/check DOM they are associated to. Their behavior
depend on the snippet option type: the search in the DOM is either done
in the body, the editable parts, the editable children only, ....
The problem is that when searching from a given DOM element, jQuery
won't match the elements whose selector contains this given DOM element.
Or in code terms, jQuery find function behavior is:
`$('A').find('A B')` <=> `$('A A B')` (not `$('A B')`)
This was indeed a problem on the job position apply form pages where the
main editable element is the <form/> element itself. Indeed, the snippet
options' selectors which began by 'form' were not able to match. Worse,
the selector is used for a jQuery search for drag & drop and saving but
not for initialization (where it is used as a `is` check on clicked
elements). So, some DOM were able to be modified by options but not
properly (re)configured before saving.
opw-705902
opw-741305
If the method commitChange from the widget FieldTextHtmlSimple was
called in mode=readonly, a traceback was displayed. This is not very
common, because most save operations are done in mode=edit, but it can
happen in readonly mode: when the user clicks on an action button, then
the form view is saved, if necessary.
To reproduce this bug, just open a form view for res.users, and click on
the Change Password button.
Before this commit, it was not possible to set the 'html' widget
for a field in Studio.
Even if this is the default widget for the form view, it not the
case for the kanban view. You need to precise each widget you
want to use (for performance reasons).
opw-744254
The snippet options are attached to `closest`, `all` and `is` functions
to be able to find/check DOM they are associated to. Their behavior
depend on the snippet option type: the search in the DOM is either done
in the body, the editable parts, the editable children only, ....
The problem is that when searching from a given DOM element, jQuery
won't match the elements whose selector contains this given DOM element.
Or in code terms, jQuery find function behavior is:
`$('A').find('A B')` <=> `$('A A B')` (not `$('A B')`)
This was indeed a problem on the job position apply form pages where the
main editable element is the <form/> element itself. Indeed, the snippet
options' selectors which began by 'form' were not able to match. Worse,
the selector is used for a jQuery search for drag & drop and saving but
not for initialization (where it is used as a `is` check on clicked
elements). So, some DOM were able to be modified by options but not
properly (re)configured before saving.
opw-705902
opw-741305
The prettifying of html when editing sources (user need to be in debug
mode to see the button) was removing too much spaces in some instances.
For example if someone got in a case such as:
<span>hello<b> cruel </b>world!</span>
The spaces between text and tag would be removed (this would work fine
with the space outside of the tag).
This code add a special case so this doesn't happen anymore.
opw-743565
closes#17142
Kishan Gajjar