The view `sale_team_dashboard` (which extends kanban) has been removed
and replaced by a default kanban view.

To use it in the ViewManager, an option `js_class` is added
on the arch description and this class be used as the View.

This avoids creating a new view type just for one view.

* use a special arg in odoo.py
* note that the previous implementation was relying on the fact that
  the openerp-gevent file was located in the same directory than the
  odoo.py file. This was no longer true since rev a0eb172c
  This commit brings back this behavior.

300ms was used during development but now 10ms seems to be high enough
to prevent bugs.

fix error introduce in commit 7596fa3e
The get_format_currencies_js_function return javascript code and the openerp.web should not have been replaced by odoo.web. The result is that reconciliation view was broken.

Coming from https://github.com/odoo/odoo/commit/232eea36ab98eb268f712b2083c637a7cb463e2c

* 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

* Add a "transparent" button
* Add a special background for transparent background buttons

+ Some minor colorpicker design change

As there is no translation for them

Do not translate variables content, does not make sense
Its value should be translated earlier

PURPOSE
=======

For each and every Hr application there should be one user category (One app = one category).

SPECIFICATION
=============

HR remains as it is : Employee, Officer, Manager

Each Application should have 2 access rights: User and Manager. Example for Recruitment:
- The user has access to the recruitment process
- The manager has access to the job position configuration

Each Application should grant the employee user access right (Namely the 'HR Officer')

Bad migration to new api... All values was resetted ith 'forumla'.
Why not formula as default value directly in product.pricelist.item ???

[IMP] website_sale: improve data to be multi currency, multi pricelist and fix tests according to new data

Now the porperty product pricelist is computed automatically.

Based on the res_country of the res_partner, and the pricelist available
for this country.

It is always possible to force another value (property) that the computed.

Now that property is computed automatically.
In some case, the compute will take the first on available.
So, the order (sequence) allow to specify the priority.

Test from point of sale are base on currency $,
So we force for the test to use a pricelist in dollard (My company, Chicago)

Now, the user can choose on the pricelist if the price should be displayed as a
discount or not (price striked red).

cart_update and confirm_order recompute unit price by default.
So we need for website_event_sale to be able to ask to don't recompute the price.
Else the price of product will be used instead of the price of ticket.

Make it generic... It is not only a concept to website !

Update tests

Without it, currency was ignored

This reverts commit b4d7b7e6.
Odoo always uses term eCommerce

In 8.0 private fields have been recently set as visible only to employees
at commit b2265108.

However between v9 and v10 two new payment acquirers have been implemented
payumoney and stripe. Those addons now have their credential set as private.

Methods using the acquirers have been sudoed accordingly to avoid access
issues when rendering the buttons. Other payment modules will be updated when
the forward port from 8 to 9 and pre-10-master will be done.

If your create an order in backend and you make payements, they remain opened while the POS session isn't closed, which may seens counter-intuitive. The payment in taken into account afterward and the reconciliation is made with the invoice (if applicable)

We shouldn't let people create POS orders from backend. And while we're at it, we should do the same with sessions. They're opened and closed from the dashboard.

There already is a redirect implementation in the chat_manager
which closely matches the on_redirect implementation in chatter.js,
however the former has the advantage of calling get_formview_id
to ensure that the view is correct.

This fixes a faulty behaviour when some models are referenced from
chatter message using data attribute data-oe-model and data-oe-id.
For example, linking invoices in the chatter would always open them
with the 'vendor invoice' view; from this revision on the correct
view will be used (assuming get_formview_id is implemented on the
model).

The default behaviour of the chat_manager when a user clicks on a
partner record is to open a channel if the partner has a user then
return a callback passed as a parameter (usually to open the channel
as a popup or in the discuss app). To keep the old behaviour
of the chatter followers list widget (i.e. open the partner form
when clicking on a follower), a small change has to be made on the
redirect implementation: when no callback is provided, do not create
the channel (instead a returning an empty callback).

The default order on `sequence` was not specific enough,
causing semi-random selection of picking type and warehouse
when several types exist with the same sequence.

The problem was made more likely by the fact that
warehouses create their own picking types.
The algorithm to determine the sequences for the
new types was not handling properly the case of
a NULL sequence.

The patch fixes both issues: the selection of the
default picking type (e.g. for purchase orders),
and the algorithm for choosing the sequence for
new picking types.

* Replace mail theme/template system with a cleaner one which only
allows to change a class on the main container of the mail
* Improve snippets
* Improve snippet options
* Improve web_editor UI
* ...

* Remove mass mailing template switching system (lemon, airmail, ...)
and replace it with a theme selector which only toggle a different
class on the body.
* Lint JS files.
* Change the way the editor is overridden by mass_mailing in a more
odoo way (put the JS in assets and check on runtime if it must be
applied.

+ fix editor style
+ remove useless code
+ remove odoo template