The dates of an event on the website was always
within the user timezone. If not signed in,
it was within the public user timezone
(which is quite not user-friendly to change)

For this purpose, we weed get the context
from the record (the context used when using
`record.with_context`), and therefore
the QWeb field
`ir.qweb.field.datetime` is slightly altered,
to use the context from the record.

opw-675427

From af614946
Allow to compute the depreciation when the asset is in state: draft

The above string was not translated, when creating a new
discussion group, in the group message input placeholder.

opw-673712

The stock history doesn't take into account internal moves. For example,
in the following situation:
- Receive 1000 products to Internal Warehouse 1
- Move these 1000 products to Internal Warehouse 2

The 1000 products are still recorded on the Internal Warehouse 1.

opw-672277

This is a complement to commit 6d4a78a2. The 'invoiced' status should
be removed automatically once the membership is expired.

opw-672259

Avoids name collisions when custom columns are involved.

Closes #11743

Oversight of commit bd025cda.
I'm an idiot, I should have checked that another solution was applied
from 9.0 with accounting refactoring. We apply it here as well.

When stock landed costs are divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when several products are bought, but
these products leave the stock one at a time.

A numerical example is the following: a landed cost of 15.00 is applied
to a purchase of 13 units. An amount of 15.00 is recorded when the
products enter the stock. If the product leave the stock one at a time,
13 entries of 1.15 are recorded (15.00/13 = 1.153846... ≈ 1.15), which
is then equal to 13 * 1.15 = 14.95. In this case, All the products have
left the stock (stock valuation is zero), but 5 cents remain on the
account.

This is of course even worse the higher the ratio is. For example, a
landed cost of 4.00 split into 1000 units sold piece by piece will never
be recorded when a product leaves the stock.

The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost

opw-675222

When the product price is divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when a product is bought in a UoM
different from the standard UoM of the product.

A numerical example is the following: a box of 13 is bought for 15.00.
An amount of 15.00 is recorded when the products enter the stock. If the
product leave the stock one at a time, 13 entries of 1.15 are recorded
(15.00/13 = 1.153846... ≈ 1.15), which is then equal to
13 * 1.15 = 14.95. In this case, All the products have left the stock
(stock valuation is zero), but 5 cents remain on the account.

This is of course even worse the higher the ratio is. For example, a
box of 4.00 split into 1000 units sold piece by piece will never be
recorded when a product leaves the stock.

The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost

opw-675222

The precision of `former_cost_per_unit` should not be set. Indeed, a
stock move can contain several quants with different unit prices.
Therefore, we should not round the field when stored, otherwise the
difference per unit will not be calculated correctly.

This is a workaround since we cannot change the DB structure in stable.

opw-675222

Use the normalized quantity, otherwise the amount per unit is wrongly
calculated.

Complement of f992c8ee,
to be reverted in saas-6+ and in 8.0 when Chrome's
fix reaches the stable Chrome channel.

Fixes #11629

See https://bugs.chromium.org/p/chromium/issues/detail?id=603507

Everything's displayed fine on orderlines with weighable products, this
only affected the small blue labels on the products.

opw-674264

In version 3, process.memory_info() returns only rss and vms
In version 4, it now returns rss, vms, shared, text, lib, data and dirty
Automatic unpacking is no longer possible in 4.0

Fixes #11052, Closes #11459

signature #11459

Closes #11639

Makes the fix in f992c8ee
specific to the view manager of the main oe_application
container, in order to avoid disrupting other view manager
occurrences (such as the ones in modal windows or x2many
list views).

Fixes #11629 (again)

Note: Hopefully the Blink team will fix Chrome so we can
get rid of this hack in the future:
  https://bugs.chromium.org/p/chromium/issues/detail?id=603507

When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.

Used case:

- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice

Before the fix: the asset was created twice.
After the fix: A warning is raised if an asset already exists for the invoice.

opw:674674

Chrome 50 treats percent-height divs inside of auto-height cells as
auto [1]. So from now on it's important that an explicit 'height: 100%' CSS
property is set on parent tds, otherwise you'll end up with elements
with a height of 0.

An extra difficulty is that this new height property on
subwindow-container will result in the element being as high as his
parent table. So the collapsed trick doesn't work anymore in the
customer list.

This has to be done conditionally. The proposed workaround of adding
100% height to parents of affected elements causes issues in IE/Edge
because the effect of adding a height in percent to a table-{cell,row}
element is not defined by CSS [2].

DO NOT FORWARD-PORT!

[1] https://chromium.googlesource.com/chromium/src/+/8876584335b48c99cf8df552ef4d8efebb131041
[2] http://stackoverflow.com/a/27384730

When canceling and clicking on "reset to draft" button a PO with
invoicing method = Based on generated draft invoice, the purchase
workflow led to a shipping exception.

To be in state done the PO must have:

All its PO lines invoiced with _set_po_lines_invoiced
All its incoming shipments done with test_moves_done

opw:673561

