Adds basic support to filter possible m2x values based on another
record. This is necessary for the website_appointment snippet
introduced within this bundle (see related ENT PR).
An important need implemented here is to not store a list of valid IDs
in the DOM but fetch them based on data stored by a different widget.
Use case covered:
Model A has a Many2Many relationship with Model B via a `model_b_ids`
field.
A first widget (Wa) on a snippet's options allows to select a record of
Model A. A second widget (Wb) allows to select records of Model B.
```xml
<!--Widget A-->
<we-many2many data-model="model.a" data-m2o-field="name"
data-fakem2m="true".../>
<!--Widget B-->
<we-many2many data-model="model.a" data-m2o-field="model_b_ids"
data-filter-in="true" .../>
```
Before this commit, the second widget would only be able to show
all records of Model B linked to any Model A record and matching a
static domain provided as attribute, which is still supported.
This commit allows, after having selected `record_a` in the first
widget, to only populate the second widget with the records of
Model B that are in `record_a.model_b_ids`.
Implementing this is done by
* Adding `data-filter-in` to Wb's xml attributes (as above)
* Calling `Wb.setFilterInDomainIds()` when another record is selected
in Wa.
Task-2574175
odoo/odoo#90748
See odoo/enterprise#23750
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Drop a block steps on a page
- Change one of the icons
- Change the color of the icon
=> The connectors are not correct anymore.
This is due to [this commit] changing the tag `<i class="fa...` to a
`<span class="fa...` when the user replaces an icon. The steps options
assume that `<i/>` tags will remain `<i/>` tags (as it was before
[this commit]). We should not change the tagName when changing the icon
of an `<i/>` tag. This is likely to break (s)css, options, public
widgets, ... This commit fixes this bug by ensuring that `<i/>` tags do
not become `<span>` tags when replacing the icon. Moreover it allows not
to recreate an editor when you change the icon.
[this commit]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
task-3068834
opw-3123850
closesodoo/odoo#112252
X-original-commit: 93eeaf538c24e7b7ee304c4323cc27bf786f261b
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This commit add a mechanism to ensure that someone could never save
changes from an history that diverge (in case there is a partition in
the RTC network or a person A was disconnected while another person B
saved changes that were not transmitted to person A).
task-3002163
closesodoo/odoo#112099
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The fix that introduced `this._shouldDelayBlur = true` in
`openMediaDialog` was wrong as it was fixing a symptom rather than
the source of the problem. Later fix probably fixed the source of the
problem as the problem is not reproducible at the time of this commit.
If the symptom comes back, it ought to be fixed at it's source.
closesodoo/odoo#112245
X-original-commit: 0dd9da029d58652123ea71085dbb3a1a1e93e77d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When trying to recover peer to peer connection, the timeout of 500ms or
1000ms might be too short and 15000ms in unnecessary too long.
If the timeout is too short, it could remove the connection before the
peer to peer had the time to reconnect to it. When we call
`_recoverConnection` on `disconnect` in `oniceconnectionstatechange`
or `onconnectionstatechange`, the signal `disconnect` does not
necessarily mean that it will remain disconnected. Doing nothing could
be enough to reconnect.
(see: https://w3c.github.io/webrtc-pc/#dom-rtcicetransportstate-disconnected)
closesodoo/odoo#112182
X-original-commit: 3647374c63fcd4bccf501e49a2af6a707fedd737
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the iceCandidateBuffer was emptied before finishing
the loop. This is wrong as we must add all candidates from the buffer.
X-original-commit: 520a880574d908a8e28fa258a1e006d1b8504221
Part-of: odoo/odoo#112182
This reverts commit [1] so as to avoid updating the DOM in two separate
places of the code for link edition. Said commit intended to prevent the
removal of custom styles on a button on which styles were applied
(erroneously) without applying a custom button class. This fixes that
issue by adapting the UI to show the button is custom if there are
custom styles applied. This way, if any change is applied, when
modifying the DOM, the custom class will be applied as well. This is the
order in which such corrections are usually applied with the snippets
bar.
[1]: https://github.com/odoo/odoo/commit/eb4edac560227b46efdcfe958e3b93e0b88def64closesodoo/odoo#112152
X-original-commit: 1b65244a1ae7ed37d7bc1faef2225ed982c94320
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
Before this commit, when the user tried to update a checklist, there
was a traceback in `handle_history_divergence` because the `value` is a
byte sequence instead of a string.
opw-3158660
task-3165844
closesodoo/odoo#112112
X-original-commit: e3900dfe51cb294ad139395cb402c9f13dd067c5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The editor offers bootstrap tooltips, but these were not all initialized
and therefore appeared as standard HTML tooltips. This commit fixes that
by initializing all the tooltips so that they all have the same style.
Details:
- The bootstrap tooltips are now available in translate mode.
- With bootstrap 5, only one bootstrap component can be initialized on a
HTML element. This is why the tooltips are now initialized on the
first child when there is another bootstrap component.
- Some tests have been adapted.
task-2777738
closesodoo/odoo#85666
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
It is wrong in 15.0 since double clicking on the link does nothing
anymore, as edition of the link is done via the popover. Having both
tooltips at the same time created a race condition that ended up
inserting the second tooltip in the DOM, where it obviously couldn't
function properly anymore.
opw-3147108
closesodoo/odoo#112035
X-original-commit: 35cc6049a8bcc3c80cb4eb2468f85d09734814b8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When we paste content in the editor, we merge the first and/or the last
element(s) from the clipboard with the element(s) before/after the
selection (eg, pasting `<p>b</p>` at `<p>a[]c</p>` (where `[]` is the
selection) should result in `<p>ab[]c</p>` rather than
`<p>a</p><p>b</p><p>c</p>`). If the element we try to merge is a table
though, we may end up pasting a `<tbody>` without its parent table,
which leads to unexpected results. In any case we don't ever want to
merge a table with another element, so we prevent that.
Steps to reproduce the issue (in the `note` module):
* Type "a" then hit the ENTER key.
* Add a table (using the /table command) and write in each of its cells.
* Make a selection that starts before "a", and ends after the last
character of the last cell of the table.
* Copy the selection.
* Paste the selection in the paragraph after the table.
What you see before this commit is the text you copied, without the
table.
Everything above is also true of lists (just replace the table with a
list in the text above) and these cases are fixed here in the same way.
task-3165836
closesodoo/odoo#112042
X-original-commit: 07604f2505d9cc32ebb3cf3f09192472f0bf30c4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, the web editor loaded the configuration for ice
servers each time it was created. It is useless to do it more than
once, so this commit simply keep the initial value around.
Part-of: odoo/odoo#111571
Before this commit, _onClipboardCut removed the selected text but did not
register it as a history step. Other than not storing history properly,
this caused unexpected behavior when followed by an action that leads to a
historyRollback on the current step, such as those in _onInput.
task-3142995
closesodoo/odoo#111927
X-original-commit: 451f1a2641b5b85ea75d9f1e8a8d1b528de031b6
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The UI elements related to table creation and edition are no longer
present in the toolbar, as the Wysiwyg and SnippetEditor instances
remove the `#table` div section from toolbar.
Furthermore, the OdooEditor instantiates a TablePicker instance to be
appended to the tablepicker dropdown menu under the (inexistant) #table div
in the toolbar.
This commit removes dead code related to table creation/edition via the
toolbar.
task-3074598
Part-of: odoo/odoo#111131
Before this commit:
On mobile view the toolbar icon gets hidden, which it should not.
After this commit:
Now the toolbar items are flexed and wrapped.
Task-2752096
closesodoo/odoo#111876
X-original-commit: d3e6797ff1bd82618601d233f757b616cb10b87e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Sometimes, two similar adjacent elements must be merged together (eg,
two `<span>` elements with the same style, or two lists of the same
type). This is done by the sanitizer, which is called on the common
ancestor of the mutated nodes after each change, and on the whole
editable when the document is saved. In the case of nested lists, this
can cause a visible discrepancy between what is saved and what is
edited:
1. In a list, say the first item contains a nested bullet list, and the
second item contains a nested numbered list:
`<li><ul>...</ul><li><ol>...</ol></li>`
2. Now we transform the numbered list into a bullet list:
`<li><ul>...</ul><li><ul>...</ul></li>`
3. The mutation happened on the second `<li>` element so we call the
sanitizer on it, and it doesn't have enough context information to
merge the two `<li>` elements, so it leaves them as is.
4. The user saves the document, and the sanitizer is called on the
whole editable, which has enough context information to merge the
two `<li>` elements, so it does so, and the saved document is
different from what the user sees. It is now `<li><ul>...</ul></li>`
as it should have been immediately after the mutation.
We solve this in a straight-forward, ad-hoc way since we currently know
of no other case where this is needed, by calling the sanitizer on the
parent of the first ancestor nested list of the mutated nodes, if any.
closesodoo/odoo#111871
X-original-commit: 50b7b41a4573fdce8891fac5d6aa1d08c557d455
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In order to be able to check checklist items and color stars even when
in readonly mode, we need to add unique ids to the checkboxes and stars.
Since these ids were random and in order to ensure uniqueness after DOM
manipulations, we updated all these ids every time the document was
sanitized. Since the `sanitize` function is called every time the
`cleanForSave` method is called, and since `wysiwyg`'s `getValue` method
calls `cleanForSave`, this meant that the ids were modified every time
we were getting the value of the wysiwyg. This meant that every call to
`getValue` returned a different value, so the editable was always marked
as dirty, sometimes causing an infinite loop (see steps below).
This commit makes the IDs iterative rather than random, so they are
predictable (practical for testing), and ensures that the ids are only
updated when necessary, so that upon two consecutive calls to the
`sanitize` function, only the first call may change the HTML.
STEPS:
* create a sale order
* add checkboxes to Terms & Conditions fields
* edit a sale order line
* click outside the edited sale order line
opw-3116430
X-original-commit: 86ff07d9c201668e372377f9ac41d3801aa223e9
Part-of: odoo/odoo#111871
before this commit:
model translation:
when the user changes the translation for the current language in the
translation dialog, the value in the form view is also updated and marked
modified.
But if the user wants to invalidate the translation and set the translation to
`false`, the form view value is also updated to `false`, if the user saves by
accident, all translations are lost.
model_terms translation:
when translations are modified in the translation dialog, the field value will
not be changed
after this commit:
form view data will be reloaded after translations changed in the translation
dialog
closesodoo/odoo#111869
X-original-commit: 9aab8347a1a4cc74050dd2e5035cba838b93863c
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Nested lists should not have a bullet point in front of them, but the
current conversion of HTML for emails made them reappear.
opw-3136324
task-3166100
closesodoo/odoo#111822
X-original-commit: 11f44de490d7e9c59b76aaade1d31b3041c9fb3b
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when editing a form view, when editing a html field,
the status indicator buttons (the save and discard buttons) didn't show
up until a click outside the html field was done (change event).
Now, the status indicator buttons shown as soon as the input field is
edited (input event).
This is was already done for the other fields in [1].
[1] : 0b2d82282d7f656a9177158fd6117cc2e7a1b4d4
task-id 3147130
closesodoo/odoo#111663
X-original-commit: f56e3bca2456f04616982a9a0e77b8d4c5a0abff
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When there is a problem in the peer to peer network where we try to
recover a connection, retry with exponential backoff instead of
potentially spamming the server indefinitely.
task-3164011
closesodoo/odoo#111802
X-original-commit: fd97295c9cf8b1b0c800f407bb5f538f78cc2665
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the image dimensions were not properly converted
when converting HTML for e-mails.
opw-3144322
closesodoo/odoo#111793
X-original-commit: 1d5c8c9adf18aded19d945cd9b0f72eb9b8bbc72
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The custom table selection was not limited to the editable area bounds,
which means we could end up styling a table as selected, which did not
belong to the editor's scope. This sometimes happened when Firefox
triggered a selectionchange event during the instantiation of the editor
and the selection happened to be in a table outside the editor.
opw-3150654
task-3166078
closesodoo/odoo#111779
X-original-commit: d51aab54775ed541d7955cee032aceed143d3a08
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The CSS rules cache for convert_inline was stored on the edited
document, which is problematic since OWL destroys the document where we
used to just hide it (eg, when switching tabs in the form view).
X-original-commit: d432ebbddae7192eca7215a8489abb3ad91a45f2
Part-of: odoo/odoo#111778
When converting html for emails, contenteditable attributes should be
removed.
X-original-commit: 9b4cff9f6ab8e1738f3fc486875f9e4ab16cea9d
Part-of: odoo/odoo#111778
The video command is supposed to be forbidden in tag-sanitized fields. A
field gets tag-sanitized if sanitize_tags is true or by default if the
field is to be sanitized (and sanitize_tags is undefined). Before this
commit, the video command was not forbidden if sanitize was true,
regardless of the value of sanitize_tags.
closesodoo/odoo#111777
X-original-commit: 96b4edfd40a3c131a7709986fc3e1599c177f986
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The images command was disabled in html fields if the field's view
didn't define the `allowCommandImages` option. This allows that option
to be undefined so it can be overridden by its default value when such
is the case. Before this commit however, the option was always set to
`false` when undefined (the opposite of the expected default value).
opw-3134660
X-original-commit: bf0f17d2c9f19b88d4db2f4e15423ec0c831167f
Part-of: odoo/odoo#111777
When resetting the editor, we need to remove the focus listener if one
was previously added. Otherwise, the editor will try to connect too
much for each resetEditor call.
task-3164032
closesodoo/odoo#111541
X-original-commit: ed73015ee8dc53692026d3bc040ece4226e2c117
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adds a new feature to the web editor of a website. A "text"
input field has been added to the link editor panel, allowing users to
edit the label of a link.
The label will only be updated when the input is changed, to prevent
loss of formatting (e.g. if one letter is bold).
However, only formatting applied to the entire selection will be kept
(e.g. if you have a "link <b>like</b> this", nothing will be in bold if
you update the label in the editor panel).
Additionally, if there is a media element (such as an image or icon)
included in the selection, the "text" input will be hidden.
task-2900529
closesodoo/odoo#99239
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website
When changing the padding of the grid items with the `Padding (Y, X)`
option (when the grid mode is toggled), depending on these items
content, the effects are not always visible.
This commit adds a highlight effect on the grid items when the padding
is changed, to better show the changes being made.
task-3058630
closesodoo/odoo#111584
X-original-commit: f3f2c4c73ce08d3898b8c88e1ef045f7bbd1f624
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since the migration from bootsrap 4 to bootstrap 5 and more precisely
since [this commit], the tooltips on too-long titles are not displayed
anymore in the mail editor.
Steps to reproduce the bug:
- Go to the email marketing application
- Create a new mail (other than plain text)
- Go to the design tab of the editor
- Put your mouse over the title "Secondary Butt..."
=> The tooltip to display the entire title does not appear. This commit
allows to correct this bug and to display the tooltip as it was the case
before the change of version of bootstrap.
[this commit]: https://github.com/odoo/odoo/commit/23facbfb76c6e8b23137cddda5f5113273555498
task-2777738
closesodoo/odoo#111032
X-original-commit: 1e5c945f462e4a9903f64fd59c89319f9f2589c1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit and on Firefox 109, clicking on a link while in
edit mode on the website app would trigger a traceback.
This is caused by the fact that the LinkPopover widget is contained
inside the iframe while use the ClipboardJS global defined in the top
window.
Indeed, ClipboardJS checks if the target (the button to copy the link)
is an HTMLElement. To do so, it uses the "instanceof" keyword. However,
the __proto__ (what is used for computing instanceof) of the target is
different depending on the browser.
For Chrome, the HTMLElement's __proto__ depends on which "document" it
was created. On Firefox, when attaching an element to a parent, it will
switch __proto__ to the one from the frame from which it is attached.
To fix this, we use the ClipboardJS from the element's instance window.
In any case, using instanceof when working with iframe is a bad idea,
see [1]. In this case, the fix is made because ClipboardJS is an
external library.
Steps to reproduce:
- Download Firefox 109+
- Go on Website and switch to edit mode
- Click on a Link : A traceback appears.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof#instanceof_and_multiple_realmsclosesodoo/odoo#111266
X-original-commit: 732848f2b52bea4ebae18cb5adedf581d5112aa6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
With the new 16.0 feature that open any form in edit mode, the html
editor was trying to connect in collaboration each time a record was
opened in a form view that has a collaborative html field.
The peer to peer connection could trigger a lot of rpc because of it's
communication through the bus.
This commit reduces the number of rpc by only trying to connect to
the collaboration network when the user focus the html editor.
task-3151577
closesodoo/odoo#111247
X-original-commit: 9d7aecec811699199e270a5096f00d5cb6f0b15d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Since [1] when selecting item images, the 'Blocks' tab is displayed
while the options are refreshed. This is visible because the image
selection awaits an RPC which therefore allows the browser to render
the 'Blocks' tab selected version of the display.
This commit prevents the return to the 'Blocks' tab to be rendered by
waiting for the image info to be obtained on start.
Steps to reproduce:
- Drop an "Items" block.
- Click on an image.
- Click on another image.
=> The options panel flickers on the 'Blocks' tab before showing the
second image's options.
[1]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2821398
closesodoo/odoo#111094
X-original-commit: d5cb2810968476b82f30582cd0d6cfdbaf351b2b
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Before this commit, a traceback would be thrown when no options were
passed to `_getEditorOptions` because of a code mistake using the
variable `options` rather than `finalOptions`.
Also, this error revealed that the `this.options` of the wysiwyg could
be wrongly reset if no argument `options` was passed to `resetEditor`.
task-3149085
closesodoo/odoo#111100
X-original-commit: 475775d3dfc230c06c7a2b127b67bc22543e8a27
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
To reproduce the issue:
- Website page (e.g. "Contact us") > Edit mode > save.
- Try to click on the page right after the save (and before the preview
is blocked) > traceback.
In this specific case, clicking in the page will activate the targeted
snippet and initializes its "SnippetEditor" while destroying the
options and cleaning the DOM, leading to wrong behaviors.
The goal of this commit is to fix this issue by simply ignoring the
click on the page during the save process.
opw-3119347
closesodoo/odoo#111030
X-original-commit: 6bf3823c2996af4ec0534ff69471887ac43a8ddf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this commit], a tooltip is displayed on the blocks that can be
dropped in a page so that the user understands that he must not just
click on it but drag and drop the block. Unfortunately, these tooltips
were not well positioned in the email marketing application because the
editor is in an iframe in this application. This commit allows to
position correctly these tooltips.
Steps to reproduce the bug fixed by this commit:
- Go to the email marketing application
- Create a new mail
- Select a template other than "plain text".
- Triple click on a block
=> The tootlip is displayed way too high.
[this commit]: https://github.com/odoo/odoo/commit/a50c09e3b432d7601cd0e02cbbfabe24a67ba70f
task-2777738
closesodoo/odoo#111011
X-original-commit: 42d32a4f40d685e10f2ae4bb678df2009cb4bd21
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In [1], conditions have been made in order to allow/forbid each snippet
to toggle the grid mode. However, a case has been forgotten: when a
snippet that cannot toggle the grid mode is dropped inside a snippet
that can toggle it (so it is an inner snippet). Indeed, if we drag one
of the inner snippet columns, we can see that the grid mode is toggled,
where it should not be the case.
This issue comes from the check looking if the grid layout option is
in the right panel. Indeed, even though such a snippet does not have
it, if it is dropped inside a snippet that can toggle the grid mode,
then the option is well present in the right panel (= the outer snippet
one).
This commit fixes this issue by improving the check: now, dragging a
column can toggle the grid mode only if the container having the option
is the same as the one of the column. This commit also improves the
siblings/children filtering (to only have the relevant dropzones) in
order to take this case into account and to be more robust to
customizations.
Steps to reproduce:
- drop a Text-Image snippet
- drop a Form snippet inside one of the columns
- drag a form field
=> the grid mode is toggled.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
opw-3100399
opw-3139938
closesodoo/odoo#110888
X-original-commit: 34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
https://github.com/odoo/odoo/pull/102662 Highlighted the fact that in some
cases, an rpc call can be done on a destroyed component.
There is such a case in Knowledge, which now causes a warning in some cases.
Impacted Versions
- 16.0 and higher
Steps to reproduce:
- create a new article in Knowledge
- type the space character: [ ] in the article body
- switch to another article
Current Behavior:
- warning
Expected Behavior:
- no warning
Contents of the fix:
Do not try to update the value of the html_field if the component is already
destroyed. This could happen when an urgent commitChanges was requested (i.e.
when leaving an article to open another).
Task-3101553
closesodoo/odoo#110862
X-original-commit: 1b683bd600bbf5c39c520afa041c4f6124c9dea8
Related: odoo/enterprise#36232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The JSON object can contain characters such as `<` (i.e. in domain expressions
for the act_window object of an embedded view). This means that the JS sanitizer
DOMPurify will remove the attribute when parsing a node that contains it.
Instead of encoding/decoding that attribute each time the DOMPurify sanitizer is
called, we could encode at all time, and decode it only when we use the value it
contains, since JSON.parse has to be used at those times anyway.
This way, we don't pollute OdooEditor.js code, which is already quite complex.
Task-3101553
X-original-commit: 7686ae282c97bc255ebb66367b39447b7bc1749b
Part-of: odoo/odoo#110862
Steps to reproduce the bug :
- In Website (edit mode), drag & drop a "text-image" snippet.
- Click on the button.
- Change the size of the button to "small".
- Click outside the button.
- Re-click on the button.
- The size selected in the options is "medium" and not "small".
Note that the same bug exist in backend with the link dialog.
This bug was introduced in ([1]), the code of the "else" (which was
removed by it) made it possible to take into account the cases where the
option had no "value" (e.g. "medium" size button). And so, without this
"else", the options without "value" were activated in any case.
This previous commit, which fixed an issue with the presence of the
"btn-success" class on a link, could in fact be based on what had
already been done for the links with the "btn-link" class (in [2]).
In this commit, this issue with the "btn-success" class is handled the
same way as for "btn-link".
[1]: https://github.com/odoo/odoo/commit/4c68b3e923610e1d573b4bd2b241b2fc5923c412
[2]: https://github.com/odoo/odoo/commit/c3e08e7a7baab1035c3d5c48d668cc02a232e1ac
task-3002177
closesodoo/odoo#110809
X-original-commit: 5e98953d67042dcffa978ab7d240d8677e847456
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
When inserting a backtick in text that has another backtick before
(case 1) or after (case 2) it, we convert the text contained between
said backticks into inline code. Case 2 was not tested, and didn't work
properly.
closesodoo/odoo#110784
X-original-commit: cc2a4a960d6d83362e35abc8a253e95105fd07f9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Wrong syntax made it so that having a text node after the text node in
which we're inserting a closing backtick character, converted all the
text after the backtick to the word "NaN". This fixes that syntax error
and ensures such cases are properly handled.
X-original-commit: 2833b42c09582dbcfed334d9fe6628a8eaf476b8
Part-of: odoo/odoo#110784
Before this commit, this flow was broken:
- Install website
- Create a new website of your own (not using the one created
automatically from XML data)
- Choose another color palette for that website
- Uninstall the website app
- Reinstall the website app
- Try to choose another color palette for any website
=> It does not work
Indeed, after the uninstallation, the DB is left in an invalid state:
the SCSS customizations attachments of the website that was created by
the user are not removed, they just have their website_id field emptied.
Some code made at [1] was already there to remove those attachments. The
problem is that it only worked for websites which were created by XML
data (at website installation), not by the user. Indeed, the `unlink`
method is not called during uninstallation to remove records that were
created by the user, thus the `unlink` override was not called either.
See [2] for some details.
This fixes the issues by moving this attachment cleaning code in a
dedicated method, called in `unlink` but also in the `uninstall_hook` of
the website app.
This also takes the opportunity to refactor the code involved, in
particular to not even consider customized attachments which do not have
a website_id.
[1]: https://github.com/odoo/odoo/commit/2f361bec36dff09181b96d140d62c477cdf013a1
[2]: https://github.com/odoo/odoo/pull/97852#pullrequestreview-1067851656
opw-3127531
closesodoo/odoo#110338
X-original-commit: 988eafa03b57be3b3a7f110650c61ce8fda88e31
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Florian Charlier