| Age | Commit message (Collapse) | Author |
|---|
|
For the ours need, we can not let the contentEditable behavior. Indeed,
this one does not have the same behavior according to the browser. The
DOM node could be erase, merge, cut, in them according to the keyboard
interactions. The problem is that if we have to manage these behaviors,
we have to manage everything. It was already the case in the previous
version, however before we created an editor by zone and by a hack we
mix the history.
In the case of the virtual keyboard of some OS / Phone, the events are
different and the autocompletion does not update (bug that prevents
modification interactions with javascript). In order to solve these
problems, we use another event for the insertion of the characters.
However, we must also force the update of the corrector by forcing a blur
and a focus.
The current version is a temporary version. We are currently working on a
version that uses a virtual dom and does not need to do excessive prevent
default.
|
|
closes odoo/odoo#35539
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
For some Chome version (e.g. 74 chrome verion on Debian) the iframe
trigger 'load' event twice (one time for document and on time for body),
the widget must insert the content in the body. Before this fix, the
content are add only one time and are removed by the next iframe loading.
closes odoo/odoo#33561
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
|
|
|
|
Previously, when user edited record having 'field_html' widget and
tried to save the record immediately, a traceback was faced sometimes
because content was not loaded yet. This commit fixes the issue
by calling super method if the content is not loaded yet properly.
Task: #1932687
Closes: #30833
closes odoo/odoo#31581
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
|
|
closes odoo/odoo#31790
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
Issue: wysiwyg asset slow down the loading of the website, error
inadvertently introduced: https://github.com/odoo/odoo/pull/29775
The assets are now loaded assynchroneously, when the editor is needed,
its assets will be loaded.
closes odoo/odoo#30700
|
|
- while clicking on send now button in mass mailing app it throws error due to wysiwyg undefined.
closes odoo/odoo#30533
|
|
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
|
|
The refactoring of the wysiwyg editor and 'html' field allows us to
move some of the code that was in web_editor but only used in website or
in mass_mailing. Some parts are still in web_editor but will be
moved at a later time.
|
|
|
|
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
In 10.0 this was not necessary since the default values were sanely set
when the editor was inside the DOM. In 11.0 the editor is not in the DOM
when this is being done and the info was wrong (eg. NaN for text size).
With this commit, we don't steal the focus and get the default like it
was done in 10.0 instead.
fixes #26366
opw-1874880
closes #26582
|
|
|
|
Before this fix, the attachments are don't save to the record and are
remove with the wizard. We can't add the attachments to mail.message
(like 'mail.compose.message') because it's auto_delete/unlink and the
attachments are removed before the recipient can read it.
|
|
|
|
Before this fix attachmentThumbnailToLinkImg is not called for
style-inline options. The mail received does not have thumbnail and the
user can't click on the invisible link.
opw-1863659
|
|
|
|
Commit 6494f511718 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
|
|
|
|
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.
|
|
The goal of this commit is to allow fast entry of the same model using
the keyboard for navigating through the form once, by blocking the user
from advancing in the form if there is a required field or once they
went through the form once to get them to a primary action (button)
This commit includes the following changes
1) Enable moving forward from field to field using the TAB key
2) Entering the one to many and many to many using the TAB key
a. When entering it, set the focus on the "add new line" link or
button
b. When adding a new line, set the focus on the field visible
editable field of the new line
c. Discard adding a new line with ESC key
d. If the user leaves the first field empty and uses TAB, we
will cancel the adding of a new line and move to the next
field of the form
3) When a field is required and not filled in, do not allow the user
to move out of the field using the TAB key (the user is still
allowed to use the mouse though), mark the field as invalid
instead
4) After going though the form once, using the TAB key on the last
field will move the focus to the first primary button of the page
5) When the focus is on a primary button (EDIT/SAVE), the user cannot
move the focus forward using the TAB key. Hitting TAB again will
display a tooltip telling to hit ENTER to activate the button.
The mouse is still available to move the focus.
6) When the user saves, the focus is placed on the first primary
button of the form renderer (like VALIDATE for a new invoice)
7) On dialogs, primary buttons should stop the users from moving out
of them, and showing a popup if the user tries
8) When closing a dialog, the focus will be moved back to the widget
that opened it.
This commit does not include the following features
1) Navigation with the keyboard on a selection one to man
2) Navigate between tabs in a form using the keyboard
3) Cancelling the adding of a new line in a many to many using the
ESC key do not set the focus correctly
4) Enhancing the focusses fields (like blue underline)
|
|
|
|
The access_token is automatically added by the media editor. It's added
on the website and by the html editor to send by email. The widget display
the attachments from 'ir.ui.view' (public attachment) and the attachment
from the current record.
Issue: can't load image in gmail or mobile because the client mail use a
proxy who avoid ours odoo access.
|
|
|
|
|
|
|
|
|
|
- Open Point of Sale > Configuration > Point of Sale
- Edit, change anything
- Save
- Crash
|
|
* website_forum
Summernote is instantiated as a simple text editor for 'simple' HTML
backend fields and in website_forum. In those cases, the user was not
able to open editor dialogs anymore as their opening was now handled
by the RTE widget in web_editor since the recent website refactoring.
The goal was to use `this._rpc` in these dialogs (and this required the
dialogs to be attached to the widget parenting system).
As a fix, a new component was implemented to handle these dialog
openings and this component is thus created by the RTE widget and the
other places that need the feature. The right fix would be a better
integration of the summernote editor in the parenting system but this
requires a lot more work than this commit, this will be the goal of the
future editor refactoring.
|
|
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
|
|
|
