Since commit ae7bd570e13fe19367f86a1519b23747b3b0b73e, the size of
`o_work_employee_main` has been reduced.
This commit fixes this issue.
task-2918464
X-original-commit: 99d13b4b3a5efabff9f71f0cfe1b9cf72bb47ccd
Part-of: odoo/odoo#101655
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
The domain of `work_location_id` requires the company_id and address_id
which were missing from the tree view, showing a traceback when trying
to change that field.
closesodoo/odoo#101195
X-original-commit: 8376adc197208490bf3e4ce0ddbdb6f8e1ae6c60
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Not all employees have a company car. This commit adds a private license plate field on hr.employee.
The field allows the HR Officer and HR Administrator to search for emloyees based on their license plates.
If fleet and hr apps are installed, the search is based on both the company car and private car license plates.
task-2936873
closesodoo/odoo#101146
Related: odoo/enterprise#31796
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Some views still use them.
closesodoo/odoo#101081
X-original-commit: adb5508afd2749dbbfeb85803d707df43358b011
Signed-off-by: William Braeckman (wbr) <wbr@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
closesodoo/odoo#100909
X-original-commit: 919c1f362b1c26dbd04b0501c4d63e2929fb8df4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@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/c0ca736193df42814389151956eb07c28c77d18eclosesodoo/odoo#100883
X-original-commit: 163167052cd904db2ca2ea4322469a066c095938
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@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
closesodoo/odoo#100768
Related: odoo/enterprise#31608
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.
closesodoo/odoo#100764
X-original-commit: d058734cf55f2c3f46f2f23e0bbbfc54f2f0da15
Related: odoo/enterprise#31605
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.
X-original-commit: 1c871ad9ea4a77468911ff6a5546688a26398a8b
Part-of: odoo/odoo#100764
The presence icon was bigger than the chat one.
Now they are better aligned with the employee's name.
closesodoo/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.
closesodoo/odoo#100315
X-original-commit: 95d3f4b0ea4dd5f1f9403b6e5ba97e1e2a510f65
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.
closesodoo/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>
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
closesodoo/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
closesodoo/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()`.
closesodoo/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
closesodoo/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
closesodoo/odoo#97773
Related: odoo/enterprise#30358
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Introduced by #85428closesodoo/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
closesodoo/odoo#99551
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#98242
Signed-off-by: Yannick Tivisse (yti) <yti@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
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.
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
closesodoo/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
closesodoo/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.
closesodoo/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
closesodoo/odoo#98283
Related: odoo/enterprise#30511
Signed-off-by: Sébastien Theys (seb) <seb@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
closesodoo/odoo#98166
Related: odoo/enterprise#30470
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
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
closesodoo/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
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Since eb67feb5 we had to redo the hack to read fields from public user and set them in hr_employee.
However in this hack we used `_read`, which doesn't fill the cache with fields that are not stored,
which caused a cache miss when reading the field `avatar_128` from hr.employee, to display the image of
the manager in the kanban view of hr_appraisal.
This fix uses `read` instead.
closesodoo/odoo#96889
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Brieuc-brd