Before this commit an error appeared if a block had been set at the top
of the /blog page and the user wished to re-enable the
'Top banner - Name / Latest Post' option. This commit resolves the issue
by giving higher priority to the activated view.
Steps to reproduce the fixed bug:
- Go on /blog page
- Disable the customize option "Top banner - Name / Latest Post"
- Enter in edit mode
- Add a snippet to the top (in the oe_structure)
- Save the page
- Enable the customize option "Top banner - Name / Latest Post"
=> An error happens.
task-2774944
closesodoo/odoo#162620
X-original-commit: 5880aac0c79330e5ef62c475102d53765895cec4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [this other commit], web_editor can call IAP to generate text via
chatGPT. Unfortunately, an unnecessary param (`version`) was given to
IAP leading to a warning on the IAP side
`generate_content_from_conversation> called ignoring args <version=X>`.
This commit removes this useless param.
[this other commit]: https://github.com/odoo/odoo/commit/386a2fdebf429b0318473e596ed9ac0966d9a8b5
Related to task-3383324
closesodoo/odoo#162249
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds the database ID to the IAP calls made to generate text.
It permits to prevent abuses of OpenAI calls.
task-3740440
closesodoo/odoo#154615
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
[This first commit] made it possible to have an error when there was no
comparator for a field with conditional visibility. [This second commit]
prevented an error from occurring in this case. The purpose of this
commit is to prevent the user from getting a conditional visibility
configuration for a form field where there is no comparator.
Steps to reproduce the problem:
- Go to /contactus.
- Edit page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Click on "Visible Only If" again.
=> The comparator is not defined.
Another way to have the issue was:
- Drop a form on a page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Set visible only if Your Name is equal to "test" as condition.
- Click on Your Name field.
- Change the field type to Radio Buttons.
=> The comparator is not defined.
This commit fixes those two cases.
Technical information:
When we change the field's visibility to conditional (`setVisibility`),
we add a default visibility dependency (`_setVisibilityDependency`). At
this point, the comparator is removed and added in `_renderCustomXML`.
`_renderCustomXML` was only called if the visibility dependency had
changed.
[This first commit]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
[This second commit]: https://github.com/odoo/odoo/commit/808780c89cfba940957f7410f787de31e31bda27
opw-3806409
closesodoo/odoo#161527
X-original-commit: 770cc162d6de82818d8e29bf156bb01f65ca8e2c
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
[This commit] fixed an issue with the menu cache. Unfortunately, during
the forward port, we missed updating the cache key according to what has
been done in [this other commit]. This commit updates the cache key and
improves the test.
Steps to reproduce the bug fixed by this commit:
- Render a website without a record URL in the menu (to the cache)
- Edit the website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This issue does not occur if there is a record like URL in the menu
before the first render.
[This commit]: https://github.com/odoo/odoo/commit/970c173530e5523d0e3242ad84dae6fe5e332d68
[this other commit]:https://github.com/odoo/odoo/commit/595aa248433246959a5fa9288e477091701c6a35
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159464
X-original-commit: 9b5647f2951cdd7bde214f860b5ea95d42d2a501
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [this other commit], the style indicating the active nav item
stopped working if the user added record pages to the navbar. This was
due to the cache system not being invalidated when switching from one
record page to another.
This commit fixes the issue by disabling the cache for the navbar if
there is a record page in the menu.
Other potential solutions were considered but ultimately rejected:
1. Using the record as a t-cache key. However, this would mean that if
you have 60,000 visible forum posts, you would end up with 60,000
different caches.
2. Activate the correct element using JavaScript. This would lead to a
duplicate logic in the JavaScript and the Python code, and it would
introduces a slight lag to add the active class on the correct nav item
(due to the time it takes to load and execute the JavaScript).
The chosen solution is the best compromise, as it maintains the cache
for most cases (website menu without records page links in it), nothing
change with this commit. For problematic cases (record pages in the
website menu), this commit disables the cache, which is a reasonable
trade-off.
Steps to reproduce the bug fixed by this commit:
- Edit a website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This commit fixes the issue (a update of the website module is needed)
and adds a test to prevent regressions.
Notes:
- To see the issue locally, remove the --dev xml or --dev all arguments.
- The same issue was occurring with other record pages (blog posts, ..).
- We will introduce back the groups on menu and benefit from this new
method to also disable the menu cache if one of the menu is linked to
a group. See task-3800830
[this other commit]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159006
X-original-commit: 43576cd424b6d0fc7da01142b5e6550e371ad1ff
Related: odoo/enterprise#59321
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
[This other commit] introduced a method to serve Google fonts from the
local server. Then it has been back-ported to previous versions with
[this commit].
Unfortunately, the font was not identical when the user chose to load
the font from Google servers versus from the local server. This
discrepancy was due to a missing parameter when downloading the font
file to serve it from the local server. This commit fixes the issue by
adding the missing parameter.
Steps to reproduce the issue fixed by this commit:
- Drop a text block onto a website page.
- Make the text bold.
- Go to the theme tab.
- Change the font to https://fonts.google.com/specimen/Poppins
=> The text style changes depending on whether you checked the "Serve
font from Google servers" option or not.
[This other commit]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd
[this commit]: https://github.com/odoo/odoo/commit/04ab4e255b7fef1608ee2c70a3a005f3064bc4f3
opw-3775683
closesodoo/odoo#157800
X-original-commit: be2d27e69d7928a46d49a7ef0a3c4b93932a36b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit prevents the sitemap from being translated when a website is
available in multiple languages. The sitemap should always be in the
default language of the website.
Steps to reproduce the bug:
- Set up a website in English and French
- Navigate to the French version of the website (/fr)
- Access the sitemap (/sitemap.xml)
=> The sitemap appears in French but should be in English.
Note: There is a cache for the sitemap. It is not regenerated if it has
been generated within the last 12 hours (see `SITEMAP_CACHE_TIME`).
task-3743970
closesodoo/odoo#155472
X-original-commit: 809854c5d10735fb280141f5291bdb84d8d36569
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Google has removed the feature that allowed sitemap submissions. Now,
it's standard practice for Google to crawl the /sitemap.xml. This commit
permits to show a notification message when the user clicks on the
button to submit a sitemap.
task-3323849
closesodoo/odoo#152700
X-original-commit: fb842f682bb8b2600d861a5e0bb92503857bd2de
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
*: website
When the user uploads an image and remove the original image, some
image options continue to work thanks to a backend fallback on another
image. Unfortunately, this fallback is not available for images coming
from unsplash. This commit fixes this issue by preventing the UI to be
blocked when the original image is not found.
Steps to reproduce the bug:
- Activate the developer mode
- Configure Unsplash in the settings
- Add a Cover block on a page
- Replace the background image with an unsplash image
- Save
- Edit the page and via the media dialog, remove the original image
=> The options on the image cannot start anymore.
opw-3636499
opw-3474103
closesodoo/odoo#148197
X-original-commit: 3b0ac160a800f70ae965b60110e83e41655bca5f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [this other commit], the recipient email option of the form on the
`/contactus` page is not filled correctly with the company email.
By chance, the form signature task fixed the bug but introduced another
one. The previous commit fixed the bug introduced by the form signature
task but reintroduced the inital bug. This commit fixes the initial bug
and adds a test.
By default, the form on the `/contactus` page sends emails to the email
address of the company. Unfortunately, before this commit, when a user
entered edit mode, the Recipient E-mail option always displayed
"info@yourcompany.example.com" even when the company's e-mail address
was different. This commit corrects this by displaying the dynamic value
of `company.email` in the Recipient E-mail option coming from the
data-for.
Steps to reproduce the issue fixed by this commit:
- Go to Settings > General Settings
- Update the company's email address
- Go to /contactus and edit
- Click on the form
=> The recipient email value is still "info@yourcompany.example.com"
instead of the company's email address.
This commit fixes the issue, adds a test to ensure the recipient email
option is correct and adds a utility to parse the data-for data.
Bonus: this commit also fixes the following issue catched by sentry:
- Go to /contactus
- Click on Edit
- In the Form option, remove the content of the 'Recipient Email' field.
- Save
- Fill and submit the form
=> An error is generated in the log.
[this other commit]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544
task-3382195
sentry-4633940473
closesodoo/odoo#147933
X-original-commit: 56f6b8dccec5cebc9a93454538b39886d4d3f63c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The email_to field of the contactus form have to be dynamic except if
the user manually set it via the form options. Unfortunately, the
website signature task broke this feature. This commit fixes it and adds
a test to prevent this regression in the future.
Steps to reproduce the bug:
- Go to the contactus page
- Edit the page
- Add a field on the form
- Save the page
- Change the company email address via the settings
=> The contactus form still send the email to the old email address.
Related to task-3382195
X-original-commit: 10b4db60fbd077936b5c9586485fa40c3c890d3f
Part-of: odoo/odoo#147933
Before this commit, when a user uploaded a webp logo through the website
configurator, the colors of the logo were not detected. This commit adds
the possibility to detect the colors of a webp logo.
task-3609329
closesodoo/odoo#145047
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Before this commit, when a user was uploading a logo for a website via
the website configurator, the logo was added as an attachment but the
potential previous logo was not deleted. This commit fixes this by
deleting the previous logo when a new one is uploaded.
Steps to reproduce the issue:
- Create a new website
- Fill the configurator until you can upload a logo
- Upload a logo, then upload another one
- Finish the configurator
- Edit a page of the website
- Change an image
=> You can see the first logo you uploaded in the list of images.
task-3609329
Part-of: odoo/odoo#145047
Since [this other commit], we add ZWS characters to the edges of links.
Unfortunately, this breaks the label option of the link tools that has
been introduced in [this commit].
Steps to reproduce the issue:
- Go to website
- Edit a page
- Click on the contact us button in the header
- Using the label option of the link tools, delete the final character
=> Nothing happens.
The final character is not deleted as expected.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
[this commit]: https://github.com/odoo/odoo/commit/75166dbcd4962f30624fe19829757acbf8e76022
Related to runbot-44779
closesodoo/odoo#146361
X-original-commit: 593dc52cd5c3362c446395a52a7782f74f445e34
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit converts the industry name in the configurator to lowercase
it in order to optimize the IAP placeholder cache.
task-3626875
closesodoo/odoo#145231
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In the past, it was possible to drop elements in non-editable areas.
Commit [1] fixed the issue but then commit [2] added a solution to be
able to edit a media element that is in a `o_not_editable` environment.
Unfortunately, the solution makes it possible to drop elements next to
the `o_editable_media` elements ignoring the editable context (ignoring
the first fix).
Steps to reproduce the issue:
- Enter website edit mode
- Drop a Team block in a page
- Click on the Team block
=> The user is able to drop a "Text highlight" block next to the team
member pictures.
This commit
- reverts the commit [1] because in the meantime, the commit [3] fixed
the issue.
- fixes the Team block issue.
- fixes the filterFunc for the drop-in.
- adds a test to ensure the issue doesn't come back.
[1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c
[2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78
opw-3536227
closesodoo/odoo#144806
X-original-commit: 9b4c2498b8fa2bc0aca604b6256e6c805b9b4c10
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The `noCheck` param of the `_computeSelectorFunctions` function should
permit to ignore the (not)editable environment. However, since
[this first commit] the `o_editable_media` class alter the behavior
despite the `noCheck` param which is not what we want. Even worse,
[this second commit] check the `o_not_editable` class and the
contenteditable attribute despite the `noCheck` param. This commit fixes
that by restoring the original behavior of the `noCheck` param.
[this first commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[this second commit]: https://github.com/odoo/odoo/commit/56e75ed063b0ae98b9824c0ba00633e529701242
Related to opw-3536227
X-original-commit: 19b269fb2cf7d2abc99d321ef98a1d9d19074e78
Part-of: odoo/odoo#144806
This commit changes the timeout of the OLG call to 20s. We don't want
users to wait too long for the creation of a new website.
Related to task-3248852
closesodoo/odoo#137703
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit prevents the editor to search for anchors when the link URL
is an email. This way we prevent an error in the console.
Related to runbot-18747
closesodoo/odoo#143791
X-original-commit: e767c7d4b0ccdeb016cf224b80e269afce4b3028
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [this other commit], the `link_tools` tour is failing because the
`_syncContent` between url and link text is not working anymore. This is
due to the ZWS that are added to the link to permit the user to select
edges of the link.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
runbot-18747
closesodoo/odoo#143728
X-original-commit: 1afd1ca1539dc61ddb12345160bb82957efae143
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [this commit], the color of the links in the backend is set to the
value of the variable `o-cc3-link`. This causes problems... Firstly,
this variable is defined in the website module, but it is used in the
web_editor module, which does not depend of website. Secondly, this
variable declared in website is made to be modified by the website
administrator via the edit panel (the theme tab). This commit corrects
this by replacing the use of this variable with a hardcoded color.
Steps to reproduce the bug fixed by this commit:
- Have website and project installed
- In the description of a project task, create a link
- Edit a website page
- Go to the theme tab
- Click on Colors Preset
- Open the 3rd preset
- Change the color for "Links" (to red for example)
=> Go back to the project task where you put a link. The link is now red
(this may require a page refresh). But the website option should not
change the links in the backend.
This commit removes the website builder related color o-cc-3-link
usage for editor links.
[this commit]: https://github.com/odoo/odoo/commit/5d598e4269431222ae28ac2196ff6f1f45466734
task-3275134
closesodoo/odoo#142542
X-original-commit: 6f10705e043115369ec581a83f65482ea83d25c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit removes some text style options when the editor is used in
the backend. In the website it makes sense to have all the options but
in the other apps, it is not necessary to have all the options.
task-1958098
closesodoo/odoo#141412
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit reduces the padding of the website loader to prevent too
much line breaks of the text.
task-3557675
closesodoo/odoo#138921
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a fake loader during website install. [Another commit]
already added a loader during extra module install. The goal here is to
have a loader even if there is no extra module to install. This should
make the user think the install is faster and prevent him from leaving.
This commits also improves the loader when there are extra modules to
install. We split the loader in two parts: one for the modules install
(70%) and another for the rest of the install (30%).
Note that to test this feature properly, you need to be in a multiple
workers environment.
[Another commit]: https://github.com/odoo/odoo/commit/ab6564be94533a64a0a942202f0860423ec7dc4d
task-3557675
Part-of: odoo/odoo#138921
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 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>
*: 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>
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
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>
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>
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>
Before this commit when the user was dragging an image in the editor,
the image was always dragged from the top middle of the image. Now the
user can drag the image from anywhere on it.
task-3369600
Part-of: odoo/odoo#125151
This commit permits to drag and drop images directly (without using the
`o_move_handle`) with the website drag & drop tools. The user can
directly drag the image in edit mode by grabbing the image itself. It
was already possible to drag the image itself but this commit permits to
activate the website tools (grid mode, see dropable areas, etc.) while
dragging the image.
task-3369600
Part-of: odoo/odoo#125151
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>
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
*: auth_totp_portal, event, portal_rating, web, web_tour, website_blog,
website_event, website_event_booth, website_event_sale,
website_event_track, website_event_track_quiz, website_payment,
website_sale, website_sale_comparison, website_slides,
website_twitter
This commit allows to have responsive font sizes on all the Odoo
frontend. It is based on the Bootstrap mixin `font-size` which
calculates the font size based on the viewport width.
task-1958098
closesodoo/odoo#129469
Related: odoo/design-themes#673
Related: odoo/enterprise#44578
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a new snippet to display an Instagram page on the
website using an iframe that embeds the Instagram page.
task-2603045
closesodoo/odoo#133905
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Some pages don't have an image for the sharer. This wasn't too critical,
as the code to retrieve the image was written in JQuery and didn't cause
any problems if no image existed.
```
$('meta[property="og:image"]').attr('content')
```
If there is no element matching the selector, it returns `undefined`.
[This commit] was merged and migrated the JQuery code to vanilla JS.
```
document.querySelector('meta[property="og:image"]').content
```
If there is no matching element, it throws an error (we can't read the
content on undefined).
This commit keeps the vanilla JS code but prevents the error if there is
no image to share. In addition, for this master commit, we took the
opportunity to refactor the code.
Steps to reproduce the bug as an admin:
- Go to /slides and click on "View" next to the user's name
- Edit the page
- Drop the share block on the page
- Save the page
- Click on the Pinterest share button
=> An error appears on the screen.
[This commit]: https://github.com/odoo/odoo/commit/ddb2c06be4196c86ff6a2fd74874487d75b31c94
opw-3326724
closesodoo/odoo#136737
X-original-commit: 66651fabcc36e8d5f455c08d5bffb9036bef8d3c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit allows you to change the title of the social media block
after the first save. If an element is in a parent that has the class
`o_not_editable` then it is only editable if it has the contenteditable
attribute set to true. We rightfully remove this attribute at saving but
without putting it back when we return to edit mode. This commit allows
to fix this case. Note that we have to improve this system in the future
(so we can get rid of this patch).
This part of the fix is very similar to [this other fix] for the team
block.
[this other fix]: https://github.com/odoo/odoo/commit/b7d53d2fcb20a447fd3098adf94ffb33bc49dda9
task-3073171
closesodoo/odoo#134281
Part-of: odoo/odoo#105964
X-original-commit: 44b0bcbdd67721e3b45567d26da00e4a3910f541
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit allows you to change the icons of custom links of the social
media block after the first save. Thanks to [this other commit], there
is now a class that permits to inform the editor that a media is
editable even if it is a non-editable parent. This commit permits to use
the new class to fix the issue.
Steps to reproduce the bug:
- Drop a social media block on a page
- Add a custom social media
- Save
- Edit
- Try to change the icon of the custom social media with a double-click
=> The icon cannot be changed.
Note that [another commit] had already been made and fixed the problem
halfway (the icon change didn't work on double-click). This commit
reverts it and fixes the problem correctly with the new system.
[this other commit]: https://github.com/odoo/odoo/commit/6ead397f33512c918f51feb2b32fb3e15ffedf34
[another commit]: https://github.com/odoo/odoo/commit/bb291b35e46e42ca098aa3e04ac0b473f72be423
Fixes https://github.com/odoo/odoo/issues/104048
task-3073171
X-original-commit: b844351b9814ff2167d2183ab3216e2d1ec1d216
Part-of: odoo/odoo#134281
Since [this commit], it's now possible to edit a media when it's in a
parent that is not editable thanks to `o_editable_media` class.
Unfortunately, these changes make the new class bypass the potential
`data-exclude` defined in the XML option declaration. So if the target
looks like that:
```html
<img class="o_editable_media odoo"/>
```
and the XML option declaration has a `data-exclude=".odoo"`, the option
will still be displayed. This commit corrects the way the
`o_editable_media` class works, so that it only bypasses the
`.o_not_editable` but not the entire exclude.
[this commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
task-3476644
closesodoo/odoo#133663
X-original-commit: f73734557116a348ac14b2724e1380546192ca12
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
As it is not possible to have a `.o_wslides_home_nav` in a `o_quiz_main`
we can remove the scss dead code related to it.
task-3476128
closesodoo/odoo#132793
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When you drop a block containing a carousel, you can change the slide.
Unfortunately, in edit mode, changing the slide creates a step in the
history (you slide in the other direction by pressing CTRL-Z). This is
not what you want.
task-3356629
closesodoo/odoo#130417
X-original-commit: 5c68489c4220fe50c26168f2fb98546626b36e78
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since Odoo 16.0, the configurator is translated in the user language.
Unfortunately, the theme previews are not yet translated in the user
language, so the user sees the theme previews in the default language
(English) but on a rtl page which causes alignment issues on the themes
previews. This commit fixes this issue by forcing the SVG containers
to be in ltr.
Steps to reproduce the issue fixed by this commit:
- Set the Arabic (Syria) language for an internal user
- With the internal user, create a new website
- Follow the configurator (in Arabic) until the theme selection step
=> Some text in the theme previews are not aligned correctly.
task-3398707
closesodoo/odoo#130325
X-original-commit: 1d0671a22582f423e55aad2907340700697c966e
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [this commit], when the user configures a new website, he can
set an unknown industry. Unfortunately, if he does so, by default, we
set the industry to abbey, which is not very good for the default images
the user will see and for internal IAP stats. This commit permits to use
the new industry called Unknown, which is used for unidentified
industries. When the industry is unknown, we leave the default theme
images.
[this commit]: https://github.com/odoo/odoo/commit/e82a1cb2ef1bcb413d99e7eb7521405d1d2e88d2
IAP PR: https://github.com/odoo/iap-apps/pull/635
task-3337894
closesodoo/odoo#129154
X-original-commit: 17dd3a84d9d9d42b04fde9aac708c032a472b13b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [this commit], we have a range input to select a price filter for
products. This input displays a min and max price that the visitor can
select. The problem is that the price is not formatted according to the
visitor locale. This commit fixes this issue.
Steps to reproduce the bug:
- With English as language, go to the shop page
- Go to Customize and activate filter by price
- Install French on the website
- Visit /shop in French
=> The price is not formatted according to the French locale. For
example, we can see a price of a thousand euros displayed as 1,000.00
but in French, it should be displayed as 1 000,00.
[this commit]: https://github.com/odoo/odoo/commit/41f7c7bc6428050d4c7956edca26b7c1bd2d8e04
task-3414455
closesodoo/odoo#127881
X-original-commit: 683b7edf0ce1f098757aa1e38ee6dc5d4e255272
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
We have a public widget that disables automatic slides on carousels when
the user is in edit mode (see `registry.slider`). Unfortunately, since
[this commit], the automatic slide of the carousel in the "Products"
block was not disabled in edit mode. This was because a
`widget_start_request` was made without specifying whether the user is
in edit mode. When it's not specify, we consider that we are not in edit
mode. As a result, the public widget no longer stopped the carousel
because it considered that it was not in edit mode. This commit fixes
this problem by correcting `widget_start_request`.
Steps to reproduce the bug fixed by this commit:
- Have an ecommerce
- Edit a page
- Drop the "Products" block
=> If you wait a few seconds, the carousel moves, even though it
shouldn't as long as you're editing your site.
[this commit]: https://github.com/odoo/odoo/commit/7af099ccf1e5892513c1b0827553fe93614f2f07
task-3356629
closesodoo/odoo#127185
X-original-commit: 4231aca9665829673e29a027469471743dab16c4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
For each form action, existing fields can be defined. These existing
fields are references to objects in the ORM. It is possible to put a
domain on the field in order to filter the elements you want. For
example, the "Create an opportunity" action has a "Salesperson" field
that refers to users. This field filters the external users of the
company in order to have only the internal users. Unfortunately,
although this domain is present, it was not taken into account when
displaying the values for the field. This commit fixes this problem and
takes into account the defined domain.
Steps to reproduce the bug fixed by this commit:
- Have the website_crm module installed
- Put a form on a page of the website
- Set the form action to "Create an Opportunity"
- Add a new field
- Set the field type to "Salesperson"
=> The list of users displayed contains external users of the company.
task-3095745
closesodoo/odoo#121903
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since [this other commit], initializing the color picker could trigger a
traceback. The traceback was due to the fact that for users to be able
to drag/move the color picker as they wished across different frames, we
needed access to the document of all the frames on the page.
Unfortunately, if one of these frames was not of the same origin, a
traceback was displayed. This commit corrects how we collect documents
from frames on the page, by only taking those whose document we have the
right to see (which do not raise a cross origin error). I didn't succeed
to reproduce the bug locally, but I got it on the runbot with theme
Nursery / Kiddo by dropping the block banner on the page, the error
appears because the block contains a vimeo video. In fact, you just need
to have embedded content (youtube / vimeo / ... video for example) start
edit mode, click on the block containing the video and the error is
displayed.
[this other commit]: https://github.com/odoo/odoo/commit/63bf363d302fe9f93a824fa6f1ff3bbe21f98088
runbot-22573
closesodoo/odoo#126447
X-original-commit: b22c1d942374014e0d50e5429c3f89cc1ca18173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
In the website settings, one of the fields allows you to switch settings
from one website to another. Unfortunately, as soon as the user did this
the record was considered to have changed (dirty) and therefore required
a save when it wasn't necessary. The previous commit prevents the header
settings (like the website switcher) from dirtying the record. This was
really necessary because as soon as a user had several websites, it was
impossible for him to access certain settings on all these websites
(except the first one). As soon as the setting performed an action, a
save was required (because the record was dirty) and the user was
redirected to the settings again.
Steps to reproduce the issue before the previous commit:
Install website
Have multiple websites
Go to Settings > Website Settings
Change the website
=> The user is notified that the record has changed and needs to be
saved, which is not true. So far it's annoying but not critical, but if
the user continues:
Activate the "Extra step during checkout" option
Click on "Configure Form"
=> The Save/Discard dialog appears because the record is dirty.
Click on "Save"
=> The user is redirected to the settings page again and cannot access
the form configuration of the second website. (it is the same issue for
most of actions).
The previous commit fixes the issue and this commit adds a test to
ensure that the users are able to change settings of multiple websites.
task-3265100
closesodoo/odoo#126387
X-original-commit: bed37396839891da04126a71b3d6a6e5e56672b0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When a user creates a link that is tracked, an interface with graphs is
presented to him so that he can track the performance of his tracked
link. Unfortunately, these graphs did not work when the site was in a
foreign language. This was due to the fact that the code had not been
designed to handle this. This commit fixes the code so that it works in
all languages.
Note that the data is received via RPC and the python code format the
dates for the current language of the website. So we had to do a little
hack to make it work properly.
Steps to reproduce the issue:
- Install website_links module
- Go to the website app
- Click on Promote > Link Tracker
- Create a tracked link
- Visit the link
- Install Arabic (Syria) for your website
- Check the stats of your link in Arabic
=> There is a traceback and the data is not displayed.
task-3289167
closesodoo/odoo#126273
X-original-commit: e690da6ed1493e1def47cca6ef61e01ca8fa885f
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This commit adds a margin top on the we-alert to make it prettier.
Otherwise, the alerts are too close to the elements above them.
task-3302433
closesodoo/odoo#120874
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Users are not supposed to be able to change the field type for fields
that are required by the model. This commit removes the option to change
the field type for fields required by the model.
Steps to reproduce the bug fixed by this commit:
- Put a form on the page of a website
- Set the form action to "Send an E-mail".
- Click on the "Your Email" field
=> The user can change the type for this field. We don't want this
because this field is linked to the `email_from` field in the
`mail.mail` model. This commit fixes this issues for every model
required fields.
task-3302433
Part-of: odoo/odoo#120874
When a user puts a form on his site, depending on the action of it, some
fields of the form become necessary. These fields cannot be deleted.
Unfortunately, some users do not understand this. This commit helps
users understand that these fields are required for the action by adding
an alert in the required fields options and by improving the tooltip
displayed when the delete button is hovered.
task-3302433
Part-of: odoo/odoo#120874
Before this commit, website and email editing was very limited on
devices that have a touchscreen. The blocks tab, the we-lists, ... were
unusable.
Example of issues (on a device that has a touchscreen):
- The users cannot drag & drop snippets in the page.
- The users cannot reorder the values of a multiple checkboxes field.
- ...
This commit allows to handle touchscreen events by translating them
into mouse events to allow users to fully use the editor.
opw-3195487
closesodoo/odoo#125976
X-original-commit: 142684dbe7e5c9d5c5fc1baa00b1027367a45213
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit adds arabic in the list of iap languages so that we can test
that the industries are correctly translated in arabic.
related to task-3343616
closesodoo/odoo#125005
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit changes the way the we-many2one and we-many2many fields work
so that they check if the model they are attached to has a website_id
field, if so, the data loaded from the model will be that related to the
current website.
After this commit, developers can get rid of the website_id field when
they add a many2X field. The domain will be automatically computed.
task-3316278
closesodoo/odoo#124985
X-original-commit: 78cfcf3b2b3a44ee8e19084639e37277991b969a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
This commit clears the cache of we-many2X widgets. Since [the merge of
the backend into the frontend], the page is not refreshed when the user
goes to modify data in his backend. This means that if the data has been
changed between two editions of a page and the many2X widget has already
made the RPC call, it will not do it again and will still have the old
data. For example with website installed:
- Edit a page of your website
- Add the add to cart button
- Search for "ERP" product
- The product does not exist so save the page
- Create and publish a new product called "ERP"
- Edit the page again
- Search for the product "ERP"
=> It is not present because the query is in the cache which has not
been cleared. If you refresh the page, the product will be found.
This commit fixes this problem by clearing the cache after an edit.
Note that a similar implementation of caching clearing has been done
here: https://github.com/odoo/odoo/commit/3efb726575679f62f9ee2894193323bfe45d7938
[the merge of the backend into the frontend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3078137
closesodoo/odoo#124908
X-original-commit: ff0cfca420a434e6024654749ea316bbfc5e0772
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
This commit adds a test to check that the IAP languages work as
expected for the website configurator. The test checks that the
industries are translated (different than other languages).
task-3343616
closesodoo/odoo#123722
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit permits to enlarge the answer textarea in the forum.
Steps to reproduce the "issue" resolved by this commit:
- Go to /forum
- Click on a thread
- Click on "Answer"
=> The textarea is too small to write a long answer.
task-2865782
closesodoo/odoo#124740
X-original-commit: faaf76c0043d72da7cec587c327d6b508b2ca0fd
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the website forum, we checked that the post content is not empty
before posting a post or an answer. Before this commit, it was just a
verification that the content is not an empty string.
Users are also able to post an image and we want to allow them to create
a post or an answer with only an image. This commit changes the
verification to check if the content is empty or if it only contains
images.
Steps to reproduce the issue resolved by this commit:
- Go to the website forum
- Create a new post
- Set a title
- Add an image as description
- Click on "Post Your Question"
=> The post is not created because the content is considered as empty.
task-2865782
X-original-commit: 048c6b779423ff34dd80f51e2a9202e16553a3ae
Part-of: odoo/odoo#124740
This commit allows users to choose any color for their navbar when it is
over the content. With this commit, the user can choose the color he
wants for his navbar when it is scrolled and when it is not scrolled
without worrying about color mixing.
To simplify the explanation below, note that "Colors" option means the
Colors option of the header (just below the Template option) and the
"Background" option means the option below Header Position.
By following these steps:
- Drop some blocks in a the page (to be able to scroll)
- Set a light transparent red for the Colors option.
- Set the navbar position to "Over the content"
- With the Background option, set the background color to a dark color.
=> When you are at the top of the page, the color is the one of the
Background option. So far so good. Now when we scroll, the color of the
navbar is dark red. This is not what the user expects. The user should
be able to have any color he wants for the scrolled navbar. It's not the
case before this commit. He cannot have a dark transparent header on the
top of his page and a light transparent red when he scrolls. In this
configuration, the Colors option should set the color of the navbar once
the user has scrolled. The colors should not be mixed.
Technical explanation of the problem:
Background option applies the color on the header element and Colors
option sets the color on the nav element. The nav element is a child of
the header element.
So when the header has a color set by the Background option and nav has
a color set by the Colors option which has transparency, the color of
the header influences the color of the navbar when scrolling. This
commit allows to correct this.
This commit also fixes the same problem for the gradient option.
task-2904507
closesodoo/odoo#106281
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
We don't want users to edit their websites on a too small screen. To do
this, we hide the edit button when the screen width is less than 768 px
(the MD breakpoint of Bootstrap). Unfortunately, when a user creates a
new website, they go through the website configurator and are then
redirected to their new website with the edit mode enabled. We don't
want that when the screen is small. This commit only opens edit mode
after a website is created if the screen is large enough. Note that this
commit will also prevent users from forcing edit mode with the url
(enable_editor=1) when their screen is too small.
task-3316267
closesodoo/odoo#123992
X-original-commit: 00ea187ce641013feea00650cb2cadab73ebe636
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
When you create a new website, the contactus page have default action
("Send an Email"). For each action, there are mandatory fields that
cannot be deleted by the user. Unfortunately, the template for the
`/contactus` form didn't have the right fields marked as mandatory.
This led to the following bug:
- Go to `/contactus`
- Edit the page
=> The Email and Subject fields can be deleted. However, when you drop a
form and set the action to "Send an Email", these fields are mandatory
and cannot be deleted. This commit fixes this bug by ensuring that these
fields are marked as mandatory on `/contactus`.
task-3302433
closesodoo/odoo#123360
X-original-commit: 09a9cff6af44157c760c4f3d95d478f10d5c2411
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Since [this commit] which allows to have mega menu with transparency,
the user can see the color of the block which is positioned at the very
top of the page (behind the mega menu when it is open). Before that,
the gap was always gray.
Steps to reproduce the bug
- Have a mega menu on your site
- Put a block on top of the page
- Put a red background color on this block
=> When you open the mega menu, you can see the red color between the
mega menu and the navbar.
[this commit]: https://github.com/odoo/odoo/commit/147f99bb04f83943aaedbacb1844234288e60eaf
task-3327094
closesodoo/odoo#123312
X-original-commit: dba1dac5d0b09e999e194debcb5907affca61bd7
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Since [this other commit], a traceback is displayed when the user wants
to see the pages of his site when he has only one site. Steps to
reproduce the bug fixed by this commit:
- Launch Odoo without any app installed and without demo data
- Connect to the DB
- Activate the Website module
- Skip the configurator
- Choose a theme
- Discard edit mode
- Go to Site > Pages
- Go to kanban view
=> An error is displayed because the record has no website_id.
[this other commit]: https://github.com/odoo/odoo/commit/f23399db1dfb816a68ecf1be4367234b6e9a28bc
task-3316267
closesodoo/odoo#122754
X-original-commit: 322f0882e9fc0b33c90a2e22fdffa01b5d4345e4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When a new user is created from the website, the company id was always
set to the first company of the database even if the website was the one
of another company. This flow has been already fixed if there is the
"Specific User Account" setting activated (see [this other commit]).
This commit fixes the same issue but for every case.
Steps to reproduce the issue:
- Create 2 companies A & B
- For each company, create a website linked to a different URL
- Activate 'Free sign up' for company B
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account
=> If as an admin you check the company of the created user, it is
company A instead of company B.
[this other commit]: https://github.com/odoo/odoo/commit/77c708c516beb322df37220634e178ba82e894c9
task-3277317
closesodoo/odoo#121834
X-original-commit: 3fbfb5301c7583583e4f46c9b4ef16e048e5800c
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Before this commit, when a cookie bar was displayed on a page and
elements of that page were animated (on scroll and on appearance), those
animations did not work while the cookie bar was present. This commit
fixes that and enables animations even if a cookie bar is displayed. The
problem was that we were looking to see if a modal (cookie bar, popup)
was displayed and if it was, all animations were based on the scroll
height of that modal. However, this should only be done for elements
that are in the modal. The other elements should always base their
animation on the scroll height of the page.
task-3151000
closesodoo/odoo#121543
X-original-commit: 406fc8a59a36313f382a34aaba143ab2a9845718
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume <gdi@odoo.com>
Before this commit, the user could use the blog publication date
selector situated in the blog sidebar even when he was in edit mode.
This date selector should behave like a link, it should not work in edit
mode. This commit prevents the user from using this selector while he is
in edit mode.
Steps to reproduce the bug:
- Go to /blog
- Edit the page
- Enable the sidebar option
- Click on the select in the sidebar
- Click on a date
=> An error is displayed.
task-3213851
closesodoo/odoo#121142
X-original-commit: 7e8e12c40b03d923b17831d95a5fe94410c2a56e
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Dieleman Guillaume <gdi@odoo.com>
*: mass_mailing_themes, website_mass_mailing
This commit adds TikTok to the already existing social networks in all
email marketing templates (droppable blocks and default mail templates).
task-3235451
closesodoo/odoo#116837
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: website, website_blog, website_event
This commit adds the TikTok social network to the other social networks
stored in DB. Thus, users of the Website application will be able to
reference their TikTok page on their websites. This commit also updates
the different templates and the social media block to integrate this new
social network.
task-3235451
Part-of: odoo/odoo#116837
*: test_website, website_blog, website_crm, website_hr_recruitment,
website_mass_mailing, website_sale, website_sale_wishlist,
website_slides
This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.
This commit replaces all the uses of the old util with the new one, it
also removes the steps that are waiting for the edit mode to start.
Finally, from [this other commit], we can start a tour in edit mode. For
these tests (which have `edition: true`), it is useless to check if the
edit mode has started at the beginning of the test because this check is
already done by default. This commit removes unnecessary / duplicated
steps.
[this other commit]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35#diff-c7720501ec33f5f92c907d8bb41de50edd832a4564317073e801a6915796a6bdR278
task-3203820
closesodoo/odoo#120481
X-original-commit: https://github.com/odoo/odoo/commit/9fd5d25f59578abc9c608578a7d2e2953880b582
Related: odoo/design-themes#656
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
In the website menu editor and in the studio menu editor, the user can
drag & drop the elements that constitute the menu of his website/app.
Users can also put a menu into another menu to create a sub-menu. For
the website, we allow two levels of menu but not more. For studio we
allow 5 levels of menu. When the user starts to drag an item, dropzones
can be drawn on the prohibited level (3 in website, 6 in studio) while
he can't create this level of menu. This commit adds a css rule to hide
those forbidden dropzones.
task-3251032
closesodoo/odoo#120497
X-original-commit: dac80feb84d213e5e0a1aa140fa019944ea4e826
Signed-off-by: loco-odoo <loco@odoo.com>
Since [this other commit], custom blocks are not displayed correctly in
the editor. The DIV tag is not supposed to be self-closing. However,
older versions of JQuery supported it anyway (they turned `<div/>` into
`<div></div>`) Since the update of JQuery to version 3.6.3, self-closing
DIVs are no longer correctly supported by JQuery.
For example, if you type this in the Chrome console:
```
$(`<div id="divRoot">
<div id="selfClosing"/>
<div id="notSelfClosing"></div>
</div>`)[0]
```
JQuery will create the following structure:
```
<div id="divRoot">
<div id="selfClosing">
<div id="notSelfClosing"></div>
</div>
</div>
```
JQuery doesn't parse the HTML correctly and returns a wrong structure
(the `#notSelfClosing` is moved inside the `#selfClosing`).
Note that doing `$('<div/>')[0]` will return a correctly parsed DIV.
This commit corrects the layout structure of custom blocks so that they
are not composed of self-closing DIV.
Steps to reproduce the issue:
- Edit a website page
- Drop a block
- Click on the save icon
- Click on "Save and reload"
=> The custom block is not displayed correctly.
[this other commit]: https://github.com/odoo/odoo/commit/ae1cd3d5bb99b9835501144522b71f152aaf8e34
task-3290172
closesodoo/odoo#120027
X-original-commit: fd76d59bcd08e824c4e46814d0754a225f7a1b72
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Since [this commit], a horizontal scrollbar appears on mega menus. This
is because Bootstrap position the dropdown automatically and the mega
menus are a bit shifted on the right (due to a `translate3d` added by
dynamic position of popper). This commit fixes the problem by removing
dynamic positioning for mega menus.
Steps to reproduce:
- Have a system setting that enlarges the texts size or zoom the page
- Have a mega menu
- Open the mega menu
=> There is a horizontal scrollbar.
[this commit]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
task-3133137
closesodoo/odoo#118842
Signed-off-by: loco-odoo <loco@odoo.com>
Since the upgrade to Bootstrap 5 and especially since this [BS5 commit],
there is a gap between the mega menu and the navbar when the user opens
a mega menu. This commit removes that gap.
Steps to reproduce the bug fixed by this commit:
- Have a mega menu on your website.
- Drop a block of a dark color at the top of the page (it helps to see
the problem).
=> When you open the mega menu, you can see a small piece of the block
of dark color between the navbar and the mega menu.
Technical explanation:
This [BS5 commit] introduces a new css rule that adds a
`margin-top: 0.125rem;` on the `.dropdown-menu[data-bs-popper]`. However
when [mega menus were introduced], another css rule prevents having a
gap between the nav and the mega menu (`margin-top: 0;` on
`.o_mega_menu`). This commit makes sure that it will be a `margin-top`
of 0 by making the property more important.
[BS5 commit]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[mega menus were introduced]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
task-3133137
opw-3226013
X-original-commit: b41c76bd7583756ad059f77f0d3c1151720b0b0b
Part-of: odoo/odoo#118842
This commit allows to reopen submenus and mega menus if one of them was
opened when scrolling on a page of a website.
Steps to reproduce the bug fixed by this commit.
- Have a submenu or a mega menu in the navbar
- Open a dropdown of the navbar
- Scroll down
=> It is no longer possible to open the dropdown.
This commit fixes this issue and adds a test for this flow.
task-3133137
opw-3226013
X-original-commit: 9b1de9e28697edbb6e1fa88665294f983f60e37f
Part-of: odoo/odoo#118842
This commit patches the font awesome library to add an icon for the
TikTok social network. Users are now able to add these icons with the
media dialog. Now, the TikTok icon works like all other font awesome
icons, with the new class introduced by this commit: `fa-tiktok`.
Moreover, the social media block in the website application can detect a
tiktok link and automatically integrate its icon with its color.
Technical note:
In order to add this new icon, a new font that contains only the TikTok
logo has been created.
task-3235451
closesodoo/odoo#118542
X-original-commit: dc926d56a286eebd3e7c10343824a6e2c1a76adc
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Before this commit, the sub-menus that appear when the mouse hovers them
were not displayed correctly. The Bootstrap/Popper code which is in
charge of positioning the sub-menu could not work because the dropdowns
were opened manually (which is not recommended) and so, the
`show.bs.dropdown` event was never triggered which prevented
Bootstrap/Popper from aligning the sub-menu items correctly.
Steps to reproduce the bug:
- Have a long sub-menu in the last position of the navbar.
- In edit mode align the navbar elements to the right.
- Enable the option to have the sub-menus displayed at hover.
- Save the page.
=> When hovering the sub-menu, it opens on the right and overflows the
page while there is enough space on the left.
task-2904507
closesodoo/odoo#116535
X-original-commit: https://github.com/odoo/odoo/commit/03c82f6b0094c9d038b1699376d49f2846298bcd
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Before [this other commit], it was possible to add a wrong video on a
page of its website. If the user did this and saved the page, it was no
longer possible for him to enter edit mode. To solve this, two
improvements have been made:
1. We now prevent the user from putting a wrong video on his page when
he goes through the media dialog (see [this other commit]).
2. Since there are probably websites that have a bad video (it was
possible before [this other commit]), this commit allows users to edit
the pages that have these wrong videos.
Steps to reproduce before [this other commit]:
- Edit a page.
- Via the media dialog add a video with the following URL: 'google.com'.
- Save the page.
=> It is no longer possible to enter edit mode.
Note that part 1 was merged from 14.0 but part 2 was merged from 16.0
because the media dialog adds `iframe` without `src` attribute since
[the refactor of the media dialog] and we cannot edit a page containing
this code `<div class="media_iframe_video"><iframe/></div>` since the
merge of the frontend into the backend.
[this other commit]: https://github.com/odoo/odoo/commit/fbab1bffa033638553750d49fcde89a9a2fc5e6c
[the refactor of the media dialog]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
opw-3167707
closesodoo/odoo#116128
X-original-commit: 242d6f2e1dc35c3d22314a4c92c2420f69eb9970
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Guillaume-gdi