81b3a37dbffdf0e731e2ee4ef448c4b6628825fd
*: website Commit [1] (and [2]) from the "website in backend" refactoring adapted the colorpalette to read color information on the right document (as the right document could now be the one of an iframe which is inside the editor environment). Unfortunately, it did not do that correctly, making an inconsistent API relying on the fact the colorpalette should receive an "editable" param... while a jQuery version "$editable" param of the same thing already existed. Doing so, it forgot to give that important "editable" param in two cases: - For editor toolbar colorpickers (text foreground/background edition) - For colorpickers inside another UserValueWidget (like we-multi). This commit solves the inconsistency by removing the need of that "editable" params and relying on the previously existing "$editable". In the future, this should be refactored anyway. Steps to see the issue (A): - Enter edit mode of one of your website page - Select some text - Hit the "reset" (trash button) of the text background colorpicker => The text becomes black for no apparent reason. Steps to see the issue (B): - Enter edit mode of one of your website page - Choose a new main color for your website via the theme tab - Select some text - Open the colorpicker for the foreground color - Go to the solid tab and input explicitly the main color of the website => The color is hardcoded on the selected text instead of using the text-o-color-1 class. => A test has been added to check this usecase. Making a test for (A) is less robust as it also requires the backend color names not being the same as the frontend ones to have the bug (otherwise it works by chance)... and that will be solved by the next commit of this PR (another test will be added by that commit too) **. Note: - After this commit, following (A), a bug remains: the text receives a strange padding (as a "inherit" background is actually applied). Another PR will be made to solve that (see task for more info). - ** After this commit, (A) done in backend HTML fields instead of a website page leads to the same bug still. This is because of another problem that the following commit of this PR will solve. [1]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6 [2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af task-3237693 X-original-commit: a30206606423af9e6c8e0313c74fd6200247437e Part-of: odoo/odoo#125131
…
…
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials
Languages
Python
49.6%
JavaScript
47.8%
SCSS
2%
CSS
0.3%
HTML
0.2%