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
An enterprise feature was in conflict with the fullscreen mode of the
editor (see commit https://github.com/odoo/enterprise/commit/125414b73e4d839fc44c445bb83591e84f4c855d which fixes it).
This commit forces this feature to be retriggered when the fullscreen
mode is left (as the feature is now put asleep during the
fullscreen mode).
This should obviously be improved to handle fullscreen mode with a more
robust way.
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
* Tip are never destroyed when change view mode
* unbind methods
* mail: memory leak with unbind methods
* web: memory leak because 'ui-autocomplete' is never destroyed
* web_editor: memory leak for wrong unbind on destroy
* web: memory leak: must remove fileupload handler
* bus: memory leak: correctly debind handlers on window in bus.Bus
* remove handlers on switch buttons and views $buttons
* remove handlers on breadcrumbs
* web: memory leak: correctly debind handlers
* im_odoo_support: memory leak: remove fileupload handler odoo_support
Note: part of this commit was actually authored by aab
There is a hackish feature in the web_editor which forces the
contenteditable to true on links which are clicked and removes it
anywhere else in the page so that only the link is editable after
click. This allows to add text at the end of a link without adding it
outside of the link by mistake.
The feature was badly implemented because, if the link was editable
without having any parent which is editable, the contenteditable was
forced to true, then immediatly forced to false when forcing to false
every page element. This was the case for lots of t-field. By example
the product categories in eCommerce are t-field links which are in non
editable <li/> elements...
The system was lost with the editor refactoring which came with saas-10
and commit bf39884a5c.
Indeed the show() method of the BuildingBlock class was removed as the
widget is now always showed but the show_blocks() method it called was
not removed (and thus was not called anymore).
As a fix, the show_blocks method is now called again, on snippets
initializations and each time a snippet is dropped or removed.
The .dropdown is in a .btn-group environment while a .btn-group can
only contain .btn or .btn-group elements.
This induced problems where the m2o options covers the full overlay
environment, preventing clicks on the customize dropdown.
The snippet options can define an on_remove method which was supposed
to be called when the snippet is removed. This was not the case since
the method was written so that the options were removed before the
on_remove method was called... (Un)fortunately, the on_remove callbacks
were not doing any critical job in current implementation. In saas-13
however, some elements will rely on this.
Before this commit, the focus point the user can move on the image in
the background position configuration dialog was only following the
mouse as we want if the image original width was larger than the dialog
one. This is because the javascript relies on the fact the image takes
100% width of its container. To fix this, the container now does not
take 100% of modal width but the size of its internal image (with a
max-width of 100%).
The call to the web_editor is made through an iframe with some get
parameters. While not really a problem in itself, this has the
disadvantage of generating long URIs. In some case, since all the
fields in the views are included as a GET parameter, URIs can be
generated that go up to several thousand characters. Most servers will
return a 414 for such URIs, preventing the edition of the mail
template in the view.
To avoid this problem, this commit extends the 'html_frame' widget and
blacklist 2 fields that can get too long once encoded.
Ideally, it would probably be better to stop sending all the fields and
simply add the *needed* fields one by one, but since it's difficult to
know exactly what fields might be needed and this is stable, I'm gonna
go with this 'workaround' but conservative fix.
opw-685646
Before commit a8ee18e172, the paragraph alignment dropdown menu was
too large for its content, so it was ugly. After that commit, it became
too small for its content, which is even more ugly.
This fix sets the width of this specific dropdown so that its content
fills exactly in (as with original summernote).
The editor bar is sometimes filled with too many options, and these
hide the save and discard buttons on small screens. To solve the
problem, the description option (which take a lot of space) has now
a max-width and the save and discard buttons are always on top.
The less refactoring in 5b65befcd8
wrongly removed the css directive that hide some elements in edit mode.
As a side effect, the product price was appearing twice when editing a
product. Commit 44ca4317a9 tempt to fix
it but removed the edition part.
opw:683343
Prevent the padding of editor .btn's to change when a theme modifies
them (by mistake or not).
Once again, this is a problem of css isolation between the editor and
the website customization. A theme cannot safely, at this time, do
"#wrapwrap .btn" to isolate its rules because it may override some
bootstrap rules like ".btn-group .btn" which would became less
important. It cannot changes the bootstrap variables either as it is
still used by the odoo ui in some places.
There is no safe good solution to "share" bootstrap theming between
odoo ui and website ui. The safest solution is to force the design
of odoo ui elements that may be overridden by themes (in the end,
it's the same as progressively removing bootstrap from odoo ui).
The editor allows using background image options on snippets which
use a background-image. For this to work, the oe_img_bg css class
has to be on this snippet. The problem is that the class is absent
when using some themes as the select_class method removes it to place
its own value.
Now, the oe_img_bg class is (re)added when a select_class method is
used within the background image option.
The code for page creation from menu edition dialog was there but
invisible to the user because of a wrong qweb template inheritance.
Indeed, the edit menu dialog relies on an extension of the link dialog
template. But this one is extended in-place in another location and
that extension is not considered when the second extension is made
because a t-extend always use the base template. The only solution to
achieve the same result is to copy the edit menu dialog qweb extension
in Javascript.
Note: the feature was still available from the link dialog in page
edition though because this was not concerned by the wrong qweb
extension.
However, adding a page by this way would create multiple pages because
one was created each time a page name was entered (and not only on
save !). So typing "test", then changing its mind and typing "hello",
then rechanging to "test", then hitting the save button created the
"test, "test-1", "test-2" and "hello" pages.
This fix takes advantage of an already present parameter which can
determine if a new page should be created or not. However, a code
refactoring should be done in master for these classes.
This reverts commit f38f8930f0.
Revert for internal choice. Odoo want to use qweb in template and remove jinja support on next version.
If users want to use jinja they can change the view to use text widget instead of html widget.
Christophe Simonis