[FIX] web: on switch form (from list & kanban) do not load record if empty dataset
[MERGE] forward port of branch 7.0 up to 60ab6f1
[FIX] website_customer: the extra / for url pager is not need in saas-4
[IMP] models.py: _auto_init: accelerate row existance check

Using `COUNT(1)` on big table can be slow. Use `min(id)` which use
pkey index to have a quicker response
[FIX] fleet: creation of suppliers is now correct
[FIX] pos: the widget.pos.cashier is not always defined
[MERGE] forward port of branch saas-3 up to 591326c
[FIX] orm field (new api): preserve empty values instead of folding to False

The new API introduced a small behavior change where empty
string values written or stored in a char/text field were
replaced by False (i.e. as if they were NULL).
This was done to mimic the web client behavior, but introduces
a very surprising effect: a.name = ""; assert a.name == "";
would fail. It would also require many more tests in the
code when reading existing required values from the database,
as they could still be False when an empty string value
had previously been stored, for some reason.
[MERGE] forward port of branch saas-4 up to b49755b

The forward port of the fix 3609ba10f2d00a608d8f32334ae1b9a25b34f037 will be done separately, as the mrp scheduler has been completely refactored from saas-5.

Conflicts:
	addons/l10n_be_coda/wizard/account_coda_import.py
	addons/point_of_sale/static/src/xml/pos.xml
	addons/procurement/schedulers.py
[IMP] website: do not translate sitemap URL
[FIX] ir.translation: export/import of QWeb terms

Fixes the translation term import/export logic to
support terms inside QWeb templates.

Refactored a bit the export code so the babel-based
QWeb terms extractor for ./static/src/*.xml files
uses the same logic as the regular extractor for
ir.ui.views with type QWeb.

Server-side QWeb rendering uses a mix of the native
 view inheritance mechanism and the template inclusion
(t-call) mechanism. During rendering the translations
are only applied at "template" level, *after* the
view inheritance has already been resolved.
As a result translations are local to a template,
not to the inherited view in which they are actually
written.
In terms of exporting PO[T] files, this is done by
resolving the "root" QWeb template a view belongs
to, and using it as the location of the translated term.

During import there is one extra quirk for QWeb
terms: they need to be linked to the `website` model
rather than the actual `ir.ui.view` model they
are really pointing to, so the rendering phase can
properly recognize them.
[FIX] web_graph : display the corresponding label for selection fields in graph view
[FIX] account_followup: avoid crashing when a move line has no ref
[FIX] portal_sale: browse data for payment acquirer form with superuser ID

The payment form needs to be rendered for non-employee
users, and may require accessing extra financial data
not available for those users.
[FIX] procurement, stock: forward port of bug fix 3609ba10f2d00a608d8f32334ae1b9a25b34f037
[FIX] account.invoice: payments can never be shown to portal users, but residual might be needed

The residual amount is typically needed to render the
online payment forms (payment acquirers).

Payments on the other hand rely on account.move.line,
something that portal users should never be allowed to read.
Removing the field from the view by setting a model-level
group permission ensures they will not see an error.
[FIX] mail, email_template: prevent user from creating
templates in the templat_idm2o field on the wizard; prevent users from
creating models in the model_id m2o field on the template form view.
[FIX] gamification: prohibitive record rule processing with many users/goals

Due to the multi-company record rule on gamification.goal,
each access to the Goals menu and each opening of the
Messaging menu (thus calling get_serialised_gamification_summary())
is extremely slow (with several thousands goals/users).

Adding auto_join to the user_id FK on goals makes it much
faster. However it causes crashes when reading the table
because the _order of gamification.goal uses `create_date`,
which becomes ambiguous after the auto_join with res_users.

Solving this can be done by re-implementing _read_flat()
in the ORM using the internal Query object, as in search(),
which takes care of fully-qualifying all column names.

Until this is fixed, a simple workaround is to use
start_date in the _order instead of collision-prone `create_date`.
[FIX] export: add the context in the export

In some cases, the data dispalyed in a list depends on the context
This context needs to be passed to the export method, so the exported data reflects correctly the data from the list view
[FIX] context_timestamp MUST return a "timezone aware" timestamp