'Write-Off' is not an appropriate label when the payment is reconciled.
A write off (aka. bad debt) is when I emitted an invoice, delivered a
service, and never got paid for it entirely.
opw-672716
This revision corrects a regression introduced by
8395f0d217:
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 "From" should not be the administrator user but
the postmaster/system, and should be an address that
ignores double-bounces. Using the default bounce
email accomplishes both.
- The "To" recipient should be the "envelope from"
sender when available, usually as provided by
the "Return-Path" header set by the upstream MTA.
If not present, fall back to the "From" of
the original email.
- adapt tests to verify the behavior wrt Return-Path
When the stage name is too long, the column header is messed up: the
'Settings' and the 'Quick Add' icons are located outside of the column.
The fix is to truncate stage names when they are too long.
opw-672710
When clicking on the "Refunds" link of a
Sale / Purchase invoices journal,
creating a new invoice did not create
a new refund invoice, but a normal invoice.
opw-675408
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
The above revision allow to edit an event with a start date
greater than the stop date.
This issue was solved by the revision
6c78541978
that the above revision reverts.
The reason why the constraint on
`event.start` and `event.stop` was replaced
by a constraint on
`event.start_datetime` and `event.stop_datetime`
and
`event.start_date` and `event.stop_date` are explained
in 6c78541978:
Basically, `start` and `stop` are computed fields,
that are not recomputed in time, before the constraint is checked.
Besides, the revision b7e393a71a
re-set the constraint on `start` and `stop`, but forget
to replace the fields in the constraint definition:
```
(_check_closing_date, 'Error ! End date cannot be set before start date.',
['start_datetime', 'stop_datetime', 'start_date', 'stop_date'])
```
opw-673297
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.
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
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.
Nicolas Martinelli