When creating an customer invoice with a product linked to a deferred revenue
category, the account used in the invoice line must be the account_asset_id.
When creating an vendor bill with a product linked to an asset
category, the account used in the invoice line must be the account_depreciation_id.
opw:22157
Previous forward-port (17b6191a02) includes
new tests (added by eb26694e0f) which are
now broken because quants with a cost of zero are forbidden.
Force a standard_price on created product to avoid this situation.
Adapt quants cost values.
Also change references of accounts and journals on records.
The read_slice method in dataset is problematic, because it alters the
dataset ids. So, if 2 consecutive read_slice are started, but the first
one ends after the second one, we don't have the correct ids in the
dataset.
This commit just make sure that previous read_slice do not alter the ids
of the next read_slice.
These 2 commits in kanban view fixed 1 bug by introducing a few other
severe bugs. The tradeoff is not worth it, especially when it is
balanced again deleting some contacts in your database.
Adding date & datetime inputs in the website
form builder couldn't work, because
the posted values for these input
types were not treated at all,
and they were not in the format
the date/datetime were stored in database.
opw-672674
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
When importing a quotation,
if the lines `name`, `price_unit`, `product_uom` or `tax_id`
are not specified, but the product is,
retrieve them from the product `on_change`
This was the case in Odoo 8.0,
it was done as well in the override `create` method
of `sale.order.line`
opw-675434
The location name get is computed as:
`parent.name + '/' + child.name`
While, the complete was computed as:
`parent.name + ' / ' + child.name`
This leaded to an obvious inconsistency.
Besides, this prevented to use the `location`
filter in the search of the products list to
know the quantity available of products for
a specifc location, as the domain used
to retrieve the locations is set as
`[('complete_name','ilike',context['location'])]`
`context['location']` containing the content of the `name_get`
(No spaces surrounding `/`)
and
`complete_name` surrounding `/` with spaces.
opw-674378
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
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
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 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
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
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
Goffin Simon