Change color #a24689 to #875A7B
Commit https://github.com/odoo/enterprise/commit/8ac1c19fac7615fecd51e670f798d13158a4e53c
changed the odoo interface violet by changing the main LESS variable
but forgot there was many direct occurences in XML/HTML/... (for
example for the mobile browser color).
Even if it's community the odoo interface violet is used at many places
(module description, XML demo data, ...).
Commit 48a1eaf792 adapt the welcome
message on website so that it fits the page height. But this does
only worked for large screens as the height was forced to main
height... which is smaller than the default welcome message height
on small screen. The fix only had to use min-height instead of height.
Commit 5f98040430 in saas-12 changed
some "saved" event to "save" event but forgot to adapt new features
which depend on this in 10.0 after forward port.
Since the library nestedSortable was updated to the release 2.1a,
at the below revision:
https://github.com/odoo/odoo/commit/aa19d9edd02756d87056a44340e36568b3183e21
It was no longer possible, in the front-end, to move the menus:
Re-sequence them, put one below another, ...
Indeed, in that piece of code, `.item_id` was never
set with the new release, while it was the case with the former one.
We replace with `.id`, which looks like to have the same behavior.
Following commit 3cbc7ebc4c, the bug for customize menu
could have been ignored but as it is an easy fix :
The customize menu is filled after a rpc which is performed on
mousedown on the menu toggle. But in the case the user clicked on the
customize menu before the mousedown handler was attached... nothing
occured. It is possible since the customize menu is rendered but its
JS widget is only attached to it once everything is ready.
Now, the menu is filled on first mousedown or if the menu is already
opened when the JS widget is attached.
Frontend tours have to wait for base.ready() before starting otherwise
they can find DOM elements whose event handlers have not been attached
yet.
Note that this is a workaround to ignore these real "bugs" as users
should not be able to see buttons they can't click at once but there is
no safe and small fix which will resolve that. The time between the DOM
becomes visible and handlers are attached is small enough to ignore
this bug for now anyway.
The commit e59a7fe3ff has moved
the ACE editor from website to web_editor. As some code on ir_ui_view
was used for this widget, the code has also been moved to web_editor.
* event, website_event, website_forum,
* website_hr_recruitment, website_sale
Website access rights were buggy. The editor assets and website editor
assets have to be loaded together to work so the previous behavior
which only loaded one with the restricted access right was not right.
Also, people which had the "Manager" access right for model like event
or job only got access to creation and edition of those objects if they
had the full access to website access rights.
Now the website module creates the two same groups :
* group_website_publisher: load all editor assets, give access to
page creation for model the user has access (event, job, ...) and
edition of those pages
* group_website_designer: implies the first one and give access in
creation and edition of all pages + access of all website menus
The manager access rights for event, product, jobs, etc now implies
the group_website_publisher group for the user (so that the manager
have the editor assets and editor ui).
Note: some python codes use the group_website_publisher for no right
reason, this has to be adapted.
* web_editor, website_blog
Since recent refactoring, web editor dialogs automatically trigger
an event when closed (saved or cancel). The problem is that there
still was manual trigger of those events or variants ("save" instead
of "saved").
To prevent multi-saving and be consistent, all save events are now
automatically triggered on save/close (no more manual) and the event
name is "save".
Publish buttons appeared in list view item in /shop with commit
5a5dd1e100.
They however never worked for some reasons:
* The publish buttons were unclickable as the around style was badly
implemented: the section title was over the publish button
* Even if it was clickable, the publish button handler had no prevent
default, thus it submitted the form it is in -> crash when no cart
button or added to cart on click on publish button if there was a cart
button...
Note: the style should be reviewed in next versions, this commit, as
a 9.0 fix, fixes the style with the minimum code and so that it does
not break any theme.
Commit 3c98c78fc7 added the feature to be proposed redirection
after a click on a menu link in edit mode. This however applied to main
direct link in the menu and not sub-ones in sub-dropdowns. This commit
fixes this.
web_editor Qweb: Add 'zoom' option for widget image
<span t-field="product.image_small" t-options="{'widget': 'image', 'zoom': 'image_medium'}" />
website: Add Zoom code to be standard for all website module
website_sale: add zoom on Main product image
In edit menu, search with de demo data /shop, was the 12th results, but limit 9.
We only move the problem to later, but when the user start with the website apps,
it avoid to be lost on first menu creation.
website -> web_editor so that they are available for mass_mailing.
To allow setting margins on td elements:
As the above mentionned option allows to control the mt and mb classes
on the mass mailing items, the problem is that we would ideally want it
to be functionnal on td element as they are the main part of a mail.
As they don't support margins, there were many options to fix the
problem:
- Add more JS to place the mt and mb classes on children of td element
- Place the option on children of td element and not td element itself
but in that case, the width control of td would imply a lot of parent
option hierarchy, or the width control had also to be adapted to control
children
- Control padding instead of margin. This forces to add lots of
css rules like pt4 pt8, ... (or td.mt4, td.mt8, ...).
The last solution has been chosen. Padding is more supported than
margins in mail client anyway and the css rules will be isolated in
the mail editor anyway. Using td.mt4 instead of pt4 had the advantage
to not require any JS modification.
The dashboard must be visible for non-'group system' users, hence
the sudo call + only display the link to modify the client id
if the user has sufficient access rights.
Small visual correction for live users counter in the dashboard.
The Website Admin dashboard displays graphs for sales, analytics,etc.
using a (somewhat easily) extensible js framework.
Unfortunately, this framework is ACL unaware, meaning that it will
completely and silently crash if you are missing any of the required
access rights.
To solve this, extensions must now specify not just a graph name
but a necessary group for it and set the value for this group in
the extension of the backend controller.
This commit also
- make the icon visible for the group 'Website Designer and Editor'
(not juste the Settings group, which is extremely restrictive)
- make the button to set the Google API key only visible to people
with sufficient access rights
* Do not read multiple DOM data on each scroll. Simply read this when
necessary (edition / initialization).
* Throttle scroll event and debounce resize events (-> performance in
edition and navigation improved).
* Do not save useless data in the DOM.
* Have the parallax state consistent if the page undergo other changes
* Simplify DOM structure and LESS
- Allow to better see how to place snippets inside the area
- Before this commit, default parallax had different height on
chrome and firefox
Commit b309f3ab54 made the snippet remove
button always be there by removing the "preventParentEmpty" mixin.
Instead of preventing to remove the only child of a snippet, the system
was changed to remove the parent if this only child is removed. This
also applies on the system which hide the remove button if the child
cannot be dropped anywhere in the DOM.
Unfortunatly the image gallery snippet relied on the remove button to
be hidden for its content images. Indeed, it was implemented so that
the "remove" button is hidden but a "remove image from gallery" was
there in the customize menu. The solution is to remove this option and
copy its behavior on the standard remove button.
Note: this probably was not done before because the on_remove feature
was broken (fixed with commit 5e9ebcfb01).
* Add the ability to define palettes custom selection.
* Add the ability to define a custom title for the colorpicker dropdown
* Define a custom layout for single (unique) palette layout
* Define overlay color options based on new colopicker for
Cover and Banner text containers
* Define default palettes
Removing a slide was buggy :
* Removing the last slide left the slide handles (and the user had to
click on remove slide again)
* There was an ugly delay before the removal
* Changing the bg image of a slide was not possible anymore once one
slide was removed
* ...