While working in the current state of the website configuration, the
overlay computation was not working anymore in case the scrollbar is
moved out of the wrapwrap. Indeed, in that case, the position was wrong
by the amount of the page scrolling.
While we could include that scrolling value in the equation, this commit
chooses to restore the way it worked before the "website-in-backend"
merge at [1]: making the overlay be naturally positioned according to
the page scrolling wherever the scrollbar is. To do that, the overlay
had to be moved inside the content (the website iframe) which has the
disadvantage of risking the overlay design being broken by a theme. This
solution was chosen as it simplifies the code, and potentially allows
for performance improvements in the future: not forcing a position
recompute after each scroll (the animation should already be smoother /
more performant this way). This will actually be needed for another fix
/ improvement: the background image overlay has to be in the iframe too.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102785
X-original-commit: 872bb20b3ac08cf82613e15e6634a2e7593ccf7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `scrollTo` method and related utils (jQuery animate, ...) were not
properly adapted to work in the context of multiple documents. E.g. the
website editor code (outside the website iframe) is calling the
`scrollTo` util to scroll to added snippet elements (inside the website
iframe). In that case, the util was performing some searches in the DOM
outside of the website iframe while it was meant to be done inside. The
result was that the scroll was not considering the website fixed navbar
and scrolled "too far".
Another bug is visible only when the scrollbar is left to be the natural
browser one (not on the `#wrapwrap`). In that case, the `scrollTo` util
simply had no effect anymore as the `animate` override of jQuery was not
adapted.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
X-original-commit: ab417de98068afaaa12995726c7c6445f075ca4f
Part-of: odoo/odoo#102785
Due to the 'transform: none' applied on images and icons on mobile, some
animations do not work in mobile. This commit makes an exception to this
rule for animated images/icons.
task-2984828
closesodoo/odoo#102713
X-original-commit: 78098b3db96e796ae6a09bd0f4bec1eb0c384d28
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the autocomplete dropdown no longer had a maximum
height, which meant that when it contained a lot of elements, it hid the
entire editor panel.
Indeed, since the CSS of the menu snippet is no longer that of the
"frontend", the 'max-height' CSS rule defined for the autocomplete
dropdown in the frontend (introduced by this commit: [1]) was no longer
applied on the autocomplete dropdown of the backend.
In this commit, we therefore moved this css code of the
'ui-autocomplete' defined for the frontend into the common css file
(backend + frontend) in order to return to a situation where this code
was applied to all autocomplete dropdowns in Website. And thanks to
that, we were able to remove the css file "edit_menu.scss" which
copied/pasted the frontend 'ui-autocomplete' code for only one of the
backend 'ui-autocomplete'.
[1]: https://github.com/odoo/odoo/commit/032dd007157de00b683a9d753aa929741c107c01
task-2900529
closesodoo/odoo#102719
X-original-commit: cce26d7697c73326e0a6f2ec81e01b56b4156ad4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Allow the mail templates to activate the dynamic placeholder
like in mass_mailing.
task-2978722
closesodoo/odoo#102603
X-original-commit: f98c472a6d3cd79c28b7b91bdc8359c45c4d3c7a
Related: odoo/enterprise#32484
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Ensure the wysiwyg.js focus() method will actually
restore the cursor in the latest selection inside the editor.
X-original-commit: 54877ecd8bf2454a7023e74aa739921e1468dad8
Part-of: odoo/odoo#102603
Add missing feature of the ModelFieldSelector popover :
* keyboard navigation
* additional debug value
* add default value page ( for dynamic placeholder)
* add validate callback
Migrate dynamic placeholder to be compatible with new OWL field.
task-2978722
X-original-commit: 929108e29168058fad5da85e0ff9c66d2c5b2525
Part-of: odoo/odoo#102603
In [1], the resizing and the drag and drop of a grid item both put
it in front of all the other items and in front of the background grid
(thanks to the `z-index` property).
This commit changes that behavior: now, the grid item stays at the same
z-index if we are resizing it or if we are dragging it over the grid
from which it is coming. In the case of a drag over an other grid, it
is placed in front of all its grid items. In all these cases, the grid
item is placed behind the background grid.
[1]: https://github.com/odoo/odoo/pull/93144
task-2973198
closesodoo/odoo#102525
X-original-commit: 67d1b078329600efce414974307d74e9fa9ba9fe
Related: odoo/design-themes#601
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In grid mode, when a grid item width is one (grid) column, if its
content is bigger than a column size, it makes the column
grow with it while the other ones are shrinking.
This issue was solved in [1] by using the `word-break` property but it
is not the best solution. This commit fixes the issue by setting the
`min-width` property to 0 instead.
[1]: https://github.com/odoo/odoo/pull/93144
task-2973198
X-original-commit: 5d37ada861bf5de348de54d5d7de0d06e14ed28e
Part-of: odoo/odoo#102525
When the footer has the "Slide Hover" and the "Shadow" scroll effects,
and if it is in grid mode, the grid dropzone flickers a lot when we
drag a column over it. This happens because the scrolls caused by the
dragging, the growth of the grid and the scroll effect all happens at
the same time.
This commit removes temporarily the scroll effect of the footer during
the drag and drop to avoid this situation. It also has the advantage of
displaying the footer entirely, making it easier to see where we are
placing the elements.
task-2973198
X-original-commit: bbde919634aeaffcf421283445e25181a522f287
Part-of: odoo/odoo#102525
When going from a dropzone to an other, and if it is done really fast
or if the dropzones are really close (glued to each other) or if they
are overlapping, the order of the "over" and "out" dropzone events is
not the one expected.
Indeed, instead of having over > out > over, we have over > over > out.
This resulted in a traceback when using the grid as the listeners and
properties were therefore not removed correctly when such a case
happened.
This commit adds the support for this situation by first detecting if
two "over" are following each other and then making a virtual "out" if
this is the case.
task-2973198
X-original-commit: c6886410603a16b6a3c5fe459d273dd883c110c7
Part-of: odoo/odoo#102525
When removing all the columns of a block with no parent, like the
footer, a traceback was appearing because updateUIVisibility was trying
to access the properties of an inexisting parent. This commit
fixes that by first checking if the parent exists.
task-2973198
X-original-commit: 3e7ad08581295af6a986ba2b81ec25d9cd78e91d
Part-of: odoo/odoo#102525
When dragging a grid item downwards in a grid, an infinite number of
rows can be added. This is unconvenient because it is difficult to
escape a grid if the snippet is "container-fluid" for example.
This commit limits the number of rows that can be added at once when
dragging downwards. The limit is fixed to 10 rows. Of course, it is not
a total limit, this means that after dropping, if the grid item is
dragged again, 10 additional rows can be added.
task-2973198
X-original-commit: 888f522aa812136f10af1c5fad8f17eea0c3b5b6
Part-of: odoo/odoo#102525
When dragging a grid item and dropping it outside (near) a dropzone,
and then undoing the operation, the grid item didn't return to its
original state: some removed classes and style properties were not
added back. This would cause the item to be broken and trying to drag
it had unexpected results that could even lead to a traceback.
This behavior was caused by the fact that the grid item was not
attached to any element when these attributes were modified, so the
changes happened "nowhere". This commit fixes that.
task-2973198
X-original-commit: 83c07fcce898225f06f1ba84059a031409db0627
Part-of: odoo/odoo#102525
Currently, the toggle to grid mode is not the same process for all
snippets: some have both the option 'Layout Grid/Cols' and the ability
to toggle on drag but other don't have the option, making it
complicated/impossible to leave the grid mode. Also, the snippets for
which the grid mode has been blocked don't have their move handle
anymore, which prevents them to use the normal drag and drop (it was
hidden because dragging them would toggle the grid mode).
This commit uniformizes the grid mode for all snippets and adds the
move handle back to the ones that cannot use this mode. It also
improves the grid mode of the 'Items' and 'Carousel' snippets.
More precisely:
- All the snippets that are allowed to have the grid mode now have both
the option "Layout Grid/Cols" and the ability to toggle on drag.
- The snippets who cannot toggle the grid mode have the move handle
back but it doesn't toggle on drag and they don't have the option. They
use the "normal" drag and drop.
- The drag and drop has been improved to allow normal columns to go
inside the grids. Indeed, since the drag was previously blocked, this
case could not occur but now that it is possible, it had to be taken
into account.
- The grid mode of the Items snippet has been improved by removing the
"hardcoded" height that was breaking the grid.
- The vertical dropzones of Carousel appearing when dragging inner
content have been removed because they appeared in grid mode and were
breaking it. It is also more logical because now that this snippet has
a column option, vertical dropzones should only appear when dragging a
column.
task-2973198
X-original-commit: 84d684d8bdf43d3db11defd8174dee44775085c2
Part-of: odoo/odoo#102525
The 'Picture', 'References' and 'Pricelist' snippets have some of their
content placed outside the row element, causing them to not be in the
grid when activating the grid mode, which is unconvenient.
This commit allows these contents to be placed in the grid when the
grid mode is toggled, by creating a column and putting them in it.
task-2973198
X-original-commit: 6f3041f9015c50b4986b3c26aad86da4a0a04d50
Part-of: odoo/odoo#102525
*: website
In grid mode, the images take the whole space in their column so they
always have the same size as them. However, if text was added in the
column (before or after toggle), it always looked like it was
overflowing and the overlay would not cover it even after resizing.
Also, since these images have the value of the `object-fit` property
set to `cover`, the images are cut if they are too big for the column.
This is problematic if the image has a shape because the shape is cut
too, ruining the visual effect.
This commit solves these issues by distinguishing the images that are
alone in their column from those that are not. An image is considered
alone if it is a direct child of the column and if there is no text in
it (the line breaks and empty lines are excluded). Now, only this kind
of images, if they have no shape, take the whole space in the column
and have `object-fit` set to `cover`; the other ones behave like the
columns in normal mode.
This distinction also allows to block the edition of the columns
containing only an image. Indeed, adding text or dropping inner content
in them had the same overflowing effect.
task-2973198
X-original-commit: e9c7e020daf88022d6e02de0a5620074e8417b5a
Part-of: odoo/odoo#102525
The grid mode allows some snippets to move and resize their columns in
a grid. However, some of them were blocked because they don't look good
in this mode. This is the case of the Big Boxes snippet: because it
contains two blocks full of padding and since toggling the grid mode
removes this padding, it ended looking weird.
This commit allows the previously blocked Big Boxes snippet to toggle
the grid mode. More generally, this commit allows snippets having only
columns containing a background color to look good in grid mode by
keeping a more logical padding for them.
task-2973198
X-original-commit: a051922f8359178f4abe578ce9555d34cbb02613
Part-of: odoo/odoo#102525
The merge of [1] happened before its code was totally cleaned. This
commit makes up for that: the variables have been correctly renamed,
the comments have been cut at 80 characters and useless blank lines
have been removed.
[1]: https://github.com/odoo/odoo/pull/93144
task-2973198
X-original-commit: 98741204c7b15cadeb22d6b536b0027327ba69fe
Part-of: odoo/odoo#102525
Before this commit, the html2canvas library was loaded in the
assets_common bundle, which is in turn loaded by pretty much all odoo
users.
Since it is a big library, and it is only used in two different cases,
it makes sense to lazy load it. The call in convert_inline.js has been
adapted. It is however also added to the point of sale bundle, and
could probably be lazy loaded as well.
closesodoo/odoo#102490
X-original-commit: 3d94b0212d2b7f4d412a578055de42e3f88058eb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, for the following flow:
- Add arabic language (or any other rtl language),
- On one of the websites, set it as the only website's language,
- Reload and go to the client action,
=> The frontend is correctly displayed in rtl,
- Click on edit,
=> The frontend, in the iframe, is reverted to ltr,
The WysiwygAdapter, introduced in [1], was not passing the correct
direction option to the OdooEditor, which would revert the editable to
the default 'ltr' direction.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
X-original-commit: 2f463ca65b149122c85a04b20b4f82e0be479fc8
Part-of: odoo/odoo#101972
This [first commit] removes the addition and removal of classes on the
color picker preview. So far so good, then this [other commit] puts back
the class addition but forgets the removal so the preview of the color
picker widget kept the old values when they were `bg-*` which could lead
to a bad preview of the selected color. This commit fixes that by
removing the old values when a new value is set.
Steps to reproduce the bug fixed by this commit:
- Go to the website app
- Edit a page
- Drop a Picture block
- Change the background color of the block to bg-black for example
- Change again the background color of the block to a custom color
=> The preview of the custom color is not correct, it is still black.
[first commit]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
[other commit]: https://github.com/odoo/odoo/commit/a396f791da94d064d58cce15892e74f45d29b7b7
task-2904507
closesodoo/odoo#101828
X-original-commit: 6da33797798e6112e0dd74a4093f296b6e1b2466
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit fixes three issues regarding the top left search input of the
Media Dialog.
First, following this flow from the website builder:
- Start the Media Dialog with no images,
=> A visual indication to guide you to use the search input is there
- Type a search query in the top left search input,
- Erase completely the search query,
=> The visual indication is not displayed again.
When [1] reworked the Media Dialog with components, it wrongly
defined the ImageSelector web_unsplash patch to load unsplash images: if
there was no query string, the state.isFetchingUnsplash variable was set
to true and never to false, therefore the component was acting as if
there was still some fetching in progress.
Secondly, pressing 'enter' when the input was focused would trigger a
reload of the window. This was due to an obscure html spec described in
[2]: "When there is only one single-line text input field in a form, the
user agent should accept Enter in that field as a request to submit the
form."
When [3] reworked the design of the Media Dialog, it added a t-if on the
second "url" input, making the form with a single input.
This commit fixes this wrong behaviour by using div elements instead of
forms.
Lastly, [3] also removed the position-fixed on the loading images,
which was preventing to modify the container height before resizing
them. This led to visual glitches before seeing the resized images. This
commit adds back this class to prevent that visual glitch.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2
[3]: https://github.com/odoo/odoo/commit/ff0b2d441252560a076a3609d81c369f0ce42d19
task-2687506
closesodoo/odoo#101788
X-original-commit: 8ce4036364de2d65921962357b11d905ca3676e0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
Since [1] when BS5 was introduced, vertical dropzones sometimes push row
children to the next row.
This commit removes the padding of the vertical dropzones, that was
introduced by BS5 because they most of the time are direct children of
.row elements.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2993565
closesodoo/odoo#101824
X-original-commit: 7d4cde7d2813284624ed3c651a3bd10df76ea999
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This reverts commit 3a7349d02b6b667c890af2f197a3640d875b804e.
This toolbar being more accessible in mobile (scrolling to access all
the buttons), sadly it broke the toolbar's dropdown...
closesodoo/odoo#101766
X-original-commit: 253152d93f381ba0e55787818294aaee24383e0a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit solves an issue detailed below, where an action would be
scheduled while the page is meant to be reloaded, creating a deadlock.
Commit [1] reviewed the hamburger option and introduced a hack so that
if the no-hamburger option is selected while a template which requires
a hamburger is also selected, the option for the default hamburger is
automatically selected.
This is done with a hack that clicks on a button when the ui of the
option is updated. The issue is that the click creates a subsequent ui
update, and since the value will only be updated once the page reloads,
a second click occurs, which triggers a second save request.
With [2] that save request locks the editor because the wysiwyg_adapter
does not expect a second save_request, and starts a second blockUI which
is never removed once the iframe is reloaded.
This commit ensures that the auto-update click happens only once.
Steps to reproduce:
- Edit your website
- Click on the navbar
- Select the Mobile Menu option "Same as desktop"
- Change the header template for one with a hamburger menu
- Click on the navbar => the editor is locked forever.
[1]: https://github.com/odoo/odoo/commit/6854ff8026999a2de20d163ff7118a59c33064c8
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
X-original-commit: 15dc96bdf626940b3493e02998f9534d9f393a70
Part-of: odoo/odoo#101687
Commit [1] moved the switchable views inside a SnippetOption. The
implementation of that ended up creating empty page options
SnippetEditors displayed on every page.
This commit makes sure that if a SnippetEditor doesn't have any options,
it is not displayed.
[1]: https://github.com/odoo/odoo/commit/69af7dcfeb3ff95c40b00ef0cc7c5c0e4021f9d2
task-2687506
X-original-commit: 39d073ccafddf4b3fbe9ec9f5f11849d77c9bdaa
Part-of: odoo/odoo#101687
This commit fixes the issue where the undo of the resizing of an
element is not done in one step.
Steps to reproduce:
- drop a snippet (like text-image)
- resize the image
- undo
=> you have to click multiple times before going back to the initial
size.
task-2968749
closesodoo/odoo#101693
X-original-commit: c4b8a2a6a7548e8a81d1ded58e6bc0e309b02975
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
DOMPurify.sanitize removes an attribute that contains a ">" for security
reasons. Make an exception for `data-behavior-props`.
That exception allows Embedded views in Knowledge to store a JSON object
containing the act_window data used to render it as an attribute of the
HTMLElement where it is supposed to be rendered (The view contents are
not saved in the html_field value).
More generally, data-behavior-props should be used when storing properties for a
Behavior Component (see Knowledge module) is required.
Prepares Task-2796156
Prepares odoo/enterprise#29423
X-original-commit: aeb9df5247a3936b1397d8056c1725a1de660b6a
Part-of: odoo/odoo#101694
Add a custom class in web_editor to prevent the selection in an embedded view
(or another bloc using that class) from being moved out in multiple situations.
(onselectionchange, onkeyup, onmouseup, ...).
This is related to the block being contentEditable=False.
Prepares Task-2796156
Prepares odoo/enterprise#29423
X-original-commit: 86c14110294c5ff986ee88bb010dbc7513bf8b01
Part-of: odoo/odoo#101694
Purpose
Allow users to copy/paste specific elements that are generated by Odoo instead
of sanitizing it on paste. It allows to keep structured data in DOM.
Prepares Task-2796156
Prepares odoo/enterprise#29423
X-original-commit: 36ed4db2b378543d51e6e3eb03962707dbf15b1d
Part-of: odoo/odoo#101694
Imported unsplash in web_editor when it was not a dependency.
This caused the test to fail when web_unsplash was not installed.
As it is necessary to import it when the module is installed,
this test is moved to test_website as both modules are installed there.
(Also updated to ES6 import syntax + odoo-module style test)
task #3000801closesodoo/odoo#101672
X-original-commit: d85ba585ec4642a507d24ab94606a65970c635f3
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Before this commit, clicking on the translate button of a web_editor
html field throw an error.
closesodoo/odoo#101551
X-original-commit: c5199c8e21abd90e2904e31240e427fa2e920803
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
With [1], the frontend main scrollbar was moved to the #wrapwrap element
and with that change came many scroll utils and code adaptation. The
goal was for the code to be generic but after multiple bug fixes, only
the case of #wrapwrap being the element which scrolls (this stable
version's standard case) was actually working. As the scroll is being
moved back out the #wrapwrap in master (see [2]), those non-properly
working generic features were found. This commit solves the stable utils
in preparation for that master merge. Indeed even if the standard 14.0
case was not impacted by those faulty utils, they were still wrong and
could impact users migrated from 13.0 and earlier.
Note: some adaptation actually handles the case of multi-documents in
the page (like triggering a scroll in an iframe from out-of-the-iframe
JS code). This is not needed here in 14.0 but will be in the forward-
ported version in master for the 'website-in-backend' features merged
at [3].
This actually includes some (parts of) fixes that were done in the wrong
version, like [4].
[1]: https://github.com/odoo/odoo/commit/4e7be69825163c0a0ff41c882a196fc7f3158fb3
[2]: https://github.com/odoo/odoo/pull/98429
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[4]: https://github.com/odoo/odoo/commit/f240a42ab501fe37b52f92957c144536a9faf09d
X-original-commit: ffc19547c8da2ef7fee8e2ac743ab99a607dcf90
Part-of: odoo/odoo#101517
Before this commit, when all editor toolbar's items doesn't fit into the
screen width, they can't be reached.
This commit fixes it by allowing the toolbar to be scrolled horizontally
to let the user reach all the items.
Steps to reproduce:
- Open a Contact
- In the notebook, open the Internal Note tab
- Focus the description field
=> the toolbar's last items are inaccessible
closesodoo/odoo#101537
X-original-commit: 3a7349d02b6b667c890af2f197a3640d875b804e
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Use system fonts for backend and web-editor's UI.
This commit removes references to proprietary fonts and allows the OS
to use the system ones. The aim is to reduce http request and the
general footprint (see enterprise counter-part).
The new font-stack:
- apple-system (San Francisco): iOS Safari, macOS Safari, macOS Firefox
- BlinkMacSystemFont (San Francisco): macOS Chrome
- Segoe UI: Windows
- Roboto: Android, Chrome OS
- Helvetica Neue: old OSX versions
- Ubuntu: Ubuntu
- Liberation Sans: Linux (others)
- Arial: Any
- sans-serif: General fallback
This was actually already introduced for the website default theme and
as a general option with [1] but it was not complete: if reaching the
need to use Roboto of the font stack, the repo Roboto was used instead
of the potential system one. It was not shown during testing with the
previous font stack. With the new one, on Ubuntu, it was revealed as
the Ubuntu font comes after Roboto.
[1]: https://github.com/odoo/odoo/commit/c0f2f670eb087991cc9a6a67f4beea5f12bd15f2
task-2995248
closesodoo/odoo#101533
X-original-commit: 9f8f8f2ef88aee746819469c918b2d31ec29d031
Related: odoo/enterprise#31985
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Since [1] it is possible to request that some blocks are not displayed
on mobile devices.
This commit adds a similar option to prevent blocks from being displayed
on desktops (i.e. on non-mobile devices).
[1]: https://github.com/odoo/odoo/commit/9463f0f889f9dd8da6077895c125da4998a933c0
task-2900730
closesodoo/odoo#101483
X-original-commit: 3103e0553011b5c1f4078972d7a88fa3fd4068b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Antoine (anso) <anso@odoo.com>
An event was not called on uploading files in a media dialog.
This meant the parent of html field didn't know of the new attachments
which resulted in attachments being linked to no record at all
and not being garbage collected later.
This adds a reference inside the media dialog file input so that it can
trigger that event on behalf of the html field.
The attachments newly uploaded in media dialog are uneditable
to prevent users from unlinking attachments
that are still used in the body of the composer (causing the same issue)
Task-2860761
closesodoo/odoo#101405
X-original-commit: f4dd1eb3f25672e7309759c347e2b552c5652b2f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior before Fix:
when we hit shift+enter the oShiftEnter doest not trigger
Desired behavior after Fix:
now when we hit shift+enter oShiftEnter gets triggered.
Task id-2991164
closesodoo/odoo#101345
X-original-commit: d1808c8d50372a5e7e0063634037e069aa7fc55a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the editor was always updating the record even when
it's content was not modified or even focused.
X-original-commit: d067710220f6a528f251a44a51863f4f8fb12034
Part-of: odoo/odoo#101118
Before this commit
The method `updateValue` was updating value constantly
because `value` was a string and `this.props.value` a Markup.
Now
Update only when necessary
closesodoo/odoo#100965
X-original-commit: 45d4ac14f65c53dcde56592715d50169bde116ad
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Since [1], as part of the new translation system made with [2], saving
multiple elements in a website page was only saving the first one. E.g.
- Enter edit mode of your homepage
- Add something in the main area of the page
- Add something in the footer
- Save
=> Only the main area is saved, not the footer.
This was actually the same in translate mode... only translation of the
first edited area could be saved.
At least, with the bug fixed version of [1] comes the small advantage
of not saving multiple times the same field (except for view parts).
E.g.: an event's dates are displayed multiple times in different formats
-> in 15.0, 3 RPC were made by date changed, now only one is made.
[1]: https://github.com/odoo/odoo/commit/1b473cf0db4d85c2b523ac87fbab533bce5f3e21
[2]: https://github.com/odoo/odoo/commit/4e82c45abdb0b420edead2bd1d0ba9ff4bb4a224closesodoo/odoo#100762
X-original-commit: c834d151afed0ca633ffb6bcba2f45b544689e74
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit
The editor used only span with a style tag in order to format text.
This was considered to be unclean code.
After this commit
- use style tag (strong, em, s, u) rather than span with a style tag
- use span with style tag if a container is already styled
- remove redundant style/tags
task-2850566
closesodoo/odoo#99812
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit
The zws character (`\u200B`) was removed regardless if it was added by
the editor.
After this commit
The zws character (`\u200B`) is removed only when it is added by the
editor using `oe-zws-empty-inline`.
Part-of: odoo/odoo#99812
Before this commit, following this flow:
- Drop a text_image snippet,
- Upload images from the media dialog,
- Change the image to an icon,
- Double click on the icon to open the media dialog again,
- Click on the 'image' tab
- The previously uploaded images are not correctly sized
To fix that, the media dialog component template is changed: instead of
rendering all the tabs and hiding the inactive ones, it only renders
the active one. This way, the images are correctly sized at all time.
Since commits [1] and [2], the design used by tabs and the Notebook
component is more consistent, which allow us to replace that part of the
template by the component.
The Notebook component receives the list of pages to render, and will
generate the right subcomponents in the content part of its template.
[1]: https://github.com/odoo/odoo/commit/68f1c90a031a7c2f751d9c8eca7ff525e9f7e206
[2]: https://github.com/odoo/odoo/commit/ff0b2d441252560a076a3609d81c369f0ce42d19
Part-of: odoo/odoo#100253
Before this commit
When creating a new mass_mailing and hitting multiples times enter, the
content was reset.
task-2985162
closesodoo/odoo#100284
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
qsm-odoo