This revision corrects a regression introduced by
8395f0d217e16df18fcc6f4309fe74b0dd8d50a2:
the possibility to call
`ir.qweb.field.datetime`.`value_to_html` with
a datetime string directly, instead of calling
`ir.qweb.field.datetime`.`record_to_html`
(which call `value_to_html` as well).
opw-675427
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
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
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
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
Makes the fix in f992c8ee19
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 setting rules on models having o2m/m2m relationship
between each other
e.g.
- `res.partner`:
o2m `sale_order_ids` to `sale.order`
- `sale.order`
o2m `message_follower_ids` to `res.partner`
an infinite loop could occur if records
of these models referenced records of the
other models in their o2m relationships
e.g.
- `res.partner` ID 68:
`sale.order` ID 9 in its `sale_order_ids`
- `sale.order` ID 9:
`res.partner` ID 68 in its `message_partner_ids`
This revision solves this use case, by passing the already
treated records in the context and checking that the records
haven't yet be treated before making the recursive call.
This revision makes sure to not break the API of methods
`get_data_context` and `prepare_audittrail_log_line`
(a new parameter had to be introduced for the above purpose)
opw-670904
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] 8876584335
[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
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.
DO NOT FORWARD-PORT!
[1] 8876584335
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 8876584335
Related to e1a99192bdFixes#11629
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
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.
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
request.website.get_languages returns a list of tuple in the form:
(`language code`, `language name`)
With this commit the code first check if there is a language exactly
matching, and only if failed check if there is a match on the short
form.
closes#11613
opw-672412
Levent Karakas
Levent Karakas
Denis Ledoux
Goffin Simon
Nicolas Martinelli
oihane
Olivier Dony
Joren Van Onder
Stephen Medina
Eduardo Rodríguez Crespo
Stefan Rijnhart
Simon Lejeune
Holger Brunn
Odoo Translation Bot
Nicolas Lempereur
Jos De Graeve
Xavier Morel
Alexandre Fayolle