Purpose:
The field date_deadline is a date field (without hours:minutes:seconds)
The customer is tempted to put the task deadline under hours, which is not
feasible
So in the calendar view for task, set the "month" view by default
instead of the "week" view.
Style attribute is now parsed and sanitized. Only a while list of accepted
properties is kept. The behavior is implemented directly in the cleaner
itself. As there is no easy possible inheritance, the styling cleaning is
appended directly after the legacy processing in __call__.
The styling sanitizer is called only if the style attribute is kept. If
the sanitizer is called with strip_style=True, the styling is removed
and therefore no sanitizing is performed.
Tests about html fields have been updated. Indeed the styling is now sanitized
and the test was not correct anymore, as the test html was stripped. It now
contains styling that is kept. The strip_classes is also tested.
Do not strip class by default on html fields, this was an error. Currently
only mail_message body field should not contain classes. Indeed as external
content can be stored through the mail gateway we do not want to keep the
classes.
Do not try to keep frames as they are already removed. Indeed tag_to_kill contain
the frame tag. This parameter has precedence on the ``frames`` parameter of the
cleaner. It was therefore unnecessary.
Added the support of strip_classes, like the already existing strip_style
parameter of html fields.. This parameter is missing but allow full
customization of html fields.
Also fixed the call to the sanitizer in fields. Indeed the strict mode is
set to False. When not in strict mode the classes are never stripped whatever
the value of strip_classes.
Sanitizer is now called always in strict mode to ensure the sanitize process
is correct and really take into account strip_style and strip_classes.
This fix is done in master due to possible side effects and possible behavior
changes that are not welcomed in stable versions.
Before this rev., editing the subtypes of other followers was only possible if
the current user already opened a record of the same model of which he is
himself follower.
- extended_chat_window feature in its own files: as it is only available in the
backend, we don't want it in the frontend assets (which contain the 'basic'
chat_window)
- move followers feature in its own files
- creation of the 'mail.utils' module in utils.js
- creation of systray.less to define the style of the mail item and dropdown
in the navbar
- use of chat_manager's search_partner function in PartnerInviteDialog
- some code linting
When loading a form_view with the follower widgets, an RPC was performed to get
the followers info (name, email...), and if the user is one of the followers,
a second RPC was done to retrieve the subtypes.
This rev. batches those two RPCs. Also simplifies read_subscription_data() as
it is now always called with a follower_id.
A few code refactoring as well.
Commit 516b1a6c72 fixes a bug with action buttons not being displayed when they
should in dialogs. However, it makes the assumption that either $node or
this.options.$buttons exist, which is not always the case (e.g. dashboard).
This rev. moves that logic out of the views to the view_manager, and protects
the call of empty() on this.options.$buttons.
That way, we have only 2 ir.actions.todo executables on the common modules
(I don't count the configuration wizards in l10n_eu_service or oauth_ldap)
- 'base.open_menu' to jump on a frontend view
- 'theme_install_todo' to open the theme installation view
As the module website_theme_install is auto_install: True and so installed after
the modules like forum, slides, ..., the theme_install_todo is by accident
always the 1st chosen one, which was the wanted behavior.
NB: Remove the ldap wizard launcher
This makes it so people can pick one of the selected fiscal positions in
pos_config.fiscal_position_ids as their default fiscal position. When
creating a new order in the front- or backend the pos order will
automatically be assigned this default fiscal position.
Bootstrap handles the primary color in a different way than the other
colors. So to not break the backend UI, the o-create-color-classes
mixin has to consider this difference.
Notice that colors management should be further improved in the future.
Allow users to define a percentage on shipping price, in order to cover
up differences between rating and shipping actual price.
Authors:
Barad Mahendra <mba@openerp.com>
Parth Mehta <pme@odoo.com>
Launching a form view in a dialog thanks to target=new did not
display the action buttons (save, discard, ...). This is because
the action_buttons flag is set to false by default and the only way
to start an action with a different value is thanks to JS code (i.e.
the debug manager modals).
Now, action buttons are also rendered if the flag footer_to_buttons
is set to true (only happens when launching an action in a modal) and
that the formview does not have any footer tag with buttons to add
(so that wizard form keep replacing the action buttons by these footer
buttons).
* Remove recursive assets inclusions (i.e. assets_editor was including
assets_common, summernote, ...)
* Better construct the assets (link, then script + type attribute)
* Better include the assets (split js / css, always use t-call-assets)
* Simplifies the number of assets
* Move bootstrap js to assets common
* assets_frontend is now created by web module to allow using it on the
connexion page but also in the web_editor, where colors have to be
bootstrap/theme ones. Note: if a module depends on website, then keep
using the inherit_id="WEBSITE.assets_frontend"
* Convert some CSS to LESS
* Split/Join LESS files
* Remove duplicates between website and web_editor
* UI improvements
* Allow simple customizations thanks to LESS var&mixins for website
Before, the whole editor UI was redefined for web_editor, each
mass_mailing template, website builder, ... Now they all inherit
from the web_editor one.
This makes it so that when you set a customer in the POS frontend it
will automatically apply the fiscal position associated to the customer
on the order.
If the customer has no set fiscal position or if the fiscal position is
not available in the POS nothing will happen.
opw-668155
Mansi Trivedi