FW-Port of odoo/odoo#70675 (13.0)

closes odoo/odoo#70728

X-original-commit: 85c24961ab9ff5c1c79eb7415c97c46d9a77cca3
Related: odoo/enterprise#18283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

closes odoo/odoo#66439

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

To reproduce this issue, install the module "Accounting" in English,
then switch language to Dutch, and go to a user's form.  The selection
field for accounting groups is missing from the users' form view.

The source of the bug is the special case introduced for accounting
groups in d8c5cc1335806d379134866262840fcafb05b643.  The groups in that
selection field are not totally ordered, and the non-ordered elements
are de facto ordered by name, which is a translated field!  In the
example above, the English version uses the field name
`sel_groups_22_23_24_25` while the Dutch version uses the field name
`sel_groups_23_22_24_25`.  Because the first one is used in the form
view, and it is not found in the model's documented fields (which uses
the second one), the field is discarded from the view.

The patch modifies the override of method `fields_get()` to consider all
the possible names for that selection field, and returns them all.

OPW-2394209

closes odoo/odoo#63423

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Before this change, the apikeys' ``_check_credentials`` override would
hard-check the ``'interactive'`` key. This turns out to be less than
ideal for compatibility with older code which might not properly
forward the environment (or might call ``_check_credentials`` from a
non-override and pass in an empty env) as it straight crashes.

Update the override to assume an interactive login if the information
is missing (as that seems like the more secure option: it ignores
apikeys and takes 2FA in account if enabled). Also trigger a warning
if the key was missing from the environment, such that the maintainer
hopefully takes a look at the issue.

Also allow a ``user_agent_env`` of ``None``, this will also trigger
the warning so seems OK.

closes odoo/odoo#62664

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.

Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).

closes odoo/odoo#59554

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

As example, on a runbot database, there are 13 duplicated indexes

```
4362411-14-0-all=> \d res_users_apikeys;
                                         Table "public.res_users_apikeys"
   Column    |            Type             | Collation | Nullable |                    Default
-------------+-----------------------------+-----------+----------+-----------------------------------------------
 id          | integer                     |           | not null | nextval('res_users_apikeys_id_seq'::regclass)
 name        | character varying           |           | not null |
 user_id     | integer                     |           | not null |
 scope       | character varying           |           |          |
 index       | character varying(8)        |           |          |
 key         | character varying           |           |          |
 create_date | timestamp without time zone |           |          | timezone('utc'::text, now())
Indexes:
    "res_users_apikeys_pkey" PRIMARY KEY, btree (id)
    "res_users_apikeys_user_id_index_idx" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx1" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx10" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx11" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx12" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx2" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx3" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx4" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx5" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx6" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx7" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx8" btree (user_id, index)
    "res_users_apikeys_user_id_index_idx9" btree (user_id, index)
Check constraints:
    "res_users_apikeys_index_check" CHECK (char_length(index::text) = 8)
Foreign-key constraints:
    "res_users_apikeys_user_id_fkey" FOREIGN KEY (user_id) REFERENCES res_users(id)
```

closes odoo/odoo#58726

Signed-off-by: Christophe Simonis <chs@odoo.com>

* override `onchange` in res.users in order to properly generate and
  send the reified group fields alongside the rest: while default_get
  sets them up, those fields then get stripped by the onchange
  machinery as they don't actually exist on the model
* add a test to check for it
* fix SSF in relation with the new default/onchange system
  - because fields may not actually exist on the record,
    `record_to_values` needs to `read` the record data rather than
    directly access the recordset: the recordset likely will not
    know about fake fields
  - after the initial onchange has run the form must be filled with
    falsy values in case the onchange has not sent defaults for
    everything
  - on creation, all fields in the form should be considered modified

Task 2341153

closes odoo/odoo#57987

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

This provides a better API to search for records by name without the
formatting part (`display_name`).

This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`.  The call to `name_get()` is done in
method `name_search` in a generic way.

* add a constant to `fields` for that purpose
* add a test to ensure that it works as expected
* fix the formatter so it handles the pattern correctly