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
"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 --
Code from delete_page has been spliited (functions, templates, ...)
to be re-usable by rename_page
Change default input type from website.prompt.
Old default value 'text' had no sense, there are no tag <text>.
The pager was not displayed in One2Many List views. This fix applies the
same behavior as in One2Many Kanban views, which is probably not the
best way to do it, but which works fine.
The issue was caused by 2 things:
- The One2Many.FormView template removes the condition around the
buttons/pager divs of the FormView template. However, it was using a
selector that does not seem to be used anymore. We thus removed it
and the buttons/pager divs are now in the rendered One2Many List View
- The rendered pager was appended to this.options.$pager whereas it
should be appended to the corresponding div in its own template.
This commit should not be forwardported
This revision completely breaks the reports
having long content in cells
To reproduce, just create a sale order with a long
line description, and print the sale.order report
before and after this revision, then see the difference.
opw-632317
- The receipt printing screen is shown both with the web and posbox
printing
- Both method can now reprint receipt
- The Change is shown on the receipt screen to help the cashier give
back the change after the cashbox is open.
It is confusing to show once pack operations and once move lines without the user being aware.
As sometimes the pack operations don't get updated the report would not show all the products available for example.
- email is now required when buying tickets, to avois having subscription
that we cannot email with event information
- 'not yet started' message should be linked to the event state, not to the
fact that the event has tickets or not. A confirmed event without configured
tickets is just displayed on the website, but not set as unconfigured.
Previously, when updating subscribers of a mail.thread, the default_{key}
arguments could override a {key} in the values.
e.g: for an new opportunity, the salesperson was overrided by the default user_id
This fix gives the priority to the values over the default_ in context.
opw-631741
In the partner ledger wizard, you can check
a boolean to display the amount within the
currency the amount has been invoiced.
This feature was simply no more working
in Odoo 8.0.
opw-630268
The number of sale order on a partner form view only counted the given customer
and not the ones of eventuals child_ids. Hence when clicking on the widget, the
result sale order tree view (which take account of child_ids sale order) is
inconsistent.
This fix adds the sale order of a child company to the sale_order_count.
opw-630249
Otherwise, it is fixed according to the other elements, here, the wrapwrap element.
So if we add a margin to wrapwrap, the margin is also added to the navbar, which
means it is not really fixed on the top.
This fix avoids this issue so the navbar is always fixed at the top of the page.
Xavier Morel