product_taxes_rel is the many2many table between
product.template and account.tax
product_id on the POS order line is a product.product.
Therefore, the join on product_taxes_rel should
be done using the product.template id of
the product on the pos order line, and
not directly the product.product id.
opw-632720
VAT error shouldn't be displayed as it doesn't look deep enough for information.
It is better to raise this kind of exception at the creation of a VAT than at its use.
opw:631769
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
Enhance current widget="monetary" client-side feature and
convert it to a first-class type of field, allowing proper
server-side behavior.
- fields: add field.Monetary, similar to fields.Float but
supporting a `currency_field` attribute instead of the
decimal_precision attribute.
`currency_field` indicates the field holding the
related currency on the same record.
The symbol of that currency is used when displaying
the field, and the rounding of the currency is applied
instead of the usual decimal precision.
- avoids application of a second decimal precision rounding,
as was the case when the model field was a `fields.float`.
- removes the need for adding explicit boilerplate to each
view containing a monetary field, i.e.:
widget="monetary" options="{'currency_field': 'currency_id'}"
- res.currency: add new field decimal_places needed to round
value at the correct decimal places
- web: cache all currencies, rounding and symbols at
webclient startup to speedup monetary fields
- new widget monetary for list view + adapt widget monetary
on form view
Limitations:
- if the currency_field is a related field, the server-side
application of currency rounding will only work when the
record already exists, not during creation (to be fixed)
- this field is only supported in the new API
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
Goffin Simon