| Age | Commit message (Collapse) | Author |
|---|
|
*: web_editor
It prevents user writing in the image preview of products.
Also, the product image view now fit its container so that the user can
click wherever in the frame to change the picture.
Part of https://github.com/odoo/odoo/pull/65575
task-2446852
closes odoo/odoo#65575
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Issue
- Runbot 13.0
- Website > Contact Form
- Double click on send button
Link dialog opened, ok
- Discard
- Double click on send button
- Click link button
Traceback
Cause
The next double click doesn't work
because in rte.js RTEWidget._onMousedown
we remove the target's contenteditable
attribute and it's never added back.
This is because we break if the element
is not editable.
The traceback is a side effect,
since we can't select the button
anymore, our selection is incorrect
and getLinkInfo use range.create()
try to use it.
Solution
Break only if the target is not
a '<a>' & non-editable element
OPW-2268595
closes odoo/odoo#54221
X-original-commit: 460bc102d0f7503207fb7bd11216c335795dd33b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
|
|
*: website, mass_mailing
In continuity with the nline crop, in an effort to make the image
workflow as seamless as possible in the website editor, the image
optimization feature has been moved out of the modal which could be
opened through the media-dialog and into the left panel.
This commit adds a quality slider and a width selector, as well as a
preview of the image's weight to the left panel, and removes the
image_optimize dialog.
This commit also introduces the possibility to add a color filter on
images.
Part of https://github.com/odoo/odoo/pull/51517
task-2192755
closes odoo/odoo#51517
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
An error has been introduced by [1]. Indeed `response.data` does not
exist, but `response.message.data` does. However, the whole `if` clause
there seems now useless so this commit removes it. The whole file is
being refactored anyway with the new editor.
[1]: https://github.com/odoo/odoo/commit/ab4000fb3cf8fa54ba714ceceec391b78d73755e#diff-b1b550326b2d36a24e94e52c3901d1fbL513
closes odoo/odoo#52534
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
*: website, web
Move the colorpicker dialog logic into a colorpicker *widget*, which the
colorpicker dialog will now instantiate.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
|
|
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closes odoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
The content of the "wysiwyg.fonts" module is duplicated in
"web_editor.base". This is a mistake that was introduced with the
revert of the saas-12.2 editor.
This duplication is the cause of github issue https://github.com/odoo/odoo/issues/44689.
This commit fixes the issue by requiring the correct module in rte.
closes odoo/odoo#46865
X-original-commit: 8bc3fd2c41c1d0fc1fa22e0849a7204b6712d7b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Revert of old editor (35b6182) has reintroduce code invalid.
Now the data is wrapped in message (f8fe314e7)
Remove guarded that raise a warning, it is the default behavior now.
closes odoo/odoo#46870
X-original-commit: 9d3a2903fd7bf946c033ec78e959e3ed86754845
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Before d00c0e317, `Datetime` fields would be editable in frontend but would
have unexpected results, especially in non-English languages, for when the
english lang format had been changed.
It would also crash when saving non-English strings, such as `Lundi`.
For more details, see https://github.com/odoo/odoo/pull/44484#issuecomment-586850490
Since d00c0e317, only date displayed in lang format would be editable, which
case is Event page in Odoo 12.0. Everywhere else, the format is changed for a
nicer layout, either with `widget=XXX` or `t-options=YYY`, such as:
`<time t-field="record.date" t-options='{"format": "MMM d, yyyy"}'/>`
`<time t-field="record.date" t-options="{'time_only': 'true', 'format': 'short'}"/>`
When a date parsing crashes during editor save, the problem is not only that
the date can be saved, but the whole changes of the page are lost, as they
won't be saved either.
This commit attempts to fix every languages cases, regardless of the website
lang or user lang.
To do so, we store the date in the user lang format in a data attribute of
every date field in the DOM. Once the field is clicked (to edit probably),
that value will replace the one displayed according to the widget/options.
That way, dates will always be sent to the server in the user lang format,
avoiding any possible mismatch.
This whole fix apply to `Datetime` and `Date` fields.
opw-2183055
Closes #44484
Closes #45555
Fixes #44047
closes odoo/odoo#45725
closes odoo/odoo#45997
X-original-commit: c0db9bb8027ff926c619aebe6e0a5cdd05808232
Original-signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
|
|
The edition of the submit button's text was broken.
Part of https://github.com/odoo/odoo/pull/44907
closes odoo/odoo#45124
X-original-commit: 85966ac29b53d9e1c2ad1efb2c35ab13c9baae89
Related: odoo/enterprise#8360
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Some elements like the file input are not compatible with selection.
Since there is no reliable way of figuring out if the element is
compatible or not we will simply try catch it.
closes odoo/odoo#44470
X-original-commit: 1f0a0b380c2738795b0b5a7976692d9e9cd88583
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
* website_event
Commit https://github.com/odoo/odoo/commit/a153ed42a09f8b7f5e0865112eb7d5affc22a353
solved a big problem which was that when an undo/redo is performed, the
whole DOM was reconstructed breaking all the JS relying on the old one.
For example, the latest blog posts which are dynamically loaded in JS
were not removed before saving since the JS relied on the old DOM... and
this broke the page because that dynamic content contained non-valid
XML markup. The solution was to destroy all JS widgets before applying
an undo/redo and rebuilding them all afterwards. Ideally this operation
should be done on the undo recording action but this would have a huge
flickering impact since many DOM would be destroyed each time the user
types text (flickering which is also bad on undo/redo but it is more
acceptable).
The problem now is the following: if a widget, like many, is declared
like this:
```
start: function () {
this.$el.append(/* Some dynamic content on page loading */);
},
destroy: function () {
this.$el.find(/* Dynamic content to remove */).remove();
},
```
Then it works in all standard cases: dynamic content is loaded on page
load and is removed when saving the editor. But this happens with the
undo/redo system:
1. The users types text, we record an undo, which is the whole page
current DOM, containing all the dynamic contents.
2. The users hits CTRL-Z:
a. We destroy all JS widgets, calling destroy, the dynamic content
is removed from the page.
b. We replace the whole DOM with the one that was saved. That one
contains the dynamic content DOM.
c. The JS widgets are recreated, calling start... creating the
dynamic content again.
Result: the dynamic content appears duplicated. On save, depending on
how the destroy was implemented only the last generated content may be
removed or both... but in any case it appears duplicated during edition.
Hopefully, our current stable version do not contain that many dynamic
content so a perfect amelioration of all of this can be found in master.
As a fix, this commit introduces an extra step between (a) and (b):
we remove the dynamic content of the DOM-to-re-apply before applying it.
For this to work, widgets have to mark their dynamic content with the
class 'o_temp_auto_element' when creating it. They also must add the
content they replace on the 'data-temp-auto-element-original-content'
attribute.
closes odoo/odoo#44025
X-original-commit: f0d2559afd3094f6fbd7e6788f7c10fa421c9080
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
* website
Review colorpicker methods to always allow to use normalized colors.
Also factorize some code in the color palette widget.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
|
|
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
|
|
The issue here is, for modal dialogs (eg newsletter popup), when we close
the dialog, the modal is destroyed and so after the delayed execution due to
timeout, the dialog will not be available and it will generate the issue.
removed delayed execution for the traceback, which is relevant to
the modal dialogs.
task-2075232
closes odoo/odoo#38914
X-original-commit: 93deb25f873f5c4aba239b050e543b23685f5ba0
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
|
|
closes odoo/odoo#37079
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
|
|
* web_editor, website
Editing the cover images or sizes was not working anymore. When it
worked, it was thanks to the 'o_dirty' class appearing magically on a
cover part... and that magic seems to be gone.
This commit fixes the problem by adding the 'o_dirty' class on all
elements whose content is changed, not only the editable ones (this is
the case for the blog cover: it is a non editable element whose bg
image can be changed).
Note: this also fixes the edition of multiple covers (of different blogs
or posts) at the same time (this could be backported in 12.0 if needed).
closes odoo/odoo#36999
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
The wysiwyg abstraction layer was introduced in saas-12.2 by
commit f2969923. Its goal was to provide an external interface
for other modules that wanted to use the editor feature such
that the editor core itself could be changed without requiring
extensive changes in the other modules.
This commit is adapting the wysiwyg interface to instantiate
the 12.0 editor below it rather than the saas-12.2 one, thus
reverting the "new editor" part of f2969923 itself.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
|
|
This commit reverts the saas-12.2 editor by putting back the editor
of Odoo 12.
The saas-12.2 editor was an intermediate work between the previous
editor of Odoo 12 and the new one slated for Odoo 13. It was unstable
but it was supposed to be replaced by the new editor of version 13.
However, since the new editor has been postponed to Odoo 14, the
saas-12.2 one would have been staying in Odoo 13, which would have
been a nightmare to maintain. To avoid this outcome, we chose to
put back the 12.0 editor in its place.
This has the particular advantage that Odoo 13 will share the same
bugfixes as Odoo 12 and 11 as they all run under the same core
editor, while the saas-12.2 one would have been an entirely
different beast to maintain.
This is a partial revert of f2969923.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
|
|
* 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>
|
|
|
|
|
|
* web_editor
When an user saves its website, all the animations are destroyed so that
a clean DOM is saved. This is particularly important for snippets like
the latest post one that would crash the page if not cleaned before
saving.
Two cases were found where animations were not cleaned before saving and
this is what this commit fixes:
- When an user used the undo/redo system, all animations were lost as
the DOM is recreated.
- When an user duplicated a snippet, animations were not restarted on
the cloned element.
closes odoo/odoo#29159
|
|
|
|
|
|
|
|
With https://github.com/odoo/odoo/commit/55131b8f5becdd3d4776f4c3e7e4288a0b185706,
we automatically add the known editor context (containing lang,
website_id, etc) when using the `this._rpc` method. Some RPCs needed
however to explicitely not send a value from this automatic context...
but this was not correctly implemented. This can now be achieved by
using the `noContextKeys` key in the `this._rpc`'s *options* parameter.
closes odoo/odoo#28322
|
|
What was designed as a new feature appeared as a regression: users were
not able to choose a bootstrap gray as a background color anymore but
instead got the possibiility to choose a hardcoded gray. This commit
restores the use of the custom gray palette that themes can customize
and which automatically uses the correct text color when used as a
background. This also allows to remove ugly inline style from snippet
definitions and allows to solve bugs like the described below one:
---------------------------------------
Also add bg-* classes on snippet cards:
---------------------------------------
Snippet cards are often put (or may be put by the user) in an element
which have a bg-* class on it. This means that the card will still have
a white background (as chosen by BS4 by default) but the text color will
be adapted to that ancestor bg-* classed element.
This commit forces the card background color (as suggested by BS4) with
bg-* classes.
closes odoo/odoo#27637
|
|
* web_editor, website_blog, website_crm_partner_assign, website_links,
website_livechat, website_mail_channel, website_mass_mailing,
website_slides
Calling a model's method thanks to an RPC will now always send the
web_editor context automatically, making sure the method gets the
website_id all the time, removing the need to guess the current website
(now the get_current_website method uses the context website_id if any).
Note: other routes already have the website_id via request.env.context
if they correctly set website=True (this commit also adds website=True
for scss files customization routes).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
create range method slow down all the web client because the handler who
use this method it's in the module (not in the widget method) and called
for each click and keyup. We need only this handler for the iframe or the
website, used by the rte.
|
|
|
|
Forward-port https://github.com/odoo/odoo/commit/f5e7b866860436782ade53308da1ff725be1f124
failed for commit https://github.com/odoo/odoo/commit/78a556601e6b1e72c6d1ac776e31588dd2ffa28f
|
|
|
|
It seems that firefox has some difference of behavior from other
browsers as said in:
- https://bugzilla.mozilla.org/show_bug.cgi?id=548397
- https://github.com/whatwg/html/issues/1813
- https://github.com/w3c/csswg-drafts/issues/571
It seems that at least in one instance (a html field hidden on the pos
configuration), firefox fails because of something similar:
window.getComputedStyle(element) returns `null` instead of the element
styles.
In my tests, using the parent window (possible if current frame and
parent have the same origin which should be the case) worked in this
instance, this is examplified by this jsfiddle:
https://jsfiddle.net/Lpv898ve/2/
This work with window.parent and not using window directly.
So this commit adds fallback on doing getComputedStyle from the parent
window (when testing on chromium this gave exactly the same result that
before).
opw-813363
fixes #22211
closes #22610
|
|
|
|
|
|
|
|
* blog, gengo, sale
|
|
|
|
event variable has been renamed to ev in 11.0 and the code was
duplicated.
|
|
|
|
Before this commit, (double) clicking an image/link in a non editable
environment still opened a dialog / change the editor bar for edition.
|
