only use alpha channel if it exists
[FIX] api: avoid to return all fields *2many in onchanges

When an onchange returns a change in a 2many field line (a '1' tuple, update), avoid to return all fields of the *2many field but only the altered field.

Otherwise, the web client regard all the fields of the 2many as dirty, and try to write on all fields (even if the value is the same, thus)

opw-615062
[FIX] account: do not duplicate analytic lines on analytic journal duplicate
[FIX] point_of_sale: fix point of sale sequence declaration, github issue #3218
improve patch according to reviewer's suggestion
[REM] python-stdnum from requirements

It is never used in the code, and causes problems with wheels: related
to pypa/pip#2105

closes #3744
[FIX] web: force company logo refresh per db

The company_logo is cached and was not refreshed when switching between database, still showing the logo of the company of the previous database
Fixes #2738
[FIX] decimal_precision: avoid refreshing float precisions at each cache invalidation

Changing the decimal precision of float fields is a rare
operation, while cache clearing occurs fairly frequently.
Signaling a full registry change when the decimal precision
is changed (instead of a mere cache change) is therefore
a better trade-off, and more semantically correct as well.
This way we avoid the decimal precision refresh for each
invalidation.

Registry invalidation implies cache invalidation.
[FIX] mrp: perform location chaining for kit exploded moves

This rev. 7307227 ensured to not (re-)set the state 'confirmed' to exploded moves with a more advanced state (for instance, 'assigned')
Nevertheless, the location chaining is performed on the move confirmation, through the action_confirm method of the stock.move model. Besides, the resulting moves of the _action_explode method had the state 'confirmed' on creation, the 'confirmed' state wasn't set by the method 'action_confirm', meaning that the moves were confirmed without having the location chaining done. Allowing moves to go through the action_confirm method even if the state was 'confirmed' or further triggered the location chaining.

Preventing already confirmed moves to go through the action_confirm method prevented the location chaining, thus.

We now create the resulting moves with the 'draft' state, and then confirm them through the procurement workflow signal 'button_confirm'. Thus, the resulting moves are confirmed by going through the action_confirm method, writing the confirmed state and triggering the location chaining at the same time. We then write the 'assigned' state if necessary.

opw-617235
[MERGE] forward port of branch 7.0 up to 529e920
[FIX] graph.py: correct Node() creation.

Fixes #3730
[IMP] doc: incorrect value documented

closes #3761
[REM] duplicated package in requirements, sort
[I18N] Update translations from Launchpad 8.0 branches
[FIX] base: copy access rights on group duplication
[MERGE] forward port of branch saas-3 up to 6c13c8d
[FIX] fix wrong filter in opportunity view (crm)

There was two problems:
* it was filtering on the probability of the opportunity, not on the
probability of the stage
* the filters were not prefixed with '&', which means that they gave
weird results when combined in the searchview (in a filter group, filters
are combined with '|', but it breaks when the filters are defined by
an implicit '&')
[FIX] http.py: invalid request must return a status code 400
[FIX] mass_mailing: attachments were not send.
[FIX] calendar: support non-ascii chars in date/time format

The calendar module generates string values with
a date/time formatted according to the user
language. Those formats may contain non-ascii
characters and are read as unicode strings,
but fed to str{p,t}time, which only accepts
byte strings (in Python 2).

This would cause an exception when loading calendar
notifications for a user using e.g. Chinese with
some CJK unicode chars in the date/time format.