Before this patch, the debian package depends on `python-pybabel`.
According to the documentation, this is a dummy package for transition
from `python-pybabel` to `python-babel`[1].
This dummy package has thus been removed in debian stretch in favor of
`python-babel`, and the odoo package is thus not installable in debian
stretch.
To fix this, we depend directly on `python-babel`, which is available in
all debian releases[2].
Closes#13905
[1] https://packages.debian.org/jessie/python-pybabel
[2] https://packages.debian.org/jessie/python-babel
Underscore method _.each expects an array like object when a
"length" property is present.
This was an issue with a record having a numeric "length" field set
to a non-negative value.
opw-691070
The `map_account()` method expects a browse_record as
parameter, and returns a browse_record (possibly the
argument if no mapping happened).
It was being called with an account ID instead, so
fiscal position mapping would never match, and would
always return the argument itself.
The `fiscal_position_id` field actually depends on both
the `shipping_partner_id` and the `partner_id` field,
not just the former.
Theoretically the recompute should trigger on both fields
anyway because changing the `partner_id` will automatically
change the `shipping_partner_id`.
Unfortunately this onchange chaining does not work as expected
as of Odoo 9, at least when the `partner_id` field is set
to the same value (was done for optimization reasons).
This special case really happens when you edit the Partner
from a sales order form view, and save the changes.
It triggers a "dummy on_change" for the `partner_id`
value, with the same value as before.
If the edit changed the fiscal position or another
field on which it depends, a recompute is really needed.
Adding the direct dependency works around this limitation,
and is semantically valid, too.
An extra fix of this special case in the framework might still
be nice to have, though.
Ref: feedback ID 29042
Underscore method _.each expects an array like object when a "length"
property is present.
This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.
This issue was fixed with 0e664c9e9 but introduced back with f0e331e00.
opw-691070
Without this, odoo log outputs to stdout and is catched by journald. We
force the use of a log file to keep the behavior consistent with the
debian package.
This fixes the problem of recomputing that field in a much better way. The
field was stored for the sake of searching; instead we implemented a search
method for it.
This is related to revision
b65c67a259
The field `seller_ids` is a field which is set
on the `product.template`, and this is why
the condition `(x.product_id == product)` is being applied
in the list comprehension searching the current seller
of the product sellers.
The `variant` variable is a string containing
the attribute name of a variant.
Therefore, if a product tempalte has only one variant, without
any attribute (e.g. when you don't use variants),
`variant` will be empty, and therefore the condition
`if variant:` will be `False`, and therefore it won't search
in the product sellers with a specific `product.product`, while it
should, as, even if there are no attributes, there could be a
seller line with this specific `product.product`.
Besides, as we are in the `name_get` of `product.product`, and
not the `name_get` of `product.template`, we are always in the case
of a `variant`, this test is therefore pointless.
opw-682390
These two fixes are now important since the ViewEditor is now also
used in the backend.
* The start method must return a deferred.
* The destroy method must unbind the event on the document element.
Note: in master, the ViewEditor is being refactored.
This grouping was causing problem at the time of bank statement reconciliation, if the expenses were set as already paid by the company, since we had only one account.move related to several bank statement lines although the DB structure wasn't allowing such a case (the link was made as a m2o from account.move to account.bank.statement.line where a m2m would have been needed).
Attendances (model hr.attendance) that overlapped different dates where not
computed correctly in timesheets (model hr_timesheet_sheet.sheet.day).
The difference in dates was not taken into account.
This commit fixes this issue; attendances are now linked with the check_in date
to hr_timesheet_sheet.sheet.day.
(so 8 hours recorded from 20:00 to 04:00 the next day will be recorded as
8 hours on the first day)
In the earlier fix 327f88df, the computation of the amount crashes when the
field `tax_id` is not set. Simply add an 'if' statement to avoid that case.
Case 1: To check schedule date of picking and manufacturing order,
- Configure lead times:
- At a product level set Manufacturing Lead Time and Customer Lead Time
- At a company level set Manufacturing Lead Time and Sales Safety Days
Case 2: To check schedule dates of pickings and manufacturing order,
- Configure lead times:
- At a product level set Manufacturing Lead Time and Customer Lead Time
- At a route level set delay of pull rules
Detailed Use Cases
==================
CASE 01 :
========
(Consider order date : 2016-04-18 11:10:44)
Create Product
--------------
Name : Product A
Product type : stockable
Manufacture : True
Make To Order : True
Manufacturing Lead Time : 5 days
Customer Lead Time : 5 days
Configure your company data
---------------------------
Manufacturing Lead Time : 3 days
Sales Safety Days : 3 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 10
Confirm this SO
Run scheduler
Result
------
Manufacure Order :-- Schedule date : 2016-04-12 11:10:44
Delivery Order :-- Schedule date : 2016-04-20 11:10:44
CASE 02 :
========
(Consider order date : 2016-04-18 11:10:44)
Create Product
--------------
Name : Product A
Product type : stockable
Manufacture : True
Make To Order : True
Manufacturing Lead Time : 5 days
Customer Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Outgoing Shippings : Pick + Pack + Ship
Routes
------
YourCompany: Pick + Pack + Ship
Procurement Rules:
------------------
WH: Output -> Customers :-- Delay : 2 days
WH: Packing Zone -> Output :-- Delay : 2 days
WH: Stock -> Packing Zone :-- Delay : 2 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 5
Confirm this SO
Run scheduler
Result
------
Manufacure Order :-- Schedule date : 2016-04-14 11:10:46
Delivery Orders :--
PICK :--> Schedule date : 2016-04-19 11:10:46
PACK :-> Schedule date : 2016-04-19 11:10:46
OUT :--> Schedule date : 2016-04-21 11:10:46
Case 1: To check schedule date of picking,
- Configure lead times:
- At a product level set Customer Lead Time
- At a company level set Sales Safety Days
Case 2: To check schedule dates of pickings,
- Configure lead times:
- At a product level set Customer Lead Time
- At a route level set delay of pull rules
Detailed Use Cases
==================
CASE 01 :
========
(Consider order date: 2016-04-18 05:34:00)
Create Product
--------------
Name : Product A
Product type : stockable
Customer Lead Time : 5 days
Configure your company data
---------------------------
Sales Safety Days : 3.00 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 10
Confirm this SO
Result
------
Delivery Order :-- Schedule date : 2016-04-20 05:34:00
CASE 02 :
========
(Consider order date: 2016-04-18 05:34:00)
Create Product
--------------
Name : Product A
Product type : stockable
Customer Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Outgoing Shippings : Pick + Pack + Ship
Routes
------
YourCompany: Pick + Pack + Ship
Procurement Rules:
------------------
WH: Output -> Customers :-- Delay : 2 days
WH: Packing Zone -> Output :-- Delay : 2 days
WH: Stock -> Packing Zone :-- Delay : 2 days
Create SO
---------
Customer : Asustek
Order Lines : Select Product A with Order Qty : 5
Confirm this SO
Result
------
Delivery Orders :--
PICK :--> Schedule date : 2016-04-17 05:34:28
PACK :-> Schedule date : 2016-04-19 05:34:28
OUT :--> Schedule date : 2016-04-21 05:34:28
Case 1: To check order date of purchase order and schedule dates of shipment and purchse order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a company level set Purchase Lead Time
Case 2: To check order date of purchase order and schedule dates of multiple purchase order line of the same purchase order,
we create two procurements for the two different product with same vendor and different Delivery Lead Time
Case 3: To check order date of purchase order and schedule dates of shipments and purchase order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a route level set delay of push rules
Detailed Use Cases
==================
Consider today's date = 2016-04-21 ( date_planned of procurement = today's date + 10 days)
CASE 01:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Configure your company data
---------------------------
Purchase Lead Time : 3.00 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 15.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-23 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 02:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Create another Product
----------------------
Name : Product B
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 2 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 10.00
Planned Date: 2016-05-01 00:00:00
Procurement Request for second product
--------------------------------------
Warehouse : YourCompany
Product : Product B
Quantity : 5.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-26 00:00:00
Schedule date of purchase order line for product A: 2016-05-01 00:00:00
Schedule date of purchase order line for product B: 2016-04-28 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 03:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Incoming shipments : three steps
Routes
------
YourCompany : Receipt in 3 steps
Push Rules:
-----------------
WH: Input -> Quality Control :-- Delay : 2 days
WH: Quality Control -> Stock :-- Delay : 2 days
Create Procurement:
-------------------
Product : Prosuct A
Quantity : 5.000
Warehouse : YourCompany
Procurement Location : WH/Input
Schedule date : 2016-05-01 10:30:43
Notes : 'Test scheduler for RFQ'
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-05-01 10:30:43
Order date: 2016-04-26 10:30:43
Incoming shipments schedule dates :--
In type :-- 2016-05-01 10:30:43
Internal type 1 :-- 2016-05-03 10:30:43
Internal type 2 :-- 2016-05-05 10:30:43
In the earlier fix 327f88df, the computation of the amount crashes when the
field `tax_id` is not set. Simply add an 'if' statement to avoid that case.
On the Customer invoice, Vendor Bills and Payments list views.
The feature exists for Journal Items and entries, but not on invoices and
payments.
Closes#13915Fixes#13914
Workflow was badly removed, before repair invoice method didn't make the stock
moves.
Corrected the issue and made the moves happen always at the end of reparation,
not when the repair reaches the done state (ambiguously named "Repaired").
- Hide life_time, use_time, removal_time and alert_time if tracking = no tracking
- Change the tooltip of these fields(life_time, use_time, removal_time, alert_time)
- Add filter 'Expiration Alert' on the Lot/Serial Number list view based on the lot/sn alert date
- Add a tag 'Expiration alert' when the alert_date is reached.
Currently all delivery methods are published after module installation. But if none is published we have an issue processing the checkout.
Free of charge : published by default
The other ones : unpublished by default
Grant the ability to publish delivery methods from the website for those who
have the access rights, in that case to sales manager with publication access rights.
Use the previous commit to display small buttons
qsm-odoo