When we validate a SO with an MTO product, then an RFQ and a delivery
picking are created. The status of the delivery picking is in state
'confirmed', but should be 'waiting' as the delivery waits for a
specific delivery input.
The problem is caused by the unreserve method, which is called in the
'procurement_jit' module. This method only checks that a move has
ancestors to determine if the move should be in waiting or in confirmed,
which is not the case for our delivery move because the RFQ has not been
validated yet so there is not ancestors yet.
To fix this issue, we check the 'procure_method' of the move, and if it
is in 'make_to_order' we put it in 'waiting' instead of 'confirmed'.
We also fixed the function recalculate_move_state that could cause the
same problem.
Steps to reproduce:
-Create a PO with two lines L1 and L2
-L1 has product P with qty=10 for a scheduled date=23/07/2017
-L2 has product P with qty=10 for a scheduled date=30/07/2017
-Confirm the PO
When delivering 5P of L1, the scheduled date of the picking is the
right date which is 23/07/2017
But when delivering the other 5P of L1, the scheduled date of the
second picking was 30/07/2017 instead of 23/07/2017.
opw:752192
On online quotations, a left menu is automatically generated on page
load by searching for the <h1/> and <h2/> elements in the page. This
also considered the empty ones which do not make sense and were
breaking the menu's layout. Ideally, there should not be any empty
title in the page.
opw-752764
When unlinking payment terms, the ir.property records linked to
the fields "property_payment_term_id" and "property_supplier_payment_term_id"
were not deleted.
opw:749459
- Set the currency precision to 0.05
- Print any QWeb report displaying amounts, e.g. the GL
The amounts are displayed with 1 digit precision instead of 2.
The formula used to compute the decimal places is actually wrong. The
correct one can be found in method `_decimal_places`. Anyway, we can use
directly the field.
opw-752283
On the CRM dashboard, the shortcut 'exp. closing' is the same than the
'overdue' shortcut. However, the number of opportunities in these
categories is computed differently (see method
`retrieve_sales_dashboard`).
We introduce a new filter "Overdue Opportunities" which reflects this
difference.
Backport of 9d2f48dc7f
opw-704173
opw-751165
- Use the form builder to send an email
- Customize the snippet to include the subject and the body
- Send a mail
=> The subject is not included in the email
This is because the subject is filtered out and considered as a
blacklisted field.
It happens because `mail.mail` inherits from `mail.message`. The field
property `website_form_blacklisted` is set to:
- `True` for `mail.mail`
- `False` for `mail.message`
Since we go through all inherited models, the property on `mail.mail` is
overriden by the property on `mail.message`.
It is actually not necessary to go through all inherited models, since
in the case of `inherits`, we copy the fields of the inherited model to
the target model. The check is simplified by only checking the fields of
the current model.
Based on work of @nla-odoo
opw-748926
- use datas of all lines, and not only the last lines.
- removed useless 'move_id' field from account.move.line
Was PR #18175. Courtesy of Sylvain Legal
From Pillow 4.2, it is forbidden to save RGBA images as JPEG
( https://github.com/python-pillow/Pillow/commit/e4d6223c944cf44c468cc65a560b94dfcf351a62 )
A crash was occurring when loading demo JPGs as
image_resize_and_sharpen() was silently changing image mode to RGBA.
Now we ensure that we return the original image mode.
We also avoid crashes when converting from PNG to JPG
Rev. 8245c1d1d8 introduced a timeout to
avoid lockup situations with wkhtmltopdf's requests on servers with low
numbers of free HTTP workers.
The initial timeout of 500ms was chosen based on average network
latency, but turned out to cause spurious disconnections on congested
networks combined with slow links.
Bumping up the timeout to 2s seems to be a better sweet spot, causing
less spurious disconnections while still recovering reasonably fast from
the wkhtmltopdf lockup situation.
See also these discussions:
- https://github.com/odoo/odoo/commit/8245c1d1d87b443701b161d8d4a42df2b4d13aec#commitcomment-22904347
- PR #12356
- Issue #2114Closes#17998
When opening the reconciliation widget, there are two queries that are done,
The first one is to find a move line that perfectly match the statement line
and is done in SQL for performance issue.
The second one is a search with a domain to find all the lines that could be used
in that reconciliation.
1) There was a mismatch between the two. The domain fetches lines that have a payment_id
while the SQL query does not. Which is inconsistent
2) In some case, we did not find a perfect match on the amount using the SQL query because
of a rounding error. Example is for amount 3,3. In python: 3,3 is represented like this
3,3000000000003 and doing a float_round of that value still returns 3,3000000000003
Since we want to match on an exact amount, using float_repr is needed to fix that error
If the website default language is not en_US, qweb fields are not
translatable in en_US (and thus can't be translated) because:
- the code expected en_US to be the default language.
- there was a error in website _dispatch
opw-746776
closes#17939
In an invoice, the modification of an invoice line triggers the complete
recomputation of the tax lines. However, it also deletes any manual
taxes that could have been set (e.g. on vendor bills).
Courtesy of @jjscarafia
Closes#17885
opw-749323
Really apply commit a9ce4ffb22 to POS orders.
Since the creation of a POS order in the backend is a feature which
nearly not used, we rewrite everything related to onchanges. To avoid
breaking the compatibility, the old onchange code is kept. As long as
the user doesn't upgrade the module it will be used instead of the new
onchange.
opw-746827
Christophe Simonis