This revision is related to eafebcb308
According to the `stock.move` fields definition:
`date` is the "scheduled date until move is done, then date of actual move processing"
`date_expected` is the "Scheduled date for the processing of this move"
The scheduled date of the product being produced in a
manufacturing order is the same scheduled date than written
on the manufacturing order.
opw-674237
When an user sends an email from the chatter then quickly switch to
another record, it may happen that this.composer is already destroyed.
We prevent to display a traceback with this fix.
The list view Column widget should be exposed, so it can be extended.
This is required to allow the creation of other kind of list widgets.
The _format method is not extendable if we don't add this line.
(comment from ged) The file list_view.js should be split in two, and
reorganized, but this should not be done in 9.0.
By default, users are supposed to be able to write messages
in threads only if they have the write access on the record.
This behavior is the behavior defined in Odoo 8.0.
This behavior can be changed by defining
`_mail_post_access` on the model,
to allow the creation of new messages
if the user has only the read access, for instance.
This is the case on `project.issue`, for instance.
Since 9.0, @ revision 88b8cd0587,
this behavior was broken: Any users having the read
access on the record was allowed to write messages in the thread,
while this should not be the case, except if
`_mail_post_access = 'read'`
has been defined on the model.
This is because the SQL query which is performed in order
to know the thread messages the user has been notified of
was expected to return only the ids of the notified message,
while it actually always returned all the message ids of the thread,
because of the LEFT JOINS, e.g.
```
LEFT JOIN "mail_message_res_partner_rel" partner_rel
ON partner_rel.mail_message_id = m.id AND partner_rel.res_partner_id = (%%s)
```
Instead of just checking the ids of the messages returned by this
query, it must check that one of the two columns
`partner_rel.res_partner_id` or `channel_partner.partner_id`
is filled, meaning the partner has been notified of the message or
is a member of the channel the message has been posted to.
opw-668589
e8a00bc50d moved the get_file function
from web.session to web.ajax. The issue is that get_file uses
session.url() for iOS devices. Also, in order to prevent an infinite
spinner options.complete() is called before actually opening up the new
window. Although this resolves the issue it still requires the user to
configure Safari to allow pop-ups, otherwise they are silently ignored.
opw-672882
Forward-port of saas-6 77dae4c9c5.
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].
[1] https://chromium.googlesource.com/chromium/src/+/8876584335b48c99cf8df552ef4d8efebb131041
[2] http://stackoverflow.com/a/27384730
Forward-port of v8 9fa53b7ee7.
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
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
Provide the possibility for the taxes
label on invoices to be translated.
In other words,
to give the possibility for the taxes labels
in the invoice report to be translated in the invoice
lines
(e.g. 21% VAT in English, 21% BTW in Dutch,
in the invoice lines)
opw-675038
The tax description in the taxes lines
(e.g. in invoices) is supposed
to be translated in the customer/supplier language,
as this is what is displayed in the printed reports
sent to the customer.
This is the behavior in place in Odoo 7.0 & 8.0.
(e.g. in invoices)
opw-675038
The "Due Date" is invisible in the tree view because in most cases, the
`journal_type` is not in the context. Since it was shown all the time in
v8, we show as well.
opw-674815
When an invoice is cancelled, the attachments (including the printed
invoice) are not deleted. If the users resets the invoice to draft,
modify it, then print it again, the previously generated document will
be used instead.
opw-674678
The `account.voucher` field `date` was twice in the view
`view_purchase_receipt_form`
Besides the fact the field was twice in the view,
this prevented to set a date in the past
for the resulting journal entries,
as the second field `date` input of the view
contained the date of today, while
only the first one was visible and editable
by the user, and it was the second field
value which was took into account when
passing the form values to the server,
most-likely because this second field was set
further in the view.
opw-674712
The method `create_exchange_rate_entry` is called
either if one of the two parameter
`amount_diff` or `diff_in_currency` is not equal to 0.0
(or, near to zero, `float_is_zero`):
```
if currency and aml_to_balance \
and (float_is_zero(total_amount_currency, precision_rounding=currency.rounding) \
or float_compare(total_debit, total_credit, precision_rounding=currency.rounding) == 0):
```
Nevertheless, the method is called with the amounts not rounded,
and, therefore, one could be considered to 0.0 (if
closed to 0.0) but not be exactly equal to 0.00,
and it should therefore be rounded before the entries
creation.
opw-673854
In non grouped mode, a recent fix (fixing race condition in do_search)
introduced a new bug, the dataset size is not correctly set.
This is a quick and dirty fix, I believe that changing the dataset
internals like this commit (and other) do is really not correct.
However, the correct fix (working on the dataset API) is more dangerous
in a stable release.
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
Rounding the unit price at that moment is a bad idea. Here is the use
case:
- Set the product 'Costing Method' to 'Real Price'
- Set the product 'Inventory Valuation' to 'Perpetual'
- Receive through a PO 9 products for a unit price of 115.80
- Receive through a PO 35 products for a unit price of 116.80
- Sell these 44 products thanks to a SO, generate and validate the
invoice
On the Stock Output Account, the following entries will be generated:
- First PO --> 1042.20 = 9 * 115.80
- Second PO --> 4088.00 = 35 * 116.80
- Invoice --> 5130.22 = 44 * 116.596
116.596 is the average price of the two POs, but rounded. The issue is
that there are 2 cents of difference... Nice ;-)
The fix is to avoid the rounding of the unit price, since we don't even
store it on the account move line anyway.
opw-673976
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.
Following commit 8276fb585, the data exported should match the data
displayed on the list view. Therefore, we need to make sure that the
context used match the context of the list view.
When a filter is applied in the list view, the context is evaluated
thanks to pyeval (see the call to `/web/dataset/search_read`). The fix
is to evaluate the context in a similar way.
opw-674473