Before this fix, the customize button was updated with each character,
which slowed down the fast insertion of characters and used resources
unnecessarily.
Part of https://github.com/odoo/odoo/commit/f4ba72a7593b67595852fc52ec0997d3276dbc67
became useless after forward-port in the new editor. Indeed, that
commit handled what happened with data-editor-message attributes on
save but as the new editor can discard changes without reloading the
page, the forward-port of that commit made the code handle the attribute
removal on editor *close*.
closesodoo/odoo#31143
Issue: wysiwyg asset slow down the loading of the website, error
inadvertently introduced: https://github.com/odoo/odoo/pull/29775
The assets are now loaded assynchroneously, when the editor is needed,
its assets will be loaded.
closesodoo/odoo#30700
Scss tour was broken due to recent task that shows only 2 new custom scss
files if not in edit mode. As the tests was trying to read `website.ui.scss`
that is now in debug mode in a filter, it would not be found.
Html tour was broken due to new editor that changed the save process.
For some reason, after the drag & drop of a snippet, clicking fast on save
would not fire RPCs as it would not be considered as dirty.
(Editor would then close, you would still see the modifications even if nothing
was saved on DB)
closesodoo/odoo#31067
* portal
The user can now choose the font-size of its header menu items through
the customize dialog.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Options and option sets can declare a data-depends attribute to specify
which options need to be enabled for them to be displayed. With this
commit, we allow specifying which options need to be *disabled* for the
same purpose (we can now do that by prefixing the options IDs with '!').
PR https://github.com/odoo/odoo/pull/29624
task-1904244
* web_editor
This commit's goal is to optimize the delay to make a scss customization
thanks to the website customize dialog. Before this commit, the JS code
took advantage of existing web_editor routes but this was far from
efficient as this was done:
1) PY: Load all scss files used in the page
2) JS: Find the one we want to customize and adapt the scss content
3) PY: Create the scss customization with the new content
(So two RPC (including one very slow) and content building in
javascript)
After this commit, this is done:
1) PY: Load the scss file being customized, adapt its content according
to the new values and save the customization
(So the whole logic is in python, requiring only one small RPC)
This commit also take the opportunity to review the web_editor ace
editor loading code (the logic is shared with website customizations).
PR https://github.com/odoo/odoo/pull/29624
task-1904244
* portal, web
This commit introduces the first of many-to-come non-color website user
values: the logo height. Now, the user can choose it in the customize
dialog.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Before this commit, in the theme customize modal, only lists were able
to be visible under the condition of a subset of options being enabled.
Now options can too.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Before this commit, the loading was shown during colorpicker choice or
body image choice too, which makes no sense. This commit also make a new
loading visual which is less intrusive and flicker less.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Before this commit, color options in the theme customize were treated
as big exception in the system. The whole color panel XML was defined
client-side and used custom design. Now, all colors are defined as
options in the "server-side" template, allowing for more customizations
and better maintenance.
This commit also makes the color saving system generic to allow for more
new options in the future (like customizing the logo height or the font
size, which is the next task).
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Move the 'Show Logo', 'Show Sign In' and 'Fixed Top Menu' options from
the customize menu to the customize theme dialog using new features
introduced with https://github.com/odoo/odoo/pull/29624
The customize menu divider is also only added if there are toggable
options in there (which is not the case anymore for all pages since
this commit).
PR https://github.com/odoo/odoo/pull/29624
task-1904244
- Make the controller part more readable and more efficient (O(1) ORM
operations instead of O(n)) and remove deprecated code.
- Add the possibility to have a toggle standalone option. This is
used as soon as an `<opt/>` is alone in its container (note that now,
the container can be any tag and will be ignored during rendering).
- If an option has no specified 'string' to attach to it, the name of
the first view it toggles will be used.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
* portal, sale, website, website_blog, website_crm, website_event,
website_event_sale, website_forum, website_hr_recruitment,
website_sale, website_sale_wishlist
At last, that ugly JS module can be removed. Before this current PR, it
was still used to wait for "page ready", to initialize widgets on page
loading. Now, all can be done thanks to public root and public widgets.
web_editor.base was also still used in tours, which should not be
necessary anymore for the same reason, especially since the tour manager
waits for the public root naturally.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* web, website_blog, website_sale, website_twitter
Before this PR, all website widgets were named 'Animation'. Now that
they are 'Public Widgets', we can at last stop using the confusing
'animation' name.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* 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
* portal, sale, web, website_blog, website_crm_partner_assign,
website_forum, website_event_track, website_links, website_mail,
website_slides, website_mail_channel, website_mass_mailing,
website_sale, website_sale_comparison, website_sale_delivery,
website_sale_wishlist
The `editableMode` option and its related options in public widget
should only be part of website, this commit moves them there. This is
also the occasion to implement something that is long overdue: stop
creating 'animations' / public widgets in edit mode by default. Indeed,
lots of 'animations' were defined by beginning with 'if not edit mode'.
Now, if a public widget should be considered in edit mode, it must be
defined explicitely through a property at *definition* of the widget.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* account, auth_signup, payment, portal, project, sale, sale_management,
web_unsplash, website, website_mail, website_rating, website_sale
This commit does probably not do what is stated for all non-website apps
but it is a first step. It also uses the system in apps which could have
already used it but did not.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
* im_livechat, survey, website_forum
When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This commit moves part of website JS to web, so that it can
be used by all 'frontend' apps whose only common dependency is web
(portal, survey, auth_signup, ...).
This PR also questioned several other similar issues which will be
handled later like:
- website should maybe not depends on portal but only on http_routing
- part of portal should be moved to http_routing and http_routing
should be renamed (especially for frontend layouts, etc) so that apps
like survey can reuse some common code
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
In preparation to future commits, the WebsiteRoot instantiation is moved
in an other file than its definition.
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
When the edit mode is entered, some elements receive
data-editor-message attributes. These were not removed on save which
could in some cases make the attributes be saved in the database. For
this to happen it would require an `.oe_structure.oe_empty` element to
be put *inside* an editable element (instead of being the one which is
editable). In that case the `.oe_structure` content would be saved in an
inheriting view but the parent view would also be COW'd for no reason
because of that attribute.
Difficult to say if such a case exist in the current views but as it
technically possible and that some of our tests use that configuration,
it is worth fixing.
Note: this fix was in fact done in the new editor in master and allowed
to detect that one of our test was not testing a feature correctly
because of that. This will be adapted in a different commit of this PR.
closesodoo/odoo#30834
Commit https://github.com/odoo/odoo/commit/29075a8e2c734624cec4f6009185616634f70dea
was written while there was an incorrect behavior related to
multi-website, oe_structure_ID and edit mode in a rare specific case
(see the second commit from this PR for detailed explanation
https://github.com/odoo/odoo/pull/30834).
That rare case was detected in 12.0 since the tour did not work on
master with the new editor (that fixed the incorrect behavior).
Basically, it was COWing the edited view even if only an oe_structure_ID
was touched.
Indeed, when saving a specific view in the HTML editor, we should also
search for its possible new ID as it could change if we also edited its
generic parent. In that case, the view will be copied and then unlinked
to preserve inherit order on the new specific tree.
* web_editor
BS conflicts with our UI again: btn sizes and form controls are
more difficult to force with BS4, this commit adapts the controls to
use less problematic sizes, and adds/adapts some more forcing rules.
Part of https://github.com/odoo/odoo/pull/31117
task-1941156
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
Every new page was being considered an empty homepage with "Welcome to
your Homepage! Let's start designing." shown. Now only an empty homepage
shows that message.
closesodoo/odoo#30839
* 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
* website_forum, website_gengo, website_mail_channel, website_sale
Retrieving the global context is now the root's job, this will prevent
problems when trying to extend the values the context has.
See upcoming improvements with https://github.com/odoo/odoo/pull/29442closesodoo/odoo#30816
Christophe Simonis