A misleading behavior occurs with the recomputation of scheduled date.
Here is the use case:
- Create a PO with 2 products
- For the product 1, set the scheduled date to today + 7 days
- For the product 2, set the scheduled date to today + 14 days
When saving, the scheduled date of product 2 is reset to today + 7 days.
This is of course unexpected, but moreover, a different behavior can
happen depending on how the scheduled dates are modified. In the
previous case (both products have now the same scheduled date), one can
observe 2 situations.
Case 1.
For the product 2, set the scheduled date to today + 14 days and save.
In this case, the scheduled date of product 2 is not reset.
Case 2.
- For the product 1, set the scheduled date to today + 8 days
- For the product 2, set the scheduled date to today + 14 days
In this case, the scheduled date of product 2 is reset to today + 8 days
when saving
The reason of a different behavior in the 2 situations is that the
scheduled date of the PO is changed in case 2 and not in case 1. Since
the scheduled date of the PO is changed, it triggers the inverse
function `_inverse_date_planned`.
When saving, it is not possible to know whether the scheduled date of
the PO was changed on purpose by the user or recomputed. There are 2
solutions to get a consistent behavior:
- Force the scheduled date of each line to be the same than the
scheduled date of the PO. However, this makes the scheduled date of
the line useless.
- Do not change the scheduled date of the lines when the schedued date
of the PO is changed. However, this removes the ability to reset
automatically the scheduled date of the all lines at once.
This is the second solution which is chosen with this commit.
opw-682934
opw-684063
Closes#12904
Before this patch, add_filter was called 2 times.
Once when we select a partner in the drop down, we trigger a onchange value
to change from false to the partner id.
Once to reset to false the value after the first add_filter()
This commit closes#9758
Steps to reproduce the bug:
-Create two companies A and B where A is the parent of B
-Admin is in A
-Demo is in B
-Create a partner P with Demo
-Create a user portal for P with Demo
Bug: Access error due to the fact that the user portal created for
P was created in SUPER_USER with company_ids and company_id set with
the same inforamtions as with Admin.
Fix: company_ids and company_id must be set with the company of Partner P
opw:682930
When the get_one_event_synchro crash, the status variable is not initialize.
So the return status, content, ... raise an error:
"local variable 'status' referenced before assignment"
This commit closes the issue #11513
Now we use the same decimal precision for cost in table 'Historization cost'
and 'product'.
It is one fix, but that will not fix the case where decimal precision has been
updated between 2 historizations.
This commit closes#12861
Prevent the padding of editor .btn's to change when a theme modifies
them (by mistake or not).
Once again, this is a problem of css isolation between the editor and
the website customization. A theme cannot safely, at this time, do
"#wrapwrap .btn" to isolate its rules because it may override some
bootstrap rules like ".btn-group .btn" which would became less
important. It cannot changes the bootstrap variables either as it is
still used by the odoo ui in some places.
There is no safe good solution to "share" bootstrap theming between
odoo ui and website ui. The safest solution is to force the design
of odoo ui elements that may be overridden by themes (in the end,
it's the same as progressively removing bootstrap from odoo ui).
The editor allows using background image options on snippets which
use a background-image. For this to work, the oe_img_bg css class
has to be on this snippet. The problem is that the class is absent
when using some themes as the select_class method removes it to place
its own value.
Now, the oe_img_bg class is (re)added when a select_class method is
used within the background image option.
When the module product_visible_discount is installed, the field
'discount_policy' allows to display the discount in the sale order or
allows to consider the discount as include in the price_unit.
The field price on product.product always compute the price according to
the pricelist then it always includes the discount in the price.
The field lst_price on product.product never compute the price according to
the pricelist then it always gives the sale price.
According to the discount_policy, the price or the lst_price must be taken.
opw:683771
Posted moves are not protected from modification if the journal is set
to 'autopost'.
If an account move is posted in a journal with 'Autopost' set, it is
possible to modify the associated move lines without any restriction.
This can for example lead to the creation of unbalanced moves.
The original issue fixed by this extra condition
(https://bugs.launchpad.net/openobject-addons/+bug/615268) does not
occur if the commit is reverted.
This reverts 4e95e4223Closes#12014
opw-683165
Old check was always ignored since 0 is False.
This commit closes#12715
Other fix; when we detach an event, we reset the rrule_type to avoid to have a
warning popup (about empty final_date) if the old one value was end_date.
In the account invoice the payments are shown and a popover with more
information is displayed when clicking on an (i) icon.
In this popover two buttons are available, but the used type of popover
disappear immediately when clicking on them, thus the buttons were
directly removed and would not work.
This commit add a delay when hiding the popover so the buttons
functionnality is not lost.
opw-680095
The welcome message was using the mt/mb classes to add some space on
top and bottom of it. This is fine when the background-color of the
website is white, but this is not the case with every theme.
To fix the problem, add padding in LESS instead. Also move the inline
style in LESS to prevent theme extension problems.
The accounting item generated from a PoS order does not contain the
related taxes. Although the accounting entry is globally correct since
the tax line is created manually, the tax should still be written on the
accounting item for reporting purpose.
Note that this is already the behavior when the accounting entry is
generated directly from an invoice.
Fixes#10855
Avoid wasting HTTP workers (in prefork server mode)
for pending/idle connections.
HTTP connections that have not sent anything for 500ms
will be dropped.
In particular, wkhtmltopdf uses a connection pool
to load remote resources. It opens more HTTP connections
than necessary and uses a random subset of them, leaving
the other idle.
On a server that has little available workers this
may significantly delay report rendering, and could
even lead to a deadlock.
OPW-667870
Similarly to werkzeug.urls.url_fix(), attempt to
correct some leftover special characters that
should have been URL-encoded.
We cannot actually use `werkzeug.urls.url_fix` or
`werkzeug.urls.url_quote`, as they expect more/most
characters to be un-encoded.
We have many existing cases where the redirect URL is
already fully encoded or mostly encoded, and those
functions would cause double-encoding, breaking the
final URL.
Similarly to werkzeug.urls.url_fix(), attempt to
correct some leftover special characters that
should have been URL-encoded.
We cannot actually use `werkzeug.urls.url_fix` or
`werkzeug.urls.url_quote`, as they expect more/most
characters to be un-encoded.
We have many existing cases where the redirect URL is
already fully encoded or mostly encoded, and those
functions would cause double-encoding, breaking the
final URL.
"total_invoiced" must only take customer invoices into account because
when you click on the button "invoiced" in the partner view form
you just see the customer invoices.
Adaptation for 8.0 of 9.0 fix made at 37569695Closes#12044
The pricelist report might show price incorrectly rounded. For example,
a calculated price of 20.625 will be displayed as 20.62 in the report
since `formatLang` does not apply a rounding but simply truncate the
value.
Fixes#12875
Rectify name conflict in tax templates between NZ and AU chart of
accounts. Otherwise, it's impossible to install both charts of accounts
at the same time.
Fixes#12600Closes#12758
The name field is the name of the product.template while the display_name will
contains the variant description and product code to allow to identitfy which
product.product is moved.
Closes#11311
Martin Trigaux