Use of '_for_xml_id' instead of read in order to avoid
access right issue on 'ir.actions.act_window'.
closesodoo/odoo#60946
X-original-commit: 4e65fbf14491ea97415ede6d10385222c8d4d074
Signed-off-by: ndeodoo <ndeodoo@users.noreply.github.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In this commit, we ensure that the vat is
added to the company data if an error occured
when contacting iap-services.
task~2092378
closesodoo/odoo#57335
X-original-commit: 848733b758063307bbbbf69eee10cd2426e9c017
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
If "force_create" is false and no account was
previously create, the function will raise an
error. With this fix, an empty recordset is
returned.
closesodoo/odoo#35664
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
For each asset depreciation lines we verify that there are not linked
to a move. This verification was done for each line separately.
Moreover, during the creation of the journal entries, we were writing
on the 'line_ids'. In this case, accessing the move of a line
was invalidating the cache. This fix ensure that this operation is
done out of the loop and the cache is then not invalidated at each
step.
See opw-2000305
closesodoo/odoo#33908
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the payment memo was copied during the duplication
of a voucher. The issue is that the payment memo is not always shown in
the view, and it's mostly unique by voucher.
Now, the payment memo it's not copied anymore.
opw-1986544
closesodoo/odoo#33708
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The "company_id" fields for the iap account has
been changed by the "company_ids" fields to allow
the use of an iap account with multiple company.
closesodoo/odoo#35093
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Rounding each element of the sum decrease the
precision and prevent to reconcile large recordset.
closesodoo/odoo#33100
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
On the ticket 1961412, the custommer has more than 12 millions
of stock moves. Before this commit, the search request does
not take too much time to execute but fetching the fields on the
recordset takes a lot of time due to the 'in' in the where clause
of the associated SQL request.
This optimization permit to avoid this 'where clause' and decrease
the time to gather all the different fields. The time has been reduce
to less than one minutes where it takes approximately 20 minutes before.
closesodoo/odoo#32520
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, the fields qty_reserved and
qty_done were displayed in the wizard with a
precision of two digits (for each case).
The problem is that the qty_to consume uses the
precision accuracy defined in 'Product Unit of Measure'.
It resulted that a quantity of 0.002 to consume
was translated to a qty_done of 0.0.
See opw-1949198
closesodoo/odoo#31822
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The generation of the deffered revenues took initially 471s.This
improvement permit to reduce the time to 72s (behave Cprofiler).
The issue was related to the fact that all the message post and logs
invalids the cache. It results that several read requests were
repeated multiple times.
closesodoo/odoo#31750
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
In some case, when the user enter by mistake an account move line
with an amount of 0,the reverse operation does not works properly.
The issue happenned during the reverse operation because it tries to
reconcile a 0 account move line with no matches (credit or debit).
See opw-1931961
When analysing the code thanks to Pyflame it cames that the 'prefetch_fields()'
function was runing most of the time. In order to improve the global performance,
I change the context of the move_lines : 'prefetch_fields = False'. It permit to reduce the
time of computation of the prefetch_fields and to avoid the MemoryError.
N.B.: The database of the customer (on saas) contains 1.3 millions of entry and to reproduce the issue
I have to set the HardMemlimit to 0.9 Go and the SoftMemLimit to 0.5Go.
OPW-1910422
closesodoo/odoo#29231
In some case, this view was used to perform a search of product.product.
Before, this modificiation all the search view had the same priority
which means that depending on some situation, the wrong search view was
loaded.
opw-1903611
closesodoo/odoo#28634
The issue happened when a user which does not have access to some fiscal
position try to print a sale order. In this case a traceback is generated.
In order to avoid the traceback and to be able to print the report
the access rights are bypass thanks to a sudo() in the report.
OPW-1943727
closesodoo/odoo#31357
Nathan de Pryck