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
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
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
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
There was an issue when selecting a video tag:
- a tag inside the video tag would be selected instead of the video tag
so video could not be removed or modified (modifying it would add a
video or image inside the video itself and so on).
- the selection was not conveyed to the editor so it would be lost
consequently due to some code who restored it to what was saved on
the editor.
This fix solves this by changing how the video tag was selected and
saving the selected range on the editor.
opw-724701
When adding a font-awesome icon to a mail template, the icon is
converted to an image once the template is saved. To do that, the
code checks all the `.fa-XXX` definitions in the stylesheets to know
which content the image have to use. The problem is that this was
not considering the font-awesome aliases. Indeed, the `fa-facebook-f`
icon was able to be used while its alias `fa-facebook` was not working.
When using the iframed editor with multilang selector (present if there
is another lang installed than en_US) an "English" language was present
before each translation language.
opw-696891
The transcoder (which transforms stylesheet rules to inline style) did
some compression of the padding and margin css properties to not always
have margin-top + margin-right + margin-bottom + margin-left.
This could cause an issue when the value of margin or padding contained
an initial or inherit value because browsers (at least firefox and
google chrome) doesn't allow it. Thus the preview could for example have
bigger veritcal spaces arround `<p />` tag than what was seen when
editing.
With this fix instead of invalid:
margin:initial initial initial initial
we have:
margin:initial
And instead of invalid:
margin:initial 5px 6px 7px
we have:
margin-top: initial; margin-right: 5px; margin-bottom: 6px; margin-left: 7px;
opw-706535
When changing of record, through the pager or the breadcrumb, the URL of the iframe
must change, as the model and id of the record is included in the URL
This wasn't done before this revision, and it could
lead to an INTERNAL SERVER ERROR in case of a deletion
followed by the loading of another record: the URL
of the iframe was still set to the former record,
and this URL crashed as the record no longer existed.
e.g.
- Create a new mass mailing, subject 1, add a random block in the content then save
- From this newly created mass mailing, Create a new mass mailing
(directly with the create button)
Subject 2, add a random black in the content and save
- Delete the second mass mailing
- Return in the mass mailing kanban view through the breadcrumb
- Open the mass mailing 1
- You had an internel server error, due to the fact the URL of the iframe
was still the one of the second mass mailing.
opw-710239
In mass mailing there is several possibilities of states when rendering
the widget with a possibly new value:
1. we are not in edition
a. we are in same language than user language => the editor content
can be updated
b. we are in a different language => the content cannot be updated
2. we are in edition
a. we are editing translation : the editor content cannot be updated
b. we are not editing translation (editor language == en_US)
i. we are requesting editor update (by having magic value
`on_change_model_and_list`) => the editor can be updated
ii. we are in same language than user language => the editor content
can be updated
iii. we are in a different language => the editor content cannot be
updated
In summary:
- if language is the same than the user, we can update the value
- if value is magic `on_change_model_and_list` and we are not translating,
we can update the editor
Before this commit, this worked as expected but for 2.a.ii. which if the
user language was not en_US would for example prevent editor updating.
closes#15583closes#15414
opw-708032
inspired by a27e24c6d1
note: the fix is a fix for 9.0 and saas-11 only.
When editing translations, you were not able to copy/paste texts before
this commit. Indeed, in some contexts, in some browsers, copy/pasting
text was creating a new paragraph inside the translation, preventing it
to be saved.
This commit simply adds code to remove these paragraphs each time text
is changed.
A more elegant solution will be found for master with website and
editor improvements.
An italic node would be taken as a basic node containing text and thus
would be merged unexpectedly.
For example with the following content : "<i>hello</i> world" removing a
letter of 'world' would merge the text node with hello making it italic.
opw-703722
In some case (for example the one solved with b51d21c5) we can have
write done on a field text in read only mode.
With 98ed53ce if :
- such a case happened (in b51d21c5 the fix only worked after the given
field was written one time) or a similar instance,
- and the user was in debug mode,
- and the widget used was TextFieldHtmlSimple
this could lead to an issue with the code trying to toggle the code view
mode whilst the editor is closed.
With 98ed53ce when a form view is saved when a html field is in code
view mode, the change is not lost.
This new backend tour check that when saving in or not in code view, the
content is saved effectively.
The test not in code view would ensure issues like #14381#14351#14394
are detected on runbot.
closes#14475
opw-693052
note: the old test system is used so this test is only for up to saas-11
The intended scenario when using the code view is the following:
1) click on code view button to use code view
2) make changes
3) click on code view button to get back to wysiwyg view
4) save from the wysiwyg view
If the 3rd step was not done:
- for the inline editor, we lose the changes that have been done in
code view,
- for the iframe editor, we lose the entirety of the content.
At one time the user was forced to go back to wysiwyg before being able
to save, but this have been removed hence the present usability issue.
With this fix, when the editor content is saved, if the user is in code
view he is automatically set back to wysiwyg view.
fixes#14648closes#14475
opw-678677
opw-693052
When editing the website, adding a gallery, choosing the grid mode
and then adding images, an extra, empty, image was
added to the grid, in the first position, making it looking weird
or at least not aligned.
This was due to the `start` method of the widget, which
is trying to focus the image in the images browser when
you double click on an image (in the big image building block
for instance) and set an image without url in the case
where `o.url` was undefined, and the url of one of the records
was also undefined.
opw-692205
This reverts commit 897290dd3f.
It seems it breaks other use case, since this was fixing more a
usability thing (need to click back on code view to save code view
changes) it is better to revert than to add drawback.
A better fix should be introduced, or the solution would be to not fix
it and have a warning indicating what needs to be done.
opw-693052
The scenario when using the code view is the following :
- click on code view button to use code view
- make changes
- click on code view button to get back to wysiwyg view
- save from the wysiwyg view
If the 3rd step is not done:
- for the inline editor, we lose the changes that have been done in code
view,
- for the iframe editor, we lose the entirety of the content.
At one time the user was forced to go back to wysiwyg before being able
to save, but this have been removed hence the present usability issue.
With this fix, when the editor content is saved, if the user is in code
view he is automatically set back to wysiwyg view.
closes#14339
opw-693052
The widget html is used for plain text and html content.
Need to check if the content is a valid html code, if is not wrap with p tag every lines.
opw-692158
Odoo Translation Bot