*: website_blog, website_crm_partner_assign, website_customer,
website_event, website_event_exhibitor, website_event_meet,
website_event_track, website_forum, website_hr_recruitment,
website_membership, website_sale, website_sale_loyalty,
website_sale_slides, website_slides, website_slides_forum
With commit [1], the "customize_show" options were moved in edit mode.
They were wrongly displayed for non-designer users. Trying to use those
would throw a warning at the user.
[1]: https://github.com/odoo/odoo/commit/17a8a37e9bfc5b787d9666597d43e63f0064919fclosesodoo/odoo#103142
X-original-commit: f2ca62a4a9ccb6713a39c100fc87c112619eac41
Related: odoo/enterprise#32768
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
`is_view_active` relies on the `website` specified in the context.
This commit turns `is_view_active` to a model method, to avoid that its
callers think the `website` on which it is called is the one used.
closesodoo/odoo#103126
X-original-commit: 52d436706bf650bb14f2bc2a398d107ff99f81ea
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Previous commit adapted the URL dependencies screen following the
website frontend > backend merge done at [1] and [2].
It allowed to pass other records than website.page and also added the
multi record capability.
This commit is going a step further, by searching for the URL in all
HTML fields and not only views + pages + menu + blog.
It also let the XML take care of the wording instead of the python.
closesodoo/odoo#103136
X-original-commit: 6ac17b93437868cbefbe13448a6fcbb29953f221
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This is following the website frontend > backend merge done at [1] and
[2].
Before that improvement, the old page manager had a button to delete a
page which was behaving as the one in the page properties dialog: it was
showing the list of (possible) dependencies as a confirm step.
But since [2], that delete button was removed as the action menu of the
list view already has a delete button, which is better as:
- It is hidden and take no space, deleting a page is rare
- It is known by odoo users as all list views have that button
- It handles multi delete
So this commit basically just restore that delete warning step for that
list view delete button, and also make it possible to use that
dependencies warning dialog for multiple pages, not only one.
It also now handles records in a generic way, not only website pages.
It's needed because now, all the main Odoo frontend records are sharing
a list view mixin (see `js_class="PageListController"`).
It also fixes the fact that the text of the collapse were inside a font
awesome class, basically using a weird font.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
X-original-commit: 11db2f6ed81419ac724ff27ac95a4438d670cbd5
Part-of: odoo/odoo#103136
This is basically reverting commit [1] which was done a few years ago
as improvement to [2], but it was a bit overkill IMHO.
Indeed, there is a sort of hack when creating a page with special
extension like "my-page.js" that will actually create a special page
with special arch. The goal is for such pages to be `t-call`ed later.
That's commit [2].
On top of that, when deleting such a special page, we introduced a
mechanism to show the views and pages that would possibly `t-call` the
that page which is requested to be deleted.
That's commit [1].
It basically is mimicking what was already done when you change the URL
of a normal page, we tell the user where that url is actually possibly
used.
But since the recent improvement in Odoo 16 done at [3], the page
manager is now a backend list view. It means that multi delete is now a
thing.
Thus, the page dependencies behaviors (key and url) need to be
refactored to handle multiple given URL/Key and not just one.
We choose to remove the key dependencies part (only used for those
special pages) instead of adapting it:
- That 'hack' is probably almost never used
- It's some code to maintain, eg now we need to refactor it
- We would need some extra code to make it only triggered for website
pages and not all records, unlike the url dependencies screen which
concerns all records
- That's an advanced feature (special pages), if you are using it, you
probably knows how to handle a website and you don't need us to remind
you where this special page's view is used.
[1]: https://github.com/odoo/odoo/commit/a91a3a563338e746d6d23cd57551af30e322e367
[2]: https://github.com/odoo/odoo/commit/727d461e1d2bcec4571665b90b6d1630f671a0a3
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 77f03abc56b147171eeba66bc55df5ee92c8af1a
Part-of: odoo/odoo#103136
Some snippets have a "hard coded" background color which doesn't change
when we want to put a preset color (theme). We have to delete the back-
ground first before being able to choose a preset color.
This commit fixes this behaviour by putting a preset color by default
on the concerned snippets (instead of a fixed color). These snippets
are searchbar and text highlight.
task-2824393
closesodoo/odoo#103123
X-original-commit: 4a1442679bb1058d08428e08bec3433e968fb64b
Related: odoo/design-themes#604
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The Masonry and Big Boxes snippets don't have a background option
because their blocks are supposed to take the whole space, so a
background is not really necessary. But since the addition of the grid
mode, these blocks can be placed more freely and a background may
therefore be necessary.
This commit adds the background option to these snippets.
task-3014939
closesodoo/odoo#103109
X-original-commit: 019f6824caafdf2cdc79babcbe45af3db0df1550
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_event
The 'website_event.menu_edit_menu' menuitem was added on 'website_event'
module to the 'custom menus' registry so it can be displayed by the
'website_custom_menus' service if the event page has menus to edit.
The goal of this commit is to move this code to 'website' by using a
generic 'custom_menu_edit_menu' menuitem that will be cloned to edit
every content menu on the current page with the corresponding
'EditMenuDialog'. This is needed as a fix as it would be a regression
to not have this in 16.0 since it was possible to edit any menu on a
page in previous versions.
task-2973149
closesodoo/odoo#102997
X-original-commit: 6af5ad67c9657c7dcaf4afa1ecb4561e9c72270a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
make searching translated field language dependent
add an extra filter using trigram index to speed up '=' and 'like' search
X-original-commit: 5b6f0a9e5f9d60735e306709a3e7d7ac46a586be
Part-of: odoo/odoo#103031
Before this commit, there was a conflict between 2 of the ways to open
the WebsitePreview iframe.
First, introduced with [1], when a user click on the 'edit in backend'
systray button, the URL he was on is stored to be used later if the user
click on the "Website Preview" breadcrumb. When he will click on that
breadcrumb entry, we want him to go back to where he was, not on the
homepage.
Second, some records in form views have a "Go to website" stat button
that will go to the website preview action, loading the iframe with the
URL of the record from the form view.
Before this commit, the second flow was not working if the user
previously click on "Edit in backend" on a record (first flow
described).
Indeed, if that "last url" was set, it would always be used, ignoring
the requested one from the second flow.
Step to reproduce:
- Go to a record in the website preview, like a product
- Click on edit in backend
- You land on the product form view, and that url was saved in JS
- From there, navigate to another record through the form view, like a
m2o relation or a stat button, or by whatever other mean, but don't
hard reload the page (F5)
- For the example, let's say you landed on a blog post record
- Click on "Go to website" on that blog post form view
-> You land on the product page you were initially, not on the requested
blog post page.
Courtesy of @rdeodoo
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#103010
X-original-commit: 7cd55e8a1d9516a6f457320064160328a49210f9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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
Since [1], the Masonry snippet is in grid mode only and its templates
have been modified to allow this mode. However, some of them don't look
good and have to be improved.
This is what this commit does:
- some text blocks were too small so their height has been increased
- the Masonry second default image has been replaced by another one
that looks better.
[1]: https://github.com/odoo/odoo/commit/85b352af319edec84407f2046cf795b4e5503460
task-3013055
closesodoo/odoo#102984
X-original-commit: ad8926eafd34c2743e1a5247f6171fd183e6e506
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@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>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@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 /web loading was slow during test when some themes are installed.
This is because without any context and request, the assets are
generated for website 1 before this fix.
With this default website:
_get_active_addons_list returns only addons that are not themes
_get_asset_paths will return less assets
When loading /web, no website is found because the domain is not empty.
This means that the web.assets_backend will have less assets when
generated outside of a request than in a request not matching any
website.
There is normaly no assets for the backend in theme BUT a tour is added
in each theme
('/theme_anelusia/static/src/js/tour.js', 'theme_anelusia', 'website.assets_editor')
('/theme_artists/static/src/js/tour.js', 'theme_artists', 'website.assets_editor')
('/theme_avantgarde/static/src/js/tour.js', 'theme_avantgarde', 'website.assets_editor')
('/theme_aviato/static/src/js/tour.js', 'theme_aviato', 'website.assets_editor')
('/theme_beauty/static/src/js/tour.js', 'theme_beauty', 'website.assets_editor')
('/theme_bewise/static/src/js/tour.js', 'theme_bewise', 'website.assets_editor')
('/theme_bistro/static/src/js/tour.js', 'theme_bistro', 'website.assets_editor')
('/theme_bookstore/static/src/js/tour.js', 'theme_bookstore', 'website.assets_editor')
('/theme_buzzy/static/src/js/tour.js', 'theme_buzzy', 'website.assets_editor')
('/theme_clean/static/src/js/tour.js', 'theme_clean', 'website.assets_editor')
('/theme_cobalt/static/src/js/tour.js', 'theme_cobalt', 'website.assets_editor')
('/theme_enark/static/src/js/tour.js', 'theme_enark', 'website.assets_editor')
('/theme_graphene/static/src/js/tour.js', 'theme_graphene', 'website.assets_editor')
('/theme_kea/static/src/js/tour.js', 'theme_kea', 'website.assets_editor')
('/theme_kiddo/static/src/js/tour.js', 'theme_kiddo', 'website.assets_editor')
('/theme_loftspace/static/src/js/tour.js', 'theme_loftspace', 'website.assets_editor')
('/theme_monglia/static/src/js/tour.js', 'theme_monglia', 'website.assets_editor')
('/theme_nano/static/src/js/tour.js', 'theme_nano', 'website.assets_editor')
('/theme_notes/static/src/js/tour.js', 'theme_notes', 'website.assets_editor')
('/theme_odoo_experts/static/src/js/tour.js', 'theme_odoo_experts', 'website.assets_editor')
('/theme_orchid/static/src/js/tour.js', 'theme_orchid', 'website.assets_editor')
('/theme_paptic/static/src/js/tour.js', 'theme_paptic', 'website.assets_editor')
('/theme_real_estate/static/src/js/tour.js', 'theme_real_estate', 'website.assets_editor')
('/theme_treehouse/static/src/js/tour.js', 'theme_treehouse', 'website.assets_editor')
('/theme_vehicle/static/src/js/tour.js', 'theme_vehicle', 'website.assets_editor')
('/theme_yes/static/src/js/tour.js', 'theme_yes', 'website.assets_editor')
('/theme_zap/static/src/js/tour.js', 'theme_zap', 'website.assets_editor')
Making the bundles for /web different with or without theme, and with or
without website id.
The proposed fix wont return a website if not specified in context and
if not during a request and if not forced to fallback.
The side effect is that the frontend assets where generated with a
website id 1 before that and it won't be the case anymore. This may be
a problem that could slow down frontend call on website 1 when design
theme is installed.
closesodoo/odoo#102690
X-original-commit: a5ed957b37b966bc50ed1219b6af65ed818f04a0
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>
In [1], the resizing and the drag and drop of a grid item both put
it in front of all the other items and in front of the background grid
(thanks to the `z-index` property).
This commit changes that behavior: now, the grid item stays at the same
z-index if we are resizing it or if we are dragging it over the grid
from which it is coming. In the case of a drag over an other grid, it
is placed in front of all its grid items. In all these cases, the grid
item is placed behind the background grid.
[1]: https://github.com/odoo/odoo/pull/93144
task-2973198
closesodoo/odoo#102525
X-original-commit: 67d1b078329600efce414974307d74e9fa9ba9fe
Related: odoo/design-themes#601
Signed-off-by: Quentin Smetz (qsm) <qsm@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
In grid mode, the images take the whole space in their column so they
always have the same size as them. However, if text was added in the
column (before or after toggle), it always looked like it was
overflowing and the overlay would not cover it even after resizing.
Also, since these images have the value of the `object-fit` property
set to `cover`, the images are cut if they are too big for the column.
This is problematic if the image has a shape because the shape is cut
too, ruining the visual effect.
This commit solves these issues by distinguishing the images that are
alone in their column from those that are not. An image is considered
alone if it is a direct child of the column and if there is no text in
it (the line breaks and empty lines are excluded). Now, only this kind
of images, if they have no shape, take the whole space in the column
and have `object-fit` set to `cover`; the other ones behave like the
columns in normal mode.
This distinction also allows to block the edition of the columns
containing only an image. Indeed, adding text or dropping inner content
in them had the same overflowing effect.
task-2973198
X-original-commit: e9c7e020daf88022d6e02de0a5620074e8417b5a
Part-of: odoo/odoo#102525
The grid mode allows some snippets to move and resize their columns in
a grid. However, some of them were blocked because they don't look good
in this mode. This is the case of the Big Boxes snippet: because it
contains two blocks full of padding and since toggling the grid mode
removes this padding, it ended looking weird.
This commit allows the previously blocked Big Boxes snippet to toggle
the grid mode. More generally, this commit allows snippets having only
columns containing a background color to look good in grid mode by
keeping a more logical padding for them.
task-2973198
X-original-commit: a051922f8359178f4abe578ce9555d34cbb02613
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>
Having multiple groups one after the other will cause the labels to not
have the same width; converge all in a single group
closesodoo/odoo#102424
X-original-commit: c787b16421807355e58d3029a0941d3bdd65fad7
Signed-off-by: Bouvy Damien (dbo) <dbo@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 loading a registry from route with auth="none" and where module
'website' is set as 'to install', request.env will be None and install
will crash as follows:
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/saas-15.3/odoo/modules/registry.py", line 88, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/saas-15.3/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/odoo/src/odoo/saas-15.3/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/saas-15.3/odoo/modules/loading.py", line 303, in load_module_graph
module.write({'state': 'installed', 'latest_version': ver})
File "/home/odoo/src/odoo/saas-15.3/addons/website/models/ir_module_module.py", line 78, in write
if request and request.context.get('apply_new_theme'):
File "/usr/lib/python3/dist-packages/werkzeug/local.py", line 348, in __getattr__
return getattr(self._get_current_object(), name)
File "/home/odoo/src/odoo/saas-15.3/odoo/http.py", line 1029, in context
return self.env.context
AttributeError: 'NoneType' object has no attribute 'context'
```
closesodoo/odoo#102343
X-original-commit: fcf6e462e116d13533014e31d4191763354811cf
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
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>
qsm-odoo