File variables.less is located in web/ in the community edition, but in
web_enterprise/ in the enterprise one.
This fix uses the template 'web.less_helpers' containing the correct version of
variables.less instead of directly include variables.less and utils.less.
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.
Mainly:
- JS refactoring and linting
- Conversion of .sass into .less split into multiple files
- Templates cleaning and DOM simplification
- Re-generation of web.pot, and update of .po files
When computing the domain to find the product available data, a special case
is currently managed when doing a child_of in locations. Indeed computing
product available data requires to check its related quants. It is possible
through the context to limitate the search to a given set of locations.
The location_id field on stock_quant model is set as auto_join. However the
use of auto_join with the child_of operator is currently not supported by
the ORM. Those parts are converted into (id, in, ids) equivalent domain leaf
that can be costly due to quants table being quite large. The existing code
in product.py therefore tries to manually optimize the quant computation
by computing manually domain with child_of, using parent_left and parent_right.
However there are some cases when parent_left and parent_right can be 0
notably in update mode. However the current code does not correctly take
into account some location not having parent left / right and other having
a parent left / right being still 0 because still not computed. This commit
fixes that, allowing the correct computation of available product data in
update mode.
This limitation has been spotted when migrating stock to the new API. Indeed
unit tests have been added. In those tests product available info was not
correctly computed. Those tests will come when merging the new API version of
stock.
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
pos.config had a special state field that mimiced what we usually do
with an 'active' field. The concepts of 'inactive' and 'deprecated' seem
to have never been fully worked out, as both of them resulted in the
same behaviour.
Before this the table edit handles where quite small. This was no
problem when editing a floor layout with a mouse or perhaps with a
stylus on a touchscreen. It was however very difficult to do with your
finger on a touchscreen.
This increases the size of the handles by a factor of 3. To make room
for this the 4 handles on the sides (non-corner ones) have been removed
on square tables since you can technically do any operation you want
with just the corner handles. The only functionality we lose is resizing
a table while constraining it's width/height, but if such fine grained
control is needed then the tables can still be edited in the backend.
Change the label of active state label from Activated to Confirmed. Indeed
it indicates the user logged itself at least once. Active / Inactive is
controlled through the active field. An user that logged once is non labelled
as confirmed.
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
[IMP] account: d'ont create journal items for invoice lines with quantity 0 (not amount because of tax)
[IMP] crm: usability kanban view and schedule an activity
[FIX] crm: schedule an activity bug when no activity yet
[IMP] website: app for website (not a menu in website admin)
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
Aaron Bohy