To reproduce the issue:
- Website (edit mode) > Drop a snippet with icons (e.g. "Steps").
- Open mediaDialog to change an icon.
- Select the same one (or click immediately on "ADD") > This will set an
empty icon (without any "fa" specific class).
The code on `MediaDialog` > `save()` adds CSS classes from the original
icon to the new created one then removes the old 'fa' classes from it.
(see `initialIconClasses`), as a consequence, the class will be deleted
(not replaced) when the selected icon is the same as the old one.
The goal of this commit is to fix this behaviour by simply closing the
dialog if the selected icon remains the same as the old one.
task-3210472
closesodoo/odoo#114345
X-original-commit: 0515e987b985622bc7b913dbbb37c0d0cd69eb4b
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This commit fixes an issue with the width of items in the we-list not
being correct when they are being dragged using jQuery's sortable
feature.
Steps to reproduce the bug:
- Drop a "Form" snippet on a page.
- Add a "Multiple Checkboxes" field in the form.
- Move an option from the list using the move button.
- Bug: while dragging the item, the width of the items is too small.
When an element is dragged, it is given an absolute position which takes
it out of the normal flow of the document, causing the input element
within the list item to no longer be able to correctly occupy 100% of
the available width.
task-3138662
closesodoo/odoo#114343
X-original-commit: e0a4ed0b21a9f87678e13609ff597cf1b3ae4189
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Dispatch events `onExternalHistorySteps` and `historyResetFromSteps` so that
they can be catched by the html_field to trigger a `refresh_behaviors`, in order
to refresh (instanciate) Behavior components.
Task-3208896
closesodoo/odoo#114262
X-original-commit: 9c6ed77988e20855ca67c5f1e03d9d2e274442cf
Related: odoo/enterprise#37745
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, it was possible to drop a snippet in a non-editable
area (e.g. dynamic snippets).
Steps to reproduce the bug:
- Drop a "Dynamic Products" snippet in a page.
- Drop a "Columns" snippet in the same page.
- Moves a column from the "Columns" snippet into the "Dynamic Products"
snippet thanks to the "drag and drop" button.
- Bugs => It works when it shouldn't.
task-3054763
closesodoo/odoo#113796
X-original-commit: 4d61c356b7deed7fd0b01cb817c274afe384c0ac
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
When a peer "A" connect to the peer to peer network, if he receive a
stale document from a peer "B", peer "A" will never be able to save.
This situation can make impossible for any new peer to receive a
converging document and block the ability to save until every peer
disconnect from the network.
task-3196778
closesodoo/odoo#114268
X-original-commit: 537f34f764fae3967496d466c420d72d172b241d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, animations on SVG shapes could use a lot of CPU
and make the page stutter on some website + machine combo.
This does not seem to be an "Odoo Only" issue as browsers seem to
struggle to optimise SVG movements and end up consuming a decent amount
of CPU depending on the machine, the size of the SVG and its position
(behind or on top of other elements).
This commit applies a new class which will warn the browser that the
element is animated. Depending on the browser, some optimisations are
done.
On Chrome and Safari, a new layer is created which simplifies the
rendering of the page and sometimes takes advantage of hardware
acceleration.
On Firefox, no optimisation is done yet. This might change in an update
which would take advantage of the CSS Property.
The documentation says to only use `will-change` when an element is
about to change. This is the case however, as most of the shape's
animations are looping. Which is why it's applied to every shape that is
animated.
This optimisation only applies to background shapes with this commit.
Performance improvements observed by (at)rdeodoo on his machine:
- SVG: 200% CPU
- SVG + fix (will-change): 55% CPU
(additional infos available in the PR)
To note: one way to easily see the improvement is on the "Layers" tab of
the Chrome devtools. Before this commit, the entire #wrapwrap is
repainted every time the shape changes (so 60 times per second since
that is the framerate the browser aims for). With this commit, the
#wrapwrap and the shape are contained in their own layers so the
#wrapwrap is only painted once.
Other solutions were considered but not used at this time:
- Reducing the frame rate of the animations. This is not currently
possible because browsers do not offer any way of doing that.
- Removing bits of the shape can reduce its CPU consumption, but
whenever a transform animation is present, the CPU usage remains high.
task-3142001
closesodoo/odoo#114252
X-original-commit: 03418be1c67e71a22f6d2ce79675280f889b663c
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit:
For the safari browser, when typing any URL and pressing space, and
continuing typing, the cursor jumps before the URL.
After this commit:
Inserting an element into a range clears the selection in Safari.
Hence, use the cloned range to reselect it and now the cursor position remains
at the end of the URL.
Task-3089091
closesodoo/odoo#114192
X-original-commit: fa532d1391aed313a9ea13ac8a4ab9df31c313e3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
When copy-pasting from Discord into Notes, get a text with color and background
color. But when clicking on the trash icon inside the toolbar to remove the
background color, it doesn't remove the background color.
After this commit:
Allowed to remove background color from text using trash icon.
Task-2889682
closesodoo/odoo#114146
X-original-commit: 711ddaf97a5f16b3fe0d5d30dba52e4c9eab8d21
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove setDirty prop from concrete fields. Now if
needed the fields can declare itself dirty using triggering
"FIELD_IS_DIRTY" on the model's bus.
Note that this PR partially revert [1] and completely revert [2]
task-id 3179751
[1] : 89c2a3978e
[2]: c79bb3c9c6closesodoo/odoo#114124
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] introduced a usage of `structuredClone` in 16.0 where
it is not supported. This was a mistake introduced by backporting
[2] from master to 16.0.
However, the `structuredClone` was not necessary in the first place
anyway, so this commit removes it.
[1]: c472e600da3237d3cb0a6352a4d26ebb3ed6e20c
[2]: a5036864b1closesodoo/odoo#114082
X-original-commit: 222ad55966d9161394b9412a5baf14043b36baea
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when moving inner content inside a carousel slide
(with the 'move' button), the carousel was jumping to the first slide.
Steps to reproduce the bug:
- In website edit mode, drag and drop a Carousel snippet onto the page.
- Move to the second slide.
- Click on the column to activate its overlay.
- Click and hold the "drag and drop" button of the column to start
dragging it.
- Release the mouse button.
- Bug: the carousel jumps to the first slide.
task-3006831
closesodoo/odoo#114067
X-original-commit: a09031d5f68de5d23bd9cab1910c6f9c50ad7cfd
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In this commit, the horizontal sizing options are disabled from the
snippets overlay on mobile view as they were ineffective and
unnecessary.
task-2978500
closesodoo/odoo#113945
X-original-commit: b7359e47ce3888433a31592a365017c1183242a7
Signed-off-by: loco-odoo <loco@odoo.com>
Before this commit, we-matrix could create a horizontal scroll bar in
the editor. This was because the inputs had a minimum width size.
Steps to reproduce the bug:
- Drop a chart block on a page
- Add some series
=> The matrix overflows from the editor.
There is no perfect solution to this problem... We have the choice
between:
1) Leave the existing overflow on the editor.
2) Put a horizontal scroll on the we-matrix.
3) Distribute the available space between the columns.
As we don't want a horizontal scrollbar, the best solution is to
distribute the available space between the columns. This solution has a
drawback which is that the cells can become really small if there are a
lot of columns but this solution seems to be the least bad from a UX
point of view.
task-3094162
closesodoo/odoo#114062
X-original-commit: 356e0a1fe5243078ba5f162b383279ae7e6a8136
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
The `target` attribute for a link specifies where that link should open
(for example, in a new tab). Previously, copy-pasting links in the
website editor (within text blocks for example) would remove the
`target` attribute. This implied loss of functionality.
This commit whitelists the `target` attribute to fix that behavior.
task-3184150
closesodoo/odoo#113908
X-original-commit: 1464752aca36198e5fed5dc8f5b5041244e6e4a9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The `isHtmlContentSupported` function incorrectly returned `false` for elements
inside `data-oe-type="html"` nodes even though those in fact do support html.
task-3184150
X-original-commit: 7d9a040fdefa527ace3150e39a03b833024b7973
Part-of: odoo/odoo#113908
Commit [1] added buttons with a `data-dependency` equal to "fake",
thinking it would hide those buttons automatically as the "fake" widget
would not exist. Somehow this got merged despite the fact that was not
working (testing probably focused on the more important things [1] was
fixing). At some point, using a fake dependency was hiding an element
but this changed one year earlier with [2].
This commit explicitly hides widgets with `data-dependency="fake"`.
[1]: https://github.com/odoo/odoo/commit/f59affcdfe9529645a02680214f3d7d96ebacf6e
[2]: https://github.com/odoo/odoo/commit/e927d1e89bc124002bb5e0b69dee711ea0d8147c
task-3208632
closesodoo/odoo#113936
X-original-commit: 7a46759a529b2d781585e0dbcb99bf7084c88007
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], an `align-items-start` class is added when going from
grid mode to normal mode in order to always have one of the four choices
of the Vertical Alignment option selected. Indeed, without this class,
none of them are chosen. However, only a few snippets have this option
and it is therefore not possible to modify this class easily in the
snippets that do not have it (except removing it from the DOM manually).
The real issue in fact comes from the computation of this option widget
state, which should select the last button (so the `align-items-stretch`
one) if no class is present, since the behaviors are equivalent in these
two situations.
This commit removes the addition of this `align-items-start` class and
fixes the `_computeWidgetState` of the Vertical Alignment option.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
task-3142615
closesodoo/odoo#113949
X-original-commit: 75ef0d5d7ed000cf55b47bebb00cc2d0bb34b581
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Since [1] it is visible that there is a race condition in the editor.
The race condition was caused by a call for an update of the option
visibility during the save, but the options may be in the destruction
process. This commit prevents the visibility of the options from being
updated when the option destruction process begins.
Before 16.0 (the merge of the frontend into the backend) the bug was
easily visible by following these steps:
- Drop 2 times the image - text block on a page
- Drop a popup block
- Save
=> During the save, a traceback occurs.
From 16.0 the race condition is more difficult to see but we still need
this fix because the problem is still there.
Note: this forward-port commit took time to get merged in master.
Meanwhile, two fixes related to it were merged in stable. The first one
already reached master a while ago ([2]) but had thus no effect as was
relying on this particular commit here. This is actually great as [2]
introduced a big mass mailing bug, fixed by the second fix which is yet
to be forward-ported to master. That one has actually been put as this
current commit's parent so that [2] is fixed before it can create the
mass mailing bug.
[1]: https://github.com/odoo/odoo/commit/686e011f9b54bcfe93cc22db24435d2ca9213664
[2]: https://github.com/odoo/odoo/commit/6bf3823c2996af4ec0534ff69471887ac43a8ddf
Related to opw-2971181
X-original-commit: 47cdb15082f774da0aa07e289361445ddc3a48f1
Part-of: odoo/odoo#107387
Co-authored-by: xO-Tx <mou@odoo.com>
Starting from [1], a `willDestroyEditors` attribute was added to prevent
race conditions caused by an update on options visibility during the
"save" (after checking the code, it seems that the issue here was caused
by the `hide.bs.modal.SnippetPopup` event which triggers the
`_onSnippetOptionVisibilityUpdate()` handler on `snippetMenu`, leading
to a traceback if editors are destroyed).
So with this fix, the visibility update will be ignored during the save
process.
[A] Note that `willDestroyEditors` is set to `true` on `cleanForSave()`
and never set to `false` after saving the content or destroying the
editors.
Another fix was added in [2] to prevent the click (before the preview
is blocked) on the page while saving, and uses the `willDestroyEditors`
attribute to ignore the click.
Now since `cleanForSave()` is called on `MassMailingHtmlField` >
`commitChanges()` and because of [A], the click will be always ignored
on this field's content.
The goal of this commit is to fix this behavior using a global
`savingContent` indicator which will be used to handle both cases
(a click on page & options visibility update) during the save.
It will be only set to `true` during the content save.
Note: the forward-port of [1] actually took too long to reach master.
Actually [2] already reached master, having no effect as relying on [1].
This commit here will actually be merged first (preventing [2] to create
the mass mailing bug when [1] reaches master). [1]'s forward-ported
version will actually be the commit following this one.
[1]: https://github.com/odoo/odoo/commit/47cdb15082f774da0aa07e289361445ddc3a48f1
[2]: https://github.com/odoo/odoo/commit/6bf3823c2996af4ec0534ff69471887ac43a8ddf
X-original-commit: b2b8590d19e07659c6ad7c3e3afba0a848b414a5
Part-of: odoo/odoo#107387
When switching records, the editable content of the previous record
is replaced by the one of the new record. Unfortunately, there was
no code that handled restoring the placeholder in case the new
content was empty after the change as this was previously only
handled in the constructor.
closesodoo/odoo#113811
X-original-commit: a3c236ef0e047127583f6565461f0b90781584e4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This event listener was added for the `historyStep` event of the editor
in [1] as a proxy for the `input` event of the editable node. This was
wrong because the `historyStep` event is also triggered at other times
than when the user makes an input.
In particular, it is called when switching records. In such case, the
new value from props can be '' which is not suitable for edition, so
it is replaced with '<p><br></p>'. But since that happens in a function
that is going to call `_historyStep` and the editing value was just
changed to something else that the value received in props, the listener
from [1] would make it dirty and thus trigger a re-render etc.
This commit fixes the issue by modifying the listener in such a way
that it listens to the proper event it was intended to target.
[1]: f56e3bca2456f04616982a9a0e77b8d4c5a0abff
X-original-commit: 384ff11f06ba86360f1993cf0c8a17c2dbaa11de
Part-of: odoo/odoo#113811
Before this commit:
Creating a new record and saving it afterwards does not show the placeholder in
the description.
After this commit:
You will see placeholders when you create a record and save it.
Task-3167136
X-original-commit: 793e48ae0478ead38ed6ac7c9a71228e2678e2c7
Part-of: odoo/odoo#113811
This removes calls to JQuery in the convert to grid tests and the
functions they test. In the process, these tests are abstracted for
better readability and maintainability.
closesodoo/odoo#113784
X-original-commit: 3eafc2d3425365bfb25b0540de95aab4e7d89ebf
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit abstracts the cell creation in the bootstrap grid inliner
tests so as to make it less wordy, easier to read, and easier to write.
X-original-commit: beceaf05f333596816623417f827ea8cdabc7097
Part-of: odoo/odoo#113784
When we convert a Bootstrap grid to a table, we sometimes need to create
filler cells to make sure the table has the same number of columns as
the grid. A mistake creeped into that process, and we were not applying
the max-width to the filler cells.
X-original-commit: a546eb1374bbe72606203ccd60322d5063a5de38
Part-of: odoo/odoo#113784
When inlining e-mails, we convert font icons to images by calling the
font_to_img route with the icon's dimensions. To get the icon's
dimensions, a call is made to `convert_inline`'s `_getWidth` and
`_getHeight` functions. These functions assume that calling
`getComputedStyle` on the icon to get its width/height will return a
value in pixels. However, this is not always the case. For example, if
the icon is in a hidden element, `getComputedStyle` can return "auto"
or whatever value is set in the icon's `style` attribute (e.g.,
"fit-content"). This commit ensures the return values of `_getWidth` and
`_getHeight` are always numbers as expected.
Doing this also reveals a false negative in the tests where the grid to
convert is not added to the DOM before calling `bootstrapToTable`. Since
`_getWidth` returned `NaN` in this case, `style.setProperty` failed
silently and no max-width was set on the cells. The tests didn't account
for the missing max-width, which now suddenly appeared with this fix
(NaN failed but 0 doesn't). This commit fixes the tests by adding the
grid to the DOM before calling `bootstrapToTable`, and adding the
expected max-width to the expected result.
X-original-commit: 73b404df9be1ba28a784711174cc19e7c599099e
Part-of: odoo/odoo#113784
When converting the field html to owl, the mediaModalParams were
not properly assigned to wysiwygOptions.
task-3097156
closesodoo/odoo#113739
X-original-commit: 1e02313ebb98c7da4823a251a8abdd4edeece7b6
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since
https://github.com/odoo/odoo/commit/1b8d663cdccced35fd294ef3481aa7ce294880f0,
in `updateValue`, the `value` and `lastValue` could have different
`data-last-history-steps` and still be the same value.
This commit fixes the method to compare the values stripped of their
history ids.
opw-3134569
closesodoo/odoo#113726
X-original-commit: 5abb2ced63caffaf528f7b71eb1c193729ecd327
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, the responsive behaviour of the toolbar was a
scroll-x.
I added conditions with widget.isMobile(), to allow the layout to change
in mobile (ex: all the list options in a dropdown).
closesodoo/odoo#110161
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, there were functional issues for the floating toolbar
and design issues for the Powerbox in the web editor.
This commit fixes those issues, like alignement for the icons in the list
of the commandbar, box shadows, and the responsiveness of the floating
toolbar on mobile.
In commit [1], the toolbar dropdown had the display static added, but it
causes problems to the responsiveness.
This commit put the display back to dynamic on the dropdown and so, fixes
the dropdown not showing on mobile because of the overflow-x on auto.
The dynamic state also allows the dropdown to change direction (dropdown
to dropup) when there's not enough space for the content of the dropdown.
Would be nice to have : use display state on the all the editor
toolbars (frontend and backend) to modify the layout of the toolbar for
mobile, for a better behavior and design (ex: the different lists in a
dropdown).
For now, it's just a horizontal scroll.
[1]: 459d4e27a8
task-3087826
Part-of: odoo/odoo#110161
The presence of the history ids in the html resulted in false
positive in the `_isDirty()` comparison. This lead to unwanted
writes when switching records, even when no change were made.
task-3186072
closesodoo/odoo#113633
X-original-commit: dcd3a538ecd4d7dc35bd7de6a8e2655e7392660a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Starting from [1], the `_updateColorpicker` method was added on the
"link tools" widget to update colorpickers with the selected link colors
(and it will create the colorpicker for each CSS property on widget
`start`).
Following this update, the code on [2] and [3] added some fixes to
handle the async parts of `_updateColorpicker`. [3] was done very
recently, more than one year later after the introduction of [1]. It
turned a synchronous method into an asynchronous one (rightfully
considering the async calls to `_updateColorpicker` that were inside).
As a fix, this commit will try to re-made it a synchronous method, and
other parts related to `_updateColorpicker` too.
The goal of this commit is to separate the link tools colorpicker
"creation" code (`_addColorPicker` now) from colorpicker's "update"
code. These changes are supposed to fix a race condition issue that
appeared on 16.0, but since the code is the same on 15.0 and subject to
the same issues, we target 15.0 with this fix. Hopefully, this prepares
for an easier refactoring in master.
[1]: https://github.com/odoo/odoo/commit/26d37812f0217ae913c8ddf761bcb26b5c44bff5
[2]: https://github.com/odoo/odoo/pull/78301/commits/6f1a6b76642db2e4f81cf3474ad0ec745a4bb3c9
[3]: https://github.com/odoo/odoo/commit/d15fdca644ef9ed1dfb011d3790f403e0157f55b
runbot-5753
closesodoo/odoo#113510
X-original-commit: 2d4a3efe0d7c9618c388575b4bb652a26913fe68
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Using a lazy `?` quantifier lead to poor matching performances and
was not needed technically.
Using `*` instead of `+` lead to a lot of false positives when trying
to write records with an empty value for `data-last-history-steps`.
It is currently unclear how to reach such a case but in the meantime
it is better to allow people to write the record as such rather than
being completely locked with no possibility of saving.
closesodoo/odoo#113540
X-original-commit: 0a370758972e6a0c399471f9982f3898da92ef68
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Olivier Dony <odo@openerp.com>
Because the `selectionchange` event is async, the selection can
be null if the node has been removed between the moment the
selection was moved and the moment the event is triggered.
X-original-commit: 3232edb1ccb196c992f75858fe81d08a5af58ab9
Part-of: odoo/odoo#113540
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When drag and dropping a grid item and then undoing the operation, it
is not undone correctly, causing the grid items to be broken. This
happens because since `observerUnactive` is called at the start of the
drag, the style (like the `grid-area`) and the grid classes changes are
not recorded and therefore, undoing does not restore them.
This issue was previously fixed in [1] by removing the call to
`observerUnactive` but it should not have been done and this call was
restored in [2].
This commit solves this issue by activating the observer for the
changes that have to be recorded when drag and dropping in grid mode,
in order to undo them properly afterwards.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/pull/106029
task-3074139
closesodoo/odoo#113384
X-original-commit: 1dfb127f70832aa9e9022ac337af343b7dc17729
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
In the website editor, a traceback error occurs when clicking on the
main element since the commit [1]. This is caused by the function
'_handleSelectionInTable' calling 'selection.getRangeAt(0)' without
checking if there is at least one range in the selection.
Steps to reproduce the bug:
- Open the website editor and drop a text snippet onto the page.
- Click on the snippet to activate it.
- Click on the empty area below the snippet, which corresponds to
the <main> element.
- A traceback error will appear (if it does not appear, repeat the
first three steps multiple times).
[1]: https://github.com/odoo/odoo/commit/d977bd64fe88c059c915f9eb0f8029cde65b216a
task-3196722
closesodoo/odoo#113383
X-original-commit: 6e79728c7e812458709d3a60ba37dc4c578905b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
Following this flow on the Media Dialog:
- Type "hell"
- Wait a few ms so that the RPC to search images starts
- Type "o"
- The RPC of before finishes, the o is removed and no new search is done
Before this commit, the search input value of the SearchMedia component
was coming from a "needle" props. This needle prop was a state on the
parent component (FileSelector), set through a debounced handler.
This is not a good design:
- Type "hell": after 1000ms, the debounced handler will be executed with
the value "hell"
- While the handler is executing: type "o"
- When the handler finishes, it has set the needle state value to "hell"
on the parent. This will rerender the SearchMedia with "hell" as a
needle prop, and the "hello" input will be replaced with "hell".
Instead of doing that, the SearchMedia component should have its own
input state, which models the input element.
On that state, we use an effect to call the debounced "search" callback.
This way, the SearchMedia is less dependent on its parent: it only
rerenders when its input element changes.
Additionally, the fetch results are only used if they are the ones from
the last call to `search`.
Dedicated `KeepLast` instances are used for attachments, media library
and unsplash.
task-3060679
closesodoo/odoo#113188
X-original-commit: 08859ca7939454303e34dc39c831ac8f75773c3d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Commit[1] intended to change the color of links in the editor to make them more
visible by making them a slightly lighter color. However, it did so in a way
that also applied to button links, which already had different colors. In the
case of primary buttons, it actually made the links less readable as a result.
This commit excludes buttons from the original css rule so that they keep their
special style while still maintaining the intent of the original commit.
[1]: 47c73c7213
task-3131568
closesodoo/odoo#113141
X-original-commit: a40bca916ac17338d82c52afd7c0eedd96d4a49d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, creating a link through the link tool made two
steps instead of one.
task-3147819
closesodoo/odoo#113135
X-original-commit: d967c21b6abdccd45f3c767925de29e874497dd4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when discarding a link in linkDialog, there was a
link and a history step that were created. We now properly come
back to the state of the editor before the linkDialog was opened.
task-3147819
X-original-commit: 79205c8df555d7194d4a8a0ad4f04a9f7dc7f535
Part-of: odoo/odoo#113135
When clicking in a link in the forum, the link dialog was opened.
This is wrong as there the link popover is shown and to open the link
dialog, we must click on the button in the link popover.
task-3147819
X-original-commit: 5c5aa21dffe3691547766cf1f16065ae74c41f07
Part-of: odoo/odoo#113135
Using the web_editor html field in the Record component causes crashes.
Why does this happen?
The fields used in the Record component do not always have modifiers.
Solution:
Use the isReadonly function of the record to know if the field is
readonly or not.
closesodoo/odoo#113072
X-original-commit: 5354321877b65d577c419255ce43806f648e1708
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit [1] removed the protection around the call to setDirty because setDirty
is always defined when the field is initialized through the standard field.js
mechanism. However, in todo_list.js in hr_payroll, the html field is called
without going through that mechanism, resulting in the prop being missing and the
call to fail with a traceback.
This could be fixed by adding the missing prop to todo_list.js, but other people
are likely to do the same mistake in the future so adding a default of our own is
probably better to avoid future similar bugs.
[1]: https://github.com/odoo/odoo/commit/f56e3bca2456f04616982a9a0e77b8d4c5a0abffclosesodoo/odoo#112994
X-original-commit: a6043b3aa290d6cecaabc02995e490f44cbd6ce2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The default font size of the frontend is 16 so the `default` option
in the font size dropdown was supposed to be enough for this use case.
However, this is not true in the context of website_blog where the
default font size of blog content is not 16. This is not a problem
because if the user does not like the default blog font size then
they can change it using the font dropdown... except they have no
way to select 16 for a size and `default` doesn't mean 16 in blog.
This commit adds an explicit entry for 16 in the font size dropdown.
opw-3110711
closesodoo/odoo#113011
X-original-commit: a35679d5a30e3931216c65ff4ea896e507ba4cf1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
xO-Tx