summaryrefslogtreecommitdiff
path: root/addons/web_editor/static/src/scss/bootstrap_overridden_backend.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
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-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