summaryrefslogtreecommitdiff
path: root/addons/web_editor/static/src/scss/bootstrap_overridden.scss
AgeCommit message (Collapse)Author
2020-06-02[IMP] website, *: allow presets user editionqsm-odoo
*: web, web_editor Now, the user can edit each individual component of each color preset thanks to the third tab of the left panel. The edition of the first preset is the same as the others for the users but it is actually also used for "no-preset" areas, meaning that they impact the whole website by default (*without impacting the other presets*). The website thus appears as areas using presets, preset 1 being the default (in the future all areas will be customizable with a different preset). The only difference between "using preset 1 explicitely" and "not using a preset" will be that background color is transparent in no-preset, leaving the body background appear. If the body background has no image, then there is no difference at all as the background color of the body is set to be the background color of the preset 1. In boxed mode, that color is used for the "box" and the website body uses a different customizable color. Note: before this commit, the "text" color edition was used to set the main text color and one of the constrasting color for the color-yiq function (the darkest if a dark color or the lightest if a light color). That last part has been removed and automatic colors will now always use $gray-900 and $white as contrasting colors, unless changed by the theme explicitely. This needed to be removed as now the "text color" edition has been moved in the "preset 1" config and should thus only impact the "no-preset / preset 1" areas instead of all the presets. Part of https://github.com/odoo/odoo/pull/45856 task-2197038
2020-06-02[IMP] website, *: introduce new classes to color snippetsqsm-odoo
*: web, web_editor, website_blog, website_event New o_cc${xxx} classes where ${xxx} is a number [1-5] to style snippets: they come with a background color, a text color, headings colors, a link color, primary button colors and secondary button colors which will later be possible to customize by the user. The classes are made so that they are working on two levels. So if a column receives a color class and the snippet too, everything will work fine. More than 2 levels are not supported and the editor is made so those cases should not appear. See o_colored_level class. Part of https://github.com/odoo/odoo/pull/45856 task-2197038
2019-01-04[FIX] web_editor: restore backend colorsqsm-odoo
Commit https://github.com/odoo/odoo/commit/52ec536cef2ec84af0b36746f19a8cdf9f23fe2a made a mistake which made the backend use the website colors. This is because the web_editor app adds its bootstrap_overridden.scss file in both backend and frontend assets as the backend needs the editor colors (alpha, beta, ...). However, the 'primary', 'secondary', etc that the backend customizes should not be overridden by the web_editor. Therefore the file contained a hack to determine if it is the backend or not... hack which did not work anymore with the new system the mentioned commit implements. Also some comments were not adapted correctly by the mentioned commit. closes odoo/odoo#29935
2018-12-26[REF] *: make stronger bootstrap assetsqsm-odoo
* portal, theme_bootswatch, web, web_editor, website With less2sass and bs3tobs4 tasks, the assets structure was reviewed to handle the specificities of both framework and to prepare for our next odoo tasks. In particular, the assets_helpers and bootstrap overrides were basically split into 4 parts: utils, primary variables, secondary variables and bootstrap variables. (see https://github.com/odoo/odoo/commit/6e4db7d13a926845bf82f5b035afede42d6d5a89) Using the !default system for the bootstrap variables parts seems now a good improvement. This is part of what this commit does: adding the default flag for all bootstrap variables overrides and inverting the order of the files in the _assets_backend_helpers and _assets_frontend_helpers templates. This allows to avoid code like this: portal: ``` $body-bg: white; ``` website: ``` @​if $var != null { $body-bg: $var; } ``` This code makes the body white with portal or equal to $var with website if $var has a value. The same behavior in the new file order is achieved with: website: ``` $body-bg: $var !default; ``` portal: ``` $body-bg: white !default; ``` This order is now also followed for the _assets_secondary_variables templates (there are only a few). This commit also make better assets hierarchy by making website inherit from portal assets (instead of web) and portal inherit from web_editor assets (instead of web) (thus relying on strong dependencies instead of installation order which is not always right for migrated databases). closes odoo/odoo#29757
2018-11-07[FIX] website, *: review auto light and dark colorsqsm-odoo
* web, web_editor The logic which chose if the user text color was supposed to be used as bootstrap "dark" text color or bootstrap "light" text color (https://github.com/odoo/odoo/commit/8b2dbd1441d6713d9072db03e8d3cb6c2246410f) was fine when using the default theme with default bootstrap but was not working as intended in some themes. This commit also introduces a more accurate and complex method to determine the correct contrasted color in most cases. closes odoo/odoo#28468
2018-09-19[FIX] website, *: review navbar color systemqsm-odoo
* 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.
2018-09-07[FIX] web_editor, *: use explicit string keys for color mapsqsm-odoo
* website ``` $map: ( test: 1, black: 2, ); @​debug map-get($map, 'test'); @​debug map-get($map, test); @​debug map-get($map, 'black'); @​debug map-get($map, black); ``` The above code leads to a: 1 1 null 2 This is because maps' keys can be *anything* in sass (even other maps). In the example, the map is defined with unquoted `test` and `black` as keys which are understood as the string 'test' and the *color* black. When asking for the value for the 'black' string key... there isn't any. This commit forces the use of quoted string as color maps' keys.
2018-09-03[FIX] website: review website customize dialogqsm-odoo
Make some changes which are needed for theme migration. - Theme colors as user colors fallback only (not hard choice) - Review option dependency system
2018-08-30[REF] web_editor, *: review color theming systemqsm-odoo
* web, website - Introduce gray color palettes (needed for themes migration) - Synchronize BS4 color maps with individual variables (see comments about this in the code). - Review alpha/primary, beta/secondary matching: Before this commit, we decided that the common way to define a color palette was defining primary, secondary, gamma, delta and epsilon. alpha and beta were then forced to primary and secondary without other possibility. The new system makes more sense: 1) define alpha, beta, gamma, delta and epsilon 2) primary and secondary will automatically be set to your alpha and beta (allowing to style the default UI with BS4-independant variables) 3) if you are not happy with (2), you can define primary / secondary in your color palette so that they are not automatically set to alpha / beta This commit also changes what classes the editor uses. Background colors and text colors will now use alpha/beta/gamma/delta/epsilon (not primary and secondary anymore). For buttons, all the possibilities are suggested but color duplicates are hidden (so if your primary and alpha are equal, only one button color is suggested).
2018-08-10[IMP] *: make customize dialog generic and improve optionsqsm-odoo
* 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
2018-08-10[REF] web_editor: rename scss file to respect conventionqsm-odoo
The file was introduced with BS4 but the name was not well chosen.