In firefox, if we have a range on eg.:
`<input type="file">`
and we tabulate to get to it, we have the range over:
`<button type="button" tabindex="0">Browse…</button>`
which seems to be a "virtual" element inside the `<input/>` but this
magic element is "Restricted" and causes error such as:
`Permission denied to access property "nodeName"`
So this fix ignore errors when getting a range from current selection on
keyup.
opw-1819279
closes#24524
The browser may throw an error when a big mail such as one with
hundreds thousands of tags is being transformed to have a style
more compatible with mail clients.
The error would be:
"Uncaught RangeError: Maximum call stack size exceeded"
This happens in jquery because we hare too many nodes (there is an
ongoing issue at https://github.com./jquery/sizzle/issues/403) so this
commit replace that part by a DFS traversal over DOM nodes.
There was also an issue that not having the option "style-inline" would
still cause some style code to be ran albeit it was intended not to be
solved in 55c7d2d5b0.
opw-1841107
closes#24550
Commit 6494f51171 introduces an access token to read images inside an
email. This avoids access errors when accessing the email through a
proxy (e.g. Gmail). That implies that all images are added as
attachments.
When going through the usual media dialog, the form is submitted to
action '/web_editor/attachment/add', creating the attachment. However,
the copy or the drag and drop of an image completely fails. Indeed,
the same method `_onImageUpload` is called, but with a completely
different argument type: `attachments` is a `FileList`, not a list of
attachments.
To solve this, we only call `_onImageUpload` on a the custom `onUpload`
callback, which is not triggered during a drag and drop or a copy. Any
image included thanks to these methods will be post-processed in the
`create` method of `mail.message` (`base64_to_boundary`).
Unfortunately, it's not possible to simulate an actual drag and drop or
a copy, so we cannot add a test.
opw-1840237
opw-1840411
The copy-paste feature of summernote was messy and led most of the time
to breaking the template you were trying to edit. While it is difficult
to solve as it mostly comes from the lib itself and that the lib is in
a complicated state as Odoo had to overridde part of its internal code
for its own purposes, this commit hopes to solve the problem by updating
only the copy-paste feature to the latest summernote version.
Of course, as summernote changed a lot meanwhile, it was not possible to
just take the up-to-date summernote file. This commit refactores the
up-to-date summernote clipboard code so that it fits the old summernote
version Odoo is using.
Note: the main problems occurred while using Windows/Mac and not Linux.
opw-1837818
In firefox the range when doing CTRL+A is the first level content of the
contenteditable element, but this was not taken into account when
"remembering" the range after clicking on buttons or features of the
editor.
In chrome the selection begin with the first displayed element (so it
may not be a direct child of the editable and is taken into account in
the code).
opw-1824017
closes#24424
The css generates all the attributes separately and not in simplified form.
In order to have a better compatibility we simplify the css tags.
e.g. border-left-style: none; border-bottom-s .... will be simplified in border-style = none
We convert the link.btn into a table to have a good rendering in outlook, and revert the
change when the user edit the content.
Since 11.0, reports could not be edited at all anymore. This is due to
the fact the editor files were refactored but the report feature is not
correctly organized since it was merged with the 'web' app. Indeed, the
'web' app is still calling files and assets of the 'web_editor' app which
is not a dependency (but it is working as 'web_editor' is auto-installed
with 'web').
opw-1826599
opw-1834971
Closes https://github.com/odoo/odoo/issues/24034
The editor is performing text selection check when clicking on the
window. However, when clicking outside the iframe an editor is running
in, a crash may occur as the editor was trying to check a range outside
of its environment (the iframe).
Related to opw-1837818
Before this fix, when a user don't have write access on a document, he
can't send an email with attachment because, the attachments is added on
the document.
The change improving security was introduced by the commit:
https://github.com/odoo/odoo/commit/6494f511718893eec3573c60c0a62e04d386359d
With this fix, for mail, the attachments is added on the
'mail.compose.message' and re-render the fields attachments displayed in
the current view. This change respect the access rules like all others
attachment of 'mail.compose.message' (can send an email when the user have
read access on the document).
The media dialog of the html widget display all documents attachments and
the added attachments Allowing users to use these in the body of their
message.
Inside the cell of a table, indenting had several behaviors:
- if the selection is contained in several nodes elements: indent the
element child nodes of common ancestor
- if the selection is contained in one or more list items: indent these
list items
- if the selection is contained in one 'content block': indent the whole
cell content
The two first behaviors are expected, but the third one is a little odd
and unexpected next to other existing editors behaviors.
With this commit, the third behavior becomes:
- if the selection is contained in one `content block`: indent this
content block
note: 'content block' is defined as p, pre, h1, h2, ..., blockquote, td
opw-1824647
closes#24182
web (tagged with `openerp-web`) translations are loaded in the backend, in
`odoo.addons.web.controllers.main.WebClient.translation(mods=None, lang=None)`
method (through `/web/webclient/translations` controller).
In website, the controller `/website/translations` is called used, fetching
the translations from modules with the (fragile) clause `name ilike 'website'`
This commit fixes two bugs:
1. Install `website_sale`, activate discussion on products
-> the chatter is not translated as the portal translations not loaded in the
`/website/translations` controller
2. Install `helpdesk` but not `website`, go to portal view of a ticket
-> the heldesk chatter is not translated as the `/website/translations`
controller is not called (only provided by the website module)
This patch implements a modular approach to translate the web resources of the
right modules only.
The controller /website/translation is moved to http_routing and each module
override the new _get_translation_frontend_modules_domain method to adds its
translatable module
Closes#23618Fixes#23610
Christophe Simonis