Commit 3c9e6c89e7 made big changes
to the link dialog.
This commit fixes two bugs it introduced:
* The color class preview was not properly set when opening a dialog
(so changing nothing and saving would change the result)
* New btn color classes were wrongly initialized. It did not use less
generation and made the button text always white. This could
introduce bugs when using different colors in themes.
Note: this code is already being refactored anyway.
Specification
=============
- no boxes around fields
- use regular form style for input fields
- don't split page/URL into two fields, just do one URL field, with autocomplete
- Add alpha, beta, gamma, delta and epsilon color in color selection because they are used in mass mailing and themes also.
- Add a selection option with label "L" inside circle for link.
- Add Color selector for choosing button color
- Remov select2 page selector and used jquery autocomplete on same input
- Fix issue of page search in ir.http
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.
Before this commit, it's was only possible to resize the width
of the ace editor when it was on the right side of the screen.
In studio, we need to put the ace editor on the left.
So, we needed to add a new resize bar.
For that, we also add a new option to know the position of the
ace_editor.
We also prevent the width of the ace editor from being recorded
too many times in the local storage for nothing.
This is why we added _.debounce.
This commit comments the code of the Animation class and allows
for lazy loading of resources before animations' start methods
are called.
This lazy loading can be performed in the willStart method (to use
the same way as in the Widget class).
This commits also removes the "stop" function of the module as it
was not really useful. It was used to restart the animations (by
immediatly calling start again after the stop call). Now the Animation
class contains a restart method and the module "start" function
automatically knows if it has to instanciate an animation or restart
an existing one.
Animation start should only be performed by instanciating an Animation
(thanks to new) or by calling the restart method, to insure the
willStart method is always called. Anyway, the best way to start
animations is to let the system handle them, using the "selector"
attributes in your Animation definitions as before.
See in-code comments for details.
* web_editor, website_portal_sale, website_project,
website_project_issue, website_project_issue_sheet
- Use bootstrap grid the right way (missing row)
- Use table-responsive for website portal tables
- Remove web_editor table layout style if inside a table-responsive
in mobile mode
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 refactoring made with https://github.com/odoo/odoo/commit/62fb1bb92493b00bd45ed3f4eced5ca8b23f81d6#diff-2b3acc31ced2b1e9f7522a3e29f33c22L825
broke the possibility to add vimeo, youku or other undefined video
sources.
This is because of jQuery. With jQuery you can create elements thanks to
multiple methods. From least efficient to most efficient:
- All in a string:
$("<tag attr1='value1' attr2='value2'/>");
- Tag in a string, attrs thanks to methods:
$("<tag/>").attr("attr1", "value1").attr("attr2", "value2");
- Tag in a string, attrs in second arg:
$("<tag/>", {attr1: "value1", attr2: "value2"});
The mentionned refactoring transformed the use of the second method
into the use of the last one. But there is a bug in jQuery: you cannot
use the first method and the last one all together. So:
$("<tag attr1='value1'/>", {attr2: "value2"});
will create a tag with attr1 but will totally ignore the attr2 part.
It happens that the allowfullscreen attr was left directly in the
creation string for vimeo and youku, preventing the src to be added.
This commit removes the use of allowfullscreen attr as fullscreen
is already handled by source players anyway.
qsm-odoo