If multiple transactions start knowing that they should generate the
bundle, each one will run lessc and create a ir.attachment record
referencing the path on the filestore. While the file is not duplicated
on the filestore (as it is stored according to its hash), the final
result of `t-call-assets` will source multiple time the same file.
This patch fixes this issue by adapting get_attachment to group its
results by file name and only select the one with the max id (latest
generated).
We also remove the `inc` argument as it is not used.
Commit 4326d864 removes the inverse function of the `date_planned`. This
is necessary to avoid unexpected changes of the scheduled dates.
However, this removes the ability to set the scheduled dates of all
lines at once.
This commit introduces back the functionality thanks to a new button.
This way, the functionality remains without unexpected behavior.
when we unreconcile an entry, amount_residual is not recompute due to missing dependencies. Resulting in problem when trying to reconcile the move later on as amount_residual is zero and aml is considered already reconciled
The previous fix didn't take into account the fact that some parts
of the file can truly be empty. Because of this, you end up with
'0,00' in some date fields.
This commit fixes a bug introduced by the forward port 1fca5e01cb.
In saas-11, the commit f970906c9e introduced the 'assets' value
for the debug mode, to active the assets splitting. To do that, the
commit had to stop the conversion to a boolean of the debug value
(initially introduced by commit 522dec2fcd).
The problem is that the forward port mentionned above did not resolve
correctly the conflict for the commit 3455daf948, reintroducing the
boolean conversion.
The menu `account.menu_finance` is named "Invoicing" in account and renamed
"Accounting" in account_accountant.
The renaming introduce 2 translations that are both in account.pot (as the
translation of an object is based on the module that created it, deduced from
the external id, here account).
When installing account module, two translations for the same item are loaded.
Remove one of the translation (keeping "Accounting" as it is probably what most
people using accounting will have) to avoid uncertainty from a duplicated
translation.
A correct fix would be to avoid renaming the module (will be done in master).
opw-683314
When the General Ledger is printed, the initial balance is zero if the
filtering is done by period.
It appears that in this case, the method `_query_get` selects all the
periods before the selected period range thanks to:
`build_ctx_periods(cr, uid, first_period, context['period_from'])`
On the other hand, `_query_get` builds the query as:
`date_start <= %(date_start)s AND id NOT IN %(period_ids)s`
That doesn't make sense since we first choose the periods before the
selected period range, then we exclude them. What the method
`_query_get` is doing seems wrong, but since this method is used in many
reports, it is safer to only fix the GL report directly.
Another solution could be
https://gist.github.com/nim-odoo/453176d9ae820615e69f9a809a3780cc
opw-681601
The aml.balance in the sql request is null, so the string encoding
fails with an error. This is a quick fix because the customer needs
this report for tomorrow, but a proper fix is required !
Allow to round the duration to a minimal unit.
Eg:
0.33 hour = 19.8 min = "19 minutes 48 seconds"
if option {'widget'='duration', 'unit'='hour', 'round'='minute'}
0.33 hour => 20 min = "20 minutes"
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.
Gourav Chawla