There is some odd behavior especially inside a editable containing
newlines.
For example in the sale description on an ecommerce item, lines could
contain newline (it is editable from backend) but as an effect of other
use case, pressing enter could have a range of unwanted side effects:
- removing all the content,
- duplicating the editable (should never happen, if we have one field
"description_sale" we don't want to duplicate it, this has no sense)
In a product name which is in the same use case, there is no newline so
the problem is not apparent, and ENTER do nothing. This is the behavior
we should want in every instance.
If we still want a newline, we have to force it with SHIFT + ENTER key,
also this is regarding field that may or could be present in the backend
views, so it could also be edited in backend.
This change make ENTER ignored when we are editing a node directly child
of an node being edited.
A second part of the issue was that dom.removeBetween (used to remove
content inside a range) could remove the ancestor node that was an
editable. This is not wanted.
For example if we did CTRL + A inside a field with `<br />` then ENTER
or pasting something, the field would be removed and not just emptied
and could not be gotten back without editing the template manually.
This was sometimes mitigated because if a `<br />` was at the end of an
element, it would stay in this use case avoiding the issue.
note: not necessary after saas-16
fixes#17445
opw-751360
closes#19313
The commit 8749410b10 corrected the way the iframe was rendered to display a video in v9.0.
In v10 though, the html sanitizer is a bit more severe and cleans data-src attributes, preventing the iframe to have a src
This commit works around that and allows the src of the video to be saved in db
OPW 761424
closes#19125
Before this commit, when the shop was in multi images, the main image was not refreshed when changed in the back end.
This was because of the ?unique parameter that was computed on the product variant image. Hence, when the product image changed, the variant image did not, the hash neither, and the image wasn't refreshed
This commit fixes this by adding an option to the qweb.field.image
OPW 765287
closes#19133
Dominican team is focused on Transifex traductions using es.po,
as es_DO.po has a lot of issues in the website and reviewed strings
with wrong wording and mixing english and spanish. From now on
Dominican Republic will inherit es.po and just make specific changes
on github just in the needed words or setences that change base on
region.
Closes#18834
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
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
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
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
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
Following bee3253b44, this commit is made
to increase the mail clients compatibility for the mails that are
created with the odoo mail editor.
Three new problems are handled:
- Font family of titles had to be forced too as outlook was not
inheriting parent font family on those either.
- Default text font-size had to be forced as was not detected in
transcoding correctly.
- text-decoration rule was decomposed in text-decoration(-line,
-style and -color) in transcoding. Outlook is ignoring those
three rules for some reason. As the decomposition is useless,
the transcoder now forces the recomposition of these three rules.
In 4e0e376b0 an iframe for the readonly preview was added when
displaying html fields.
In e5112ee00 this iframe was only used if style-inline was set in the
widget options.
This brought an incompatibility if the not iframed preview contained an
iframe (eg. a youtube video which is then resize to a 30px height) which
is solved by this commit.
opw-725161
closes#16955
Odoo Translation Bot