Some views still use them.

closes odoo/odoo#100884

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Since commit [1], we use base.main_company as default value for the
address of the admin employee. This is not correct as base.main_company
is referring to res.company model while address_id is expecting a
res.partner id.

This works in most default situations as id = 1 is the same for both
res.company and res.partner, but not anymore in case we have merged
the initial partner with another one.

We should use base.main_partner instead of base.main_company.

[1]:https://github.com/odoo/odoo/commit/c0ca736193df42814389151956eb07c28c77d18e



closes odoo/odoo#100866

X-original-commit: 16316705
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>

When installing l10n_mx, a error occurs

    Traceback (most recent call last):
    File "/data/build/odoo/odoo/service/server.py", line 1289, in preload_registries
        registry = Registry.new(dbname, update_module=update_module)
    File "<decorator-gen-15>", line 2, in new
    File "/data/build/odoo/odoo/tools/func.py", line 87, in locked
        return func(inst, *args, **kwargs)
    File "/data/build/odoo/odoo/modules/registry.py", line 91, in new
        odoo.modules.load_modules(registry, force_demo, status, update_module)
    File "/data/build/odoo/odoo/modules/loading.py", line 482, in load_modules
        processed_modules += load_marked_modules(cr, graph,
    File "/data/build/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
        loaded, processed = load_module_graph(
    File "/data/build/odoo/odoo/modules/loading.py", line 206, in load_module_graph
        registry.setup_models(cr)
    File "/data/build/odoo/odoo/modules/registry.py", line 289, in setup_models
        model._setup_fields()
    File "/data/build/odoo/odoo/models.py", line 3294, in _setup_fields
        field.setup(self)
    File "/data/build/odoo/odoo/fields.py", line 512, in setup
        self.setup_nonrelated(model)
    File "/data/build/odoo/odoo/fields.py", line 4524, in setup_nonrelated
        m2m = model.pool._m2m
    AttributeError: 'Registry' object has no attribute '_m2m'

Since #99438 hr is sintalled automatically
This means that when doing a -i l10n_mx, hr is installed too

hr will conditionnaly call a button_immediate_install in this case.

What's going on after that: It's a mess

button_immediate_install will create another registry
This registry will be present on some models that will ne used later
by the initial registry creating the missing _m2m case

For the record, here are some of the strange and key element during
the install

    2022-09-21 16:31:27,691 2579263 INFO test_mx odoo.modules.loading: loading 1 modules...
    2022-09-21 16:31:27,691 2579263 INFO test_mx odoo.modules.loading: Loading module base (1/1)
    ...
    2022-09-21 16:31:36,222 2579263 INFO test_mx odoo.modules.loading: Module base loaded in 8.53s, 8902 queries (+8902 other)
    2022-09-21 16:31:36,222 2579263 INFO test_mx odoo.modules.loading: 1 modules loaded in 8.53s, 8902 queries (+8902 extra)
    2022-09-21 16:31:36,240 2579263 INFO test_mx odoo.modules.loading: updating modules list
    2022-09-21 16:31:36,241 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.update_list on [] to user __system__ #1 via n/a
    2022-09-21 16:31:36,943 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Mexico - Accounting'] to user __system__ #1 via n/a
    ...
    2022-09-21 16:31:49,775 2579263 INFO test_mx odoo.modules.loading: Loading module base_install_request (26/78)
    ...
    2022-09-21 16:31:50,043 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Project', 'Email Marketing', 'Employees', 'Knowledge', 'Sign', 'Planning', 'Appointments', 'Surveys'] to user __system__ #1 via n/a
    2022-09-21 16:31:50,167 2579263 INFO test_mx odoo.modules.loading: Module base_install_request loaded in 0.39s, 228 queries (+228 other)
    ...
    2022-09-21 16:32:10,816 2579263 INFO test_mx odoo.modules.loading: Loading module l10n_mx (55/78)
    ...
    2022-09-21 16:32:17,618 2579263 INFO test_mx odoo.modules.loading: Module l10n_mx loaded in 6.80s, 4302 queries (+4332 other)
    ...
    2022-09-21 16:32:50,371 2579263 INFO test_mx odoo.modules.loading: Loading module hr (35/112)
    2022-09-21 16:32:57,594 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_immediate_install on ['Employees - Mexico'] to user __system__ #1 via n/a
    2022-09-21 16:32:57,594 2579263 INFO test_mx odoo.addons.base.models.ir_module: User #1 triggered module installation
    2022-09-21 16:32:57,595 2579263 INFO test_mx odoo.addons.base.models.ir_module: ALLOW access to module.button_install on ['Employees - Mexico'] to user __system__ #1 via n/a
    ...
    2022-09-21 16:32:58,558 2579263 ERROR test_mx odoo.modules.registry: Creating Registry <odoo.modules.registry.Registry object at 0x7f02cc0e8130>
    Stack (most recent call last):
    File "/home/xdo/osrc/master/odoo/odoo-bin", line 8, in <module>
        odoo.cli.main()
    File "/home/xdo/osrc/master/odoo/odoo/cli/command.py", line 56, in main
        o.run(args)
    File "/home/xdo/osrc/master/odoo/odoo/cli/server.py", line 179, in run
        main(args)
    File "/home/xdo/osrc/master/odoo/odoo/cli/server.py", line 173, in main
        rc = odoo.service.server.start(preload=preload, stop=stop)
    File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1391, in start
        rc = server.run(preload, stop)
    File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 570, in run
        rc = preload_registries(preload)
    File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1289, in preload_registries
        registry = Registry.new(dbname, update_module=update_module)
    File "<decorator-gen-15>", line 2, in new
    File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
        return func(inst, *args, **kwargs)
    File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 91, in new
        odoo.modules.load_modules(registry, force_demo, status, update_module)
    File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 482, in load_modules
        processed_modules += load_marked_modules(cr, graph,
    File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
        loaded, processed = load_module_graph(
    File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 248, in load_module_graph
        getattr(py_module, post_init)(cr, registry)
    File "/home/xdo/osrc/master/odoo/addons/hr/__init__.py", line 19, in _install_hr_localization
        l10n_mx.button_immediate_install()
    File "<decorator-gen-74>", line 2, in button_immediate_install
    File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 75, in check_and_log
        return method(self, *args, **kwargs)
    File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 486, in button_immediate_install
        return self._button_immediate_function(type(self).button_install)
    File "/home/xdo/osrc/master/odoo/odoo/addons/base/models/ir_module.py", line 607, in _button_immediate_function
        registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
    File "<decorator-gen-15>", line 2, in new
    File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
        return func(inst, *args, **kwargs)
    File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 79, in new
        registry.init(db_name)
    File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 115, in init
        _logger.error(self, stack_info=True)
    2022-09-21 16:32:58,580 2579263 INFO test_mx odoo.modules.loading: loading 1 modules...
    2022-09-21 16:32:58,581 2579263 INFO test_mx odoo.modules.loading: Loading module base (1/1)
    ...
    2022-09-21 16:33:35,294 2579263 INFO test_mx odoo.modules.loading: Loading module base_install_request (30/85)
    ...
    2022-09-21 16:33:35,745 2579263 INFO test_mx odoo.modules.loading: Module base_install_request loaded in 0.45s, 131 queries (+131 other)
    ...
    2022-09-21 16:34:05,789 2579263 INFO test_mx odoo.modules.loading: Loading module l10n_mx (62/85)
    ...
    2022-09-21 16:34:28,497 2579263 INFO test_mx odoo.modules.loading: Loading module hr (35/113)
    ...
    2022-09-21 16:34:32,067 2579263 INFO test_mx odoo.modules.loading: Module hr loaded in 3.57s, 4092 queries (+4092 other)
    2022-09-21 16:34:32,067 2579263 INFO test_mx odoo.modules.loading: Loading module link_tracker (37/113)
    ...
    2022-09-21 16:34:32,690 2579263 INFO test_mx odoo.modules.loading: Module link_tracker loaded in 0.62s, 267 queries (+267 other)
    ...
    2022-09-21 16:35:04,063 2579263 INFO test_mx odoo.modules.loading: Modules loaded.
    2022-09-21 16:35:04,068 2579263 INFO test_mx odoo.modules.registry: Registry loaded in 125.514s
    2022-09-21 16:35:04,068 2579263 INFO test_mx odoo.addons.base.models.ir_module: getting next ir.actions.todo()
    2022-09-21 16:35:04,071 2579263 INFO test_mx odoo.addons.base.models.ir_module: next action is "Open Menu"
    2022-09-21 16:35:04,094 2579263 INFO test_mx odoo.modules.loading: Module hr loaded in 133.72s, 4344 queries (+81420 other)
    ...
    2022-09-21 16:35:04,094 2579263 INFO test_mx odoo.modules.loading: Loading module link_tracker (37/112)
    2022-09-21 16:35:04,163 2579263 ERROR test_mx odoo.modules.registry:
    setuping model: ir.model.fields()
    registry on model: <odoo.modules.registry.Registry object at 0x7f02cc0e8130>
    registry calling setup_models: <odoo.modules.registry.Registry object at 0x7f02e92399d0>

    2022-09-21 16:35:04,164 2579263 WARNING test_mx odoo.modules.loading: Transient module states were reset
    2022-09-21 16:35:04,165 2579263 ERROR test_mx odoo.modules.registry: Failed to load registry
    2022-09-21 16:35:04,165 2579263 CRITICAL test_mx odoo.service.server: Failed to initialize database `test_mx`.
    Traceback (most recent call last):
    File "/home/xdo/osrc/master/odoo/odoo/service/server.py", line 1289, in preload_registries
        registry = Registry.new(dbname, update_module=update_module)
    File "<decorator-gen-15>", line 2, in new
    File "/home/xdo/osrc/master/odoo/odoo/tools/func.py", line 87, in locked
        return func(inst, *args, **kwargs)
    File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 91, in new
        odoo.modules.load_modules(registry, force_demo, status, update_module)
    File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 482, in load_modules
        processed_modules += load_marked_modules(cr, graph,
    File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 371, in load_marked_modules
        loaded, processed = load_module_graph(
    File "/home/xdo/osrc/master/odoo/odoo/modules/loading.py", line 206, in load_module_graph
        registry.setup_models(cr)
    File "/home/xdo/osrc/master/odoo/odoo/modules/registry.py", line 293, in setup_models
        model._setup_fields()
    File "/home/xdo/osrc/master/odoo/odoo/models.py", line 3294, in _setup_fields
        field.setup(self)
    File "/home/xdo/osrc/master/odoo/odoo/fields.py", line 512, in setup
        self.setup_nonrelated(model)
    File "/home/xdo/osrc/master/odoo/odoo/fields.py", line 4524, in setup_nonrelated
        m2m = model.pool._m2m
    AttributeError: 'Registry' object has no attribute '_m2m'

Naive fix here: use button_install instead of button_immediate_install
(not even sure this is 100% correct)

All calls to button_immediate_install should be fixed maybe to avoid
a registryloadingception

closes odoo/odoo#100755

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

*: hr, im_livechat, snailmail, website_livechat

This commit introduces the public livechat bundle, which
contains the models that are specifically used in public livechat.

Doing so reduces the amount of model and data in frontend and
external lib, which makes the page load faster.

Task-2990182
Task-2990191

closes odoo/odoo#100683

Related: odoo/enterprise#31559
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Prefer using hooks instead.
Makes use of the new open_chat_hook from mail when possible.

closes odoo/odoo#100471

Related: odoo/enterprise#31516
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Those fields may be used in the new views.

Some of the legacy fields had to be kept because they are used
in some legacy views, more notably the gantt and activity views as well
as in the mrp work order tablet mode.

Part-of: odoo/odoo#100471

closes odoo/odoo#100573

Related: odoo/enterprise#31507
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

The presence icon was bigger than the chat one.
Now they are better aligned with the employee's name.

closes odoo/odoo#100564

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Fields param is actually not a kwargs. This cause a stack trace when opening a chat window (other than a chat with yourself) from a Kanban user avatar icon.

closes odoo/odoo#100315

X-original-commit: 95d3f4b0
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

There was an extra `r` in the name of the super method called, which
produces a traceback.

closes odoo/odoo#100361

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Translated fields no longer use the model ir.translation.  Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table.  The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages).  Empty text is allowed in translation values, but not NULL.

Here are examples for a field with translate=True:

    NULL
    {"en_US": "Foo"}
    {"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
    {"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}

Like before, writing False to the field makes it NULL, i.e., False in all
languages.  However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.

Here are examples for a field with translate=xml_translate:

    NULL
    {"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}

Change for callable(translate) fields: one can now write any value in any
language on such a field.  The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values.  Basically the
structure of the value must remain the same in all languages, like before.

Reading a translated field is now both simpler and faster than the former
implementation.  We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:

    SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...

The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages).  For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.

Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language.  Before this change, only the source value of the
field ('en_US') could be indexed.

Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages.  We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.

Code translations are no longer stored into the database.  They become static,
and are extracted from the PO files when needed.  The worker simply uses a cache
with extracted code translations for performance.  This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker.  Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).

Performance summary:
 (+) reading 'model' translated fields is faster
 (+) reading 'model_terms' translated fields is much faster (no need to inject
     translations into the source value)
 (+) searching translated fields with operator 'ilike' is much faster when the
     field is indexed with 'trigram'
 (+) updating translated fields requires less ORM flushing
 (-) importing translations from PO files is 2x slower

Some extra fixes:
 - make field 'name' of ir.actions.actions translated; because of the PG
   inheritance, this is necessary to make the column definition consistent in
   all models that inherit from ir.actions.actions.
 - add some backend API for the web/website client for editing translations
 - move methods get_field_string() to model ir.model.fields
 - move _load_module_terms to model ir.module.module
 - adapt tests in test_impex, test_new_api
 - because env.lang is injected into SQL queries, its returned value is
   now guaranteed to correspond to a valid active language or None
 - remove wizard to insert missing translations (no longer makes sense)

task-id: 2081307

Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>

taskID 2969653

closes odoo/odoo#99407

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Adapt all manifest, split some XML file and update JavaScript files.

Part-of: odoo/odoo#95500

Change the default recipient of the simulation link to be the employee's
work email address, instead of the private email address.

Currently the private email of employees is used for this but this doesn't
work because mail.compose.message does not allow allow private partners
to be configured as recipients. Secondly, it also just makes sense to send
work-related email to the work email address.

In addition, since a partner is automatically created when sending an
email to this work email address (which is currently a string field, a new
field is created to keep track of this partner, in addition to other
partners that might be linked to employee.

task-2790044

closes odoo/odoo#95655

Related: odoo/enterprise#27808
Signed-off-by: Kevin Baptiste <kba@odoo.com>

This commit adds the possibility to link a stress day
to specific departments. If the employee is in a
sub-department of the department subject to a stress
day, the stress day will also apply for that employee.

taskID 2946420

closes odoo/odoo#97888

Signed-off-by: Kevin Baptiste <kba@odoo.com>

It was no longer possible to load the My Profile for users with an
employee that were not HR Officer.

In the `get_views()` method, the 'search' view was requested after the
'form', thus it omited the fields requested as SUPERUSER in
`get_view()`.

closes odoo/odoo#99750

Signed-off-by: Kevin Baptiste <kba@odoo.com>

hr_*:
hr
hr_contract
hr_recruitment
website_hr_recruitment

Increase UX and possibilities to postulate to a job on recruitement.
Also moves the model hr.contract.type from hr_contract to hr so that it
can also be used from hr_recruitment without having two models in parallel.

taskID 2898063

closes odoo/odoo#96551

Related: odoo/enterprise#29777
Related: odoo/upgrade#3861
Signed-off-by: Kevin Baptiste <kba@odoo.com>

In the Employees app, when using the department kanban view and clicking on the
Time Off Requests or Allocation Requests, it leads to a tree view but the department
from which the user comes from is not part of the filters.

This commit adds the department in the filters of the tree view.

Due to the search panel being present in the tree view, the department filter is removed from the list of
filters to avoid a duplication of the filters in the search panel.

task-2939207

closes odoo/odoo#97773

Related: odoo/enterprise#30358
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Introduced by #85428

closes odoo/odoo#99672

X-original-commit: e6cef5ab9ec189f1f0b86e21a1400859f021ba06
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Steps to reproduce:
-Install planning
-Go to Gantt View
-Click on resource avatar

task-2960247

closes odoo/odoo#99551

Signed-off-by: Kevin Baptiste <kba@odoo.com>

The cache key of _get_bindings was not super efficient.
The result of _get_bindings is cached,
but its performance was altered by the cache
key which requires to fetch the user groups for each call to
_get_bindings.
Besides, as there is a lot of possible group
combination, this resulted in a lot of possible cache keys,
and therefore a lot of cached values.

This revision aims to make _get_bindings more efficient
by:

- do not use the groups in the cache keys (less cached values)
- filter out actions not available to the user groups after
  retrieving them from the cache
- use has_group to do the above, which is itself cached as well,
  and therefore do not need to fetch the user groups
  at each call to get_bindings.

In addition, move get_bindings from `get_view`
to `get_views`. If there was 3 views asked by `get_views`
(let's say kanban, list, form)
`get_bindings` was being called 3 times, through `get_view`
with each time the same arguments and therefore the same result :-).
Moving it to `get_views` allows to call it only once for all view types
requested, and for the web client it doesn't change much,
as it always request the toolbar/get_bindings through `get_views` only.

In addition, add the lang to the cache of _get_bindings.
it was actually a bug not to put it: if you had 2 users
with the same group set, using 2 different languages,
the user accessing first the get_bindings would cache
the action names within his language, and then the second
user would see the action name within the language of the first user
:-).

Before
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 790 ms, sys: 104 ms, total: 893 ms
Wall time: 1.7 s
```

After
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 23.5 ms, sys: 9.12 ms, total: 32.7 ms
Wall time: 36.9 ms
```

Part-of: odoo/odoo#99417

task-2700425

Currently there is no container in which to add content to the bottom of the hr
department kanban cards. Any module that wants to place content there therefore
has to create this section itself. This results in conflicts when two different
modules both try to add this section to the card. As a solution, an empty lower
section of the kanban card is created by default. Any module can then add
content to that empty section, regardless of how many or which modules are
installed.

The icon that is displayed in the employee kanban view is determined by the
field hr_icon_display, computed in the method _compute_hr_icon_display. This
method is overridden in multiple modules such as hr_holidays, hr_attendance
and hr_homeworking.

Currently this field has a state to show no icon (presence_undetermined). In
this change this state is extracted into the a separate field
show_hr_icon_display with the default state of hr_icon_display being
presence_to_define. In this way a module such as hr_attendance, which only
overrides _compute_hr_icon_display to show the default icon for everyone as a
default, now only needs to change this separate field and does not need any
knowledge of what other states exist. This reduces coupling between modules.

Part of task-2948676.

closes odoo/odoo#99281

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Part of the overall v16 SCSS optimization/restyle, task-2704984

task-2892062

Part-of: odoo/odoo#96195

closes odoo/odoo#98562

Related: odoo/enterprise#30639
Signed-off-by: Raphael Collet <rco@odoo.com>

The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.

- This feature wasn't really known or used by most developers,
   and not straight-forward to understand.
   Removing it allows one less complicated thing to learn for developers.
   Besides, thanks to odoo/odoo#95729,
   changing the behavior of the `groups=` attribute,
   we can easily get rid of this `groups_id` feature
   by simply adding `groups=` in the elements of the views
   using the `groups_id` field, it will have the same effect:
   adding the elements in the view only for the users part of the specified group.

- By getting rid of the groups_id many2many field on ir.ui.view,
   it makes possible to cache the view architecture without
   requiring to use the groups in the cache key.
   Currently, if we want to cache the view architecture,
  it would be required to use the intersection of the user
  groups with the groups_id groups of the view,
  making it costly to compute the cache key,
  therefore altering the performance point to cache the view
  architectures.

Part-of: odoo/odoo#98551

When selecting the action "Create User" from the employee view, use the available
employee information as default values for this new user. Additionally, make the
"Create Employee" option invisible as this is not relevant when the employee
already exists and save an extra click by closing the user form upon saving.

task-id 2942602

closes odoo/odoo#97632

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Scenario:
hr_contract is installed and employee/officer without rights on contract
tries to archive an employee.

Before the fix:
An employee/officer without rights on contract gets the following access error:
Due to security restrictions, you are not allowed to access 'Employee Contract' (hr.contract) records.
THis is because the action tries to access employee's contract and set
date_end on it.

After the fix an employee/officer without rights on contract can archive
an employee without access error.

task - 2811165

closes odoo/odoo#98648

X-original-commit: c7ff577053a120f8f961642891d3a0ec0c960ae8
Signed-off-by: Kevin Baptiste <kba@odoo.com>

This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.

Before this revision,

in a back-end view:
 - In the Python model, if a field has the `groups` attribute set
   and the user is not part of
   the groups, the field is removed, completely, from the view.
 - In the view architecture, if a node has the `groups` attribute set
   and the user is not part of
   the groups, the node is made invisible (not completely removed, just
   made invisible).

in a front-end view:
 - if a node has a "groups" or "t-groups" set and the user
   is not part of the groups, the node is removed from the view.

So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.

In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.

closes odoo/odoo#95729

Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Automatically add `required` and `readonly` on identifying fields and
remove them from field definition.

Task-2955910.
* = calendar, hr, im_livechat, rating, snailmail, website_livechat

closes odoo/odoo#98283

Related: odoo/enterprise#30511
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

The avatars were not properly shown anymore on kanban and form views.

closes odoo/odoo#98264

Signed-off-by: Kevin Baptiste <kba@odoo.com>

* = calendar, hr, im_livechat, rating, snailmail, website_livechat

This simplifies definition and overrides and opens up new identification
opportunities.

Part of task-2741982

closes odoo/odoo#98166

Related: odoo/enterprise#30470
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

closes odoo/odoo#98027

Taskid: 2784316
Related: odoo/enterprise#30398
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

*: calendar, hr, hr_holidays, im_livechat, note, rating, snailmail,
test_mail, test_mail_full, website_livechat, website_slides.

Part-of: odoo/odoo#97771

Only for terms containing Credit Note and expenses

closes odoo/odoo#97840

X-original-commit: 1754b094
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Part of the overall v16 SCSS optimization/restyle, task-2704984.

task-2865713

closes odoo/odoo#93049

Signed-off-by: Pierre Paridans (app) <app@odoo.com>

Drop custom cursor classes in favor of Bootstrap default ones.
Part of the overall v16 SCSS optimization/restyle, task-2704984.

task-2918463

Part-of: odoo/odoo#97051