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>
Bootstrap 'img-responsive' behavior was opt-in for a reason but commit
https://github.com/odoo/odoo/commit/f79b00c3b71e02f73537cb17285a6902fc0906b5
tried to defy that anyway. This would break existing client databases
... or at least our odoo.com.
This commit adds the img-responsive class for *new* *editor* images
(still with inline-block display), preventing breaking libraries or
custom (prod) images.
The commit fix an issue causing the portal navbar to overlap/inherit wrong style in customised websites.
The previous layout used to add the entire portal navbar inside an <h3>, causing inner elements to inherit the titles style.
According to WC3 standards, titles can have phrasing content only.
Titles reference > https://w3c.github.io/html-reference/h3.html
Phrasing content reference > https://w3c.github.io/html-reference/common-models.html#common.elem.phrasing
By chance this issue was not visible on runbot, but was severely affecting our website and probably clients ones too.
This commit wrap the portal navbar in a standard bootstrap navbar structure, fixing the title issue and provinding some imp. too:
- Search is now available for mobile
- Modules can inject a custom/botstrap class (eg. navbar-default) ot customize design if needed
The portal view for tasks previously listed all task of all projects
without grouping them. It was a problem, mainly when we want to make
the distinction on project label_tasks, to make the difference
between tasks, issues, ... Grouping task by project by default allows
to show the label_tasks before each project.
Grouping the tasks removes the possibility to define a primary
ordering. We want to be able to ungroup the tasks in some cases.
The implentation was done in the portalsearch bar adding
a group by option. The portal proposes two grouping options,
project (by default) and none (to keep strict ordering).
Task: #1827950
PR #23769
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
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
This commit prevent VAT and company name edition if an user has already at
least one document (SO or invoice) for his partner or his related company
partner.
Any module can override this feature to add their own condition to prevent
campany name/VAT edition.
task-33088
Closes#23420
In the frontend only plaintext is saved without any javascript fiddling
so in the controller it should be adapted to be saved.
With this change, the behavior is more similar to backend chatter which
sends html (processed by javascript) to the server.
opw-1817918
closes#23706
Purpose of this commit is to standardize portal user creation when
creating new portal users (when 'Free sign up (B2C)' option activated). It
copies the portal user template. The same behavior now applies when
converting a partner into portal user using the portal wizard.
This commit is related to task ID 31399 .
60c920d4a should solve duplication of chatter when editing the website.
But portal module doesn't depends on website, so eg. on a instance with
just helpdesk (and no website) we would not see the chatter on the
frontend.
This fix reverts 60c920d4a and adds another solution not depending on
website.
opw-1813792
closes#23614
When editing a view on the frontend with a dynamic chatter (chatter
added dynamically to the view), if that part was edited, that
dynamically rendered part would be saved as is. Thus we would get a
duplicated chatter (with the first one statically the rendering at the
edit time).
opw-1813792
closes#23593
When a chatter is displayed and the document is accessed with a valid
access_token, the message related to the document are searched in sudo.
This bypass valid filtering we may down the line.
This change apply the filtering so note type messages are not displayed
for user who are not employees.
note: before 11.0 this logic was in 1b5c2ced. In future version it would
probably be better to have a method eg. _get_domain_based_on_user
that would be called before sudo and if not sudo.
opw-1819702
closes#23544
Christophe Simonis