A 100% height is not distributed anymore to the children of a table-row
if they are not themselves table-cell in Chrome 50. This breaks the
indenpendent scrolling of the menu and the view manager.

However, setting the `table-cell` display breaks the layout in Internet
Explorer.

When the webclient is loaded by Chrome 50, we load a stylesheet
forcing a `table-cell` for display.

Seems to be related to https://bugs.chromium.org/p/chromium/issues/detail?id=353580
and https://chromium.googlesource.com/chromium/src.git/+/8876584335b48c99cf8df552ef4d8efebb131041

Related to e1a99192
Fixes #11629

or how to break every internet explorer releases while
attempting to fix chrome 50

Catching and hiding database transactional errors can
sometimes cause a POS order to be entirely lost.

When it occurs, the transaction won't be committed
into the database, and if there is only one order
in the batch, the server won't return any error to
the frontend POS which will consider the order saved.

This is very unlikely to be exploitable because the
alt-field usually comes from master data (e.g. product
names) that can't be injected.

Courtesy of Naglis Jonaitis

When creating an invoice from a contract with button "create invoices",
the description linked to the contract has to written in the comment field
of the invoice.

opw:671660

The height was not distributed anymore to the children of a `table-row`
element if they are not themselves `table-cell` elements.

Fixes #11629

Marks official support for the Raspberry Pi 3.

When the POSBox boots without a network cable attached it will
automatically launch a wireless AP that people can connect to. This
allows them to configure what wireless network the POSBox should connect
to.

This wireless AP was configured to use the 10.10.0.0/24 subnet. The AP
itself was on 10.10.0.1. Although this is fine if used as intended it is
a quick way to take down an existing network if you where to plug in an
ethernet cable after the wireless AP has started. 10.10.0.1 is commonly
used by routers all over the world and plugging in a booted POSBox into
their networks will cause serious issues because the POSBox will share
the same IP as the router.

This moves the POSBox AP to the 10.11.12.0/24 subnet, with the AP on
10.11.12.1.

This also makes the DHCP server listen only on wlan0 because otherwise
you can end up with two DHCP servers on the same network which would
still break stuff.

Useful when updates to the initialization scripts don't go as
planned. This leaves something to inspect.

The initialization script already automatically stops (because of 'set
-o errexit') but it was a bit tricky to actually see what went wrong
because scrollback in QEMU isn't great.

The main reason for doing this is supporting the new Raspberry Pi 3. No
functional changes where made.

For Raspbian Wheezy we used to download the full image and strip it as
best we could to obtain a reasonable image size for people to
download. Since Raspbian Jessie the Raspberry Pi Foundation has started
releasing an official minimal image (Raspbian Jessie Lite) which we will
use from now on to build our image. One downside of this is that the
minimal image is a 1.3 GiB image which is too small for our
purposes so it has to be resized.

Because Raspbian Jessie migrated to systemd we cannot rely on
/etc/init.d/rcS to set up the ramdisks anymore. Jessie provides a
compatibility layer so old SysVinit scripts still work but rcS does not
block like it does in a SysVinit system, it is run in parallel with
other startup services. In our case this is a bad thing as setting up
the ramdisks has to be done before any other services are started. To
accomplish this the rcS hack has been migrated to a systemd service
running before basic.target and with DefaultDependencies=no. This has a
similar effect as the rcS hack because normal systemd services (with
DefaultDependencies=yes) all require basic.target by default.

When processing a payment transaction, double-check the
match between the amount of the transaction and the
amount of the SO, to be sure that we won't be validating
a SO that has been modified since the payment.

Such cases have to be double-checked manually.

Also add a bit of extra logging to make auditing ecommerce
transactions easier.

In addition to being mostly useless because Paypal's API
changes are supposed to be backwards-compatible, this
warning was using inconsistent version numbers.

Switched to a simple INFO line with IPN version.

When the line is linked to an event ticket, the price must be taken
on the ticket.

Fixes #11521

opw:673176

Current behavior before PR: if you create a new record within a one2many
field and the model's form has a clickable status bar defined, clicking
this status bar will raise an exception because the virtual id
(one2many_v_XXXX) will be passed to the model's write method

Desired behavior after PR is merged: clicking just changes the cached
value

Users may sometimes need to edit their own partner records directly,
although indirect access by writing on `res.users` directly works
fine in most cases.

The SQL view `crm_partner_report_assign`
makes a join on `account_invoice_report`

A column is added to
`account_invoice_report` in the module
`sale` (`section_id` is added to the view),
making the SQL view `account_invoice_report`
replaced automatically at the install/update
of the `sale` module, which leads
to the automatic deletion of the SQL
view `crm_partner_report_assign`,
because the SQL view `account_invoice_report` is
altered.

Therefore, after the install/update of the `sale`
module, the view `crm_partner_report_assign` was
deleted, and the "partnership anaylsis" unusable.

This revision makes sure to init the
`crm.partner.report.assign` report after
every init of the `account.invoice.report`.

opw-674177