Before this commit, when pasting multiples lines a new step per line.
So when performing an undo, only one line was removed instead of the
whole pasted text.
task-2833740
closesodoo/odoo#89932
X-original-commit: 06fb4e3e8377dedb02644779f0077e0d883df918
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when unsing the function `insert()` with data being
an empty string, the function crashed but shouldn't.
task-2833740
X-original-commit: d44302550ddc027d4891ad04bf16c364e171e5ad
Part-of: odoo/odoo#89932
Ensure the current editor value is set in the Odoo FieldHtml during
`commitChanges` so it can be used by the `urgentSave` when needed.
closesodoo/odoo#89916
X-original-commit: 43dfc8140760497d9f0352897d71ad49b12fd6e5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The command `/image` used by portal users (in a forum post for example)
throws an access error. This fix removes this command for portal users
until master. In master, the command is reintroduced [here].
Indeed, before the new editor in v15, those restricted users could
insert an image as we were using an "in place" image upload dialog
from summernote resulting in simple base64 image added in the image tag.
This allowed to add image without creating an attachment.
But with the new editor, there is no such base64 image upload, and it
would be too tedious / risky to introduce one in stable.
[here]: https://github.com/odoo/odoo/pull/82612
opw-2648770
task-2811325
X-original-commit: e453d4c119a69f285d9a014babe485492bbe9c40
Part-of: odoo/odoo#89890
Disable checklist and stars when the html field attribute readonly is
true.
task-2832281
closesodoo/odoo#89845
X-original-commit: 7c87495d34713cf4ea82cfeb376097d67862eb2a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Commit [1] introduced a way to use pre-configured gradient that included
a change to the util method _areCSSValuesEqual.
Commit [2] added lines of code to compare shadows but unfortunately
broke commit [1].
The changes of commit 2 left a lots of elements in the body of the
document.
Steps to reproduce:
- Install base database
- Find HTML field (e.g. Login as admin => preference => Email signature)
- Select text and click on Text Color
- Click on gradient then custom gradients
- Move the slider around
- Inspect the body element
- Lots of divs are there
[1]: https://github.com/odoo/odoo/commit/a48a30f954afcb6ff3a59c4f32b05fd0c2cfcd2b
[2]: https://github.com/odoo/odoo/commit/212d8ec10bb48e8fd7de3d3ff7660447b968c62aclosesodoo/odoo#89785
X-original-commit: 043dea4d8a46465f2faf3d6b93847dc2eabfde8c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when the selection was not in the editable at the time
of calling the LinkTool, a link was created outside the editable, which
is wrong.
Task-2696969
closesodoo/odoo#89772
X-original-commit: 78decd6a75d6abf06177747f350871fefc84fd5a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
There are cases that seems to reset the editor content but shouldn't.
This commit:
- provide a dialog to allow the user to save his content before being
lost forever
- reset only if the record content has changed
task-2810115
closesodoo/odoo#89625
X-original-commit: e812e923ffe040e734e4d913eceaae396adf6c3d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Ensure the `onChange()` callback is called
after each history steps in the editor.
Call the `_doAction()` directly, to avoid using the
disabled `_doDebouncedAction()`.
task-2760436
closesodoo/odoo#89339
X-original-commit: 18eaabcb4dab4682e3a94e16dbe66ff3c6f35a77
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
* Avoid auto-transforming an valid url inside an existing <a> tag.
* Ensure the current selection range is deleted
before embedding an image or video.
task-2604627
closesodoo/odoo#89210
X-original-commit: 070bceeadd16e0b5643b91ad583449d31c48313d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
We change the way we handle paste of html data :
The basic flow is :
1. if any range => deleteRange and continue from here
2. if the paste data has only one root <p> :
> we unwrap its content in place
2. if the paste data has two root <p> :
> we unwrap the content of the two p in place
> we force a oEnter between the two contents
3. if the paste data has more than two root <p> :
> we unwrap the content of the first and last p
> we force a oEnter between the two contents
> we insert the rest in between, out of focus block element
@see unit tests in `test/spec/copyPaste.test.js`
task-2604627
X-original-commit: 4dde6d37f30c35714c52e7e28f7011414fed7b6a
Part-of: odoo/odoo#89210
whitelist of html element was not designed to keep the style
set by our own editor ( style on <span>).
We add a system to keep the spans when they meet some requirements.
Requirements are basically having one of the few allowed inline styling css rule.
@see tests in `test/spec/copyPaste.test.js` section 'Html Paste cleaning'
task-2604627
X-original-commit: da92c2335a1241ec9f3974d3bac1c4b7227b2d28
Part-of: odoo/odoo#89210
When delete backward/forward OR deleteRange,
we need to ensure the break lines stay consistent with the user action.
Some cases where not handled correctly.
Mainly when a <p> tags was removed and not directly adjacent to another block element.
In those case we kept too much or too little break lines.
@see tests added in `test/spec/editor.test.js`
task-2604627
X-original-commit: 9f14422ffceadd48b76ff460e4080e0cf5bc6fa2
Part-of: odoo/odoo#89210
Ensure we never move nodes that were not initially in the deleted element.
When deleting an element and merging its content with its sibling,
the nodes contained in the removed element will temporary be hosted
in the common parent, beside possible other nodes.
We don't ever want to touch those others nodes when merging.
This change fix some instances where nodes would wrongly be carry
into another element.
@see new "merge node" tests in `test/spec/editor.test.js`
task-2604627
X-original-commit: 0af6e15ba9d15f20ec74144fd3069e6f409ef802
Part-of: odoo/odoo#89210
Ensure the `_active` property on the PowerBox object is always a boolean.
@see test/spec/copyPaste.test.js
task-2604627
X-original-commit: 124298546cfbc129eb9ae934923a5e4e47392797
Part-of: odoo/odoo#89210
ADD load of units tests covering :
* text paste
* html paste
* image url embed on paste
* url embed on paste
* video url embed on paste
* better coverage on some delete backward and forward
CHANGE some others unit tests :
* tests about merging of block elements that where not accurate
* test about insert HTML ( spec change )
task-2604627
X-original-commit: 378e8d1bd64e3758eb0202be33cb2d8c5bf97eea
Part-of: odoo/odoo#89210
`o_editable` is not supposed to be removed.
Example of a problem if o_editable can be removed:
In translation mode, when deleting the text of the `o_editable` container,
that container could be removed but shouldn't.
See https://drive.google.com/file/d/1U_NUFBvUninOuFKn2H2c4BDcka3OetlD/view
task-2810332
closesodoo/odoo#89071
X-original-commit: 2010c0e2c402f5bb423a0fe683e51923e1e14042
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The function `setContenteditableLink` makes all the `contenteditable=true`
that are not the link or in the link being `contenteditable=false`.
Before this commit:
If we click on a link A then we click on link B, and if link B has
elements being `contenteditable=true`, the first click makes them
`contenteditable=false` and the second do not makes them
`contenteditable=true`.
After this commit
If we click on a link A then we click on link B, and if link B has
elements being `contenteditable=true`, the first click makes them
`contenteditable=false` and the second click now makes them
`contenteditable=true`.
task-2810332
X-original-commit: 72dd8d6e3c95f614353b1e87322a67c877c255c7
Part-of: odoo/odoo#89071
This commit fixes a symptom of a more general problem which will be
investigated later.
Steps to reproduce:
- Go to apps
- Install website
- Follow the configurator flow up to entering edit mode
- Go to the 3rd tab of the editor panel
- Change the "background" color of the third color combination and
choose one of the gray colors
- Go to the backend => SCSS compilation crash
Basically, "frontend" color (complex) maps are available in all assets
(via the variables parts that all assets have in common). The original
plan was for them to be used in shared "frontend" environment like the
mass_mailing application. The web_editor SCSS generation uses those
variables to customize bootstrap variables... but it conflicts with the
backend also customizing those. That's why there is code to "clean" what
the web_editor app does when you are in the backend environment. The
problem after the mentioned steps is that this "cleaning" is done too
soon: gray colors are removed from maps to not alter backend grays and
a web_editor css rules wants to access those gray values if configured
to be used as mentioned in the steps to reproduce. This commit basically
reviews what was done at [1].
In master it should be reviewed so that the web_editor probably does not
touch any bootstrap variable when in a backend environment and/or some
code should simply be moved to the website app only. See also
web_editor.common.scss where many CSS rules depends on this and are
available in the backend... while they probably should not (like the one
which tried to use that gray value like explained above). But in stable,
we wanted to avoid changing too many things.
However, this was only a symptom of the problem: the fact that some
CSS rules should not be loaded in the backend is not a critical issue.
The real problem is that those CSS rules were breaking because the
backend assets are actually generated using website-specific assets
while the backend is supposed to be website-independant. That's probably
a bug introduced with the new assets system (ir.asset) which would
explain why this bug cannot be reproduced in 14.0. This will be looked
into in a future update. Also, this could be backported later if judged
necessary or if a traceback is actually found.
Note: the forward-ported commit also includes the fix made at [2].
[1]: https://github.com/odoo/odoo/commit/70f35620babdfdf43e2c603efbf37f2cf7399240
[2]: https://github.com/odoo/odoo/commit/0fef8cfb5dc2fc0a2d9e0352ea6a473a0d7b9dbc
opw-2735123
closesodoo/odoo#88968
X-original-commit: c58cee82939edb0ae0a95b5141d5c3b85dc404c0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the tab labels of the colorpickers were too long
in some languages (e.g. German) making them overflow and making the UI
impossible to use in some cases. Indeed, the bug was different depending
on where the colorpicker was:
- In the text tools, the colorpicker overflew the whole panel, making it
impossible to use
- In the snippet options, the colorpicker buttons were cropped without
ellipsis making them impossible to read
- In the backend, as the toolbar is floating, it was ok but the code was
quite dependent of the other colorpicker-related scss
This commit solves those problems and unifies the way colorpickers look
independently of their position (always full width, the buttons fill the
available space, if the buttons are too long they are cropped with
ellipsis, they have a title on hover and are always aligned on the
left of the tabs area).
opw-2786778
closesodoo/odoo#88844
X-original-commit: a4755218f239e5c00e9c6a23321654a3ab029470
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit e834173314f00e36cb3a1f99690d9f220584682c fixed an issue where editable
elements could not be removed if they were nested in a non-editable element,
because the editor considered them to be an editable root.
However, the same logic also applied when doing a history step after adding
such an element. Adding a nested editable element would make the history step
invalid and result in a rollback.
Such a situation can be encountered when adding a recaptcha legal notice to a
website form. The footer of the form is a non-editable paet of the document,
however the legal notice can still be updated by the user. This commit adds a
separate test for the addition of such editable elements that were previously
considered unremovable.
opw-2723017
closesodoo/odoo#88733
X-original-commit: f693e8ed27f753a728d903dfe4d7d10ae1334526
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this change, if a contenteditable=true element was a child of a
contenteditable=false element, it was always flagged as unremovable=true.
In fact what should happen is that this.editable should be unremovable, but one
of its subchildren can be contenteditable=true while having a parent
contenteditable=false and not be unremovable.
Task-id: 2794990
X-original-commit: 72e2fd7439a0d6e44b5082def35079019371a3b7
Part-of: odoo/odoo#88733
On mass_mailing, the button does not have a specifc width.
Defining a width to the button makes the styling more predictible.
Task-2781002
closesodoo/odoo#88679
X-original-commit: 5f5b806559e06aad7f67b66c8da96d15516fcd52
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The overflow: auto on the container in mass mailing generated a
scrollbar whenever the drag and drop of snippets because
of the drop zones.
Task-2781002
X-original-commit: 2af04ad4798e11bb2c08798dddb04ed32c42992e
Part-of: odoo/odoo#88679
A mechanism is provided by the OdooEditor to circumvent certain problems while
editing links. More specifically, editable zones are patched when editing a
link. This avoids the cursor ending up outside the link whenever the link tag
is emptied.
However, the mechanism does not check if the link is also in the editable zone
before doing so. In translation mode, the editable zones correspond to the
individual translation strings. When translating link texts, this means the
anchor tag containing the translation string is outside the editable zone. The
patching mechanism still applies, resulting in the anchor tag becoming editable
as well.
This causes problems while translating links, for example oDeleteBackward
commands are being rolled back. Checking if the anchor tag is inside the
editable zone resolves the problem.
opw-2780312
closesodoo/odoo#88674
X-original-commit: 99050b26446bbbe949e1fa797210c2a8a68d94cd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, this bug was present in edit mode:
- Go into edit mode on an empty page.
- Click on the THEME tab on the right.
- Click on the empty "DRAG BUILDING BLOCKS HERE" area.
- Click on the THEME tab again.
- The content of THEME is empty.
It was because since this commit [1], clicking on an 'oeStructure'
activate the Blocks tab but without updating the options in the tabs.
Another similar bug was present when clicking the style tab and then
clicking on the theme tab.
About the first bug, actually a call of '_updateRightPanelContent' is
already done in '_activateSnippet()' (and the Blocks tab is activate by
default) so we only have to use '_activateSnippet(false)' to activate
the Blocks tab. This commit also remove '_updateRightPanelContent' from
the click event of the Blocks tab where it was not necessary.
For the second bug, we can't do the same fix, because it's not possible
to activate the options tab with only '_activateSnippet(false)' so we
had to combine the two functions.
[1]: https://github.com/odoo/odoo/commit/fbe048c202ff7878984adf26bef0651a45851f0a
task-2794266
closesodoo/odoo#88537
X-original-commit: 52d32e26c34bef10823582ef5c1f840492b73d7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The chatter and activity html have the video being sanitized upon
save. As it is a desired behavior, disable the ability to add
video from the editor for those field.
Task-2726483
closesodoo/odoo#88266
X-original-commit: c70d42d12eb522767f84a728c71ac30f66521e2a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The commands are grouped by command group when rendered by the Powerbox.
That creates a dissociation between the order in which they are rendered
and the order of the arrays in which they are present in the code. The
mechanism to navigate between them with the arrow keys is however
dependent on the latter. As a result we may end up with a visually
disordered navigation.
This adds a private function to reorder these arrays in the same way as
they are rendered, thereby fixing the dissociation.
task-2802749
closesodoo/odoo#87209
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When no command is found in the Powerbox, the text "No results" is
shown, which is annoying. Instead, this hides the Powerbox we such is
the case.
task-2802749
Part-of: odoo/odoo#87209
Before this commit
On mobile, clicking on a powerbox item called the first command.
After this commit
On mobile, clicking on a powerbox item call the clicked item command.
task-2751059
closesodoo/odoo#88059
X-original-commit: 03638e4d46941bb4751ac2d6df8c08cb4cc2208e
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the user create a button in the website builder through the
powerbox command "/button":
- call the editor fix for the link
- select the link
task-2704540
closesodoo/odoo#88010
X-original-commit: 92fcd5e15cf3fec96cdd2565157cd41ffd39a084
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit
Calling a command of the powerbox created a step that delete the input
content of the powerbox. That input content came back upon undo.
After this commit
The input content that select a command from the powerbox should
never come back upon undo.
task-2806849
closesodoo/odoo#87994
X-original-commit: 2da3d928ad4c7e7c285b753fb1241326089d45e7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit permits to:
- avoid DOM modification when starting options of social_media.
- remove the useless HTML related to the social media block.
- generate all available social networks that are present in the DB for
the social media block.
- delete DB social media if there is no value for it in the DB.
- display an alert banner in edit mode if the block has no link.
- use a shared variable for social media db urls in order to avoid too
much RPC.
- custom links are no longer togglable, only deleteable.
task-2739937
X-original-commit: f243bcbafb9291d94840795951c8fd51cab0cae1
Part-of: odoo/odoo#87933
This became more and more needed. Of course, it should be avoided most
of the time as you do not want to rely on async operations to build the
initial rendering of a snippet (best to do server side during the
rendering of the editor panel).
This can however make sense and it is needed as a fix for the social
media snippet (see next commit).
task-2739937
X-original-commit: 3fb1718ce494ccf48959e6e4fe9f640621c4a3a9
Part-of: odoo/odoo#87933
Before this commit `selectStyle` was always applying inline styles as
`!important`.
After this commit the `!important` priority is only set if the style is
not taken into account without it.
Steps to reproduce:
- drop a "Text - Image" snippet
- select a solid Background color
=> `background-color` appears in inline style without `!important`
- select the image
- set a 10px Border width
=> `border-width` appears in inline style with `!important`
- set a 10px Round Corners
=> `border-radius` appears in inline style with `!important`
- set a 1px Border width
=> `border-width` does NOT appear in inline style because the added
`border` class already specifies that width
task-2765880
closesodoo/odoo#84765
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior of this commit the paragraph margin-bottom was forced to '0'
braking the typography's vertical rhythm.
This commit will remove the customisation rules restoring bootstrap
default values for the backend.
task-2798759
closesodoo/odoo#86740
Signed-off-by: Antoine Guenet <age@odoo.com>
Prior to this commit, when an exception occured during the save of an
ir.ui.view, the traceback was shown to the user and an alert directly
asks the user to reload or cancel the page.
While reloading, the changes that produced the traceback were not saved
and the other modifications were saved.
If the user choose to cancel the reload, the web editor UI was freezed
and there couldn't be any edition anymore.
This commit adds correctly the popover to target the invalid element and
shows the error rather than reloading the page.
The element which caused the error can still be edited. The other are no
more editable.
task-2700198
closesodoo/odoo#87350
X-original-commit: 10b97f37ab5d78b3a2b0f63fa019ee95bb78ea7d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Commit [1] redefined the target in generic methods of snippet options so
that some buttons of the Design Tab snippet option could target a
different node than their parent option. This reverts that in favor of
the more generic `apply-to` data attribute.
[1]: c4bfedc37bclosesodoo/odoo#87325
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This allows users to use the shape feature on images in mass_mailing.
Since email clients do not support the svg file type, it converts these
svg images into png images on save.
task-2760157
Part-of: odoo/odoo#84926
Prior to this commit, when a user edits the Shop page, clicks on the
pricelist dropdown and finally clicks elsewhere, a traceback occurs:
`Uncaught TypeError: Cannot read properties of undefined (reading
'getColorNames')`
This commit ensures the link tools is not toggles on dropdown links,
i.e. the customizable links selector does not contain the dropdown
anymore.
task-2695091
closesodoo/odoo#87300
X-original-commit: 73b98a53e8bd19b3b96502d6006b002819287e44
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Before this commit, if an option targeting an element had a
data-no-check attribute this had the effect that all other options
targeting this element were also displayed even if they did not have a
no-check attribute (no-check => display the option even if it is
a non-editable element).
The issue came from the is() function of _computeSelectorFunctions which
did not take into account the no-check as it should.
Note: this is fixed in stable only as custom apps may rely on the broken
behavior. An issue with this in stable can be met by *hiding* the
related unwanted options with `_computeVisibility`. No case of this
problem currently exists in the Odoo codebase (but it will, that's how
the bug was found).
task-2710582
closesodoo/odoo#86011
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit
When trying to open the linktool on link that are not
`isContentEditable`, the linktool was initialized and not
showed in the sidebar.
After this commit
As it does not make sense to edit a link that is not editable,
prevent the linktool from being initialized in the first place.
task-2802592
closesodoo/odoo#87203
X-original-commit: 4a634f2c5bfceb3f2dc200f9b391ef1cdbc0e697
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Nicolas Bayet