Let's consider 4 products P0, P1, P2 and P3 where:
- P0 depends on P1, P2 and P3
- P1 depends on P2 and P3
- P2 depends on P3
NB: "x depends on y" means that there is a phantom BOM for x where
y is in a line.
With this example, before the fix, when creating a MO for P0,
the function "explode" raised a user error saying that there
was a recursion error.
Even if in this case there was no recursion.
Now to check if there is a recursion, a graph of the dependencies of
the bom is created while exploding the boms and a function "isCyclic"
is applied on the graph to verify that there is no cycle which means
no recursion in the dependencies.
The algorithm was taken from this site: http://www.geeksforgeeks.org/detect-cycle-in-a-graph/
opw:745453
When several user run a production on a workorder, things go awry.
For example the end of the "productive" production is computed based on
ProductiveStartTime + DurationExpected - Duration
so if the duration was bigger than the time expected, we easily get a
productive end before the start, and start of the "reduced speed" before
the production actually happened.
eg:
productive time is 30 minutes
user A: start production at 10:00
user B: start production at 10:10
production is set to done at 10:50
=> result before the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has been productive from 10:10 to 10:00
user B has not been productive from 10:00 to 10:50
this is totally erroneous.
=> result after the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has not been productive from 10:10 to 10:50
this is a measure of right, we could argue about wether one or the other
should be productive or not but this is anyway an edge case.
In master we are considering only allowing one user to run a production
at a time but we prefer not to change such a behavior in stable version.
opw-709223
closes#17528
When the user processes a picking with a large amount of pack operations
but validates a few lines (the remaining goes to a backorder), the
operation can fail due to timeout.
Closes#17670
Set up:
- Use the usual working schedule from 8:00 to 12:00 and 13:00 to 17:00.
- Set the OS and user TZ to Australia/Sidney TZ (restart your browser)
- Create a BOM with 3 work orders, taking 1, 2 and 3 minutes (you can
use the 'Assemble Furniture' routing)
- Create a MO using the previously created BOM, e.g. for '[FURN001]
Computer Desk'
Case 1: Plan to start the next day at 08:00, e.g. 2017-06-08
The result is amazing. The system probably hit a flaw in the space-time
continuum, which can only be explained with M-theory:
- WO1 is planned from 2017-06-08 08:00:00 to 2017-06-07 08:01:00
- WO2 is planned from 2017-06-07 08:01:00 to 2017-06-06 08:02:00
- WO3 is planned from 2017-06-06 08:02:00 to 2017-06-05 08:03:00
Case 2: Plan to start the next day at 11:00, e.g. 2017-06-08
Once again, the result is literally a piece of art:
- WO1 is planned from 2017-06-08 11:00:00 to 2017-06-08 08:01:00
- WO2 is planned from 2017-06-08 08:01:00 to 2017-06-07 08:02:00
- WO3 is planned from 2017-06-07 08:02:00 to 2017-06-06 08:03:00
To solve the problem, a first commit is made in MRP to force the end
date to be larger than the start date. That hides the issue, but it
doesn't solve it.
To prevent the system to hit the 88 mph and go back in time, we force a
'hard limit' to prevent any selection of intervals starting before the
requested start time.
opw-745905
Version 2.7.1 is not yet available in most distributions,
but is now considered the recommended version.
Odoo will work just fine with any psycopg2 version >= 2.2, though.
- Set your timezone in Brasil
- Install the Maintenance module
- Create a Maintenance Request, set the Requested Date to 2017-06-15
- Save
In the chatter, the track fields message shows a Requested Date of
2017-06-14.
This can actually happen with any date tracked. The issue comes from the
web client: it converts the date in UTC, which should of course not be
done. This only applies for a datetime, not for a date.
opw-746216
Before this commit, the JS parser would add 0 after the input, then add the ean key.
Whereas reportlab.graphics.barcode fills the input with 0's on the left, then add the key
http://pydoc.net/Python/reportlab/2.5/reportlab.graphics.barcode.eanbc/
At: Ean13BarcodeWidget.__init__()
This commit makes the ean parser coherent with the lib the python uses
It is still possible to have negative and positive quants in the same
location because of returns: if you send something to the customer that
is not there and you return it, you will still be able to reserve the
returned goods to send to another client.
Before, if you would do an inventory adjustment, it would not take into
account these returned quants and their negative counterpart, which made
them difficult to get out of the system.
This fix takes them into account by creating two movements for one
inventory line: move the positive counterpart to the inventory location
before getting back from this location the same quantity.
This way, even if you have 0 as quantity on hand but you have those 2
quants, it will eliminate them. (if you are increasing the stock, part
of the process might have done it automatically already).
Test cases contributed by @jir-odoo
Cherry-pick of be9dce625c
NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
Jeremy Kersten