`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.
closesodoo/odoo#70476
X-original-commit: 92352ed2b5524c97b0aeeba3193c6a8d93ed82a1
Related: odoo/enterprise#18172
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Previously, when toggling on background shapes, they always had the
default colours. In [1] we made it so that when you toggle on a shape on
a section, it would automatically reuse the colors of the surrounding
shapes if any.
Unfortunately, when the "implicit" colors were also the default colors,
they were still marked on the shape, and it got an explicit background
image that would no longer react to changes in the palette.
This was caused by the fact that the call to _getDefaultColors returns
an empty object when the section doesn't already have a shape-container,
this was not a problem before since we were not passing in any colors
when creating the initial shape previously, the the aforementioned
change made it so that we did.
This commit fixes the issue by creating the shape-container before
calling the method that will set the colors on the shape, this way
getDefaultColors works as expected, and the colors are not marked on the
section when they are the default ones, restoring the ability of the
shape colors to adapt to the palette
[1]: https://github.com/odoo/odoo/commit/875aca63f7dab287c61485ebe999b3b8dd89d91c
task-2500607
closesodoo/odoo#70054
X-original-commit: 63acc2b0d1957dedd40af2033722f9ea4ef2e597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
On creating a new note, the focus was automatically set into the "tags"
field. This was inconvenient and was replaced with an autofocus on the
note itself so we the user can immediately start typing.
closesodoo/odoo#70195
X-original-commit: 8fe89c5ebc138cb517938dbd6d975b8bec4eaf4d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Scenario:
- add a file in mass mailing editor => an generic icon (instead of lower
version where icon depended on mimetype) is added linking the file
- save and send mail => no icon is shown in email received
The system is targeting `a[href*="/web/content/"][data-mimetype]:empty`
to add real image inside instead of using background-image attribute
which is stripped in sanitized.
With this commit, data-mimetype is not removed when image processing
attributes are removed when a file is inserted.
opw-2474053
closesodoo/odoo#70022
X-original-commit: eb3772508ce518ff3f84724eebbe43fd1e040d77
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The media modal's document tab has cells with icons and filenames. If
the filename was too long, it would overflow its cell, which caused an
ugly design glitch. This ensures an ellipsis on the filename when it is
too long.
closesodoo/odoo#69990
X-original-commit: 8a4f4bf04bd5e5f9cf827273ea27a189a43c2515
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The "note-editable" class was lost on the editable element when loading
it into an iframe. As a result, some selectors failed, making it so that
some options wouldn't activate when they should.
closesodoo/odoo#69908
X-original-commit: d71b7d87daa5b33f16eb9c6ade29580fb2076313
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In an iframe, we need to make sure the element is using jquery on its
own window and not on the top window lest jquery behave unexpectedly.
This was apparent with tooltip which was called in snippets.editor with
the "wrong jquery", with the result that tooltip.js had a reference to
the top window/document instead of that of the iframe. Because of that,
it appended its tooltips to the top window instead of the iframe, and
as a result, said tooltips were wrongly positioned.
closesodoo/odoo#69879
X-original-commit: 19be8709efa8f690ccff8d04dd9a17e4ef4d82fd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
The overlay around an image when cropping it is positioned absolutely.
If it has no relative ancestor, it will cover the entire body. This is
what happend in mass_mailing, making it impossible to scroll the page
while cropping. This commit addresses the issue by positioning that
editable relatively so that the overlay never goes beyond its bounds.
closesodoo/odoo#69878
X-original-commit: c4d423640a9f1f9892e9d24dc08531ba0bbf8887
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
We need to check the selection on click in the editor's document so as
to update the visibility of the toolbar (we want to hide it if the
selection is in a non-editable area). When the editor was in an iframe
however, the wrong document was targeted: we want to check on clicks in
the editor's document, not the top document.
closesodoo/odoo#69775
X-original-commit: b0429c96e30751390991a9471a4c031dfed98d81
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before introducing the new Odoo Editor, the body of an iframe containing
the editor has the class "editor_enable". Now it's applied to the main
document's body. This ensure the class is applied on the iframe's body
like before.
As a consequence, some CSS had to be adapted:
- The position property of the snippets menu which had been overridden,
probably as an ad-hoc fix for the fact that this class was missing.
- The top padding which is applied to accomodate a top toolbar which was
removed with the new editor and can now be removed.
closesodoo/odoo#69767
X-original-commit: b7cbb8a8fdbebdb7d33e3286fa9f4ec760ad9fe6
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This fixes a bug in mass mailing, that made the toolbar still visible
while the selection was not in an editable area. It was due to a jquery
selector targetting the top document instead of the iframe's document.
closesodoo/odoo#69707
X-original-commit: 5e3cda847a42561ae709cb792d3e612f8a5e66dc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
A colorpicker in an option positioned above the toolbar in a snippets
menu would be hidden by the toolbar because of the toolbar's z-index.
That z-index is only needed when the editor is in a modal.
The bug this commit fixes only arises when the toolbar is in a snippets
menu.
This applies the z-index only when there is a snippets menu in the page.
To accomplish that we need the "editor_has_snippets" class that the
website module applied to the body. For the sake of harmony within Odoo,
that class is now applied by snippets.editor so that no matter the
module, if there is a snippets bar, the class is on the body of its
document.
closesodoo/odoo#69680
X-original-commit: b1aa9c6093cea918337d5600ff9b16b7dd80de23
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Dropdown menus (eg.: font-size) had their contents cropped if space was
lacking underneath the toolbar. With this the user can scroll down to
see the rest of it if needed.
More info: https://github.com/twbs/bootstrap/issues/23378closesodoo/odoo#69644
X-original-commit: d360b751acfc1649673739b185b635732cf5b78f
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add a new parser in the ace for the qweb highlight. This makes it possible
to visualize the qweb tags and the part of code.
Used in the website and in xml fields.
closesodoo/odoo#69609
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
`setCursor` routinely failed to actually select the target link on
destroy the link tools because the nodes passed to it were not in the
DOM. This fixes that problem, which in turns has the effect of keeping
the editor's toolbar in the sidebar on the website builder after link
insertion.
closesodoo/odoo#69525
X-original-commit: c8fa05813da82fd2b282721f3a86053b7b6661ba
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this fix, pressing CTRL+Z right after saving a link dialog
didn't do anything because the dialog prevents the focus from being in
the editable, even though the range is in the link. This waits for the
dialog to be removed from the dom so we can force the focus on the
editable.
X-original-commit: 769a22a579e4622861ca239084d7259820266b23
Prior to this fix, link tools didn't create a history step when they
were destroyed, meaning that you couldn't undo the creation of the link.
This ensures that the link tools are destroyed whenever a click is done
outside the toolbar, which ends the link edition and commits it to the
DOM. At that moment we can consider the link edition is over, equivalent
to saving the link dialog, and we can create a history step.
X-original-commit: 9b10c5923dadab3a49d474eb236c7c2617fb4be0
Template `wysiwyg.iframeContent`'s `#iframe_target` includes a `script`
element that defines an odoo module (`web_editor.wysiwyg.iniframe`).
`wysiwyg_iframe.js` resets the html of that target so that the node
prototypes are defined relative to the top window rather than the iframe
window. Resetting that html had as a side effect that the script was run
a second time while that is unnecessary given that the module has
already been defined. This resulted in an error, which is here fixed by
removing the `script` element from the html when resetting it.
closesodoo/odoo#69492
X-original-commit: 3d4e0f15dd9a0009a7d0fc19fc29a5df9a6f92e8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit fixes multiple bugs related to the new link popover edition [1].
Those bugs mostly comes from new editor integration [2] conflicts, as those
where merged almost at the same time and needed a quick fix of rebase
conflicts.
- The navbar & footer link would not load the popover link edition anymore,
as it was only targetting `#wrap`.
- Double click on links was re-introduced but it was supposed to be gone.
- Tooltip from Edit and Unlink inside the popover remained open after popover
was closed.
- Some leftover code that were not related to popover but kept during the
rebase.
[1] Commit 8fcf930a6b
[2] Commit 740168ce8dclosesodoo/odoo#69389
X-original-commit: e13966cc8e04111a9e18a344132546c6baa79fea
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Trying to select the contents of a content-less element should select
the element itself instead.
closesodoo/odoo#69173
X-original-commit: 6905eaad2ccaa782e3dce99b9581ed0194c37db9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Bootstrap sets a z-index of 1050 for modals while the editor's floating
toolbar has no set z-index and is therefore invisible in modals. This
ensures the visibility of the toolbar in bootstrap modals.
closesodoo/odoo#69160
X-original-commit: 9cd4eb6db072fd55d47240260e63fd5923b3bddb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
LinkTools were recently introduced to provide a new UI from link editing
within a sidebar where there is one. It was implemented separately from
the existing LinkDialog despite them having a lot of code in common. In
order to prevent future discrepancies between them, this commit
introduces the Link widget which contains the common logic for link
editing, to be extended by LinkTools and LinkDialog (via an intermediary
widget).
closesodoo/odoo#69137
X-original-commit: 5415ea46f8d3ee4732111a21b0cd9fa8bdb9526e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The transcoder (transforming CSS rules into inline CSS for mail clients)
was not working for text-decoration property because it would transform
text-decoration values in:
{'text-decoration-thickness': 'normal', 'text-decoration': none}
And the regex that ensures we don't add duplicates check if there is:
"(^|;)\s*text-decoration"
so if there is text-decoration-thickness, text-decoration is not added.
The regexp could be changed to:
"(^|;)\s*text-decoration[^\w-]"
but we already have special case for other text-decoration-* properties.
With this change we should get text-decoration applied in:
- edit mode (was already the case)
- readonly mode (new)
- mail client (only if mail client does not override it)
As a side note: text-decoration-thickness seems to be rather new[^1] so
at one point in time there was probably no issue.
[^1]: https://developer.mozilla.org/docs/Web/CSS/text-decoration-thickness
opw-2496490
closesodoo/odoo#69078
X-original-commit: f4f1b890e15e98d9a7e72586faf73327d3f7b716
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Kamen Zhekov <kzh@odoo.com>
Focus is sometimes called on the Wysiwyg class in Note.
When the user use TAB to select the next field.
Implementation was missing.
closesodoo/odoo#69033
X-original-commit: 720c1f38a17ef54cf30e0a52bab5bceed70c2144
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Rationale:
The majority of cases where an ir.asset is manually declared
outside of manifest files is to specifically add a single asset file.
This means developers are specifying a single asset *path*, and not a
glob expression. In this context, it seems better to name the filepath
field `path`, and document that it can be specified with a glob
expression when (seldom) needed, rather than making the exception appear
to be the norm - possibly puzzling many developers (What's a glob and
why do I need one?)
The doc is updated as well, and some spell-checking and wording
improvements were done too.
This required some adaptations to the existing `ir.asset` declarations:
- odoo/enterprise#17465
- odoo/design-themes#459closesodoo/odoo#68695
Related: odoo/upgrade#2348
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Xavier Morel