This PR refactor the "inputs design system" by reverting the correlation
'$input-bg == $light == color-3', initially introduced by #120302.
Beside ensuring color-consistency, the former system aimed to simplify
palette edition by clarifying how color-3 was used (simply all the UI
elements...).
While the former system was responsive to user customization and
color-presets, it didn't necessarily delight everyone's discerning
taste, at least not with default settings/palette.
This commit enforces a classic "white with borders" design that's
independent from the color palette and doesn't adapt to color-presets.
The rationale behind this decision is that the need for non-white inputs
is "nonexistent" and exceptional cases should be addressed using the
SCSS editor.
As a workaround to ease edition for users that still wants to challenge
themselves with the creation of "not standard" palettes/designs, this
commit introduce a colorPicker option assigned to $input-bg.
The hope is that this new controller help users finding a "compromise
color" that could work with any color-presets.
task-3568806
closesodoo/odoo#139642
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This follows [commit 1], which introduced a way to separately reorder
columns on mobile and desktop.
This commit replaces the custom mobile order classes with the Bootstrap
`.order-x` classes.
It also ensures those orders are not used for mass mailing in case the
editor composes their email on a small window. The reorder would indeed
not have any effect for the end users in such a case.
[commit 1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
task-3576046
closesodoo/odoo#140362
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this commit:
When we try to click on element contenteditable=false then it is switch to
nearest editable area.
After this commit:
When we try to click on element contenteditable=false then it will not switch to
nearest editable area.
Task-2977246
closesodoo/odoo#139961
X-original-commit: 3b8e4bc123dd87857d6634b55ddaaa716a0729ce
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, there was an issue with the dropdowns in the editor
panel. When the selector was at the bottom of the panel, the dropdown
opened outside the viewport, requiring the user to scroll the editor
panel to see it.
After this commit, the dropdowns in the editor panel open above the
selector if there is not enough space below for it to be visible without
scrolling.
task-3500768
closesodoo/odoo#135788
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Open the Menu Editor.
- Add a menu item.
- Type a URL (which will trigger the autocomplete).
- Bug: You can't select the last URLs in the autocomplete dropdown
because it goes off screen and can't be scrolled.
This bug was introduced by the commit [1]. Since this commit, all modal
dialogs are vertically centered, which is why the bug fixed in this
commit occurred.
[1]: https://github.com/odoo/odoo/commit/dd141a22f44ea88af18448c4a6089252daeba8cc
task-3580373
closesodoo/odoo#140846
X-original-commit: 23272e38d822c734d1ea2fdb404ba2b1d6890cb3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
*: mrp_subcontracting, project, test_website, web, web_editor,
website_slides
This commit removes jQueryUI autocomplete that was the last usage of
jQueryUI.
No longer usage of these features inside the codebase
task-3439226
Part-of: odoo/odoo#139209
This rearranges the non-floating toolbar buttons so that the AI, animate
and highlight buttons are grouped together at the bottom and take up the
full width of the toolbar, and so that the options appear below them.
task-3572337
closesodoo/odoo#139857
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
When selecting an alternative in the AI Copywriter dialog, what we store
in the state is the index of the message. But that targets a different
message every time we add each new message at the start of the list.
This pushes new messages at the end of the list and only displays them
in reverse order, but also adds an ID to each message so they can be
targeted more robustly.
Part-of: odoo/odoo#139857
When inserting generated content in the editor, a frame is added around
the content to highlight it for a moment. This frame was not properly
positioned in the website builder. This also restyles it to match the
style of the "DRAG BUILDING BLOCKS HERE" frame.
task-3572397
Part-of: odoo/odoo#139857
With this commit, opening the ChatGPT alternatives dialog still
generates three alternatives, but whenever the user clicks on one of the
buttons:
1. one new version is generated (rather than three)
2. this new version is added at the top of the list (rather than
replacing everything)
3. older versions are showed in grey so as to differenciate them from
the new one
4. a badge next to each version shows which instruction was used to
generate it (shorten, lengthen, etc.)
Since we add new versions from bottom to top, the spinner is now shown
above the existing versions.
Since a badge is added, it's not necessary to keep the last used button
green anymore so once the AI is done generating the new version, the
button returns to its blue state.
task-3572397
Part-of: odoo/odoo#139857
This implements a way to abort the generation of a batch of alternatives
by the AI Copywriter. This is needed because if a batch was being
generated when the user clicked one of the buttons to select a mode, it
continued to be generated and to update the state while the new batch
was in the making, resulting in a potential total of more alternatives
than requested.
task-3572397
Part-of: odoo/odoo#139857
Sometimes, ChatGPT includes a little intro text (eg, "Sure, here are
some alternatives:") to its answer. This avoids this as much as possible
by improving the system prompt and asking to wrap the answer in tags
that we then remove.
task-3572397
Part-of: odoo/odoo#139857
This commit resolves the issue that arises when a widget contains a
reload attribute but lacks a no-preview attribute. That config leads to
an "Uncaught Promise" error. With this update, when a reload attribute
is detected, the no-preview attribute is now automatically added,
preventing the error from occurring. The problem occurs since [1].
Steps to reproduce:
- Go to website
- Edit
- Click on the header
- In the navbar options, change the Mobile Alignment option.
=> Works but traceback anyway.
[1]: https://github.com/odoo/odoo/commit/fcb16a3b1bd373726ffb54f0fbe41fb6d1784769
task-3572334
closesodoo/odoo#139909
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In order to improve the user Experience and not uselessly
block access to the document, we prevent collaboration error
to open the traceback dialog.
task-3568680
closesodoo/odoo#139964
X-original-commit: df39cbc4dbc1922e91c53278db7fdcb12f01306e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
In some cases the changes done in the editor were lost when using other element of the the UI.
For example : changing the tab containing the editor component to another one.
To avoid loosing the changes made by the user in those cases, we force an urgent commit change
in the `onWillUnmount` hook.
task-3530998
closesodoo/odoo#137716closesodoo/odoo#139959
X-original-commit: b2c3775ea01bfdb8e0dd40b3b8e57534c1785116
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
On creating link in debug mode produces prop validation error, and link
dialog doesnot appear
After this commit:
Now the issue is resolved and link dailog appers.
task-3571940
closesodoo/odoo#140178
X-original-commit: 8519cbab2e22506b12a1d93066c2c4fd87e753fe
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Sanjay Sharma (shsa) <shsa@odoo.com>
There is an exact case where having a grid mode block inside a mega menu
item will fully bug: all elements will be on top of each other.
In order to reach this case, you need to:
- Create a mega menu
- Make the block inside this mega menu use grid mode
- Find a screen size where this mega menu will be part of the extra menu
items (hidden in the `+` entry)
- BUT the screen size should not toggle the mobile view
Point of attention when trying to replicate the issue:
When you enable grid mode, the result will depend on the available size.
So be sure to not enable the grid mode on a megamenu which is already
hidden in the extra items when you are in edit mode, in such a case,
there is no bug.
This commit simply disables the grid mode in such a case, it will thus
behave like the grid mode in mobile view and therefore be responsive
(disabled in mobile).
opw-3547405
closesodoo/odoo#139956
X-original-commit: fb209432049d9874308a2bdc3c9d2baa210ccced
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: test_website, web_editor, website_sale
The goal of this commit is to replace all Dialog in the Website Editor
flow with OWL Dialog. This uses the new `bindService` and `call` methods
available on legacy widgets. The replacements mainly use the
ConfirmationDialog component, but some had to have custom-made dialogs.
closesodoo/odoo#138947
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
This commit removes useless function from legacy/utils.js and removes it
from several backend bundles. The file is moved in wysiwyg and frontend
bundles as it is still used in these bundles.
task id: 3439226
closesodoo/odoo#140260
Related: odoo/enterprise#49812
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Follows commit: ffef01e327.
It caused an issue in Firefox:
On the sale order form view (with the field "notes" handled by the OdooEditor),
clicking on a Many2one made the browser crash because the method getSelection
did not exist on the target which was the input element.
It did not crash in chrome as the event's target was always the Document.
The added test actually tests the feature of the referenced commit, and checks, as much
as possible, that there is no crash.
closesodoo/odoo#140143
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit introduces some adjustments to the dark mode color scheme
and the use of bootstrap classes in Community.
- Mini calendar contrast -
The colors were not using variables, making them non dynamic
and breaking the contrast in dark mode.
- Avoid !important rules spreadsheet -
Prior to this commit, spreadsheet top bar was using a `bg-white` class,
making it pure black in dark mode.
Since spreadsheet is designed with light colors and we don't provide a
dark mode for it, we remove that class and set a `background-color`
property using CSS in Enterprise.
- Input color -
This commit fixes the focus behavior on the searchbar in the control
panel, the `command_palette_search`, and the `start a conversation` in
discuss.
- Copy clipboard field border color -
Make use of the `text-primary` color for the copy to clipboard field
We use the o-theme-color function to avoid an undefined since primary
doesn't exist in the o-theme-text-color map in white mode.
- Web_editor toolbar variables -
The toolbar was using the `o-brand-primary` variable
which was set to a darker shade. This caused issue when activating an
option due to how vibrant the color is.
- Improve the controls on border-color -
Introducing a custom property on the border-color to allow
further control on individual components (such as the popover).
- Improve setting tabs colors use -
Prior to this commit, the colors of the settings tabs menu were kinda
inverted. The menu was light in dark mode and dark in light mode.
We fix this by changing the values associated to the CSS variables in
use.
- Make model field selector dark mode proof -
Fixing the design of the model field selector popover in both
light and dark mode. Since the popover was using custom style with
arbitrary values, it was not designed for the dark mode and had a lack
of consistency.
To improve the design, we use variables rather than custom style, and
make sure the desired render is as close as before.
- Sign colors use -
This commit aims to improve the sign module in both light and dark mode.
There were some readability issue with some `btn-light` having poor
contrasts in both light and dark mode, and the use of some classes was a
bit unexpected (e.g `card-header` to set a grey background with some
padding).
- Improve buttons design inside listview -
Prior to this commit, this button was using custom CSS to make it look
like a primary button, while it was using classes related to secondary
buttons.
We remove the custom CSS used to style it correctly and keep our button
design consistent.
- Messaging menu layout in mail -
This commit aims to improve the design of the notifications displayed
in the messaging menu. Prior to this commit, the notifications dropdown
was using custom CSS variables overriding the regular behavior
of our dropdowns.
In fact, the layout was generating some friction:
1) Marking a notification as read would turn its background into a
darker color
2) Effects like `:hover` were all based on the custom CSS variables
resulting in an inconsistent layout.
- Multi company selector adaptations -
In darkmode the multi company selection was using the btn-light which
creates a weird effect and overrides the dropdown default hover behavior
This commit uses the btn-link to display an hover effect on the
company switch and on the checkbox while blending with the background
and the default dropdown hover effect.
- Adapts default badge design -
Improve the design of the default badges in dark mode.
If you open the light mode, these badges are dark grey with a white
text. If you switch to dark mode, they are dark grey but with a dark
text, which makes them look either muted or off.
We make use of SCSS variables to handle the color of the component,
providing a good styling in both modes.
- Fix kanban cards borders inside dropdown -
Fixes the issue with the divider inside the kanban dropdown menu not
showing in dark mode.
To ensure it is visible, we assign it the `$dropdown-divider-bg`, which
is the color it should use, as the horizontal divider above uses.
- Fix tour pointer design for dark mode -
This commit aims to insert the tour pointer and its content inside the
styling we applied to our tooltip.
To do so, we make sure it uses CSS variables, allowing more control and
consistency, plus we replicate the overall look of our tooltips.
- Fix `text-primary` on action background contrast -
This commit improves the readability of our `text-primary` classes when
it's used on a `$o-component-active-bg` background.
Prior to this commit, the `text-primary` was not meeting the contrast
standard, mainly when you were using the `CMD+K` shortcut on the
app switcher.
To prevent that, we changed the background to a `$o-component-active-bg`
background with an opacity ensuring our text provides a good contrast.
- Fix input states -
Prior to this commit, the `--o-input-border-color` CSS variable was
using the `$o-form-lightsecondary` variable to define the standard color
of the `border-bottom` property of our inputs.
This was conflicting since `$o-form-light-secondary` is also used to
define the `background-color` of our table on focus.
With this commit, we separate these two element with different variables
to make sure they don't affect each others.
- Fix kanban ghost background -
Before this commit, if you created a project without any stage or element
in it, the ghost cards that act like placeholders would be pure `#000` in
dark mode, due to the `bg-white` class.
This commit replaces that class with a `bg-light`, providing a better
visual result in both light and dark mode.
- Fix new message design -
Improve the design of the new message element while
inside Discuss, using our danger color, ensuring a good visual result in
both modes.
task-3201038
closesodoo/odoo#139966
Related: odoo/enterprise#49666
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: chgo-odoo <chgo@odoo.com>
Co-authored-by: stefanorigano <sri@odoo.com>
Steps to reproduce:
- Edit a mailing (mass_mailing)
- Click the save icon
- Type to '/' to open the Powerbox (it does not...)
The `getPowerboxElement` function fails to return the correct node
because `this.options.document` is no longer the iframe document after
the Wysiwyg component is re-rendered. This happens because when the
Wysiwyg component has its props updated, its `options.document` is
overwritten by its default option (the top document).
This commit makes sure that, when the editor is mounted inside an
iframe, `options.document` evaluates to the iframe's document throughout
the entirety of the Wysiwyg component lifecycle.
task-3548120
closesodoo/odoo#140075
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
When a user browses a website, he can visit two types of pages:
- Static page: the page is a website.page record.
- Dynamic / controller page: the page isn't a website.page (e.g. /shop).
Some options are only available on static pages, like the option to
make the header over the content. Since [this other commit], when a user
change the header template, the editor activate/deactivate an extra
options in addition to the header template change. The problem is that
this extra option may be available only on static pages, and the option
to change the header template is available on all pages.
Before this commit, if the extra option is not available, we stop the
process, the page was not reloaded and the user didn't see the new
header template. Now, we just ignore the extra option without stopping
the process, so the page is reloaded and the user see the new header.
Steps to reproduce the issue fixed by this commit:
- Go to /shop
- Edit
- Change the header template
=> The header template is not changed.
[this other commit]: https://github.com/odoo/odoo/commit/e7dcfc19298948b76caa4c214724c93854cf5f4c
task-3572277
closesodoo/odoo#139896
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
This commit removes the promise extension which added the function
`guardedCatch`. It was used to filter server and connection errors from
javascript errors. Instead of using guardedCatch, we should use catch
and check if the reason is a server or connection error if needed and
re-throw the error if it's not handled.
closesodoo/odoo#137702
Task: 3439226
Related: odoo/enterprise#48451
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When using the media dialog, the dialog always seems glitchy as its size
is always changing with the loading files. This behavior is not really
convenient as it can make the user click on unwanted images. Another
"issue" of the current media dialog is that when loading more images,
the dialog auto-scrolls to the "Load More" button, which can make the
user miss new images and he therefore needs to revert the scroll. A last
issue encountered by the users is that some of them think that the "Add"
button in the footer is used to upload files from their device, while it
only adds the selected media to the page.
This commit improves the UX of the media dialog:
- The dialog height is now fixed and has the same size as when it is
fully filled by images.
- The top bar with the search input now stays at the top when scrolling.
- There is now a small footer under the attachments (for the Images and
Documents tabs only) and containing the following:
- When there is content to scroll, a small circle with an arrow that
scrolls one row when clicking on it.
- When there is nothing to scroll, the "Load More" button which will
load more images. When new images are loaded, if we can scroll, the
small arrow is displayed again.
- When there is nothing to scroll and to load anymore, the "All
images/documents have been loaded" text.
Note that the main goal of this footer is simply to indicate to the user
when there is still content to scroll and when he can load more files.
In order to solve the "Add" button issue, this commit also enables and
disables this button, depending on whether some media are selected:
- if a media is already selected, we can click on the button;
- if not, the button is greyed out and we cannot click on it.
task-3441587
closesodoo/odoo#135875
Related: odoo/enterprise#49535
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The goal of this commit is to replace the "Toggle underline" option
from the website's text editor by a new "Highlight effects" option which
should allow applying some highlights on the selected text and setting
their color & thickness. Also, the text editor "Toggle strikethrough"
option will be moved to the list of highlight effects in the new option.
For this purpose, the JS code used for text animations will be updated
to be more generic and handle text highlights too. Moreover, The "Text
Highlight" options will be applied by adding a SVG to the targeted text
element (allowing to adjust their `stroke` and `stroke-width`).
To simplify adapting highlights when the text content is updated,
we follow this generic structure:
```
<span class="o_text_highlight">
<span class="o_text_highlight_item">
line1-textNode1 [line1-textNode2,...]
<svg.../>
</span>
[<br/>]
<span class="o_text_highlight_item">
line2-textNode1 [line2-textNode2,...]
<svg.../>
</span>
...
</span>
```
Rendered line breaks in text nodes are detected using range client
rectangles (see: `text_processing.js` > `splitNodeLines()`), and the
highlights are updated on window resize...
We also need to adjust highlight SVGs to fit an updated text in "edit
mode" (mainly using editor's commands), a `MutationObserver` is used
for this purpose (we only redraw the SVG for each text unit).
A simple SVG path generator was implemented in this commit (see:
`text_processing.js` > `drawPath()`) to build highlights. It applies a
list of SVG path commands according to text dimensions in a specific
mode (E.g. on "pattern" mode, we repeat the same elementary path to fit
targeted text node...).
Remarks:
- The `--text-highlight-width` and `--text-highlight-color` properties
are used to control the highlight effect's thickness and color.
- We build the highlight option preview in the same way as text content.
To achieve this, a hack was used (we open the `<we-select/>` first since
we need the right `getBoundingClientRect()` dimensions to correctly draw
highlight SVGs).
task-3285817 (rd-website)
task-3269759 (rd-design)
closesodoo/odoo#122751
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Chrysanthe (chgo) <chgo@odoo.com>
*: web_editor, portal
This adds a button to add language in theme tab. When clicked, opens
the "add a language" wizard.
If the website has only one language, the options to enable language
in header & footer are hidden.
When an user add a language, the default behavior is Header: dropdown
& Footer: inline.
Also provides two more rendering options : Language Code and Flag +
Language Code.
task-3457554
closesodoo/odoo#119650
Related: odoo/design-themes#651
Related: odoo/upgrade#5214
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit, some snippets did not have any or complete preview
when dragging them over a dropzone.
This commit covers `s_website_form`, `s_countdown`, `s_map` and
`o_facebook_page`.
Some elements with class `s_preview` are added to the template. These
elements are removed when the snippet is dropped.
Also, the class o_colored_level was added to snippets so that the
previews matches the snippet dropped.
For "New page templates", an `s_keep_preview` class can be added on a
parent element of an `s_preview` to prevent its removal when creating
the page - thereby making the snippet ready as if is had been dropped
into the page.
Note: `s_chart` and the "dynamic snippet" and its variants are not
covered in this commit.
task-3555325 (was task-2431469)
Part-of: odoo/odoo#138748
Co-authored-by: Benoit Socias <bso@odoo.com>
This commit removes the last low level legacy stuff (e.g. Widget,
mixins...) from the backend bundle, and from the webclient bundles
of mrp_subcontracting and project. They are no longer used in the
backend. There're still necessary for the frontend and for the
web_editor though, so we had to manually add them in the lazy
loaded bundle of the editor. Hopefully, the last widgets and
dialogs will be converted soon, and we'll finally get rid of all
those legacy files.
Part-of: odoo/odoo#139154
This commit refactors the website AceEditor to owl. The wrapper
around the lib was defined in web_editor, and extended in website,
where it was used (single usecase). This commit thus introduces an
owl Component to replace it, directly in website, and specialized
to the website usecase.
This thus allows to remove the legacy implementation.
This also removes the last usecase of Widget and select2 library
in the backend bundle, which will allow to trim it down.
Part of task~3439226
Part-of: odoo/odoo#139154
When changing the grid gaps (see commit [1]) a grid preview is displayed
in order to visualize the changes. As it cannot be displayed in mobile
view (otherwise, the layout looks broken), some code prevents it to be
added in this case. However, a case has not been taken into account:
- In desktop view, change the gaps of a grid with the "Spacing (Y, X)"
option.
- Before the preview disappears, quickly activate the mobile preview.
=> The preview is displayed (before disappearing).
This commit prevents the grid preview to be displayed in mobile view. To
do so, its height is forced to 0. Note that `display` could be set to
`none` instead but since it prevents the animation to be played, the
preview would not be removed by its listener.
[1]: https://github.com/odoo/odoo/commit/4345df3aeeb83463d81bc24749856fef3a58fb3a
task-3555898
closesodoo/odoo#138795
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
We used to have two libraries (Bootstrap and jQueryUI) providing
tooltips.
Since the removal of the jQueryUI implementation in commit [1], adding a
image-like block in the wysiwyg editor throws an error telling that
`$().tooltip()` is not a function.
Actually, this issue happens when the wysiwyg editor is used in an
iframe and the jQuery instance used is the one from the iframe.
In a nutshell, Bootstrap 5 - even though it doesn't require jQuery
anymore - has a compatibility layer which bind the current components'
implementation to the v4-like jQuery based methods (in this case
`$().tooltip()`). In the tooltip's case, both libraries have the same
method signature.
When removing the jQueryUI implementation, most of the calls to this
method naturally fallback to the Bootstrap's one... But not in our case,
as the wysiwyg editor uses its own window/frame's jQuery and not the
parent one (in the iframe's case).
Amusingly, the way Bootstrap bind its compatibility layer relies on the
`onDOMContentReady` event being dispatched... which is not the case in
the iframe, resulting to having a jQuery version without the said
compatibility layer.
This commit fixes it by removing this dependence on an external library
and use our own (existing) Tooltip component instead.
Steps to reproduce:
- Open Email Marketing app
- Create a new mailing
- Choose a template
- Drag&drop an image-like block
- Click on the newly inserted block
=> Error about $target.tooltip not being a function
[1]: odoo/odoo@25d0783b59closesodoo/odoo#138847
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the tags t-field,t-esc,t-out were difficult to select
and couldn't be stylized.
After this commit, when clicking or selecting a tag t-field,t-esc,t-out
the whole tag is automatically selected and a style can be applied onto it.
task-id-3457404
closesodoo/odoo#135265
Related: odoo/enterprise#47089
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the save operation of wysiwyg was applied on the current editable.
After this commit, the save operation of wysiwyg can be used on a given element.
This advantage of this change is that saving can now be triggered on a copy of the original editable
element, or on any document in memory.
This makes the use case of the report editor easier to handle. That is, when the save fails, we need to
go back to the state of the editor before the save: that is WITH the changes of the user, but not cleaned by the
wysiwyg yet.
task-id-3457404
Part-of: odoo/odoo#135265
Before this commit, adding column in a report added a line instead because columns were too large.
After this commit, the created columns are not "lg" anymore, so column creation does make a column.
task-id-3457404
Part-of: odoo/odoo#135265
Follow-up of https://github.com/odoo/odoo/commit/ee38c69503a0fd9175751f054d88bf760ec660b8
Before this commit, the padding of these buttons was too big and
the text was partillay hidden.
This issue was introduced in the commit above. The selectors generated
by the ´.extend´ were not correct and the css rules associated to ´.btn´
was never applied. It was therefore good to remove this rule but we shoudn't
have added the ´.btn´ class.
Steps to reproduce:
- Go to website and open the Editor
- Click on "Edit"
- Drag and Drop "Text"
- Go to Customize
- Change the Background or the font color
closesodoo/odoo#139437
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: mass_mailing
This commit introduces options for the flex column layout and the
horizontal resizing to be used on mobile and be independent from
the desktop layout.
This makes it possible to:
- Have different number of columns on mobile and on desktop.
- Use different column widths and offsets for mobile and desktop.
- Reorder columns independently.
The behavior expected from the columns is:
- In the editor panel, Cols indicate the number of columns per row on
both mobile and desktop. The option is conditional of your environment:
you edit the number for the screen size of your current resolution.
- When columns have different sizes (either because it is the default
behavior of the snippet, or because the user resized some), the counter
should read "Custom". Same when the user changed some offsets.
- If manual modifications were made on width and offset, they are reset
on the current display if the number of elements is updated. This was
decided because an old, specific layout with custom offsets / width
doesn't work well with a different number of elements. (This is also the
default behavior before this PR with desktop-only modifications.)
The expected behavior when reordering is:
- On mobile, it should only affect the mobile layout.
- On desktop, it should affect both layouts.
In order to have a coherent feature on both mobile and desktop as well
as correct some non-ideal but non-blocking behaviors, the commit also
changes the following behaviors:
- When setting a columns count lower than the current number of items in
the `.row` container, extra items are now wrapped on the next flex-rows
(still within the container) instead of being deleted.
- When going from e.g. 3 to 5 columns (and as many items), the change
happens all at once instead of each item being visibly added one by one
on the next row, then brought back to the first row.
- The columns count automatically updates when resizing an item, instead
of updating only after you click somewhere else on the snippet.
This commit also adds a test to validate the new behavior.
task-3097045
closesodoo/odoo#117562
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The logic done in the `_computeWidgetVisibility()` method of the main
`SnippetOptionWidget` should have been placed in the `SnippetMove`
sub-widget as an override method.
This commit moves the logic at its right place and removes an unneeded
condition.
task-3097045
Part-of: odoo/odoo#117562
This commit implements two generic utility functions with similar
behavior that check whether the view is mobile or desktop:
- For web_editor: depending on the view of the targeted element
- For website: depending on the context
task-3097045
Part-of: odoo/odoo#117562
Reproduction for creation:
1. Create a link using /link
2. Click after the link, press enter
3. The link and cursor disappear.
Reproduction for cancellation:
1. Create a link using /link, don’t save it but cancel it
2. Click after the link, press enter
3. The link and cursor disappear.
Fix: After clicking the save button of the link dialog, the next history
step is not correctly set up as the history step is not unpaused. This
causes the mutation list of the current step to have all the mutations
before starting the link insert. Thus after the link creation, whenever
the historyRollback is executed, it’s rolled back to the very start
The cancellation has two cases, clicking the discard button or clicking
the close button. Unfortunately, they have to be handled differently.
For clicking the discard button we need to bind the button with a
function doing the historystep then close. For the close window button,
we have to rewrite the close function by overwriting
this.env.dialogData.close. The overwrite method is specified in this
commit: https://github.com/odoo/odoo/commit/dc1191f6939c4bbf5cfcc865884813610f4f8f2c
task-3446357
closesodoo/odoo#139325
X-original-commit: 60089e7e100039670d98f2f41b4f56fafdb8f830
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When `_resetFromClient` returns an error, `_historySyncFinished` should not be
set to true since the history was not updated from the requested snapshot.
Also await the result of `get_client_avatar` and `get_client_name` during
`rtc_data_channel_open` so that no error is produced during tests after calling
`removePeers` without properly awaiting those promises.
Export collaborative test utils for usage in Knowledge.
task-3551505
closesodoo/odoo#139040
X-original-commit: fb389213078e96c97b7187248dfdf79ad331db9f
Related: odoo/enterprise#49170
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
This commit implements a dialog for content generation using ChatGPT,
which can be opened via the Powerbox or via a button in the toolbar.
If text is selected, the dialog opens in "alternatives" mode. In this
mode, five alternative versions of the selected text are generated. The
user can choose one and it will be inserted in lieu of the selection.
Five buttons can be used to guide the AI to make the content longer,
shorter, more professional, more friendly, or more persuasive. Clicking
any of these buttons will restart the generation process with the new
parameters.
If no text is selected, the dialog opens in "prompt" mode. In this mode,
the dialog contains a textarea in which the user can input a prompt
which is then used to generate content. The user can then exchange with
the AI back and forth until the content is satisfactory. Any of the AI's
responses can be inserted into the document by clicking its "Insert"
button.
When content is inserted into the document, a green frame is shown
around it for two seconds, to make it clear to the user that something
has been inserted and where.
If an error occurs, it is inserted in the dialog like other responses
but in red and it can't be inserted into the document.
Please find the PR of the IAP part (Odoo Language Generator) here :
https://github.com/odoo/iap-apps/pull/703
task-3383324
closesodoo/odoo#137064
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Lou (loha) <loha@odoo.com>
xO-Tx