In the portal module,
the `index` method from the `web` module controllers
is overriden to redirect `/`
to the portal `/my` for the portal users,
instead of the regular backend `/web`.
However, when `website` is installed,
this behavior should not happen,
as you would like the signed in portal users to
be able to see the website homepage,
and not to be redirected to `my` when
they try to access `/` root path of the website.
Because the override in the website module was done on the
`index` method coming from the `web` module instead of the `portal`,
according in which way the Python module were loaded,
it sometimes redirected to `/my`, sometimes it correctly
displayed the homepage. This is because the modules are not
loaded in a determinist order.
To summarize, on runbot, if you logged as portal/portal,
one time on two you were redirected to `/my`, and the other
time you saw the homepage correctly.
As `website` depends on `portal`,
we have the possibility to override the `index` method
of `portal` instead of the one of `web`,
to force the determinist order,
and therefore the determinist behavior of the homepage for
portal users.
Previously, customizing the website footer was not very easy. This
commit will allow users to customize the footer like any other
snippet area.
There are several behavior changes, as mentioned below:
- Removed toggles 'Automatic Footer' and 'Payment Icons' from the
Customize menu
- Language Selector was moved near the 'Copyright' section of the footer
and features a dropdown (dropup technically) to select the language
- Moved some footer links from various modules to top menu
List of the added menus / changed menus:
(a) Resellers (new menu for previous footer link 'Resellers')
(b) References (new menu for previous footer link 'Our References')
(c) Forums (renamed from 'Forum', as a replacement of 'Forums'
footer link, showing all the forums instead of 'Help', as there
is no link available to all forums after this commit)
(d) Live Support (new menu for previous footer link
'Livechat Support')
(e) Mailing Lists (new menu for previous footer link 'Mailing List')
(f) Members (new menu for previous footer link 'Members')
- Links which were already available as a website menus (Presentations,
Jobs, Events, News, Documentation, etc) are simply removed
Technical Notes:
- Introduced a new template called 'brand_promotion' in website.
This will help to avoid adding redundant footer content (like
copyright, language selector etc) from several modules (website_sale,
website_event, website_quote, etc) while the only intention is to
replace module page links.
- Removed summernote related fix in portal.less (caused by xpath)
because footer is now customizable and added padding to structure
instead of footer itself so that bg-color/img can be applied on
whole footer.
- Few of the tours are improved to drag and drop snippets at proper
places and not inside the footer.
- Used Flex in copyright portion of footer, so that text will always be
horizontally centered (Some themes have different padding for buttons,
etc, so if we don't align text dynamically, it has to be managed in
particular theme and in particular layouts like full-screen / boxed.
And if someone changes height of this portion, we have to re-design
this portion again, etc).
task-38069
Closes https://github.com/odoo/odoo/pull/22298
Co-authored-by: Dharmraj <dja@odoo.com>
With this commit, it is now possible to delete a page directly from it's page
properties dialog.
Before this commit, you had to go into the page manager and then find your page
that could take some time.
task-1850578
Closes#24861
With this commit, we introduce a better screen to manipulate the search
view in a mobile device.
Note: most of this work was initially done by suh-odoo, then was adapted
and moved to community by myself.
task 31464
This commit:
1. removed the possibility to create page from the menu manager.
The usability of this feature wasn't great since create menu as a new page
would redirect to that newly created page without saving the menu manager
state.
Plus, there is already the 'NEW' button on the navbar to create a new page,
the menu manager should, as its name hint, only manage menus.
2. Handle a new case (officially at least) of menu: menu container.
Those menu are simply menus with '#' as URL. It will be usefull to create a
menu as a dropdown list container.
Note: We should take care of a menu's URL being updated to '#' to avoid the
menu's page URL to be also edited to '#'.
opw-1825883 & opw-1824263
Before this commit:
1. If a menu was used as a container (dropdown) and had an unpublished page_id
(website.page), we would never show that menu (and so its submenus) even if
it has visible submenu.
Some users are stuck with this since they:
a) create a new page 'A' (unpublished by default) included in menu.
b) create a new page 'B' (unpublished by default) included in menu.
c) set 'B' as a submenu of 'A' in the menu manager
d) decide to publish the website.page linked to menu 'B'
Then, since menu 'A' is linked to an unpublished page, the menu 'A' and 'B'
are never visible.
2. If a menu is being created with an URL that match a website.page URL, the
m2o relation will automatically be set (website.menu.page_id).
Still, if the user type the URL without the leading slash, the m2o won't be
set.
This could be misleading since on the page property in the page manager the
URL is being shown without the leading slash even if it is stored in DB.
Now:
1. We always show menu container if they contains visible submenu, even if the
container menu is linked to an unpublished page
2. The page URL search is more clever and will match URL even if the only
difference is the leading slash.
This closes#24635
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
Unlike LESS, SCSS variables are not lazy loaded. Our system has thus
to be updated. This commit creates new templates which are t-called
in assets bundles (to replace the old less_helpers template):
- web._assets_utils: regroups the mixins and functions which *can*
(and so should) be available in every asset bundle
- web._assets_primary_variables: regroups the variables (or mixins
used as variables) which *can* (and so should) be available in
every asset bundle
- web._assets_secondary_variables: same as above but provides an
environnement where all the 'primary' ones are accessible. This is
for example useful to handle the community/enterprise split:
// Community primary variables
$o-pink-color: pink; // enterprise color
$o-brand-primary: blue;
// Enterprise primary variables
$o-brand-primary: $o-pink-color;
// Community secondary variables
$o-my-darker-primary: darken($o-brand-primary, 5%);
=> If there was only one variable template, enterprise edition would
have been able to define its primary color at the end but the
darker primary would not have been updated. Using the "!default"
system and putting enterprise definition above would not have
solved the problem as the $o-pink-color would not have been
accessible.
- web._assets_backend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the backend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
- web._assets_frontend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the frontend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
Note: bootstrap variables are not accessible in any of those anymore.
If you have variables that should depend on bootstrap, you have 3
solutions:
- Find another way: your variable is probably useless, use bootstrap
variables directly or create a variable that will influence the
value of bootstrap variables. E.g. instead of declaring:
`$myvar: $bootstrapvar * 3`
and using $myvar alone, declare:
`$myvar: 3` and use `$myvar * $bootstrapvar` where needed.
- Declare a copy of the bootstrap variable and use that one. In that
case, you should also force-set the real bootstrap one to be sure
they match (this should be done in appropriate templates mentioned
above). E.g.
```
$o-boostrapvar: 5;
...
$boostrapvar: $o-bootstrapvar;
```
- Set your variable to null and set it to your bootstrap expression
in the file you will need it (where bootstrap variables are accessible)
without forgetting to add the !default flag to allow overriddes.
```
$myvar: null;
...
$myvar: $bootstrapvar * 5 !default;
```
This commit also partly changes the variable names to follow the
convention:
$o-<app_id>-<name> where 'app_id' is the current's app name or a
meaningful unique identifier ("theme" for all themes for example, as
no multiple themes can be installed).
Convert content so that the assets compile on app installation. The
style is still broken after this as the variables/mixins/... are not
defined in the right order (as it did not matter in LESS but does in
SCSS).
This commit basically changes:
- Variables: @var_hello -> $var-hello
- Mixins: .mixin_world() {} -> @mixin mixin-world {}
- Classes used as mixin: .my_class() -> @extend .my_class
- Here there were no other solution than to convert the use of
a mixin call by the use of an extend as a first approximation
- LESS functions -> SCSS functions (e.g. fade -> rgba)
- Move first variable definition before the variable is used
- Still need to make sure last variable definition is at the
right place
The 'oe_link' class is not linked to any style. The class is
automatically converted to 'btn-link' for <button/> elements but this
will not be done on <a/> elements as they are (nearly) unprocessed
node during views rendering.
Also there is minor difference between a '.btn-link' element and a
<a/> element anyway (and maybe there should not be at all).
Note: original work of @dbh-odoo was to have + and - buttons on the
editor overlay but specs changed to use a standard dropdown (the work
of @dbh-odoo was thus adapted for this).
See task-46094
Closes https://github.com/odoo/odoo/pull/22197
web (tagged with `openerp-web`) translations are loaded in the backend, in
`odoo.addons.web.controllers.main.WebClient.translation(mods=None, lang=None)`
method (through `/web/webclient/translations` controller).
In website, the controller `/website/translations` is called used, fetching
the translations from modules with the (fragile) clause `name ilike 'website'`
This commit fixes two bugs:
1. Install `website_sale`, activate discussion on products
-> the chatter is not translated as the portal translations not loaded in the
`/website/translations` controller
2. Install `helpdesk` but not `website`, go to portal view of a ticket
-> the heldesk chatter is not translated as the `/website/translations`
controller is not called (only provided by the website module)
This patch implements a modular approach to translate the web resources of the
right modules only.
The controller /website/translation is moved to http_routing and each module
override the new _get_translation_frontend_modules_domain method to adds its
translatable module
Closes#23618Fixes#23610
Move zoom next the original picture
Disable it if same img and max size with ratio < 1.5
Allow to enable zoom automatically
...
Task-33499
Co-authored-by: Jérémy Kersten <jke@odoo.com>
This commit reverts part of f5912cb since the spec changed afterwards.
Unpublished page will have a red toggle, which even if it is small should be
enough to draw user attention, and not a ribbon anymore.
Task-44005
Before this commit if /foo redirect to /bar?a=1
/foo?debug=1 was redirectd to /bar?a=1
After this commit,
/foo?debug=1 is redirected to /bar?a=1&debug=1
Adrian Torres