In the media dialog, when an image is selected, it has a colored border
to indicate it. Commit https://github.com/odoo/odoo/commit/e011d58bee140411ccfb1ef9115dddc090d573c3
made changes, part of them designed to "Improve the image dialog to be
able to select/unselect". While this commit was indeed doing that, it
was also breaking stuff: when selecting image(s) then performing a
search, the colored border disappeared while the images were in fact
still selected.
Fortunately, this stuff breaking is only due to code modification that
was made for no reason (so reverting part of the commit is enough to
restore the features while keeping the commit's improvements).
before this event, when editing an email template from the chatter
by adding an image through the mediaDialog, the message was always empty
if nothing more than the image was present.
this was because the html field was not marked as dirty,
the event responsible for the marking was not triggered.
After this commit, when sending solely an image from the media dialog,
the email sent does contain the image
opw 779167
closes#20817
Snippet options were not receiving proper data parameter on
instantiantion due to a websitepocalypse wrong adaptation. Those
data are parameters to tweak an option behavior, directly defined
on the option's <div/> in the XML. By mistake, they were now taken
on the child <li/> element (main DOM element of the option).
A visual example of the bug is the overlay colorpicker displaying
"Background Color" as a title instead of "Overlay Color".
In Enterprise:
- Go in Settings > Technical > Mail > Templates
- Edit a template
- In the editor, upload an image
- Choose "Upload image without optimization"
You are sent back to the app switcher.
opw-778918
When using the HTML editor, when attempting to save a syntax-invalid
XML, the error line is supposed to be displayed in red. This was not
the case anymore since saas-15. This was a simple mistake of comparison
between a stringified integer ID and its integer equivalent.
When following these steps on Firefox:
- Select all text in a bold link (triple click)
- Type some text
The typed text did not replace the selected text but was instead put
at the front of it.
When double-clicking on a link/button, the link dialog is opened. The
problem was that the "btn" class is sometimes used on non-link elements.
While this should not be, the editor can easily be adapted to this.
When an element is placed multiple times in a page, it is saved only
once. Unfortunately, when a view was divided in multiple editable
parts (XML branding), only one of those parts were saved.
When editing the content of a <label/> which has XML branding (first
DOM element which is editable in its hierarchy), a <p/> element was
added inside. This behavior is there to automatically add <p/> elements
in empty editable <div/> / <section/> elements on edition. This should
however not apply on <label/> elements.
- Hide navbar divider in mobile view
- Change font to default when applying header style
- Remove form tag from media dialog search input to avoid redirection
This commit solves a bug when using custom background option: if a
custom background was selected, then hovering a non-custom background
and leaving the dropdown was selecting the non-custom background for
good instead of resetting back to the custom one. This is because the
custom background option is a non-preview one (you have to click) so
there should not be any need of resetting... except that the non-custom
background option is a preview one and messes with the same DOM
attributes as the custom background option.
The save on the frontend worked, but there was no feedback that it
worked if the identifier of the file currently edited broke a jQuery
attribute selector value (eg. /test.less breaks it).
website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.
From now, we don't have a specific /page controller to serve 'page'.
We use a new model website.page which is rendered if none route matches the url
and that the field 'url' on website.page matches the request.httprequest.path.
The order to serve a path is:
- Routes defines in controllers (/shop, /blog, ...)
- ir.attachment with name matching the path
- website.page with url matching the path
- website.redirect with url_from matching the path
- 404
To improve:
- allow regexp in website.redirect model
- allow to edit the view_arch from the page.management via redirect backend
(needed when traceback in the page, or when modifying a js/css/less/...)
Nicolas Lempereur