Before this fix, the customize button was updated with each character,
which slowed down the fast insertion of characters and used resources
unnecessarily.
Purpose of this commit is to introduce a new way of displaying and managing
slides in eLearning module. Its purpose is to give a better experience to
users when going through a course. Notably a fullscreen mode allows to take
lessons one by one without going out of the elearning display. Integration
of all slide types eases taking the course step by step.
Quiz are introduced in this commit. Those are an addition to slides with
some question / answers (multiple choice). It allows customer to gain karma
and improves gamification. Certifications are still done using the survey
application. Quiz targets only small tests at the end of a given slide.
A new widget is added to display and control slide display in fullscreen
mode. Old display is still available for documentation channels or when
going out of fullscreen mode, to see details on comments / review / statistics
and have access to share options.
This commit is linked to task ID 1902304 and PR #29876. It closes the main
work on refactoring website slides into eLearning, with other tasks already
merged in current community [1][2][3][4][5].
[1] Task ID 1940360 landed at b2149bc7a2: certification inclusion
[2] Task ID 1936153 landed at 6c6179e57c: homepage inclusion
[3] Task ID 1937160 landed at 8b7605c9e5: selling courses
[4] Task ID 1922159 and 1940516 landed at 5fa651cb01 and 6a64c3ce82:
new user profile and gamification of slides / forum
[5] Task ID 1938643 landed at 77b5673a0d: upload channel/slide
When evaluating js tests using the browser_js method, they are
considered a success when 'ok' is found in the console log and a failure
if 'error' is found instead.
This is not very robust and recently failed with this commit : 7410de111f
It adds a filter named 'Error' in a view, when the 'click_all' test
clicks on this filter, a message with the name of the filter is written
in the console, wrongly leading to a test failure.
With this commit, the browser_js method expects a log message in the
browser console with the explicit text "test successful".
On the other hand, any error in the console log will lead to a test
failure but a test can be forced to fail with the explicit error message
in the browser console "test failed".
As a bonus, the python logger should now also log browser js trace messages.
closesodoo/odoo#31158
Purpose
=======
The "publish/unpublish" widget is always shown on the frontend as long as the user
is a website_publisher and the object has a "website_published" field.
In some modules (namely website_slides) we need to handle a more refined level of access.
This commit adds a "can_publish" computed field that can be overridden to add some additional
access rules to the object and hide the widget if the user doesn't have the rights to
publish/unpublish.
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
This commit provides the abilty to create channel from the website
instead of creating a slide. To do so, the user still have the "upload"
button on the channel home page.
The new modal allow user to set title, description, type and channel
tags. We prevent channel tag and group tag creation on the fly, as it
can impact the UI (coming in a future commits).
Task-1938643
* 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
Next commit will change that file to make it extend a web_editor model
instead of a web_editor controller. This commit only moves the file.
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
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.
Before this commit, if the first website in the select was not in your current
company, it raises a traceback.
Now with filter on your own company, and support empty website selected
removing required on related field and using attrs dynamic to make it required
closesodoo/odoo#30769
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
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
'web_editor.BodyManager' stopped being used by the editor and the
related file was moved to website without being renamed or considered.
Hopefully, the editor replaced it by something else so the `BodyManager`
makes no sense on its own anymore. This commit merges its features
with the only other component which still used it: `WebsiteRoot`
See upcoming improvements at https://github.com/odoo/odoo/pull/29442
(related to task-1932066)
closesodoo/odoo#30740
Before this commit, clicking "Edit in backend" from the website could randomly
lead to the backend under another menu or without module, depending on the
other modules that are installed or version com/ent used.
After this commit, it will always open the backend under the specifiec menu
or website menu if not defined.
+ uses existing website dedicated action for product.template in 'Edit backend'
task-1919436
closes#30555
Co-authored by seb@odoo.comclosesodoo/odoo#30657
Before this commit, if you installed website in community you was not able to
install web_enterprise, because the web.login_layout was replaced (by hinerit)
by website and break the xpath from enterprise login.
Now we apply the Enterprise login xpath before that website replace it.
Before this commit:
1. If we were editing a template with no xml_id, typically the case when
editing a specific view (COW'd), the 'Template ID' label would be left empty
as the view does not have an xml_id but only a key.
2. If we were editing a generic view, the template would be COW'd and replaced
by the specific one created during the save.
After the save, the page would be reload and will try to reopen the edited
template (stored in url `res=123`). But as this template would be replaced
by the COW'd view, the JS would crash trying to access an inexisting view.
The HTML editor would then open in a very thin modal, barely editable.
Now:
1. Display the template's key instead of its xml_id. The key is basically a
duplicate of the xml_id, mainly used in website.
2. If we are saving a generic view, we search for its newly created specific
view to upload the URL hash before reloading.
task-1934279
Fix#30447
With the following view hierarchy:
A
|
B' (oe_structure_ID view)
Before this fix, when saving multiple templates at once from the same hierarchy
the COW views (website) would not be saved correctly as the first call to
`write` would COW the parent view, then the second concurent call to `write`
would create the child specific view under the generic parent view.
Instead, the generic parent should have been cloned to a specific parent view
and then the child view should be COW under the specific parent.
A A'
| |
B' B*' (This one is the old B', without B' changes in the html editor)
Instead of
A A'
|
B'
Calling the `write` one after another will do the trick. Indeed, when the
second call is fired, the first call has already triggered the COW behavior.
Thus, the second call correctly retrieves the COW view.
Another issue might still appear, if the parent view write is sent first.
Indeed, the parent view will be COW, thus the specific child view (second write
waiting to be fired) will be deleted to be added on the new specific hierarchy.
Thus, that write will then raise an error since the view does not exist anymore.
task-1934279
Fix#30447
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes#30564
Before this commit, if you duplicate a published record on the website,
the copy was already published, while in most of case you need to update
it to adapt to the new content. There doesn't make senses to duplicate the
same content on a website and let the duplicate content.
Task-1930058
Christophe Matthieu