Previous system was strange: you were able to choose a body color but
not a body background when you were in full layout mode.
As transparent colors will soon be able to be chosen by the user, it
makes even more sense to give that possibility as the user can set a
body background pattern and a transparent footer color to let it
appear. Choosing a transparent background image which will be mixed with
the body color is also a common feature.
Also changes boxed layout option to use a white background for the boxed
content (we should maybe give the opportunity to the user to choose that
color instead of using always white).
Same as it was done before for buttons, this commit adds an option in
the theme customize dialog to allow selecting the font for the navbar
elements.
Needed for themes migration.
* web_editor, website_slides
Current system is styling all navbars with the user color. This was not
the expected behavior but it is in fact quite nice, so we decided to
keep it. There was however a problem: choosing the menu text color only
applied to the main navbar (as it was an xpath toggling the navbar-dark
class).
This commit solves the problem by forcing navbar-light to behave as
navbar-dark automatically if the menu background is dark, and this
without any JS or extra CSS rules. This allows to get rid of the menu
text color option.
This commit also reviews the light and dark colors which are used when
website is not installed.
- Remove theme specific parts and move them in theme_common
- Use IDs to ease theme overrides
- Use the same convention for all options: the default one is not bound
to any xml_id (that's just the default scss files)
Rev. 2f7c03d added a second admin user (id 2), the 'human' one, on
top of the 'technical' one (id 1, also known as the superuser).
Basically, all calls to _is_superuser() should have been changed to
_is_admin(). They weren't. As a consequence, some features that
were previously available for the admin weren't anymore (e.g.
tours).
This rev. replaces all calls to _is_superuser() by calls to
_is_admin().
Revision on https://github.com/odoo/odoo/commit/0de5c1f076d7e7d0e5361e08c810c727bd41d9e0
With the commit above, the following error was shown in the devtools
when accessing a frontend page without website that is installed:
missing module "[root.widget]"
This is caused by the fact that there is no root widget in the frontend
bundle without website installed. This may prevent executing tours
in some cases, because the tour manager needs a root widget to run.
This commit solves this issue by ensuring a root widget in the frontend
even when website is not installed, so that tour manager can run.
* website, website_sale, website_sale_delivery
While we used BS3, we used our own responsive classes for text
alignment (text-right-sm, text-center-not-lg, ...). Now BS4 classes can
be used to achieve the same behavior so there is no point in declaring
our own ones anymore.
Also, as the breakpoint names changed (lg -> xl, md -> lg, ...), the
current code was not working as intended anymore anyway.
Modal generic:
- Fix footer overflowing buttons by pushing them to a new line.
Page manager:
- Add an SEO column to easily see which pages have incomplete SEO.
- Add an edit SEO column to navigate to the SEO modal on said page.
- Hide "edit in backend" column as debug.
- Generally improve the whole view by adding appropriate titles on icons, etc.
SEO modal:
- Improve general style.
- Add description length alert.
- Restructure the keyword table/suggestions.
- Reset page meta to their initial value on Discard.
- Various small usability improvements.
PR: #26897
task-1850579
Make some changes which are needed for theme migration.
- Theme colors as user colors fallback only (not hard choice)
- Review option dependency system
[FIX] web_editor: adapt col size to avoid too small select
We should avoid col-md-3 in col-md-9 as the menu dialog is instanciated at 2
places:
- When creating a link in the editor
- When editing website navbar menu
In the second case, there is a hack in `content.js` to remove `modal-lg`
lowering the width of the modal and making the select too small.
[FIX] website: lower navbar font size
With BS4, font-size of navbar element went from 13px to ~17px (rem unit
computation).
14px seems better than previous 13px as the frontend content size is
higher than the backend one. Thus, 13px looks too small in contrast with the
frontend page content.
[FIX] website_crm_partner_assign, website_customer, website_membership: fix layout
This commit fixes multiple layout issues, mainly by aligning code of the 3
modules:
- Add margin right to avoid text to be against image
- Using image_medium everywhere
- Fixing search input width
publish toggle red + odoo primary is weird -> gray
navbar now has a background & float-right not working since flex
-> remove navbar class, use d-flex and ml-auto so the right element will be floating since using all available width
task-1878150
It was easy to mess with the footer unintentionally when dropping
snippets in the page. Now we only allow one "main" snippet in the
footer, solving the problem.
With this commit now user can set custom meta image from the seo dialog. If the
user sets such image then it will be displayed when the user shares that URL in
social sites.
By default, it will show the list of images used in the current page.
Alternatively, user can use media dialog to select/upload images. By default, it
will take the company logo as a meta-image.
We also improved how custom meta tags are handled for different pages, Now we can
set custom meta tags based on the model and we can override '_default_website_meta'
method in case you want to change default meta values from the specific model.
e.g. For products displayed on the shop, if we want to change the value of
og:image to product specific images instead of default logo
In future, it will be used to add model specific metas like og:price, og:currency
We passed 'website_company_id' in frontend session info because we display
company logo in dialog for all pages. We can't use /logo.png as it is not
updating in multicompany and multiwebsite.
task id: 1835370
Closes: #25430
Fix bug from the initial poc of JOV
Fix menu creation
- creating a menu would create a 'container' menu in the DB (.create is call without website_id)
then writing on it would copy (if condition to cow) the menu with a website_id leaving the first
one as a menu container unused.
- website_menu should always have a website_id
we dont want to support the multiwebsite system that allow to have generic/specific menu
unlink/write is useless now since we always have a website_id
Make unique_path website dependent, 2 distinct website can have a page with same name
Make Sale report multiwebsite compliant
Make website_id on sale_order / account.invoice as a related stored from partner_id.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
Now we can see which specific page override wich page when page are sorted by url.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@odoo.com>
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
* web_editor, portal
This commit introduces the first page options: header overlay and color.
The website builder is improved to allow the management of those. With
this commit, users can now click on the website header to make it go on
top of the first snippet, with a chosen transparent color. This is a
configuration that can be done on each page individually (as the feature
is very dependent of the first snippet on the page, this is typically an
option for homepages).
task-32155
* web, web_editor, website, website_theme_install, portal,
theme_default, theme_bootswatch
The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:
1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
the dialog without any risk of breaking the style and also allows to
not care about lots of technical details.
3) New options have been included. Those were themes options that are
now generic and which themes can simply adapt without touching the
customize modal (navbar colors, footer color, navbar layout, fonts,
body background, ...).
The color palette can now also be customized with user colors.
Using sass functionnalities, color palettes and fonts integration is now
a lot better.
Thanks to @qha-odoo for the original design.
task-31677
[NEW] base: show enterprise module, with an 'upgrade' button
[IMP] *: some modules renaming, and improved copywriting of manifest
[IMP] *: utm on links to odoo.com
As soon as a website menu contained a sub-menu, the whole website layout
was broken as we put <li/> elements inside a <div/> element (this
occured by mistake with BS4 migration).
* payment, portal, website, website_sale, website_sale_delivery
The way we used BS3 was not always perfect/conventional and was thus
not BS4 compatible at all.
Also improve the general look of some screens.
In a previous commit, we removed the use of the 'btn-sm' classes as we
used it everywhere for default-size buttons instead of customizing the
size of those default-size buttons directly.
This commit proves it was even more necessary as the 'btn-xs' class does
not exist anymore in BS4 and we so can use the 'btn-sm' class instead.
The 'form-horizontal' class have been removed; the '.form-group'
elements must now use the 'row' class for an horizontal layout.
The 'control-label' class was renamed to 'col-form-label'.
The 'help-block' class was renamed to 'form-text'.
The 'has-error' and 'has-success' classes have been removed and
replaced by a new system using the :valid and :invalid pseudo-classes,
when a parent has the 'was-validated' class. While this system is great,
it is not straightforward to use it in Odoo. Fortunately, BS4 provides
the 'is-valid' and 'is-invalid' classes as fallback. This commit
replaces the 'has-error' and 'has-success' classes by 'o_has_error' and
'o_has_success' classes (for JS compatibility) and use the 'is-*'
fallback classes. (The 'has-warning' class has no equivalent but was
unused in Odoo anyway).
The input-group-addon class has been replaced by a combination of the
input-group-text and the input-group-append/prepend classes. The
input-group-btn class is replaced by the input-group-append/prepend
classes.
Odoo used to declare two main colors: primary and optional (which are
purple and turquoise in enterprise). Those were respectively assigned
to the 'primary' bootstrap variable and the 'btn-primary' bootstrap
variable.
BS4, however, does not allow to have a different primary color for
buttons. Instead, the 'primary' color is used for all 'primary' related
components and utility classes, same as for all other colors. So, if we
want to keep our enterprise buttons green, our 'optional' colors had to
become our 'primary' color. The old odoo primary is then renamed to the
'odoo' color.
The palette of grays is now larger by default and is numbered from 100 to
900 alongside the $black and $white variables. The equivalence for older
variables and the way we used them is:
$gray-darker -> gray 900 (unused before)
$gray-dark -> gray 900
$gray -> gray 700
$gray-light -> gray 600
$gray-lighter-darker -> gray 400 (the old variable was created by us)
$gray-lighter-dark -> gray 300 (the old variable was created by us)
$gray-lighter -> gray 200
Fortunately, the 'lighter' variations we created fit well in the default
BS4 system ! Unfortunately, our $gray-lighter which carried the same
function as $gray-200 (see above) is very close to the new default
$gray-100 and quite distant from the new $gray-200. This will be handled
in the next commit.
Now the nav structure is more declarative: the 'nav-item' and 'nav-link'
classes have to be put on related nav item and links. Also, the 'active'
class has to be put on links instead of items.
Same as for the navbar component:
- The navbar structure was simplified and meant to be more declarative.
- The navbar colors are also now handled by a different set of classes.
The 'nav-stacked' class was removed and replaced by flex utilities.
The set of classes for colors and nav styles also changed.
qsm-odoo