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
Avoid having multiple tooltips. We keep only one "t-field"
in the template. The other are replaced by a "t-out".
We also add a specific message when the datetime format is not
respected.
task-2942617
X-original-commit: a99d684507782cd0d9ff700dc7a12f7a46442403
Part-of: odoo/odoo#102545
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>
*: web_editor, website
Prior to this commit, the template structure for declaring the snippet
options used in a specific context (website, mass_mailing, ...) made it
hard to easily modify SnippetOptions defined in web_editor.
Indeed, the structure was as below
```xml
<template>
<t t-call="web_editor.snippet_options" />
... Additional Options ...
</template>
```
If someone wanted to alter the behaviour of an option from web_editor
for their module, they had 2 solutions
- To extract that option inside another template, extend that template
inside their own module, remove its call from web_editor and instead
call manually the option inside each module (preferred method)
- To impact the web_editor template directly with an extension instead
of a new primary template or override JS options using include or
replacing an option inside the registry.
The second solution was often used but created extra code to make sure
that other modules were not impacted... and it was often not properly
done. For example:
- [1] and [2] introduced javascript code inside the web_editor options
and isolating it by checking if they are in fact, inside mass_mailing.
- [3] adds code in mass_mailing mentioning JS classes of website, and
actually broke parallax for website (after [5]).
- [4] broke the image transform option for website (after [5]).
- [6] added some shapes for mass mailing images but ended up adding them
for the website builder too.
- [7] created different images options for mass_mailing... but ended up
impacting website options too. Half of those can actually either be
put in web_editor to improve everything or just in mass_mailing to not
break the website.
- ...
This commit tries to fix everything "the right way" in master (and will
be backported for the recent 16.0). Other stable fixes will need to be
made to restore the website options in a stable way.
To fix that, this commit changes the structure to
```xml
<template inherit_id="web_editor.snippet_options" primary="True">
<xpath ...>
... Change existing options ...
</xpath>
<xpath expr="." position="inside">
... Additional options ...
</xpath>
</template>
```
This allows each module to modify the existing web_editor templates
without impacting it and each other. They can even change the JS
behaviour by using an XPath to replace the data-js of an option, and
changing it to their own extended version of the JS option.
[1]: https://github.com/odoo/odoo/commit/f296992317e96562c66bd7ad59a5080d6c551ed5#diff-df5e4ff426027c53ebe6e25c25820fb92237c17a036f6202a93e5ca681ec8c16R134-R138
[2]: https://github.com/odoo/odoo/commit/cd403480f90cf7103651f3be818a14b06d3c73ca#diff-df5e4ff426027c53ebe6e25c25820fb92237c17a036f6202a93e5ca681ec8c16R175
[3]: https://github.com/odoo/odoo/commit/e9237ae8004502a3071e8ceb132d9dac11fe00b3#diff-df5e4ff426027c53ebe6e25c25820fb92237c17a036f6202a93e5ca681ec8c16R372
[4]: https://github.com/odoo/odoo/commit/ff422df49201be6ed7baa11ef3deb5b9a41042a7
[5]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[6]: https://github.com/odoo/odoo/commit/24a4c7f897d4db6bdf0f3cbfc91a3ce7351241a2
[7]: https://github.com/odoo/odoo/commit/d0c2d8e9a1436a8eaf263797c790329f81d7615bclosesodoo/odoo#99850
Related: odoo/design-themes#597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@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>
- Take them out of `legacy` codebase.
- Group them in a generic `static/src/scss` folder, as those files are
used in webclient but also in public livechat, portal...
X-original-commit: ca2e4fea92b5a26078a412072275a969508358c7
Part-of: odoo/odoo#100759
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>
When the ACE editor was introduced in [1], it relied on the already
existing `_views_get` to obtain the list of views that could be edited.
When the `mode` of `ir.ui.view` was introduced in [2], no mechanism was
introduced in `_views_get` to avoid fetching primary views that have
nothing in common with the current view.
This commit adds a parameter to `_views_get` to request the
exclusion of unrelated primary views.
Since even before it appeared in [3], `_views_get` relies on the
following approach:
- consider the top-most parent of the `t-call`ed views
- consider the views that inherit it
I.e.: reach each node of each view hierarchy tree by starting from its
root.
Because this starts from the top-most parent, simply preventing the
call to each primary child view is wrong, because any child on the
parent path must be considered - be it primary or not.
We therefore introduced a `skipped` list that keeps track of those
"later to be processed" views - so that the filtering of primary
children does not remove them.
[1]: https://github.com/odoo/odoo/commit/7c45e5976e6caf3d7b9eb508f728062704232261
[2]: https://github.com/odoo/odoo/commit/434be479f97a32987d0817bf329183fc2bbe3bf5
[3]: https://github.com/odoo/odoo/commit/bff6e04e9536d7b80916987eb123de98b1b689b1
task-2898555
closesodoo/odoo#100625
X-original-commit: 34ac97ce96019573a6a0af968d9c90b9d0d89ae8
Signed-off-by: Quentin Smetz (qsm) <qsm@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
*: auth_password_policy, bus, calendar, event, mass_mailing, stock,
survey, web_editor, web_tour, website, website_event, website_forum,
website_mass_mailing, website_sale
This commit is a first step towards a potential deletion of the
assets_common bundle, although that step would need more work, specs and
discussions as some layouts kinda only use the assets_common bundle
(some take the full assets_common but parts of the assets_backend one
for example).
The main goal of this commit is to have the assets_frontend bundle
directly include the "common" files we need. As a first step, this
commit only blindly duplicates them all into assets_frontend (without
removing the potentially useless ones). The goal is to have those
advantages:
- Reaching a frontend page only calls two main JS files (one normal and
one lazy-loaded) instead of 4 (two normals and two lazy-loaded). This
may help reach a better google page speed (which is becoming more and
more strict).
- The frontend CSS is built as one: the common SCSS which was using
bootstrap variables, or even Odoo-based SCSS added by mistake in
common instead of both backend and frontend is now computed with the
right bootstrap customizations. E.g. the tempusdominus datetimepickers
use bootstrap grays... after this PR, they use the right grays as
customized by the user on the website.
It was also chosen to not have a common "sub-asset" which is included in
assets_frontend. Making assets_frontend completely independent makes
sense (as it probably will for other "main" asset bundles): we can focus
on adding the files each layout needs without the need of worrying if it
impacts unrelated layouts. Sub-assets (when not strictly necessary) is
also a source of errors: extending the "main" bundle instead of the
right sub-asset it may use (like it was the case with the sub-assets of
assets_common: _assets_common_scripts and _assets_common_styles as
explained in the previous commit). So this is indeed a small drawback of
not factorizing the code for the inclusion of "common" files in bundles
but it seems more explicit and easier to maintain that way. Note that
adding "common" file is not the most common usecase anyway, apps
generally only need files in backend or frontend.
The __manifest__ declaration will also likely evolve in more and more
uses of wildcards to match entire directories. In the future, adding
"common" web-app files in both backend, frontend and other "main"
bundles could just be about one line duplicated into each bundle.
closesodoo/odoo#100314
Related: odoo/enterprise#31394
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Sébastien Geelen (sge)