Since commit 6494f51171, all images in mass mailing are created as
attachments. This can lead to URI too long to be handled by some proxy,
e.g. Nginx.
opw-1853188
* web_editor, website
This commit fixes a bug with table duplication in mailing template:
- Click on a snippet with two columns
- Duplicate it
-> the snippet is duplicated but the two columns are transformed in two
rows.
This was because there is an implemented behavior for column
duplication: if we duplicate a column which was alone on its row, we
duplicate the row instead. This code should however be triggered when
duplicating the column alone to be working, not the snippet that
contains it.
Note: this required a backport of a33ec972ab
which was fixing a non-critical "bug" for 11.0. This non-critical "bug" is
therefor fixed here too.
opw-807105
Browsers' default alignement of <td/> is 'inherit'. Some mail clients do
not set this value properly though and even if it is explicitely set,
they do not compute the final value well.
As a fix, this commit forces the 'inherit' value on <td/> and computes
the real alignment for 'inherit' values when transcoding.
opw-813688
Mail content is wrapped in a table to properly allow centering the
layout in all mail clients. The problem was that this table was able
to be customized by the editor while it should not.
Without this patch, default images for themes are not used automatically
in themes' templates when one is chosen for the 1st time. This was not
inducing any bug in standard 10.0 but with custom-made templates, you had
to put the correct themes images in the defined template. This allows to
just `t-call` snippets instead of having to fully hardcode them in theme
templates.
Origin of the fix: the snippet background image did not change the background image.
This was due to commit a14f89c which wraps the snippet's content into a table for outlook display compliance
This issue is fixed here, with the modificaion of the background snippet option.
OPW 772442
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
In some case we don't want to wrap the content to be centered.
Now, you can add a data-nowrap when you define the theme params to
don't wrap it in a table automatically
Eg:
<div data-name="blank"
data-img="/xxx"
>> data-nowrap="1"
data-images-info='{...}'>
Following bee3253b44, this commit is made
to increase the mail clients compatibility for the mails that are
created with the odoo mail editor.
Three new problems are handled:
- Font family of titles had to be forced too as outlook was not
inheriting parent font family on those either.
- Default text font-size had to be forced as was not detected in
transcoding correctly.
- text-decoration rule was decomposed in text-decoration(-line,
-style and -color) in transcoding. Outlook is ignoring those
three rules for some reason. As the decomposition is useless,
the transcoder now forces the recomposition of these three rules.
Creating a mail template which is complex and compatible with all mail
clients is a very difficult task as each mail client supports a
different subset of basic CSS rules.
This commit fixes 3 problems which were occuring in outlook and/or
thunderbird but not in gmail:
- Main layout horizontal overflow
-> change 24px horizontal padding of main layout to 3% and set the
width to 94% (so that the sum is 100%)
- Fixed 600px content was full width instead
-> Change the .o_mail_wrapper to be a <table> element instead of a
<div> element. The table is full-width and contains one row of 3
cells: an empty left one, a fixed 600px-width center one and an
empty right one. This allows to have the same layout as before but
without using the unsupported max-width css rule.
- Texts were not using the right color and font-size
-> <p> elements were not properly inheriting the color and font-size
properties, so force the style on <p> elements.
opw-743156
* hr_attendance, hr_gamification, hr_recruitment, mass_mailing,
project, sales_team
Before this commit, the kanban column did not know about the model
name which make customization impossible without a getParent. Kanban
records were supposed to know about this thanks to the options
parameter but this was broken. Now the model name is automatically
initialized from the given state.
Adapt all extensions which relied on this.
* account, mass_mailing, sales_team
These view extensions have already been ignored for around two years.
The new views development is a great opportunity to remove them.
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
If you followed these steps, Chrome deleted the link and image:
1. Create a new mass mailing, fill the subject.
2. Drag & drop any snippet with pictograms.
3. Change a pictogram for an image.
4. Add a link to the image.
5. Save the record.
This happen in chrome if the image was for example floating in
the link, so this change check if an element is a contained element
is visible before removing it.
This issue doesn't happen with [jQuery 3][1] and may be linked to
[this][2].
[1]: http://api.jquery.com/visible-selector/
[2]: http://stackoverflow.com/a/8337382/1468388closes#15623
opw-710237
note: this is only needed in 9.0 and saas-11 because this features
doesn't seem present in version 10.0
- Go to Mass Mailing > Configuration > Mail Templates
- In the Kanban view, find a template which contains a link (http,
mailto, whatever)
- Click on the link
You are redirected to the link instead of being redirected to the
record.
opw-706047
Sometimes, there is a need for mass mailing "basic" mails with no
image or style. The "basic" theme is designed for this (note that
there still is the possibility to add style and images, default
images are just gray placeholder).
In mobile view, the mass mailing kanban view crashes.
Commit eee1d8c159 aims to prevent drag and drop for mass mailing.
However, in mobile view, the the drag and dropd is by default
deactivated, and "sortable" is not initialized.
opw-708140
The witdh and height auto has apply on image, when the mass_mailing
clean_for_save is called, the image is considered as invisible because
the with is temporary null.
opw-692805
- When opening a mass mailing
- Editing it and making a change (e.g. add a block)
- Click on the breadcrumb
- Click "OK" on the warning popup telling your changes will be discarded
- Choose another mass mailing
A crash occured. This is basically the same case than in the revision
7bf80d22dd
but for Firefox, for which `window` is still there
`!window` returns False
but is `closed`
opw-702211
The mass_mailing editor has a feature which switches the images of the
content and/or the droppable snippets according to the theme.
Unfortunately, this images were only initialized on theme choice and
not when entering in edit mode. So when reediting an already edited
mass mailing (or when duplicating one), the theme images were not
initialized.
Nicolas Martinelli