Before this commit, following this flow in the Website Builder:
- Enter edit mode,
- Drop a snippet with text,
- Paste a youtube video link,
- Click on the "Embed Youtube Video" option of the powerbox,
=> There is a traceback.
This is coming from the bad function calls in the Wysiwyg to create a
video node.
When [1] reworked the MediaDialog in owl, a first implementation was
done exporting some utils (saveVideos, videoSpecificMediaClasses). But
this implementation was not kept and later changed to use static methods
and properties on the VideoSelector class (createElements and
mediaSpecificClasses).
Unfortunately, the outdated util methods used in the Wysiwyg were not
changed, and it was breaking the youtube video instertions.
This commit changes the Wysiwyg to use the existing
VideoSelector.createElements and VideoSelector.mediaSpecificClasses
static method and property to fix this flow.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#105475
X-original-commit: 4923c20c29170407d43908f983f2a168241f4817
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Website themes make customizations to the default snippets. In
particular, some are applying shapes on default images. To do that, the
customization is not applied on the image directly but by changing its
src to a special web_editor route in charge of automatically adding the
shape on whatever default image the configurator chose for this snippet.
Typically, in a snippet with an image whose src is:
/web/image/website.my_snippet_default_image
The src is replaced by the theme with:
/web_editor/image_shape/website.my_snippet_default_image/website/some_shape.svg
That controller/route crashed since [1], making those images blank
areas in pages generated by the configurator. Indeed, the image from
the filestore was accessed via `file_open` which only allows reading
inside the addons_paths.
[1]: https://github.com/odoo/odoo/commit/da8def8e410de68256ba4ab09ebf7a8b699355acclosesodoo/odoo#105421
X-original-commit: d536e0a23cf0aa06c3ee13fb2c105e83201434e0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Prevent the PowerBox command bar to open in (non html) Odoo field
embedded inside the editable zone.
task-3040872
closesodoo/odoo#105372
X-original-commit: cab3a9b9b89a6b1c0d430e5374feb2f963e466fc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
The rpc service has a protection (when used via useService) that
prevents the returned promise from being resolved/rejected if the
component has been destroyed meanwhile.
However, as the FormView still uses the legacy BasicModel, all rpcs
done by its model do not go through our new rpc service. As a
consequence, before this commit, they did not benefit from the
protection. This caused a non deterministic issue in the main flow
tour.
This commit implements a similar protection as the rpc service, but
specialized for the BasicRelationalModel, which redirects all RPCs
done by the BasicModel.
This change highlighted two scenarios where we sometimes performed
RPCs (or could perform RPCs) on a destroyed component. This commit
fixes those as well.
X-original-commit: f613e916d5e8b465fc360e340094c09037450ff1
Part-of: odoo/odoo#105332
Tests for `deleteBackward` with a non-collapsed selection should always
be repeated using `deleteForward` to ensure the behavior is indeed the
same for both. This was not the case for some of the tests.
task-3032817
closesodoo/odoo#105217
X-original-commit: 183246102406ccb4730ee2e11c8d42ccca6dce6b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Tables have their own custom selection in Odoo Editor, so rectangular
cell selection is supported. Selecting a whole row/column/table then
pressing delete/backspace removes the whole row/column/table. But just
selecting some cells should only empty them, which we failed to do,
resulting sometimes in broken tables.
The code to remove selected rows/columns/table was triggered when
pressing backspace/delete, which failed to account for cases where we
need to delete the range without pressing those keys (for instance when
typing a character). This moves that code to `deleteRange` so as to make
it the standard behavior when deleting a range that includes table
cells.
task-3032817
X-original-commit: fad5d2d7e241e22382a2f3dc0fd68eca741e59a7
Part-of: odoo/odoo#105217
deleteBackward and deleteForward tests were just directly calling the
editor's implementation, without triggering events that are sometimes
crucial to the behavior. This is at least preventable in cases where the
selection isn't collapsed, by triggering the keydown event and calling
the document's `execCommand` function with the "delete" command.
task-3032817
X-original-commit: cd7c647f45487e8d8a763875a30e327422af4e68
Part-of: odoo/odoo#105217
With commit [1] the "load more" button of the media dialog went from a
btn-primary style to a btn-secondary style, which is displayed a link.
It was done in an Odoo global effort of making each and every screen
having only one (sometimes two at most) primary action to help the UX,
as explained at [2].
But in this case, it seems to more misses with the UX than helping the
user as that button really becomes invisible without it. We already were
afraid of that but still merge it, see [2] again.
Indeed, in secondary style this button is barely visible due to the
unsplash and undraw image results which have an "author" text like on
top of the image which looks like the "load more" style.
This commit is using the `btn-odoo` class to show it as a button and not
a link to avoid people not seeing it.
`btn-odoo` is chosen instead of `btn-primary` as this is how "secondary
important actions" are designed now in Odoo.
Note that in community, it looks like a btn-primary but that's not
related to this PR.
[1]: https://github.com/odoo/odoo/commit/ff0b2d441252560a076a3609d81c369f0ce42d19
[2]: https://github.com/odoo/odoo/pull/98706#issuecomment-1236804203closesodoo/odoo#105193
X-original-commit: f204d3a6ed5b5de08c7921a0bcd5188d78b0cf8b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This addresses issues with image dropping and pasting.
1. The code to compute the position of the drop was not always run so
that resulted in a sometimes wrong position (dropping at current range
instead).
2. Images dropped internally within a same document should not be
converted to base64.
3. Dropping an image should apply to it the `img-fluid` class so as not
to break the document's layout.
task-2954499
closesodoo/odoo#105137
X-original-commit: 9c258bf18c17a55f1d22c8a7d1b74f5dd51ee73d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The `getTraversedNodes` function sometimes failed to include descendants
of traversed nodes, which should logically be included. Eg,
`<div>[<img>]</div>` where the selection is expressed as `div 0 div 1`:
the iterator is set on the common ancestor, which is the `div`, so it
stops immediately, only returning the `div`. Here we add its ancestors
in every case.
X-original-commit: 0e765277871a57c367d09fc05bb13a9d6670d11d
Part-of: odoo/odoo#105137
When discarding the link dialog, we need to restore the selection in the
editable area. This failed because the selection was recomputed when the
dialog was actually removed from the DOM. This is the same case as a
couple of lines above the restoration of the selection, where we need to
wait for the element to be removed before triggering a focus on the
inserted link.
task-3000250
closesodoo/odoo#104847
X-original-commit: 6b86f6c91fc69bec59f39377e322d79242466d42
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Reading only 'id' with `search_read` is equivalent to use `search` but
complexify the result usage. Fix all these bad usages.
Part-of: odoo/odoo#104838
Co-authored-by: Julien Castiaux <juc@odoo.com>
Change isolation link unit tests to cover both deleteBackward methods :
- deleteBackward via direct contenteditable command
- deletebackward via input event ( mobile )
task-3054245
closesodoo/odoo#105066
X-original-commit: 123051fc8b61e27fc8e39f0fed02a58186fca7e3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Sometimes the link isolation was broken when
the editor rollbacked some browser behavior :
the content editable was reset on the all editable.
And thus the cursor was able to get out of the
isolated link creating issues.
task-2957000
X-original-commit: 0a04ef6c2617741b90c151c367c1731ed180ad70
Part-of: odoo/odoo#105066
We avoid listening to mutation during test selection "[]" rendering.
Those rendering would be registered by the editor and sometimes wrongly
put the editor in rollback mode.
X-original-commit: cb9348e3f7a95d787337b5c3c8fbba5cf6c9e7c4
Part-of: odoo/odoo#105066
Paste a url in the editor from the URL bar of the browser. If you then
select it all and paste another URL in its stead, the zws inserted by
the sanitizer when deleting the selection ends up in the URL.
This is because the sanitizer moves downward into the DOM tree,
therefore change the link URL before removing the zws in its text child
node. To make sure this can't ever happen, we now remove zws from URLs
when parsing them from the link's text content.
task-3054233
closesodoo/odoo#105045
X-original-commit: c4c9627297c0e3e3977cbfd51129227f8ec1ce3c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In commit [1], a check was added to see if a media is editable in order
to prevent its edition if it is not the case. However, this also had as
effect to block the edition of some grid images. Indeed, as the columns
in grid mode containing only an image have their `contenteditable`
property set to `false`, the images don't pass the check because their
parent is therefore not editable.
This commit removes the `contenteditable` property from these columns
in order to make their images pass the check and therefore allow their
edition.
Tests are also added, ensuring that these grid images can be correctly
replaced.
[1]: https://github.com/odoo/odoo/commit/ddade4346347266b7f699d05865578dc96e2bf98
opw-3028116
Fixes#103234closesodoo/odoo#104899
X-original-commit: d8c374e3e6b31bf88aa42952aadf3379936f7600
Related: odoo/design-themes#617
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit:
When we try to add html data in translated email templates then it does not
remove those extra classes from the html code.
After this commit:
Now those extra classes will remove from the html code.
Task-2985072
closesodoo/odoo#104859
X-original-commit: 5e192a3ccd93c3aafda26abdcfae50ab8f0e053e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When a change was added within a field like adding a class (eg. o_dirty,
o_transform_removal, or oe_edited_link), it triggered the
`_observeOdooFieldChanges` mechanism that replace all identical fields
from the first mutated field in the set of identical fields.
The bug appeared when there were two identical in the pages
- field A: first to appear in the document
- field B: second to appear in the document
When clicking on a link inside field B, multiples class could be added
(o_dirty, o_transform_removal, or oe_edited_link) within the fields.
Field A and field B were mutated. This activated the mechanism
`_observeOdooFieldChanges` and replaced the innerHTML of field B with
innerHTML of field A.
That replacement of innerHTML made the reference of the anchor node
in the link tool being outdated and changes made inside that link tool
ineffective.
Step to reproduce:
- Install website
- Go to any page and enter edit mode
- Click on the navbar and in the right panel select Vertical header
- Activate the CTA option in that navbar right panel (should already be)
- Click on the CTA button
- Try to edit the URL in the right panel or any link option (style etc)
The link will not update properly and the history undo create a new
link.
This commit add the ability in the editor to prevent classes from being
taken into consideration in the filterMutationRecords and in undo/redo
and when receiving external steps.
closesodoo/odoo#104872
X-original-commit: e07e149e01646cc2e59c8ac205a5047fd74ae0ba
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
It's impossible to specify a custom color in the text input of the color picker
for the selected text.
After this commit:
It's possible to specify a custom color in the text input of the color picker
for the selected text.
Task-2896109
closesodoo/odoo#104560
X-original-commit: f1f3fcef6cc471fc01da574da26712e643315da6
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The dynamic placeholder result was not added in the
editable dom in some situation. When the editor was
in rollback mode `true` after a `commitChange`
( maybe because of a `_toInline` called) the result
of the dynamic placeholder was rollback.
task-3044924
closesodoo/odoo#104343
X-original-commit: e9bd4f020ff4a5dd4240fde9caef0bded9a2e28c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
When checking whether an element was removable or not, we failed to
check whether it was within the editable area. As a result it was
sometimes possible to accidentally delete something outside of it. To
reproduce the bug, insert a link in a blank editor, then press delete
repeatedly until the whole link is gone, and then one more time. This
deleted an element from Odoo's UI.
task-2993740
closesodoo/odoo#104268
X-original-commit: 55e4e0577ac8a62d57f759572b8a5e608c7582b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: mass_mailing, website
Commit [1] introduced data-option-name allowing to name snippet options
without data-js so that their automatic snippet-option-XXX class was
not snippet-option-undefined. This was indeed useful to target specific
options in tours.
The attribute is however a complete duplicate of data-js (if you use
one or the other, it does exactly the same thing). Indeed, you can
define a data-js without a linked JS class (as it is already done). And
if you define both expecting the class using data-option-name but the JS
used from data-js that won't be the case, data-option-name is simply
ignored.
This removes data-option-name. This prepares refactorings that will be
done in the future:
- The way to define option in XML will be reviewed (probably client
side definitions, probably OWL templates).
- Adding data-js will probably require a JS class to exist, but all
option definitions of Odoo will declare one to ease extensions and
stable fixes.
Those are theoretical at this point though. This commit main focus is
simplifying the code.
[1]: https://github.com/odoo/odoo/commit/7b0a147cd43e8e890ebe5a882292a69a5c8c90acclosesodoo/odoo#103988
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.
This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.
Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:
- Current height is 700px
- There is some code that forces a min-height on all carousel items so
that they are the same height. As the gallery image dimensions depend
on the block forced height (this is how the snippet work), the forced
min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
is already set)... it ends up removing it as it thinks that setting
that height is not needed as the snippet is now "naturally" 800px tall
thanks to the carousel items' min-heights.
opw-2838774
closesodoo/odoo#104068
X-original-commit: d4d0da320d42093e720c7d440cf6611249c0295a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit:
When trying to edit a link with mailto, there is an "https://"
added and preventing the link to work successfully
After this commit:
The mailto part of the link is correctly kept as is and the link works.
Task-2961012
Task-2977682
closesodoo/odoo#104064
X-original-commit: a22d6d1859a8f97c3cccdba755392cd13d7eb866
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, the table border color was only applied to the
columns (left and right borders).
This commit applies the border color to all borders and adapt the color
to be consistent with the dark mode.
task-2710677
closesodoo/odoo#103162
X-original-commit: fc8a0653c2e98cbda9c1ff60f3a5ea7347aadd48
Related: odoo/enterprise#32786
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit:
The behaviour of the text were not identical in edit mode and after save, the
word was wrapped in edit mode.
After this commit:
To make the behaviour identical by unsetting the default overflow property
in edit mode.
Task-2878307
closesodoo/odoo#103975
X-original-commit: 6177fac863a29c86ed4e5ede8d48aa31da3a8508
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When a change was made on the same record, the editor could wrongly
be reset.
Step to reproduce:
- Go in knowledge app
- Click inside the editor outside a template block
- Click on inside a template block
- Click inside the editor outsie a template block
=> The editor is reset
closesodoo/odoo#103947
X-original-commit: d0a079a76c3f5078178717966e3d4caf0987ebf9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- Edit
- Add a snippet with columns
- Save
- HTML editor
- Set up a border on one column of the snippet with different colors for
the top/right/bottom/left sides
- Edit
- Click on the column => crash
This is only an example, but if a colorpicker widget is linked to a
SnippetOption instance's `selectStyle` method designed to handle the
"border-color" property of an element, the value received can be split
if the item uses different colors for its top/right/bottom/left borders.
For instance, you could receive "red blue" if the item has red top and
bottom borders and blue left and right borders. In that case, the
colorpicker widget code would try to add the class "bg-red blue" on its
preview item which would crash because of the space inside).
After this commit, we simply do not show any color for this case.
opw-2803311
closesodoo/odoo#103842
X-original-commit: 484230481cd7195e2c992e673a2b6e627baf505d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When a table isContentEditable=false:
- Don't show the resize cursor
- Don't show the table ui menu (which allows to move columns/rows)
Currently in Knowledge, when an embedded view contains a `<table>` element, it
was possible to use the editor to edit rows and columns of the view and it is
not intended. Those table are not editable, and as such the menu to edit them
should not be shown.
Task-3000318
closesodoo/odoo#103805
X-original-commit: aec6b02dacf02f18b53cb8b31ffbb52772f5ac27
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reprodue:
- enable any rtl language (arabic)
- move to the product page for exemple
- the page is frozen (dependecy loop in css)
Bug:
when the CSS gets minified the missing semicolon error spreads and
produce an invalid file
Fix:
added the missing semicolon
opw-3019173 3032064 3032250 3035077 3034712 3035077 3023730 3022962
closesodoo/odoo#103699
X-original-commit: 8048bdac4cec56edd92c68f7041b802376f9372c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*: website, test_website
Before this commit, the LinkPopoverWidget element was not positioned
correctly in mobile edition.
With [1] that introduced the website edition using an iframe, the
element was appended on the global document, outside of the iframe, so
that it was not overlapped by the snippets manipulators (that were also
in the global document).
But Bootstrap popovers are not meant to be used "on top" of iframes.
Bootstrap uses the container's ownerDocument to compute placements, and
does not take into account whether or not the target is located inside
an iframe (therefore, skipping the iframe's offset and dimensions in the
placements computations).
This was leading to a visual bug in mobile edition: the iframe top, left
values were not computed by the popover, and it was not positioned
correctly.
Since [2] moved the manipulators inside the iframe, the popover can be
initialised using its target ownerDocument body, without being
overlapped by the manipulators.
Styles are adapted so that the popover stays consistent in the frontend
and the backend, and a container option is added to the widget so that
the element can be placed with other snippets manipulators from the
website builder.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
task-2687506
closesodoo/odoo#103562
X-original-commit: 931d488af0d4dce529e4ea4ab3c8b827bda0d699
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
In the Website Builder, when clicking on the THEME tab, and clicking on
the "Switch theme" button, the loader behind the dialog was not placed
correctly.
After [1] moved the manipulators inside the iframe, the css rule for the
loading elements was not updated to remove its right value, used to
position the loading element next to the right panel.
[1]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
X-original-commit: 106a5a56a96090ae4adfd9e7b3ea2f93d69dca22
Part-of: odoo/odoo#103562
* web_unsplash, website_forum
With [1], the access errors when a portal user were using the media
dialog got fixed. It also came with the unsplash capability for portal
user in the media dialog.
Still, there was a remaining problematic point: an internal user can't
upload an unsplash image in the backend through the media dialog. It
doesn't really make sense for an internal user to have less right than
the portal user.
This commit corrects that part.
Note that only unsplash images were problematic, not regular uploaded
image as the difference was that unsplash images attachment are saved
with an `url` property, which was triggering due to [2].
Finally, it was chosen to make that "bypass" more robust and opt in, so
forum and unsplash are allowing their use cases to go through, it's not
done in a generic way anymore.
Also fixing a small issue about the res_id not being sent when editing a
forum post, because it was assuming that the URL would end with the ID
which is not the case when you edit your answer.
[1]: https://github.com/odoo/odoo/commit/e10493711879c7f0cc8832db3f1936c622ea605c
[2]: https://github.com/odoo/odoo/commit/bfffe39f1376a56226572295b945a2cc73ba50ce
task-3007844
closesodoo/odoo#103138
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When two building blocks are one above another, if there is no padding
between them, we notice that the move handle of the columns of the
lower block is located on the upper block. This is a problem when the
upper block is in grid mode because since the mouse is above it, the
drag is considered over this grid, instead of the block from which
the column comes from. The column is therefore "trapped" in the grid,
which is unconvenient.
This commit solves this issue by "canceling" the over if the start of
the drag falls in this situation. More precisely: if the first dropzone
to detect the "over" event when we start to drag a column is a grid
dropzone that is glued to this column, then the over is canceled.
task-3013882
closesodoo/odoo#103107
X-original-commit: 122eb3821a9294e4f6e2d346df942b394ca039dc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit
1) click on a record in a list view
2) change the html field of a record
3) click on the top right arrow to change the next record
4) click on the top right arrow to change the previous record
5) click on the top right arrow to change the previous record
The value is not updated corretly at step 4, retaining the value from the
previous record. The wrong value is then saved at step 5.
After this commit
Properly reset the HtmlField property `currentEditingValue` when
the update of props value does not comes from the editor.
X-original-commit: 39d02c3cdc2d4256b62cd6414369a8cf82efff48
Part-of: odoo/odoo#103034
Due to a previous fix, attachments uploaded through media dialog would appear in the attachments of mail marketting.
That fix prevents attachments from 'dangling' and being garbage collected later.
That fix is now limited to the mail composer in this commit as attachments are only garbage collected for that model, for now.
related commit: c112361bf9e2f5e7b087c5e5b9a31879856b1da4
task 3003939
closesodoo/odoo#103038
X-original-commit: 69fdca133b06eb66443635bc52d380233580ef51
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this fix it was possible to edit a media that was not editable
because no check existed for such a thing.
task-2962912
closesodoo/odoo#103035
X-original-commit: ddade4346347266b7f699d05865578dc96e2bf98
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Followup of #102259
Instead of adding a class to remove field borders, we want the opposite: hide the borders by default, except when specified specifically with a `.o_field_highlight` class (on a parent or the field itself). This makes it much easier to add field borders on specific parts of the ui (just add the class in the template), rather than having to _remove_ the class through a js override, which is far less discoverable.
I converted all the new rules to work opposite as before, same for the JS logic which added the class based on mobile device detection (size + touch support).
closesodoo/odoo#102977
Forward-port-of: odoo/odoo#102823
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Instead of having a dedicated module for all-things dark mode related,
this commit moves the (S)CSS files into their respecting modules and
uses `web` and `web_enterprise` to provide the base infrastructure for
the dark mode (cf. dedicated assets bundle).
Note:
Don't forget that you have to handle 2 cases:
1: SCSS variables must be placed BEFORE bright ones
2: CSS variables must be placed AFTER
task-2710677
Part-of: odoo/odoo#102868
This commit adapts the module in order to correctly handle color-scheme
variations.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Add 'black' and 'white' color in the list of backend's $theme-colors to
preserve during website's customization.
This commit is preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Younn Olivier