Instead of having a dedicated module for all-things dark mode related,
this commit moves the (S)CSS files into their respecting modules and
uses `web` and `web_enterprise` to provide the base infrastructure for
the dark mode (cf. dedicated assets bundle).
Note:
Don't forget that you have to handle 2 cases:
1: SCSS variables must be placed BEFORE bright ones
2: CSS variables must be placed AFTER
task-2710677
Part-of: odoo/odoo#102868
Move the file in a more convenient place to be shared and customized to
match different color schemes.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Before this commit, some functions overrode the save function of the
form controller. The issue is that this function is only called when the
button save is clicked, and not when we save differently (for example,
when clicking on the breadcrumb).
To avoid this mistake the save function on the form controller was
renamed to: `saveButtonClicked`, and the code that overrode the function
now override the save function of the Record, that it's called at each
time a save is perform.
X-original-commit: b6e3d833e6131562084eb13b2955c22f50ad1e79
Part-of: odoo/odoo#102992
*: website_forum, website_hr_recruitment, website_sale
Before this commit, most of the backend redirections to the
WebsitePreview, introduced in [1], were using ir.actions.url with the
get_client_action_url util, which was not optimal.
This commit changes that to use a new get_client_action method, which
returns the ir.actions.client record. It will execute the action
directly, avoid to redirect the router before, and improve performances.
Also, it allows to solve bugs, as:
- The back navigation from the WebsitePreview to the ListViews.
Going through the /web controller would add an entry in the history, and
going back on it would reload the client action.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102991
X-original-commit: 30fb11e479fb7b3db3649e55fcbdb06bfcdb398c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit at [1] factorized some code and in the process used a service
that was not declared. This prevented to use the "add page" dialog
(which allows to create pages via the "+ New" button) to create special
pages ".js", ".css". That feature will likely be removed or reworked
in a future update though.
[1]: https://github.com/odoo/odoo/commit/58698f848703395ff680bc7586ecc8eec4fb61ae
X-original-commit: 21b90ff8bdad22b6beea1b6b5a6d70276817c00e
Part-of: odoo/odoo#102991
This commit fixes the behavior of the website app when creating content.
Since commit (1), once a new record was created, it was no longer
redirected to the correct page. Now, this behavior is reintroduced and
works as expected.
(1): https://github.com/odoo/odoo/commit/916a5bebb3e74047a66503ddc59299540c252831closesodoo/odoo#102959
X-original-commit: 7cfe4523d18989b0273a026000109617bbfb2d13
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In PR https://github.com/odoo/odoo/pull/101763 the page_kanban template
in website has been changed because it was thought that the xpath was
meant to be inserted in the default slot.
However this wasn't the case (we want it applied to the Layout) so it
crashed the view.
This commit restores the proper xpath.
closesodoo/odoo#102942
X-original-commit: 631d552fc6d6279fd2564fffeb30d099abd767c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The goal of this commit is to add some fixes on page properties dialog
after the Owl REF [1].
- XML: use default form view style (remove </group>).
- Move the '/' back into the non editable part of the URL.
- Prevent python code from creating a different URL (and optionally
setting "website.rewrite" record for it) when the new URL is the same
as the initial one after slugify.
- 'useAutofocus()' on the first page properties field.
[1]: https://github.com/odoo/odoo/commit/61a9d7bd2abc6081b321a51d329f9e85209215e5
task-2687506
closesodoo/odoo#102869
X-original-commit: 1165dfcd4fd5677d14f3d3329ad7c62be847b31a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the Plausible dashboard height was hard-coded to avoid the
display of a scrollbar on the iframe.
In case the Plausible dashboard height grows in the future, it will not
be possible to scroll to the bottom elements.
This commit virtually restores the scrollbar, so that in case the
Plausible dashboard grows in the future, the scrollbar will appear and
still give access to the whole dashboard.
[1]: https://github.com/odoo/odoo/commit/b8c1976e933628182496929d348dda11b5051a0c
task-2993773
closesodoo/odoo#102852
X-original-commit: 616eb5384df085fdc94cb18ab8e14336f9b68702
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The website edition system is based on a main mutex to guarantee the
order of user manipulations. Meaning that if an user follows any flow
really quickly, each part of the flow should be guaranteed to be done
in the order the user asked for, independently from the duration of each
part. The mutex system to ensure that is not robust yet though, or at
least it is not easy to use and should probably be replaced by something
more easier to use in the future. Indeed, some operations are badly
implemented around this mutex.
This is the case of the drag and drop of a snippet into the page. Drag
and dropping a snippet is a long series of operations, to name a few:
1. The user mousedown on a snippet thumbnail
2. The user drags the snippet around
3. The user drops the snippet in a dropzone
4. We scroll the page to the position of the snippet
5. The snippet is built (options' `onBuilt` methods)
6. The snippet public widgets are started
That whole series of operation has to be reduced to an atomic work to
be added to the mutex queue. Meaning that for example, if the user
manages to click on the save button while he is dragging a snippet
around... the editor should only save the page after the whole series
of operations of the drag and drop has completed. This is not the case
right now: the mutex lock is released between (4) and (5) because we
have too: (5) and (6) use the mutex themselves and would thus induce
a deadlock if we only release the mutex after (6) as it should be. This
means that during the scroll to the snippet (4), if the user manages to
click on the save button, the save operation will be scheduled to be
done before (5) and (6). It is thus technically possible to save a
snippet which is not built** (even if it would not be critical most of
the time). Worse, before building a snippet, its options have to be
instantiated... and that operation is not mutex protected so this is
probably (not 100% sure) possible that this happens:
a. Drag and drop a snippet. During the scrolling, click on save.
b. End of scrolling, the mutex lock is released, we create the first
option and its widgets as part of the onBuilt process. Creating each
widget is async, once the first one is created, the saving process
starts as it was scheduled in (a).
c. Saving the content, destroying all snippet options and their widgets.
d. Continuing building snippet options widgets started at (b)... but
previously-made ones were destroyed at (c)... possible crashes***.
Fixing all of this probably requires a change in the system, maybe the
use of multiple mutexes, maybe the saving operation can always be
delayed at the end of the queue somehow, ... but this requires some more
thinking and probably not possible in stable. In stable, it could be
enough to disable the saving entirely during drag and drop (like drag
and drop of another snippet is currently disabled during another drag
and drop). This will be done in another commit if this is decided.
Meanwhile, this commit just changes the behavior in tours for now:
waiting for drag&drop to fully complete before clicking on save, like
an human would.
** It is possible to reproduce by using the ALT + S shortcut: start
dragging a snippet which has a onBuilt method in its options, hover
the dropzone where you will drop, ALT + S to save (the editor waits
you drop your snippet), drop your snippet -> the snippet is saved and
the edit mode is left... but the onBuilt was not executed.
*** a crash was indeed found during a specific theme tour (out of ~30
Odoo themes because of this after the other commit of this current
PR). After those other commits especially, it is also possible to
reproduce with the ALT + S trick, although not consistently. It may
be linked to the specific last snippet added by that theme tour
instantiating specific options. But as explained saving just after
drop is an issue independently from this potential crash problem
(snippet not built, etc).
X-original-commit: e96167ae20d2a143d7def4347166b37e158003b0
Part-of: odoo/odoo#102800
Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] keeps the snippet cache alive through different
instance of the website snippet menu.
This allows for the user to switch pages, even apps, while
keeping the snippets in cache, decreasing the startup time of the
snippet menu.
However, the cache is not invalidated when switching website or
installing a new theme.
This commit adds a `invalidateSnippetCache` property to the
websiteService. If this property is set to `true`, the cache will be
invalidated next time the menus loads its snippet.
This property is currently set to `true` when changing website and
switching theme.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2687506
X-original-commit: bb503962a36f3798c50049f2844e7b288b632955
Part-of: odoo/odoo#102799
This commit allows to regenerate the connectors of the step block when
one of the columns of the block is duplicated or deleted.
Steps to reproduce the fixed bug:
- Drop a steps block
- Duplicate one of the columns
=> The last column of the first row has a connector to the right of the
page.
closesodoo/odoo#102797
X-original-commit: 56522f4a26c95878bb726f54eb02c8c948576875
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
For the "+New" button, a `get_modules_info` route was added because the
information cannot be built-in the page by a server-side QWeb template
anymore.
This commit removes this route and replaces it by a call to the default
`search_read`.
task-2687506
closesodoo/odoo#102791
X-original-commit: 7f83e398b68d7c7544753e2b8bb1b334fb5f7036
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit includes several changes in the Plausible dashboard:
- Remove the "Analytics" title.
- Add margins (container-fluid => container).
This also fixes the country map overflow and the flickering.
- Remove the duplicated scrollbars.
- Use the background colors from within the iframe.
- Hide the date range buttons by default, but show them if website_sale
is installed.
It also reorders the Reporting menu as follows:
- Analytics
- eCommerce
- Online Sales
- Visitors
- Page Views
task-2993773
X-original-commit: b8c1976e933628182496929d348dda11b5051a0c
Part-of: odoo/odoo#102782
While working in the current state of the website configuration, the
overlay computation was not working anymore in case the scrollbar is
moved out of the wrapwrap. Indeed, in that case, the position was wrong
by the amount of the page scrolling.
While we could include that scrolling value in the equation, this commit
chooses to restore the way it worked before the "website-in-backend"
merge at [1]: making the overlay be naturally positioned according to
the page scrolling wherever the scrollbar is. To do that, the overlay
had to be moved inside the content (the website iframe) which has the
disadvantage of risking the overlay design being broken by a theme. This
solution was chosen as it simplifies the code, and potentially allows
for performance improvements in the future: not forcing a position
recompute after each scroll (the animation should already be smoother /
more performant this way). This will actually be needed for another fix
/ improvement: the background image overlay has to be in the iframe too.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102785
X-original-commit: 872bb20b3ac08cf82613e15e6634a2e7593ccf7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
An option to edit tables via a specialized overlay was made with [1] for
the backend edition of HTML fields. It was indirectly added for the
website builder where an UI to do that already exists (in the editor
panel). It is actually a problem because of the way it was implemented:
- Rely on the fact this is not the `<html>` which scrolls (which cannot
be considered necessarily true and won't be true by default in a
future update).
- Use 'visibility' property instead of 'display' to hide the UI making
the UI participate in the rendering of the page at all times (and when
the `<html>` scrolls actually shows a white bar at the bottom of the
website page).
It was decided we do not want this UI on the website side. This commit
takes the easy road: just force the fact it is hidden. Indeed, not
instantiating it comes with a bunch of problems as the related code is
spread throughout the editor code. A better implementation will follow.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/7a64a04421171469c58bb94bbe8c55b1e2fdf3f2
X-original-commit: 8c1a719674315eadb6d8f6c925cc4303227fad67
Part-of: odoo/odoo#102785
Reproduce:
Go on a kanban view, with enough columns so it goes off the screens.
Scroll on the right, try to drag anything beyond the original (before
scrolling) limit of the screen. The cards are stuck floating at that
limit. Note it didn't prevent the drop to work properly where the mouse
was.
Issue:
The useSortable hook gets an owl ref, which is used as a limit to where
things can be dragged and dropped. Originaly and logically, it was the
current component ref, the renderer. But for some unknown reason, this
space was not getting wider than the initial screen size. It may be a
problem with the flexbox layout.
Tried solutions:
- A first solution was to add the overflow-x-scroll css property to the
renderer. It works, but now the horizontal scroll bar is no longer
always visible. You have to scroll all the way down to see it. UX wise
this is not acceptable.
- We could remove the clamp mecanism inside useSortable to let the drag
and drop motion go anywhere. This works, but decrease the quality of the
interaction. It looks cheap and not polished.
Final Solution
Finally, we decided to pass a ref to the o_content div from the layout
component down to the kanban renderer. If the useSortable is given this
ref, it works as intended. While it may seem too much, it is not
unreasonable to propose a reference to the most parent element of the
view contents to the renderer.
X-original-commit: a569305acaa1c812ede739c267e2e9530945f65f
Part-of: odoo/odoo#102756
Before this commit, the autocomplete dropdown no longer had a maximum
height, which meant that when it contained a lot of elements, it hid the
entire editor panel.
Indeed, since the CSS of the menu snippet is no longer that of the
"frontend", the 'max-height' CSS rule defined for the autocomplete
dropdown in the frontend (introduced by this commit: [1]) was no longer
applied on the autocomplete dropdown of the backend.
In this commit, we therefore moved this css code of the
'ui-autocomplete' defined for the frontend into the common css file
(backend + frontend) in order to return to a situation where this code
was applied to all autocomplete dropdowns in Website. And thanks to
that, we were able to remove the css file "edit_menu.scss" which
copied/pasted the frontend 'ui-autocomplete' code for only one of the
backend 'ui-autocomplete'.
[1]: https://github.com/odoo/odoo/commit/032dd007157de00b683a9d753aa929741c107c01
task-2900529
closesodoo/odoo#102719
X-original-commit: cce26d7697c73326e0a6f2ec81e01b56b4156ad4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The tour contains this part:
1. Change the font-size
2. Click on save
3. Check that edit mode was left
4. Check the font-size is ok
The problem is that step 1 induces a series of RPC and processing
(rebuilding assets, reloading them in the client, etc) but those are
not awaited before going into step 2 which also induces a RPC (the save)
which is only done once the other RPC are finished.
While we will try to optimize the duration of those RPC in the future.
Meanwhile we could simply increase to the timeout of step 3 but it seems
better to change the tour to divide the multiple things to await:
1. Change the font-size
2. Check the font-size is ok
3. Click on save
4. Check that edit mode was left
5. Check the font-size is still ok
runbot-4706
closesodoo/odoo#102609
X-original-commit: c2bc6c2f8446e98c8a4089daf048e67457be277f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When the footer has the "Slide Hover" and the "Shadow" scroll effects,
and if it is in grid mode, the grid dropzone flickers a lot when we
drag a column over it. This happens because the scrolls caused by the
dragging, the growth of the grid and the scroll effect all happens at
the same time.
This commit removes temporarily the scroll effect of the footer during
the drag and drop to avoid this situation. It also has the advantage of
displaying the footer entirely, making it easier to see where we are
placing the elements.
task-2973198
X-original-commit: bbde919634aeaffcf421283445e25181a522f287
Part-of: odoo/odoo#102525
This commit modifies the Masonry snippet, along with all its templates,
in order to always be in grid mode.
A change worth noting is that the images are now real images and not a
background and text can be added over them with the "Add Elements"
option. This change happened mainly for the look of the mobile view but
also because it is more logical since the snippet is supposed to
contain "images" and "text".
The themes extending Masonry have also been adapted in [1].
[1]: https://github.com/odoo/design-themes/pull/592
task-2973198
X-original-commit: 85b352af319edec84407f2046cf795b4e5503460
Part-of: odoo/odoo#102525
Currently, the toggle to grid mode is not the same process for all
snippets: some have both the option 'Layout Grid/Cols' and the ability
to toggle on drag but other don't have the option, making it
complicated/impossible to leave the grid mode. Also, the snippets for
which the grid mode has been blocked don't have their move handle
anymore, which prevents them to use the normal drag and drop (it was
hidden because dragging them would toggle the grid mode).
This commit uniformizes the grid mode for all snippets and adds the
move handle back to the ones that cannot use this mode. It also
improves the grid mode of the 'Items' and 'Carousel' snippets.
More precisely:
- All the snippets that are allowed to have the grid mode now have both
the option "Layout Grid/Cols" and the ability to toggle on drag.
- The snippets who cannot toggle the grid mode have the move handle
back but it doesn't toggle on drag and they don't have the option. They
use the "normal" drag and drop.
- The drag and drop has been improved to allow normal columns to go
inside the grids. Indeed, since the drag was previously blocked, this
case could not occur but now that it is possible, it had to be taken
into account.
- The grid mode of the Items snippet has been improved by removing the
"hardcoded" height that was breaking the grid.
- The vertical dropzones of Carousel appearing when dragging inner
content have been removed because they appeared in grid mode and were
breaking it. It is also more logical because now that this snippet has
a column option, vertical dropzones should only appear when dragging a
column.
task-2973198
X-original-commit: 84d684d8bdf43d3db11defd8174dee44775085c2
Part-of: odoo/odoo#102525
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_slides
This commit adapts the code of website, and modules depending on it, which
overrided the save method of the FormView controller to execute a doAction.
It was no longer possible to wait for the default save action to proceed,
because the default behavior is now to close the dialog, and here we need
to pass another parameter allowing to redirect the website to a newly
created record.
Now, a method is available directly from the NewContentModal, which reduces
the need for the service in form views. The save call pass the right method
to compute the path needed for the redirection once the record has been
created.
closesodoo/odoo#102522
X-original-commit: 916a5bebb3e74047a66503ddc59299540c252831
Related: odoo/enterprise#32448
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In [1] the padding of the discrete cookies bar template was moved from
the column to the row.
This prevents editing the padding per column using the website editor.
This commit moves this padding back onto the columns and wraps the text
inside a paragraph so that it does not get closer to the bottom border
of the screen.
[1]: https://github.com/odoo/odoo/commit/2ca91a90d0aa61405547349d5cd366179bc3f419
task-2800976
X-original-commit: c50e2adf592a336d1f991e9a461eeeb21a2a64f0
Part-of: odoo/odoo#102380
When [1] introduced the website edition using an iframe, it did not
correctly adapt url attachments redirections.
Following this flow, in the Website Builder:
- From the Media Dialog, click on the "add document" top right button,
- Paste a google doc url and save,
- Click on the inserted document icon,
=> The google doc is opened inside the iframe (it leads to tracebacks).
This commit fixes the way these documents are opened from the
Website Preview iframe: '/web/content/...' links are always opened in
the top window, as they can be external redirections.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2172311
closesodoo/odoo#102318
X-original-commit: c05f7de22600b5719117a188ab105e4140b6a3de
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
Before this commit the Device visibility option was on its own row
inside the options panel.
This commit moves the buttons of the Device visibility option before
the dropdown inside the main row of the Visibility option.
task-2900730
closesodoo/odoo#102154
X-original-commit: 82000acfb6f8c7884994135413dcddac5441f8b4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, in edit mode, it was not possible to close an open
dropdown in the header anymore.
This was due to BS5 (merged at [1]). Before, the 'show' class was added
to the dropdown menu element (the element with the 'dropdown' class).
But that changed: the 'show' class is now added on the button (the
element with the 'dropdown-toggle' class). And as in edit mode the
openings/closing of the dropdowns are handled manually in the header, it
no longer worked correctly.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-3001198
closesodoo/odoo#102145
X-original-commit: f3e1dc52356164453f72827e3dc87ad903df3d0e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the dynamic snippet would only start sliding after
the first interaction.
This commit makes it slide right away.
task-2677203
closesodoo/odoo#80128
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the Dynamic Snippet options would modify the DOM
at places were it is not supposed to.
PR [1] aimed at making it more stable, but the changes required to make
the option conform to the framework cannot be done in stable as some
methods' signatures needed to be changed (Changing a sync function to
async).
This commit aims at making the option follow the flow of an option:
- Modify the target's DOM either on build or on a change of option
- Modify the UI either during willStart or updateUI
To do so, the methods that fetch the template data needed to be split
from the methods that creates the buttons.
The benefits of this commit are that the option is less likely to cause
race condition and errors while performing its tasks.
[1]: https://github.com/odoo/odoo/pull/82222
task-2677203
Part-of: odoo/odoo#80128
This commit improves the design of dynamic products templates.
It introduces templates using multiples rows and fine tunes the
design of the other ones.
To make thumbnails work in the template selector, an extra
data-attribute can now be processed by the snippet option.
- data-thumb: it references the location of the thumbnail for a
template. If present the option will show the svg / img.
If not it will display the name of the template.
task-2677203
Part-of: odoo/odoo#80128
Co-authored-by: Arthur Detroux <ard@odoo.com>
*: website_sale
Previously, on the debug dynamic snippet, you could choose a product
filter and a template that had an add2cart button but that button
would not work.
This commit fixes that by creating a widget per card and moving the
card specific code to this widget.
task-2677203
Part-of: odoo/odoo#80128
*: website_blog, website_event
Commit [1] introduced new templates. This commit's goal is to build on
that template system to provide more flexibility for designers.
It adds new data-attributes to set on the first node of a template.
- data-row-per-slide: Allows for the template to tell a dynamic snippet
carousel how many rows of cards it should display.
- data-arrow-position: Allows for the template to tell a dynamic snippet
carousel where the arrows should be positioned.
(for now just bottom, or side)
- data-extra-classes: give the template the possibility to add extra
classes to the dynamic snippet instead of just the card.
This commit also removes options to select the amount of elements
displayed on each row. This is now only changeable through templates, or
by directly editing the snippet's DOM through debug tools. This was done
to reduce the amount of options visible, so that the user just chooses
a template and it is ready to go.
[1]: https://github.com/odoo/odoo/commit/49bd79b0bdca76415780bdfa199195371c2692e5
task-2677203
Part-of: odoo/odoo#80128
In some place the search params are mandatory in the route.
We now add the search and hash params to the editedObjectPath to
avoid having an error when trying to go back.
task-2993826
closesodoo/odoo#101996
X-original-commit: 2bed20392084bcbec2683939e5659b03e3ea7acf
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_hr_recruitment
After [1], the multi-edit was added on the pages list views not using it
except 'hr.job' records since editing the 'Department' field leads to a
traceback.
The goal of this commit is to fix this issue by setting an invisible
'company_id' (to be available in domains since necessary to change
'Department') and add multi-edit on the view.
The 'home' icon for 'home page' records on list view should be hidden
after this commit (on multi edit mode) to edit the fields correctly.
[1]: https://github.com/odoo/odoo/commit/be58687284884550cc4e6c2ac7255abee4eb1125
Related to task-2889981
X-original-commit: d101be46a2a9c392e2d63f491fcc5ccec2d65c78
Part-of: odoo/odoo#101814
Before this commit, the WebsitePreview document title was not completely
replaced with the iframe's one: it was still prefixed by 'Odoo - ' by
the title service.
Now, the WebsitePreview, introduced in [1], is adapted to remove the
'zopenerp' part when replacing the title (and adding it again when
unmounted). While doing this, the backend's favicon is also changed with
the frontend's one, to be consistent with displaying the frontend
document title only.
This commit also adds an effect on the Optimize SEO dialog, so that the
document title matches the user's input.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#101972
X-original-commit: 52ec7d1279144b9cd38f8444648b8246df694b9c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
Before this commit, for the following flow:
- Add arabic language (or any other rtl language),
- On one of the websites, set it as the only website's language,
- Reload and go to the client action,
=> The frontend is correctly displayed in rtl,
- Click on edit,
=> The frontend, in the iframe, is reverted to ltr,
The WysiwygAdapter, introduced in [1], was not passing the correct
direction option to the OdooEditor, which would revert the editable to
the default 'ltr' direction.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
X-original-commit: 2f463ca65b149122c85a04b20b4f82e0be479fc8
Part-of: odoo/odoo#101972
Before this commit, the Editor Menu was confusing when opened for a
translatable website: it would list the menus in the user's language,
not in the displayed website's language.
First, this commit shows that menu only for websites in their default
language, as the user should edit his website structure in the default
language.
Secondly, the 'get_tree' and 'save' requests on the website menus are
done with the website's language, not the user's language.
This commit also fixes a bug introduced with [1]: the website override
of the start method of the SnippetsMenu was incorrectly done.
In translate mode, it should not activate snippets on clicks, otherwise,
the LinkPopover was instantiated when clicking on navbar menus, allowing
to edit the menus from the translate mode, and breaking it.
[1]: https://github.com/odoo/odoo/commit/df1869153a90898bad3e0b61e5fc43a9ed3d59c9
task-2687506
X-original-commit: 4266966a9b0fa452b5991d9bea0fe914aca85f4d
Part-of: odoo/odoo#101972
This commit fixes 2 issues with the position of the dropdown with the
suggested links in the url picker input of the snippet options. (e.g.
redirect url input of the countdown snippet) and the one for the input
of the link editor.
1- Before this commit the dropdown went over the input while editing the
url.
2- Before this commit the position of the dropdown (when above the
input) was a little too low if there were images in the dropdown. It was
because the images are loaded after the positioning of the dropdown and
no height was defined for these images.
task-2900529
closesodoo/odoo#101815
X-original-commit: 774a42ff18651a20b09a5e34222665216b19c8ec
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The cookies bar default templates are designed in order to guide the
user towards selecting the option that will provide the best user
experience.
This raises security concerns (see discussion in PR for details).
This commit adapts the buttons of the default cookies bar templates so
that both options are shown with the same style, forcing the user to
take a decision.
task-2800976
closesodoo/odoo#101845
X-original-commit: 32d88f47a67679b7e90fa58e25089846484b48ca
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: im_livechat, survey, utm, website_crm_iap_reveal, website_forum,
website_livechat, website_sale, website_sale_comparison
Before this commit all cookies were considered essential.
This commit makes some of them optional. It also makes it possible for
the website visitor to only accept the essential cookies.
task-2800976
X-original-commit: 9a8a9463289a7446e9be0ef62ff895feb37a4de4
Part-of: odoo/odoo#101845
Co-authored-by: Benoit Socias <bso@odoo.com>
Before this commit, the only possibility when adding a google font was
to use google servers to serve the font.
This was not ideal as some people really want to serve it themselves
without the need of their visitors to reach google servers.
That's especially true since recently where it seems like German clients
are receiving letters about that to tell them it's illegal and this
should be changed, as it wouldn't respect the GDPR.
Somehow, it seems related to the fact that google knows you visited a
website by just downloading the font, because they very well know with
just your IP who you are exactly.
It's yet unsure if that issue is well-founded or not, but since German
courts seem to be sanctioning people about this, there is no reason to
not at least provide a workaround.
What is sure is that it makes a lot of noise and more and more people
seem to be impacted by this as many opw are getting opened, as well as
github messages.
Whether it is well-founded or not is thus not really our problem
anymore, we should just provide a way for our users to protect
themselves against this "German law problem" (or at least think they are
protecting, if Odoo thinks that's a non issue or the German court is
wrong or ambiguous).
Note that a cookies banner to inform users would not be enough for that
"problem", as the user would already have accessed your website and thus
the related problematic fonts.
Another solution which is not something we want (at all) would be to
serve local system fonts while the user did not consent about google
fonts, or having a blocking screen page telling people visiting the
website will fetch google fonts. Obviously those 2 possibilities are a
no go as it leads to terrible UX.
Finally, note that:
- in Odoo 16, the default fonts will be the system fonts, meaning there
won't be any call to google by default, regardless of this pr
- there is a work in progress to improve the current cookies bar to
differentiate essential and non essential cookies and to allow user
to accept only one or both (task-2800976).
Useful links:
- https://github.com/odoo/odoo/issues/83638#issuecomment-1054470699
ODO detailed point of view about this
- https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
The German law about this
Closes#83638
task-2756486
opw-2970167
opw-2960466
opw-2960555
opw-2952427
opw-2800976
opw-2748647
(possibly many more)
Courtesy of @bso-odoo for the regex part which was inspired by another
of his google font fix attempt
closesodoo/odoo#101826
X-original-commit: b06ce21eba6388ce34bbffffadcb489f0e8557dd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, the WysiwygAdapter would crash with a TB if an
event reached the wysiwyg_adapter when the websiteRootInstance was no
longer accessible (in case of a PageReload while an event in the mutex
is still trying to fire events).
Note that normally, events should not be sent when the
websiteRootInstance is gone as the editor should be destroyed. But
since "widgets_start_request" triggers also implement a "onFailure", it
seems right to use that in such case.
closesodoo/odoo#101687
X-original-commit: 0cc206f94151e2da646064e265e14a341daff58a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Use system fonts for backend and web-editor's UI.
This commit removes references to proprietary fonts and allows the OS
to use the system ones. The aim is to reduce http request and the
general footprint (see enterprise counter-part).
The new font-stack:
- apple-system (San Francisco): iOS Safari, macOS Safari, macOS Firefox
- BlinkMacSystemFont (San Francisco): macOS Chrome
- Segoe UI: Windows
- Roboto: Android, Chrome OS
- Helvetica Neue: old OSX versions
- Ubuntu: Ubuntu
- Liberation Sans: Linux (others)
- Arial: Any
- sans-serif: General fallback
This was actually already introduced for the website default theme and
as a general option with [1] but it was not complete: if reaching the
need to use Roboto of the font stack, the repo Roboto was used instead
of the potential system one. It was not shown during testing with the
previous font stack. With the new one, on Ubuntu, it was revealed as
the Ubuntu font comes after Roboto.
[1]: https://github.com/odoo/odoo/commit/c0f2f670eb087991cc9a6a67f4beea5f12bd15f2
task-2995248
closesodoo/odoo#101533
X-original-commit: 9f8f8f2ef88aee746819469c918b2d31ec29d031
Related: odoo/enterprise#31985
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Since [1] it is possible to request that some blocks are not displayed
on mobile devices.
This commit adds a similar option to prevent blocks from being displayed
on desktops (i.e. on non-mobile devices).
[1]: https://github.com/odoo/odoo/commit/9463f0f889f9dd8da6077895c125da4998a933c0
task-2900730
closesodoo/odoo#101483
X-original-commit: 3103e0553011b5c1f4078972d7a88fa3fd4068b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Antoine (anso) <anso@odoo.com>
The goal of this commit is to add a 'Publish' / 'Unpublish' button to
the additional actions of the 'website content' list views.
'Archive' / 'Unarchive' options are also removed for the 'website.page'
records.
task-2889981
X-original-commit: de02335b8db1396a24e10b78f8f78ed79fded421
Part-of: odoo/odoo#101215
*: website_blog
The goal of this commit is to update JS code to have the same behaviour
from the 'website content' list view (trigger the 'new content' dialogs
on "CREATE", add a website selector to filter content) on kanban views
too.
The blog post kanban view has been adapted to use this. Other "website
content" related records will receive a kanban view in a further update.
This is is also important so that the mobile UX is nicer.
task-2889981
X-original-commit: ed09db19c372da8d8be541f365117d1ce8e965ba
Part-of: odoo/odoo#101215
Pierre Paridans