Since [1] the back button did not navigate within the steps of the
website configurator anymore.
After this commit the window location change that happens within the
browser is copied back into the state - thus causing a redraw of the
correct configurator step.
Steps to reproduce:
- Create a new website
- Go to second step
- Press browser's Back button
=> Did not navigate to previous configurator step.
[1]: https://github.com/odoo/odoo/commit/56cc3dfab156f21c7ef97b3c407f1480b094fe93
task-2789075
closesodoo/odoo#96766
X-original-commit: d32f8a9d64f0487e1e61ec7cee7cffde21b8ddb2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When navigating backward to step 2, the website purpose is reset in
order for the navigation to not automatically advance to step 3.
Because of this, when navigating to further steps with the browser's
forward button, that field remains empty. This ultimately produces
an error when the configurator state is extracted to generate the
website.
After this commit the former selected purpose is kept when no purpose
is selected anymore. It is then used when collecting the configurator
details if there is no selected purpose.
task-2789075
closesodoo/odoo#96640
X-original-commit: d874958aa44c0bd96ab7b84f7066c9b8d28642d6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] moved the editor in the backend introducing changes to the
way some options interact with the website. This unfortunately broke
the header position option, the header background option and the footer
visibility option.
The header position option would loop indefinitely, the header
background color option would not display the correct preview colors and
the footer position would trigger a traceback.
This commit fix those bugs:
- The header position option had a callback that was never called, it is
now called.
- The copy of styles introduced by [2] is now less implicit. Only styles
that are defined in web_editor/common/utils:
[EDITOR_COLOR_CSS_VARIABLES] are copied on the snippet menu, and only
those variables will be used as background colors for the preview
elements. (Allowing for every other colors like black and white to be
used with classes).
- The footer visibility option had a broken line of code that was copied
from past code. It is now fixed and working.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
task-2687506
closesodoo/odoo#94949
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since this commit [1], when you select the Header position option and
set it to "Over The Content", the change is not saved if you did not
edit something else in the page too.
Indeed, now that the "save" works correctly (and that it no longer saves
the page every time). It does not detect the change made by this option
which is to add a class on the '#wrapwrap' element. (The editor looks
for changes inside the wrapwrap but not on it).
This commit checks if any page option is dirty on save on top of
checking if the content of the page has been modified.
Additionally, this commit fixes a bug that would occur on Firefox based
browsers where the hidden input used to display the status of these
options would be auto-completed by the browser in some conditions.
(https://bugzilla.mozilla.org/show_bug.cgi?id=520561).
This could result in an incorrect state being displayed.
To reproduce:
- Change the option, click on cancel, start the editor
- the incorrect state is displayed
A test is also added by this commit to verify that all the page options
works correctly.
[1]: https://github.com/odoo/odoo/commit/bab673488e185ddd7792aedecc3870663290fed3
task-2871426
X-original-commit: ea7a69b344d970cc2b31555f4cd8fd7c5e2fc6d2
Part-of: odoo/odoo#94949
==== Short version ====
Google is deprecating Universal Analytics in July 2023 and Google
Sign-In in March 2023. Google Analytics Embed API is based on Sign-In,
meaning it won't work anymore. It actually already doesn't work anymore
for accounts created somewhere after mid-2020 apparently.
There is no plan for now for Google to allow Analytics 4 dashboard to be
embed in external website.
We therefore can't do anything to keep the Google Analytics dashboard in
Odoo.
In previous stable version, it was kept but is displaying a warning
about it (as until mid 2023 old accounts can still embed it).
All this is about the embed dashboard, not the tracking in itself for
which Odoo is already adapted in Odoo 15.0 for Analytics 4.
==== Detailed version (following short version, read it first) ====
- Universal Analytics EOL July 2023, see [1].
- It will be replaced by Analytics 4 for which Odoo is already ready and
actually using it since version 15.0 with [2].
- Google Sign-In EOL March 2023, see [3]. Analytics Embed API was based
on it, it won't work anymore.
- There is no plan (for now) for Google to allow Analytics 4 to be able
to be embed in external websites. They seem to just have dropped the
"feature".
This was confirmed by Google here [4] and indirectly here [5] in the
DOC:
`Note: This API does not support Google Analytics 4 (GA4) properties`
- While the EOL is planed for 2023, the dashboard integration is already
not working anymore for new accounts.
- Old projects/keys/accounts can still embed their analytics dashboard.
The threshold seems to be somewhere mid-2020, according to [6].
It seems to be accurate as my own key from 2018 still works, while my
keys from 2021 do not.
==== Fix ====
- In stable, warn user about it in their Odoo Analytics dashboard (this
PR) and also add a warning about that on the doc.
- In master, simply drop the whole google analytics dashboard
integration and remove the doc about it, see [7].
==== Useful links ====
[1]: https://support.google.com/analytics/answer/11583528?hl=en
[2]: https://github.com/odoo/odoo/commit/78bc86cbeccfc5df16218aee2b0d7c501e5c05b5
[3]: https://developers.googleblog.com/2022/03/gis-jsweb-authz-migration.html
[4]: https://issuetracker.google.com/issues/233738709?pli=1
[5]: https://developers.google.com/analytics/devguides/reporting/embed/v1
[6]: https://support.google.com/analytics/answer/11583832
[7]: https://www.odoo.com/documentation/15.0/applications/websites/website/optimize/google_analytics_dashboard.html
Finally, note that it means that from July 2023 to Octobre 2023, while
Odoo 14.0 is still supported, Google Analytics won't work anymore in
that version as it will still be designed for Universal Analytics and
not Analytics 4.
opw-2710910
opw-2855405
opw-2881515
opw-2892370
task-2790245
task-2820890
closesodoo/odoo#96280
X-original-commit: d065595f77790fb5ab9480f6de5b88549352324b
Related: odoo/enterprise#29666
Related: odoo/upgrade#3698
Related: odoo/documentation#2499
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the "Edit Menu" was displayed for the restricted
editors, even if they didn't have the right to access the website pages.
This was leading to a warning in the "click_all" test with the demo
user, and didn't make sense for the real user (who was prompted an
"access denied" modal).
Now, this menu is displayed only for the website designers.
Additionally to that, the website root instance would load the wysiwyg
assets if it is created inside an iframe which has the "load-wysiwyg"
data-attribute. But the test was not correctly written (as
data-load-wysiwyg was the string 'false'). This would lead to a warning
in the console when a user with no website rights was accessing the
website client action, introduced in [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#96520
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
*hr_timesheet,point_of_sale,website
This commit moves the settings form view implementation from base
to web, and converts it to owl.
The setting's search has been improved to take into account more
elements. Before, it was possible to only search on the field's
labels. Now, we can also search on the field's description, and
the titles of setting's group.
Part-of: odoo/odoo#78221
Co-authored-by: Samuel Degueldre <sad@odoo.com>
When both a specific inheriting view and a non-specific base view are
written simultaneously, the specific inheriting base view must be
updated even though its id will change during the COW of the base view.
This commit sorts the list of written views in order to first handle the
website-specific ones then the base ones which might change some of the
ids of the already updated view.
Steps to reproduce in 14.0+ (no scenario found in 13.0):
- Create a new website.
- Configure the language selector layout to "Inline".
- Configure the language selector layout to "None".
=> Error notification was displayed and change was not applied.
task-2885882
closesodoo/odoo#96248
X-original-commit: 317eea48186c948009399daedf70dd407f6a9ca8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the tours default_shape_gets_palette_colors and
edit_link_popover were not using the tour utils function
registerEditionTour, that starts a tour on the iframe, in edit mode,
with a timeout on the first step.
Because this timeout was not there, loading the iframe and the snippets
menu could take longer than the default timeout and the test would fail
inconsistently.
task-2687506
closesodoo/odoo#96164
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, if installing a new module from the "new content"
modal would fail, the "Building your website" gif was not removed.
This commit removes it when the installation fails.
task-2687506
closesodoo/odoo#95955
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, following those steps:
- Go to /hello.css
- Create the page/file
- View in page manager
- Click on its row
-> You're redirected to the file, with infinite loading
This commit fixes this behaviour by unblocking the iframe:
- on the OdooFrameContentLoaded event for frontend pages
- on the load event for other pages
To do that, the BlockIframe component is changed to handle process ids.
Before this commit, the BlockIframe component would count the calls to
block or unblock the iframe (and store it in an iframeLocks variable),
so that multiple processes can block the iframe independently from each
other.
As an exemple, for two processes A and B, the iframe should remain
blocked during those two processes, and released at the end:
(A) blockIframe => (B) blockIframe => (B) unblockIframe => (A)
unblockIframe.
But that iframeLocks variable was fragile: a process that blocks the
iframe should unblock it once, otherwise it would mess up the locks
count. It was not appropriate for a process that could be ended with two
events, for example loading the iframe. The first of the 'load' or
'OdooFrameContentLoaded' events should unblock it.
To change that, a process can block the iframe with a processId. The
first unblock call with the same processId will unblock the iframe, the
other ones will be ignored.
task-2687506
Part-of: odoo/odoo#95955
Before this commit, clicking on a different variant of a product from
the WebsitePreview client action introduced in [1] would not update the
browser's url.
This commit adds an event listener to update the browser url on hash
changes, as load events are currently handled.
The product variant buttons are directly changing the hash instead of
replacing the state of the history.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#95955
This commit aims at making the website dialog as well as the edit_menus
tour more stable.
Commit [1] introduced a new dialog API for website.
The component WebsiteDialog handles click asynchronously.
Prior to this commit, the tour could sometimes detect and click on modal
triggers before the actions that the previous trigger was triggering
could complete. This could lead to a modal closing too early either
because a click would done on the wrong modal or the input was completed
before the validation method was called (since the click handlers are
asynchronous).
Here are a few examples of possible failure in the tour :
- The tour clicks on "Add Menu Item", which should open a new modal
- The tour then clicks on OK to make sure the modal does not close.
- The click on OK is done before the New Menu Item modal is open and
therefore is triggered on the previous modal
- The modal is closed too early
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field.
- The validation method doesn't block the OK method which results in the
dialog being closed
- The tour expects the dialog to be open and crashes
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field
- The tour clicks on OK again
- 2 entries are created instead of one.
The last one doesn't crash the tour but is still incorrect.
This commit disables the buttons when they're clicked for the first time
until the handler is processed.
This commit also make the triggers in the tour more specific so that the
tour always clicks on the right modals.
[1]: https://github.com/odoo/odoo/commit/28a78fb4e4e4465aa99fb94f7cac3a21b2188502
runbot-4122
closesodoo/odoo#95839
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when Bootstrap 5 was introduced, the position of the
connectors between steps of the "Steps" block is wrongly computed.
The left offset of the connectors between steps is computed as 50% of
the column width + half the size of the content it connects to.
In Bootstrap 4 the columns are positioned as relative.
In Bootstrap 5 the columns are positioned as static.
Because of this "50% of the column width" became "50% of the row width"
in Bootstrap 5.
This commit makes the specific columns of this snippet positioned as
relative so that the offset calculation get back to its former result.
Steps to reproduce:
- Drop a "Steps" block.
=> Connectors are wrongly positioned, even spanning outside the page.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2729177
closesodoo/odoo#96071
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when clicking on a link with the standard header as
anchor (e.g. Enable "scroll to top button" option to the footer in edit
mode). The scroll animation stopped before reaching the top.
This happened because we stop the scroll animation when the scrollTop no
longer changes. This is the case during the standard header transition
animation. It is only at the end of the transition that we can know that
there has been a change of scrollTop. So this commit makes sure to wait
for the end of the transition to check the scrollTop position.
This commit also adds a "z-index" on the footer "scroll-to-top" button
to place it on top of the elements around it. Before that, the entire
button area was not clickable because it was partly covered by the
elements around it.
task-2773973
closesodoo/odoo#96067
X-original-commit: 201298c66d86c27c1ee05489ccf5c70da88b7e14
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since frontend to backend commit [1], links having `enable_editor=1` to
enable edit mode were not working anymore in certain cases.
Case 1 [OK]*:
From frontend, click on `enable_editor=1` link without `/@/` in it.
Case 2 [OK]:
From frontend, click on `enable_editor=1` link with `/@/` in it.
Case 3 [KO]*:
From backend, click on `enable_editor=1` link without `/@/` in it.
Case 4 [KO]:
From backend, click on `enable_editor=1` link with `/@/` in it.
This commit fixes case 4 and adds a test for all cases, while leaving
case 3 commented as it will be fixed later with a larger fix related to
URL change listener.
* Note that we will probably change the behavior for case 1 and 3: if
the version with /@/ + enable_editor=1 enters edit mode properly in
both frontend and backend contexts (case 2 and 4), it's probably not
worth having code to support case 1 and 3.
The issue for case 4 was that it was trying to load the whole Odoo app
inside of website preview iframe instead of making the parent window
load that URL.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#96054
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit makes some adaptation in the scss of the website visitors
kanban view with respect to the introduction of the owl kanban view.
closesodoo/odoo#96003
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since 4f984568e1, the css theme is not
correctly applied to the website theme selector.
The order in which the css rules were applied without the
'.o_legacy_kanban_view' selector removed a margin from the
kanban_record element.
closesodoo/odoo#95936
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Install multiple langages, each time translating the website. In a
private browsing session access /contactus, show the page source, the
multiple alternate URL (`<link rel="alternative">` in the `<head>`) are
all pointing the canonical URL instead of the alternative.
closesodoo/odoo#95683
X-original-commit: 3d4b4d3dcff864613a9e7038137e21674425ed08
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
With this commit, users can no longer have headers that have the sidebar
template and the over the content option at the same time.
Steps to reproduce the problem:
- Edit a website
- Edit the navbar
- Set Header Position to Over the Content
- Change the navbar template to Sidebar
The navbar is not displayed properly and there is a margin on the left
that should not be there.
task-2877421
closesodoo/odoo#95463
X-original-commit: 618fd49642310c7b97ef3b9e6c01f8f691c7b12f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the switchTheme option was redirecting the window to
the theme_install_kanban_action url.
After [1] was merged, the editor is instantiated inside the webclient
and the action can now be opened directly from there, without a reload.
For that, the request_save event data can include an 'action' parameter,
which the WysiwygAdapter will use after leaving debug mode to trigger
the action with the action service.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#81485
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website_modules
This commit restores the display of the website loader (the "Building
your website" GIF) during the installation of a module from the new
content modal, or after completing the configurator flow.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Before this commit, clicking on the edit button of a slide viewed in
fullscreen mode would instantiate the wysiwyg, remove it, exit the
fullscreen mode et re-instantiate the wysiwyg.
To prevent that, the editor component never starts with the wysiwyg
shown by default when mounted. Before that, it checks if it should
redirect somewhere in the publicRootReady method (if not, it shows the
wysiwyg).
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Before this commit, switching languages from the language dropdown while
in edit/translate mode was broken.
Now, the click event on this dropdown is listened alongside links with
external redirection from the WebsitePreview client action, so that the
client action leaves the edit mode while frontend is redirected to the
right language.
For that, a new leaveEditMode method is added to the website service,
which removes the edition classes and unmounts the Editor component.
This will further be reviewed in future commits.
Also, adding a new language from the language switcher dropdown directly
opens the wizard in a dialog on top of the WebsitePreview client action.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
This commit adds the PagePropertiesDialogWrapper and
AceEditorComponentAdapter as children of the client action, instead of
the NavBar. Both of the components are displayed conditionally based on
the websiteContext. It allows us to remove the navbar xml patch.
With the PagePropertiesDialogWrapper rendered only when needed, it can
open directly the appropriate dialog in the onRendered hook, so that we
can avoid passing the widget to the parent that would later open it.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
- new prefix `bs-` for the root CSS variables
As some website snippet relay on these values we need to restore the old
behaviour by setting this prefix to an empty string.
- restore negative margins disabled in BS5 by default
- restore BS4 behaviour for setting element content
Fix some cases when we want to render more than one node on the root
level.
In BS4 the jQuery was using all node but in the jQuery compatibility
layer in BS5 it takes only the first node if the jQuery Element is used
in the function. This hack try to restore the old behaviour wrapping all
element in a DIV element (to be single root node).
PS: this can break some querySelector and some CSS selector if they are
too fragile.
e.g. of element that break before this hack:
Popover content for PaymentPopOver XML in ShowPaymentLineWidget
- restore old value from BS4 and adapt to new value
$table-cell-padding -> $table-cell-padding-x
$table-cell-padding -> $table-cell-padding-y
$table-cell-padding-sm -> $table-cell-padding-x-sm
$table-cell-padding-sm -> $table-cell-padding-y-sm
- restore BS4 smooth-scroll behaviour
- restore `text-X` from BS4 that use text-emphasis-variant
In BS5, to generate the text utilities `test-X` its use BS5 utilities
(See $utilities SCSS variables). To restore the old behaviour we replace
with the custom `text-emphasis-variant` mixin.
See odoo/odoo@e111cfd35e
- restore border and background of table
In `_reboot.scss`, BS5 add `border-style` to all element of a table.
In some case we customize the table with CSS rules (e.g. `listview`),
these rules set a size of border. The mix of all rules made that the
border of the `td` in `tfoot` are visible and make a black line.
- reset block quote Y margin to 0
BS5 add a spacer and we reset that by puttin margin-y 0
- In BS5, border color is linked to the text color in it. We doesn't
want that and we restore the same behavior as un BS4 by putting
border-color in grey.
- restore HR style like in BS4
Since in BS5, the height matter we remove the padding and added into the
margin.
Also, we restore the color of BS4 for the HR tag
> <hr> elements now use height instead of border to better support the
> size attribute. This also enables use of padding utilities to create
> thicker dividers (e.g., <hr class="py-1">).
https://getbootstrap.com/docs/5.1/migration/#content-reboot-etc
- restore old value for grid gutter to avoid calc error
In BS5 `$grid-gutter-width` is set in rem and in BS4 it was in px.
So SCSS compiler generates error when it tries to calc rem and px.
- restore badge, navbar paddings like in BS4
- restore link decoration in frontend (Portal) whiteout website
Task ID: 2766483
Part-of: odoo/odoo#95450
> Data attributes for all JavaScript plugins are now namespaced to help
> distinguish Bootstrap functionality from third parties and your own code.
> For example, we use data-bs-toggle instead of data-toggle.
https://getbootstrap.com/docs/5.1/migration/#javascript
Task ID: 2766483
Part-of: odoo/odoo#95450
Converted for new Javascript of Bootstrap 5.
Note: some parts are removed as not found equivalent function name in
BS5.
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 JS use the `data-bs-toggle="dropdown"` attribute to
automatically enable the BS Component.
But in this case as the `.dropdown-menu` is only rendered when the
`.dropdown-toggle` is clicked we can't initialize the Dropdown at the
first render. So we do it manually.
- change .dropdown-menu by .o-dropdown-menu (owl)
-> to handle keyboard navigation we can't use BS dropdowns
- use currentTarget of event
As the event can bubble we use currentTarget to be sure to be at the
higher level in the DOM.
> All the events for the dropdown are now triggered on the dropdown
> toggle button and then bubbled up to the parent element.
- BS5 don't add .show on parent group anymore
-> dropdown show class not on the same node on BS5
- avoid dropdown warning using margin in CSS
BS5 show a warning if we use margin statically in CSS for a dropdown.
> Popper: CSS "margin" styles cannot be used to apply padding between
> the popper and its reference element or boundary. To replicate margin,
> use the `offset` modifier, as well as the `padding` option in the
> `preventOverflow` and `flip` modifiers.
- adapt the systray activity dropdown for mobile
On desktop positions are now dynamic and on mobile it's static
- In BS5 the CSS `bottom: 100%;` is not more applied to the
`.dropup .dropdown-menu` selector.
- Change right -> end and add data-bs-popper="none" to avoid
Popper interaction
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 uses native inputs instead of pseudo-element for some
input like checkbox, radio, ...
in BS5 input checkbox don't have "virtual visual" checkbox anymore
(::before), so we remove the relative's rules
- removed `.custom-control` class
- `form-switch` use a new layout system in BS5 we adapt the code to
match the Bootstrap approach (inline SVG).
- In tests, we don't check the exact value of the background as it
change in community/enterprise, and it's difficult to check the value
of an SVG.
- Overflow in progressbar is now hidden.
-> we had to restore it.
- In BS5 margins in forms/inputs has been changed
-> we had to restore it (e.g. 'mb-3')
- .form-group, .form-row, .form-inline
> Dropped form-specific layout classes for our grid system.
> Use our grid and utilities instead of .form-group, .form-row,
> or .form-inline.
- .input-group-append and .input-group-prepend
> Dropped .input-group-append and .input-group-prepend.
> You can now just add buttons and .input-group-text as direct
> children of the input groups.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#forms
Task ID: 2766483
Part-of: odoo/odoo#95450
From [1]:
> Dropped all .badge-* color classes for background utilities
> (e.g., use .bg-primary instead of .badge-primary).
We now have to manage constrast for some badge. It's why we
add 'text-dark' at some point.
Note:
Due to the backport of 'text-bg-#{theme}', we can use this to
avoid to use 'text-dark'.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#badges
Task ID: 2766483
Part-of: odoo/odoo#95450
* restore position relative:
> Columns no longer have position: relative applied, so you may have to
> add .position-relative to some elements to restore that behavior.
https://getbootstrap.com/docs/5.1/migration/#grid-updates
Example:
Favorite widget isn't shown on the right location due to change
in Boostrap 5, so we restore the old positioning of the `.col`
PS: another fix is to simply remove the position absolute of
`.o_favorite` but its break the favorite in kanban project.
* remove usage of `width` in kanban image when `col` is also used:
The class `o_kanban_image` is
```css
.o_kanban_image {
width: 64px;
}
```
In BS4 the col rules are:
```css
.col-4 {
flex: 0 0 33.33333333%;
max-width: 33.33333333%;
}
```
and in BS5:
```css
.col-4 {
-webkit-box-flex: 0;
-webkit-flex: 0 0 auto;
flex: 0 0 auto;
width: 33.33333333%;
}
```
So `width` overrides the `col` rules.
To summarize:
In BS4
```css
{
max-width: 33.33333333%;
width: 64px;
}
```
In BS5
```css
{
width: 33.33333333%;
width: 64px;
}
```
e.g. where there is the case:
Helpdesk > Reporting > Customer Ratings (Kanban card)
Task ID: 2766483
Part-of: odoo/odoo#95450
The logic not identical in BS4 -> BS5
The color contrast system in BS5 relies on WCAG 2.0 contrast algo.
So color-yiq is converted to color-contrast.
Note that there are some "texts/buttons/other visuals" elements
which will not have the same contrast as before.
$yiq-text-dark and $yiq-text-light are respectively replaced with
$color-contrast-dark and $color-contrast-light.
Note that we had to use '$min-contrast-ratio: 2.2' for .o_tag_color_X badge.
Task ID: 2766483
Part-of: odoo/odoo#95450
Co-authored-by: Stefano Rigano <sri@odoo.com>
This commit is a hack for Bootstrap 5
In Bootstrap 4 these variables was used with map-merge()
In Bootstrap 5 these variables has set only if they don't exist before
PS: Another fix will be to reorder all bundle to follow Bootstrap
documentation and do another logic that wasn't use before.
Ref:
https://getbootstrap.com/docs/5.1/customize/sass/#colors
Task ID: 2766483
Part-of: odoo/odoo#95450
* = base,http_routing,hw_drivers
- Update Bootstrap from 4.3.1 to 5.1.3
- Update PopperJS to version 2 for Bootstrap 5 (JS part)
Some code was for PopperJS V1, but it's not compatible anymore.
- Remove some BS5 classes utilities backport
- Fix path for BS5
Task ID: 2766483
Part-of: odoo/odoo#95450
*: test_website
Issue: The url is cached and no longer depends on the url. This part
should not be cached.
closesodoo/odoo#95222
X-original-commit: 4b255ed129b0e458d3cf7f432d076913b14d5450
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue introduced by commit b0a2a41
The template's "flags" value was not in the t-nocache values to use when
rendering languages.
X-original-commit: 7827d2dbc1fbef3cc0dc898baa0af30ed1f23fca
Part-of: odoo/odoo#95222
Benoit Socias