summaryrefslogtreecommitdiff
path: root/addons/website/static/src/js/user_custom_javascript.js
AgeCommit message (Collapse)Author
2019-02-26[REF] website, *: use public widgets instead of website animationsqsm-odoo
* website_blog, website_crm_partner_assign, website_event, website_event_track, website_form, website_forum, website_links, website_mail, website_mail_channel, website_mass_mailing, website_sale, website_sale_comparison, website_sale_delivery, website_sale_stock, website_sale_wishlist, website_slides, website_twitter While using the 'Animation' class of website instead of the frontend 'Widget' class leads to the same behaviors, this refactoring is done for two reasons: - Stop using the confusing 'Animation' name for non-animated behaviors - Instantiation of 'Widget' is slightly faster than 'Animation' Part of https://github.com/odoo/odoo/pull/29442 task-1932066
2019-02-05[IMP] website: improve documentation of user custom filesqsm-odoo
See https://github.com/odoo/odoo/pull/29999
2019-02-05[IMP] website, *: improve CSS edition usability + add JS editionAndrea Ulliana
* web_editor Currently, when an user wants to edit the css of its website, he has access to lots of files and, in debug mode, to even more files. While the feature is nice for people who know what they are doing, a lambda person can easily break its website by changing the wrong files. Also, nothing warns the user that the files that are edited will never receive updates anymore (unless if they are reset). The goal is to prevent those behavior while still allowing the add custom css. Another goal is to be able to *add* custom javascript. Custom files created for the user: SCSS: user_custom_rules.scss, user_custom_bootstrap_overridden.scss JS: user_custom_javascript.js See https://github.com/odoo/odoo/pull/29999 task-1919350