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
The `beforeEditorActive` props is a function, not a boolean. So
before this commit, there was a crash in debug mode when the
WysiwygAdapter was instantiated.
Part-of: odoo/odoo#139154
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*: website_crm, website_event, website_event_track
Before this commit, when accessing the visitor views without having any
event rights, an error was triggered.
This commit restricts the display of the `event_registration_count`
field on the `website_visitor_view_form` restricted to the
`event.group_event_user` group so that its invisible condition does not
fail. Similarly it restricts a visibility condition on
`event_track_wishlisted_count` to the `event.group_event_manager` group.
To avoid encountering the same issue with further extensions of
`_compute_email_phone` on the `website.visitor` model, we make its
fields `compute_sudo=True`, and revert the specific `sudo` that had
been added in [1].
Steps to reproduce:
- install `website_event`
- set Demo user to have no Events right, but be an "Editor and Designer"
for Website
- register to an event as an anonymous user
- access the Visitors page as Demo user
=> An error was produced.
Steps to reproduce (2):
- install `website_event_track`
- set Demo user to have no Events right, but be an "Editor and Designer"
- access the Visitors page as Demo user
=> An error was produced.
[1]: https://github.com/odoo/odoo/commit/5ba09c2cb2bb180cfb1363c352f35bd8cf3b132b
opw-3537849
closesodoo/odoo#139271
X-original-commit: 4cb18fab5e8d14dd9a2dfb5cb3e65b43fab02846
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@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>
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
*: 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>
*: website_event, website_forum, website_livechat, website_mass_mailing,
website_slides
This commit permits to reduce the risk to have a wrong h1 tag or
multiple h1 tags on the same page. This commit replaces some h1 tags
with a h2 in snippets. In addition, this commit removes some font sizes
written in the style attribute and replaces them with a font size class
now that they are possible to use and edit as an user.
task-1958098
Part-of: odoo/odoo#129791
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: 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 adds a set of new options in the theme tab to allow the user
to customize the style of the display-N classes. He can now choose the
font family, the font size, the line height and the margins top/bottom
for the display-N classes (1 to 4). Note that we will not use display-5
and display-6. A further commit will allow the user to use those classes
in their content via the editor UI.
task-1958098
Part-of: odoo/odoo#129791
Co-authored-by: qsm-odoo <qsm@odoo.com>
When the user has contacts with different websites and tries to create an order,
a traceback will appear.
Steps to produce the error:
- Install 'website_sale' and 'contacts'
- Create 2 websites: 'Website A' and 'Website B'
- Go to Contacts > New > In Sales & Purchase, select 'Website A'
- Create another contact with 'Website B'
- Go to Website > eCommerce > Orders > New > try to enter Customer
Error: A traceback appears:
'Expected singleton: website(6, 16)'
https://github.com/odoo/odoo/blob/1cb866347eed8c43d1da225f441cc3b3ce9c5a01/addons/website/models/res_partner.py#L42
Here, instead of partner, self is used.
So when the user tries to create an order,
it will lead to above traceback.
sentry-4545021252
closesodoo/odoo#138929
X-original-commit: b053805d96c5fd8a9579e49b4f842f488c4adf60
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
In 15.0, the SEO dialog did not allow trailing/leading spaces.
However, in Odoo 16.0 one can add leading and trailing spaces in their
SEO keywords.
This is becausethe commit which converted the SEO dialog to OWL [1] did
not trim new keywords, which could lead to keywords with trailing space.
It means that those keyword won't be marked as checked in the SEO
Dialog.
This commit removes trailing spaces when opening the SEO Dialog, in case
of an existing DB having such a case, and also when adding new keywords.
To note that trailing spaces will still be inside the page until the SEO
dialog saves the SEO data again.
Note that there might be (or might have been at some point) some cases
of migration which seems to lead to those spaces being added when the
user land in Odoo 16.
[1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1
opw-3460300
closesodoo/odoo#138872
X-original-commit: 69c0293b59468c24c92b8b900cba7dd93bbbd0cf
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
In the conditional_visibility_1 tour, when setting up the UTM Medium,
the "Email" value is searched for.
But if more records (like with the design-themes testing enabled) push
this value out of the autocomplete initial proposition, the value cannot
be selected.
This commit fixes it by adding a step that search for the "Email" value
to ensure it is in the autocomplete propositions' list.
closesodoo/odoo#138834
Note: detected on the Lastest Chrome builds on the runbot (nightly)
X-original-commit: 8993a187f9918478f106c1913885cf980a6a9698
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit permits to check if the text theme is translated before
asking IAP for a text generation. We need the text to already be in the
target language to be able to generate the text in the target language.
task-3248852
closesodoo/odoo#136937
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The aim of this commit is to improve the impact and rendering of app
icons in bright and dark mode. It also reduces the size of svg files.
To achieve that, this commit updates the colors to flat colors. This
change will make the icons stand out and improve their readability.
task-3072562
X-original-commit: 667a19162b74fb6554a2389ba9c6e69de4ff5113
Part-of: odoo/odoo#138279
This commit introduces 3 new inner snippets: button, image and video.
What sets these snippets apart is that, once dropped onto the page, they
transform into basic HTML code, just like if they were created using the
editor (no data-snippet etc).
task-3248881
closesodoo/odoo#126717
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: bvr-odoo <bvr@odoo.com>
In commit [1], the Banner snippet has been redesigned in order to be
in grid mode by default, to highlight some cool features of the editor.
However, some grid classes and attributes are missing or not well set:
- the first column has a `g-height-4` class despite having 8 rows: this
causes the vertical resize to not work correctly.
- the row does not have the `data-row-count` attribute, which is needed
to display the background grid correctly.
This commit fixes this by replacing the class by `g-height-8` and adding
the `data-row-count` attribute, which is set to 11 rows.
[1]: https://github.com/odoo/odoo/commit/3cbdf754ff8fac8a77887c4307b658cb86b0be1d
task-3369695
closesodoo/odoo#136683
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, toggling the "Text Cover" snippet to grid mode did
not produce a good-looking result: the column containing the background
image loses all its padding and therefore appears smaller and shifted
compared to the normal mode.
This commit adds a background color to the image column. Indeed, with a
background color, and more precisely thanks to the `o_cc` class, the
padding is taken into account when computing the grid items size, making
them look similar to how they were in normal mode.
task-3369695
Part-of: odoo/odoo#136683
The `display: grid` property allows to modify the spacing (or gaps)
between the rows and columns of the grid with the `row-gap` and `column-
gap` CSS properties. When the grid mode was added with [1], these
properties were deliberately ignored and the gaps were forced to 0px.
This commit adds the "Spacing (Y, X)" option that allows to modify these
grid gaps. A grid preview is also added when using this option, in order
to visualize what is being changed in the grid.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
task-3369695
Part-of: odoo/odoo#136683
This commit modifies the "New Page" dialog so that it displays a list
of page templates to pick from in addition to the possibility to create
a blank page.
task-3381714
Part-of: odoo/odoo#126719
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>
This commit adapts the configurator so that the pages it generates are
composed of the primary templates generated from the manifest by the
previous commit.
task-3381714
Part-of: odoo/odoo#126719
This commit is a preparation for the new page from template feature.
In order to make it possible for new page templates to be customizable
at several levels from themes, it was decided to create several layers
of primary templates.
Those templates are build from the descriptions found in manifest files
under the new `new_page_templates` key.
The same principle is also applied for configurator pages (described in
manifest files under the `snippet_lists` key) because we noticed that
some of the changes that were made in themes for some blocks were not
supposed to impact the "drag'n'drop" version of the block, but only
the version used inside the pages generated by the configurator. (E.g.
connecting shapes between blocks)
The manifest entries now have the following structure:
```py
'snippet_lists': {
'somepagename': ['s_block_name', ...],
},
'new_template_pages': {
'somecategoryname': {
'sometemplatename': ['s_block_name', ...],
},
},
```
This commit finds those entries in the manifests and creates the
following primary templates:
- `s_block_name`: already exists, this is the block that is drag and
dropped using the website builder
- `configurator_s_block_name`: specialization of `s_block_name` used in
all pages generated by the configurator
- `configurator_somepagename_s_block_name`: specialization of
`configurator_s_block_name` for that specific page
- `new_page_template_s_block_name`: specialization of `s_block_name`
used in all new page templates
- `new_page_template_somecategoryname_s_block_name`: specialization of
`new_page_template_s_block_name` used in new page templates of that
specific category
- `new_page_template_somecategoryname_sometemplatename_s_block_name`:
specialization of `new_page_template_somecategoryname_s_block_name` for
that specific template
For the template pages defined in `website` it also creates primary
templates that assemble `t-snippet-call`s of the most specific block
templates. Those templates are named
`new_page_template_sections_somecategoryname_sometemplatename`.
task-3381714
Part-of: odoo/odoo#126719
The issue that can happen is a t-cache covering a t-call-asset.
The asset_cache is invalidated but not the t-cache, meaning that the url
pointing to the asset will lead to a 404 once another request, without
t-cache, will regenerate the asset.
X-original-commit: fffc198914b8c885905e9dddd72b6490fcc4c120
Part-of: odoo/odoo#138647
Since commit [1], the 'jquery.ba-bbq' library has been removed. Now,
when you drop the Facebook snippet into a page, there is a traceback.
This is because we were still using the 'querystring()' function from
'jquery.ba-bbq' to combine the parameters of the Facebook iframe's URL
with its URL.
[1]: https://github.com/odoo/odoo/commit/507c36883675a45a15485ce5c73aa4557ba23639
task-3543529
closesodoo/odoo#138592
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
By default, images on websites can be dragged and dropped in browsers.
As we have a custom drag & drop system, this commit removes the default
drag & drop behavior during the edition of a website page. In addition,
this commit prevents `OdooEditor` from managing drag and drop on images
that should not be dragged and dropped by the user.
task-3369600
closesodoo/odoo#125151
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
This commit removes all the legacy envs (common_env, env, public_env)
as well as the files used to set up them.
task 3439226
closesodoo/odoo#138348
Related: odoo/enterprise#48781
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit removes instagram from the `snippets_all_drag_and_drop` tour
to prevent too much external calls.
task-2603045
closesodoo/odoo#138558
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] introduced a method to restore the mega menu state (closed)
so it's not saved open when saving the website builder edition.
That method is `_restoreMegaMenus()`.
It was then moved with commit [2], where it was called in `destroy`
where it was actually making the code crash because once you reach
`destroy`, the website content (the iframe) has already been reloaded
(and thus removed / recreated).
It's done through `reloadIframe()`.
So, depending of your network speed and the server response time, if the
page is served before reaching the mega menu restoration, it will crash.
Restoring the mega menu in the (wysiwig) destroy doesn't seems to do
anything as the page is already saved when reaching `destroy`.
Step to reproduce:
- Have a high latency, like 500ms (you can create a profile in chrome
debug tool in network tab)
- Create a mega menu on the website
- Enter edit mode
- Directly save or discard
-> Traceback, the jQuery toggle elements (`.o_mega_menu_toggle`) are not
in the DOM anymore, since the iframe got reloaded. Those elements
thus don't have a reference to `$` anymore, ultimately making this
line crash:
```js
const $toggle = toggle.ownerDocument.defaultView.$(toggle);
```
[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
opw-3483837
opw-3478642
closesodoo/odoo#138538
X-original-commit: caeb92bfb624c9c30ec9f9e3c2b1dd385e9b089b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
HtmlField's Wysiwyg and website's Wyiswyg have different needs when it
comes to record info. The former has such info in the options object
received from its parent component, which is updated when the record
changes (ex: switching pages in a form view). The latter uses the
Wysiwyg with multiple editable ".o_editable" elements, and each one of
those carry such information in its dataset.
Before this commit, when the HtmlField's record changed, the MediaDialog
would fetch the record info from the editable's dataset, which was no
longer updated. This led to the creation of attachments for uploaded
images with the wrong record reference.
This commit makes sure the correct data is read from the Wysiwyg options
object instead (which contains the up-to-date record info), while making
this behaviour overridable (by website).
This commit also removes the 'res_model' and 'res_id' props passed to
the MediaDialog component, as such props are not used ('resModel' and 'resId' are
used instead).
task-3502797
X-original-commit: 5cd7145a6a182c5d9bff68b0df7d825d4d932209
Part-of: odoo/odoo#138525
Prior to this commit, lazy-loaded bundles weren't pregenerated,
potentially causing non-deterministic test failures when the
generation process took too long. Plus, each Python test loading these
bundles necessitated their regeneration.
With this commit, the lazy-loaded bundles are now included in the
pregenerated bundles.
task-3493014
runbot-24842
closesodoo/odoo#134464
Related: odoo/enterprise#46985
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: web_editor
This warning redirects users to the code snippets block and footer/body
code injection. We want to avoid editing the XML code for no good reason
because it complicates upgrades to the next version.
task-3229205
closesodoo/odoo#117051
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit changes the name of the option which changes the color of
the header. Before this option was called 'Colors' this commit renames
it to 'Background'.
task-2904507
closesodoo/odoo#99732
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a new option to choose the text color when the nav bar
has the position "hover the content".
task-2904507
Part-of: odoo/odoo#99732
Co-authored-by: jpr-odoo <jpr@openerp.com>
This commit allows users to choose any background color for nav bars
that are over the content. Before this commit the available colors were:
- bg-black-{15/25/50/75}
- bg-white-{25/50/75/85}
Now the users can choose any color (except gradients).
task-2904507
Part-of: odoo/odoo#99732
Co-authored-by: jpr-odoo <jpr@openerp.com>
The page options code had a callback for header_text_color, this one was
useless because the select style code already does the job. This commit
removes this useless code and allows the page options not to have a
callback.
task-2904507
Part-of: odoo/odoo#99732
Before this commit, the font color was subject to animations, this
commit removes that because it doesn't look good with a header over the
content.
Steps to reproduce the bug:
- Edit a website
- Set the header to "over the content"
- Put a dark background color on this header
- Scroll down and then up
=> The text color flicker.
Part-of: odoo/odoo#99732
This commit allows to restructure the header formatting options. The
font style option is now alone on one line. A new line of options is
added with the font size, font color and the alignment of the navigation
elements. Note that the font color option is a brand new one.
task-2904507
Part-of: odoo/odoo#99732
This commit allows the color picker widget to manage an SCSS variable
which can itself be a reference to another SCSS variable.
task-2904507
Part-of: odoo/odoo#99732
In this commit, we remove three usages of the getBundle function from
@web/core/assets.js. The final goal is to remove it totally to simplify
the understanding of assets's API. To replace the use of getBundle in
mobile preview dialog, an xml template has been created on the server
side and then called by http requests. During the request, we retrieve
the list of assets (server side getbundle) to inject these into
the xml template.
taskId : 3266441
closesodoo/odoo#138055
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Since the PR [1], the function autocompleteWithPages does not receive
a widget anymore and does not trigger an event on it when an url is
selected. Instead it is replaced by an optional function property
"urlChosen" which is called if given.
The error is that the optional check is wrong. The check is done on
the "options" parameter, not on its optional property "urlChosen".
This commit simply fixes this check.
[1]: https://github.com/odoo/odoo/pull/136271closesodoo/odoo#138047
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Aaron Bohy