| Age | Commit message (Collapse) | Author |
|---|
|
Improve the mobile kanban when it's embedded in another view like
the Dashboard app
- Improve swipe: Allow to swipe on empty space
- When it's embedded :
- The Kanban column height now is fit to the content
- A empty space is now display if the Kanban column is empty
Task Id: 1904747
|
|
closes odoo/odoo#30045
|
|
Some features are common to portal and backend, such as the sign modal in
enterprise.
This commit uniformize the width of the modal to make it more consistent between
the two by default. Of course themes can still customize this behavior.
closes odoo/odoo#29521
|
|
BS4 colored cards do not have a very popular design. This will reset
them to a BS3-like one: only the header and footer are colored and the
body will use the color of a default card background with a light
opacity (to let the chosen color appear).
|
|
Do not mix Community and Enterprise color themes. Moreover, increase the
contrast of the control panel for better readability.
closes odoo/odoo#27502
|
|
Task-ID 1878649
|
|
The navbar in community now looks more like the navbar in enterprise.
Here is a sum-up of the changes in community:
- The navbar in community is now in blue, instead of black.
- No more app list that almost fills the whole navbar: there is
now an "Apps Menu" in the left-most side of the navbar.
- No more sidebar for the menus inside an app: those menus are
now located in the middle part of the navbar.
The navbar in community does not support mobile (< 768px width),
but it should still somewhat usable on most mobile devices.
As for the website navbar, it has been unchanged and should still
support mobile layout.
Task-ID 1878649
|
|
Commit https://github.com/odoo/odoo/commit/903ff171acbef7f9fe6e533f43b99eba801b200f
lowered the font-size to 14px for the frontend by customizing the
bootstrap variable in the portal app. It changed the web_editor
rte_inline tour accordingly.
This however broke the test on runbot "base" database, as the font-size
in the editor without having installed the portal app was still set to
16px. Commit https://github.com/odoo/odoo/commit/e3bc059c3649a05c12cd3c8099092282c10141b7
only moved the failed test from "base" to "all" database.
This commit unifies the font-size for all frontends by setting it in the
web app. So, after this commit: reports, editor, login screen and
frontend will always have a font-size of 14px no matter the application
which is installed (except themes).
|
|
* web, web_editor, website_hr_recruitment, website_mail_channel,
website_mass_mailing
- Review all snippets and add new ones
- Add lots of new options
- Use odoo colors as default theme colors
task-38878
|
|
Add a new record layout that make the image compensate the record
padding and fill the available space.
|
|
This is a standard BS4 bug: radio buttons's dot is not properly centered
as soon as the html font-size is not a multiple of 4 (and our backend
uses 13px). As a quick fix, I change that to 12px and use a font-size base
of 13/12rem so that the body font-size does not change. Bootstrap will
probably fix this in a future update.
|
|
See previous commit for more explanation.
|
|
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.
|
|
BS variables were renamed or changed and all (most) variables now
use 'rem' units instead of 'px' unit.
|
|
media queries that target a specific screen size handled by bootstrap
have now a more convenient way to be defined:
```
@media (min-width: $screen-sm-min) { ... }
->
@include media-breakpoint-up(sm) { ... }
```
```
@media (max-width: $screen-sm-max) { ... }
->
@include media-breakpoint-down(sm) { ... }
```
```
@media (min-width: $screen-sm-min) and (max-width: $screen-sm-max) { ... }
->
@include media-breakpoint-only(sm) { ... }
```
```
@media (min-width: $screen-sm-min) and (max-width: $screen-md-max) { ... }
->
@include media-breakpoint-between(sm, md) { ... }
```
Also, bootstrap has changed the values for its default screen sizes:
------------------
| BS3 | BS4 |
------------------
0 | XS | XS | -> Portrait Mobile
576 | / | SM | -> Landscape Mobile
768 | SM | MD | -> Portrait Tablet
992 | MD | LG | -> Landscape Tablet / Small Desktop
1200 | LG | XL | -> Desktop
------------------
While it is possible to configure BS variables to behave as BS3, we took
the decision to keep the BS4 variables untouched. BS4 system seems
indeed better and having the purest bootstrap possible is better for
Odoo to be used as a framework.
|
|
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).
|
