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>
This commit removes the legacy global bus (core bus) and the places
where it was used.
The main users of this bus were the public widgets, they now use the bus
on Component.env.
Some of the uses were dead code and has been removed.
closesodoo/odoo#139076
Task: 3439226
Related: odoo/enterprise#49131
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
*: mass_mailing, test_website, web, web_editor, website, website_event,
website_sale
This commit removes jQueryUI draggable and droppable component to
instead use our own implementation of the feature. This replaces the
last use of the lib: the web_editor drag and drop. This takes advantage
of the code that was already written for other features of the backend.
task-3079246
closesodoo/odoo#136793
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit permits to apply custom font size as rem instead of px. The
users still use px to define and to read the font size but the editor
will convert it to rem.
task-1958098
Part-of: odoo/odoo#129791
Co-authored-by: qsm-odoo <qsm@odoo.com>
The code of this commit is ugly: it only forces extra new rules to make
dropdowns in the right panel toolbar closer to the we-select design.
This should be refactored. Mass mailing should have the same visual,
CSS rules should be shared, etc etc.
task-1958098
Part-of: odoo/odoo#129791
This commit improves the text style dropdown by adding new styles with
responsive font sizes. This will allow to solve the biggest responsive
font-size problem we have right now: users add a cover snippet with
a big font-size (it is currently hardcoded as 62px font size in
snippets). On mobile, it stays 62 and it's too big. Using displayN
classes of bootstrap will allow to solve that problem. Previous commit
also changed the way custom font-sizes work, so after this commit, and
after snippets are adapted every text will now be responsive.
task-1958098
Part-of: odoo/odoo#129791
*: web_editor, mass_mailing
This commit changes the way the font size selector works. Before this
commit, the font size selector applied a hardcoded font size using the
style attribute of the selected element. The purpose of this commit is
to change this to apply a class on the selected element, making it
responsive and customizable.
In all Odoo applications, the font size selector will now apply a class
on the current selection. An exception is made for mass mailing where
the class would not make much sense as not related to the custom heading
sizes (probably needs to be refactored in the future to use the standard
font-size classes) and fonts cannot be responsive in mails anyway (so
there would be a difference between preview and sent mail).
Those classes are:
- `display-N-fs` with N in [1 => 4]. The sizes are stored in the
`$display-font-sizes` map.
- `hN-fs` with N in [1 => 6]. The sizes are stored in the
`$hN-font-size` variables.
- `small` for the small font size. The size is stored in the
`$small-font-size` variable.
The font size selector shows the value of the class (which is dynamic)
that will be applied.
In the website application, the value of each class is configurable
thanks to a previous commit. The user can choose the size of each font
size class in the website settings.
Note that many alternatives were considered for this feature, this is
the chosen compromise. For the record, here is a very short summary of
the alternatives:
- Doing nothing: voted as the worse idea. Users see a font-size selector
they will use it one way or another. The font-size won't be
responsive, breaking their mobile website. And there are real use
cases you could not do: a big "promotion" paragraph on your product
page? Not possible: you either break your mobile page (using the font
size option) or possibly hurt your SEO (using the font-style option
and turning your paragraph into an h1).
- Removing the font-size selector: we did not want the loss of the
feature as there are correct usecases to use it (as mentioned above).
- Using the Bootstrap hN and display-N classes instead of making new
ones. Closed to be the chosen idea but discarded because those classes
comes with colors (that the user can configure) and it would feel
weird to have the color change when changing the font-size. Also, in
the end, we also did not want the line-height, margins, etc of those
classes (only the font-size).
- Instead of X new classes, have only one: o-fs, which would be applied
alongside a bootstrap hN or display-N class, when chosen by the user,
to cancel the unwanted style of those. It works but it forces us to
always have an added `<span>` to apply the font-size, which we don't
want in the future (mainly because of display-N classes, see next
commit). It is actually very needed to be able to use proper
line-height when reducing the font.
- Using a combination of an inline `em` font-size + a class to clamp it
on mobile. Was probably the best next idea but rejected for several
reasons. The main one probably being the inconsistency when changing
the whole size of a title/paragraph (not part of it) and later
changing the related theme size later. E.g. have an `<h1>` followed by
a `<p>`. The h1 is 40px, the paragraph is 20px. Force the title to
20px, because you want it smaller, same size as the paragraph. Real
use case but also users could simply use the font-size controls by
mistake. We would thus apply 0.5em to do that. Later, change the theme
font-size of h1 to 36px (small change). The 0.5em one is now 18px,
smaller than the following paragraph. Preventing that would require
more checks which would "break" other things / possibilities.
- Probably others that were forgotten.
In the end, there was no good or bad answer. "Anything works", as long
as the feature "I want this text smaller/bigger" is there. The
surrounding features are always compromise (some users would expect some
behavior, some users would expect others). This commit focused on
solving the unresponsiveness of those custom font-sizes, which was a
problem for many users.
task-1958098
Part-of: odoo/odoo#129791
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit removes the code that removes some attributes when the
font size selector is closed. We don't need this code because bootstrap
already does it for us.
task-1958098
Part-of: odoo/odoo#129791
Reproduction:
1. in Website, enter Editing mode, drag a block with a button, for
example, banner
2. click on the button then click on the text above the button
3. the selection should be around the text paragraph, but it's on the
button
Note the behavior is only for the first time of clicking on the element,
e.g. when dragging and dropping a new block
Fix: The selection restoration when destroying the link tools should be
done on the spot instead of binding to the destroy of linkToolsInfos.
Without this fix, the selection restore in link tool is done after the
full selection step for o_default_snippet_text element
task-3514638
closesodoo/odoo#139031
X-original-commit: 6dcc33c6c85b605f43e8f42a5d4013eca9e0ef7a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Reproduction:
1. install website, drag a block with button
2. click at the beginning of the button text
3. type something, it will be outside of the button area
Reason:
The contenteditable is reset depending on the o_editable and
o_not_editable class in the _onPostSanitize function.
Fix: don’t do the resetting when we have the _fixLinkMutatedElements key
in OdooEditor as it indicates that the link isolation trick is executing
task-3514628
closesodoo/odoo#139030
X-original-commit: 1727317f258d184432b01b6295d01f688e298257
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Commit [1] changed a method to be asynchronous instead of synchronous
but did not care about where it was called or overridden. That code and
its surrounding needs to be refactored when fully switching to OWL.
Meanwhile this extracts the asynchronous part of the method to be done
once in all cases at initialization for now.
This is probably a cause of race condition or bugs but this was mainly
discovered during a master task development, preventing to code the new
feature properly.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997closesodoo/odoo#138985
X-original-commit: e26c007dd14de9d0cbf76181e8054a3498e67bd9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Create a new model mixins that allow other model to
activate the history feature on html fields.
This history automatically track the changes
on the related html field and allow the user
to revert to a previous version at any time.
This also introduce a new component that can be used to :
* List the recent history
* See a previous version of the document
* Compare a previous version to the current one
* Revert the document to a previous version of it
task-3039787
closesodoo/odoo#112957
Related: odoo/enterprise#37211
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The purpose of this commit is to delete the legacy/js/core/time.js file.
We have therefore replaced all calls to time.js with the l10N/date.js utilities.
Part of task 3439226
closesodoo/odoo#138609
Related: odoo/enterprise#48918
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Sébastien Geelen (sge)