Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
A form view record may be saved even if the record is displayed in
readonly (e.g. when a button in the form view is clicked). When
this happened, if there were an html field with html_frame widget
in the form, it crashed (e.g. in Email Marketing > Mass Mailings >
open one > click on Test Mailing).
Uppercase style shouldn't be applied to all btns by default.
The usage should be set progressively, following an importance criteria.
If we design everything as important (uppercase), nothing will be
perceived as important anymore.
- Cleaner design
- Reduce element size
- Use LESS variables to simplify maintenance.
- Switch from ‘em’ to ‘ex’ measure units.
- Remove :hover state (not useful).
- Clearly show margins' size on editing
- Top margin icons/cursors: by an user point of view, adding a
margin-top will move the content 'down', so change handler's icons
and cursors accordingly
- Highlight handles during editing and if previously edited
- Vertically center handle's icon if enough room is available
There was a lost promise which made website_form loaded before the
languages informations (such as date format) was loaded.
The server expect the format of the client thus that could lead to wrong
or invalid dates.
opw-749544
closes#18074
web_editor can be installed without website, thus missing needed CSS
causing e.g the widget sidebar to overlay and hide the mass mailing
content if website is not installed.
This fix implement a simple middle ugly solutions, but doing something
more in stable would be an hassle (for example in 88c2b684 the #wrapwrap
CSS is included in report module).
opw-748975
closes#18005
based on v10 terms and saas-15
add the new languages
Much noise due to the different softwares that do not indent the terms the same
way. Merged the po files with --no-wrap option which makes long lines.
opw-751014
* mail_channel, mass_mailing, twitter, event
- t-install attribute holds the technical name of the module that
needs to be install to use a particular snippet.
- Disable the drag & drop feature for these dummy snippets.
- Move some images to website module.
- Installed snippets display at the top of the list.
- Hide not-installed module snippets if user don't have rights to install module.
If the website default language is not en_US, qweb fields are not
translatable in en_US (and thus can't be translated) because:
- the code expected en_US to be the default language.
- there was a error in website _dispatch
opw-746776
closes#17939
Before 036ccbef when writing on qweb field with default language mi_SC:
- writing in mi_SC: wrote on the current res.user language (wrong)
- writing in en_US: wrote on en_US translation (right)
- writing in de_DE: wrote on de_DE translation (right)
but after 036ccbef:
- writing in mi_SC: wrote on mi_SC (right)
- writing in en_US: wrote on mi_SC (wrong)
- writing in de_DE: wrote on mi_SC (wrong)
With this commit, this drawback is also solved by keeping the lang in
context if present.
opw-746776
closes#17917
The translate feature of widgets html and html_frame had been
broken by the new views refactoring. This commit restores it for
the html widget, and removes it completely for html_frame as it
wasn't working correctly before the new views anyway (moreover,
it had already been disabled for mass_mailing: de403dc1ab).
This commit also ensures that the changes are correctly saved for
the html_frame widget. Note that this widget still needs to be
converted to our new coding guidelines.
* web_editor, web_tour, website_event_track
Before this commit, one JS file was responsible for all the library
extensions and fixes. There were two main problems with this system:
- The file was only available in the backend (as some extensions are
made on backend-only libraries).
- Some other modules were doing library customizations.
This commit creates one file per library to regroup their associated
customization and adds them in the right asset. These are placed in
the web module and every other module should avoid doing customizations.
This allows to have libraries consistency accross all modules and
between the backend and the frontend.
Steps to reproduce the bug:
-Change the default lang on the website to be different than en_US
-Edit the name of a product in the website
Bug:
The name of the product is changed in en_US and not in the language
set on the website. The lang is in fact removed from the context in
function saveElement(in addons/web_editor/static/rte.js).
opw:747084
Creating and editing mass mailing in multiple language is managed with
the change 05daa15.
But currently the language the mass mailing is sent in, is the language
of the "Process Mass Mailing Queue" (root user if not changed) so all
the recipients will receive the mail in the root user language has at
the time the given batch of mails is sended.
So this is different from what someone could expect by it being
translatable. In any case the recipients list could be based on a lead,
a partner a mass mailing contact or other and a language could not be
determinable in stable (a mass mailing contact does not have a language
for example).
If the system worked, there is also a usability downside in the meaning
that someone could duplicate a mail and not check all translation and
not be aware that the mail he see is maybe not the mail that will be
received (if translations have not all been completed).
In stable to have the same behavior in any case and lessen the usability
burden of users thinking erroneously the mass mailing may be sent in
several languages depending on a not-existing heuristic, this changeset
remove the translatability of mass mailing content.
This has the following effect:
no translation editing appear,
the mass mailing is edited and sent in one and the same language,
If someone want to send a mass mailing in several language, currently in
Odoo it would then require to:
duplicate the mass mailing,
change the domains of recipients base on choosen heuristic,
edit the duplicated mass mailing in the choosen language
opw-746445
opw-746776
closes#17718
Xavier Morel