On the Customer list, the request on `fields_view_get` takes 12 queries instead
of 62. Overall, it saves queries on every call to `fields_view_get`.
The cache is invalidated upon any creation/modification/deletion on models
'ir.values', 'ir.actions' and 'res.groups'.
* creating the huge builtins dict inline represents ~40% of safe_eval's
total cost according to line_profiler
* for the specific situation of opcodes, using a set difference is
apparently much faster than for+if. all(gencomp) is also faster than
for+if but not as much as letting Python do (almost) all of it
might be that returning a set from _get_opcodes would be even faster,
but didn't test it
When method `fields_view_get` retrieves the toolbar actions, let it `browse`
the actions to check instead of `read`ing them. This enables prefetching and
reuse of cached values.
On the list of Customers, `fields_view_get` takes 62 queries instead of 73.
During conversion to new API[1] the superuser bypass
was dropped in the computation of karma-based
permissions on forum posts.
The check still needs to be bypassed to avoid
blocking sudo() mode when the admin account
has a low karma.
sudo() mode is used for various actions done
by the system on behalf of the forum users,
and should not fail because the admin has less
karma than the user herself.
[1] See rev. 893d7fa864
Saves 2 requests per post, aka 20 requests on a full page (89 -> 68):
* don't create a new sudoed env and recordset for each post, create a
single one so prefetch can work
* don't do unnecessary sudoed access (.parent_id.create_uid without
reading any field)
* temp variables in template seems to save a few queries, not sure why
There's still a linear growth of requests wrt posts in the
page (single-post page has 56 queries), but it's a bit less terrible.
In previous versions the system would simply refuse to import
a bank statement if the corresponding journal/account did
not exist.
As of 9.0 the system can create them automatically, but
should not do that without asking for confirmation first,
to avoid user mistakes with dangerous consequences.
Closes#6023
_lang_data_get returns only numerical data, the website tends to need
date formatting stuff instead with one lang lookup for each date or
datetime formatting (via t-field).
Caching the id matching a lang code means one less query for each
date/datetime formatting on the website, that's 10 queries saved for the
default forum front page.
Added new field `event_based` for marking dynamic rules that need
to be re-evaluated even for leads that were checked previously
and did not match. (default: False)
If this field is not set to true, check only newer leads that
were never checked before, significantly speeding up the
check when there are hundreds of thousands of leads.
Closes#6019
Reduces the number of SQL queries needed to render a typical page.
Considering the low number of config parameters, we could probably cache
all the parameters for a user the first time one is requested (and not
in cache), really.
On the contact form with (almost) all website_* modules installed,
brings the number of queries from 21 back to the original 15 once caches
are warm.
The extra auth blows an environment and causes an extra query
of ``website`` before calling the controller.
The preceding two SQL queries likely can't be avoided: one uses uid1 to fetch
the current website's public user in order to set it, the other one
fetches the current website using the user set beforehand
By using get_object and not passing in the request's context, creates a
divergent environment from the one used in the rest of the request,
resulting to the cached menu items not being reused when displaying the
menu in the page (during qweb rendering), saves ~4 requests on the index
page (though probably nothing elsewhere)
date_open is not a required field of event.registration.
There is therefore very likely that this field could
not be defined. We should therefore not rely on the fact
it is always defined.
When trying to sent an event mail for an event registration
with a date_open not set (false), the email wasn't sent,
and it prevented the rest of the event mail queue to be
sent as well.
opw-632549
Backport of 8.0 code, rev f61339b
Create a new journal item with an tax included, the automatically created tax
line had the amount computed as tax excluded.
Fixes#3731, opw 618305
When changing the fiscal position of a sale.order, the taxes are recomputed
which means that total amounts may no longer be correct (need to press 'update'
button).
Reset the amount_* fields to force the recomputation at write.
Fixes lp:712772, opw 618419
"An external CSS files were included after an external JavaScript file in the document head.
To ensure CSS files are downloaded in parallel, always include external CSS before external JavaScript."
-- Chrome analyzer --
Each time a product is added in the cart, the qty of this product must be checked to
adjust the price if there is a rule (with min qty) in the partner's pricelist.
opw:630049
The `find` method will get the current accounting periode according to the
user's timezone while time do not. This means that it is possible that users
get a move with a date belongign to a different period that the one returned by
`find`.
Fixing b101808, linked to #4147, courtesy of Graeme Gellatly
contracts_count function field
&
journal_item_count function field
used for the "contracts" and "journal items" buttons
in the partner view are computed by the same
method.
But, this is possible that you have access to
one without having access to the other.
e.g., Project users not being salesman nor accountant
must have access to the contract counts,
but not to the journal items.
Besides, these buttons are added to the partner form
by two separated views, applied to analytic accounting group
& accountant group, respectively.
We therefore avoid to compute the journal items count when
not needed, when not loaded in the partner view.
We therefore prevent the access right issue, and provide
a performance improvment at the same time. Yay.
opw-632454
This module brands a view adding fields on the partner
form, after the field 'last_reconciliation_date'.
This field is added by the view
account.view_partner_property_form,
not by the view
base.view_partner_form
So, if the user do not have access to the view
account.view_partner_property_form, then
the field last_reconciliation_date wasn't in the view
and the inheriting view could be applied.
This inheritance worked only because
account.view_partner_property_form,
had no group applied, and the sequence
was lower.
opw-632454
- Support negative costs by creating reverse valuation move,
and undoing the quant computation.
This may or may not produce the exact reverse effect on
the quant, as it depends on the rounding of the unit
cost, which uses decimal precision 'Account'
- Hide 'compute' button when cost is not draft
- Forbid cancel of posted cost
- Forbid deletion of cost if not draft
If the default language of the visitor is not the default
language of the website
(If the default website lang is en_US, and the visitor
browser is configured in nl_NL, the default language
visitor will be nl_NL),
the go to cart button in the option modal was no
longer working.
This is related to revision a696913364
opw-632490
When generating the accounting entries, to compute the name, the invoice
reference (e.g. origin purchase order name) was first used before the supplier
invoice number. To facilate reconciliation of bank statements, the supplier
invoice number makes more sense.
Fixes#3839, opw 618765
* rename functional -> business
* fix navbarification of main toctree: would stop processing after it
hit the first toc item without children, and the business links (with
children) follow the web service toc item (without children)
Nicolas Martinelli