Introduced by #85428closesodoo/odoo#99672
X-original-commit: e6cef5ab9ec189f1f0b86e21a1400859f021ba06
Signed-off-by: William Braeckman (wbr) <wbr@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
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.
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>
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>
By enabling the method '_employee_values_sync' the original behavior is
keep. Furthermore, by overriding the method now is possible to decide
either a field is synced or not into employee.
closesodoo/odoo#96609
X-original-commit: 46c12cc0f72b2a6aba907fe903a255aed61a1695
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps:
- Schedule some activities to `admin` (users with hr officer)
- Remove hr rights to `admin`
- Log-in with `admin` and click on notification
- Click on `Summary`
- Traceback
If we click on `Summary` a `_search` is executed in `hr.employee`
When a user does not have the required rights we will apply `_search` on
the fields on `hr.employee.public` instead of `hr.employee.private`.
Except that in the case of `activity_ids` this field does not exist in
`hr.employee.public`
opw-2765032
closesodoo/odoo#95802
X-original-commit: c4a5c63b6141424e31d7a7c8bc6d0c00d58643c0
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Move the definition of class Query to odoo.tools, in order to avoid
circular imports when importing Query in core Odoo modules.
Also reorganize imports in the impacted modules.
Part-of: odoo/odoo#66938
account.account: code was already in unique constraint
account.journal: inverting compound unique constraint to benefit from indexing company_id
hr.employee: user_id already in unique index
phone.blacklist: number already in unique index
stock.orderpoint: product_id already in unique constraint/index
closesodoo/odoo#92932
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Plans can be available for a specific department or global for the
company.
closesodoo/odoo#92648
Taskid: 2868447
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose:
Increase usability of the Plan feature
This change implies changing 'hr.plan.wizard' m2o employee_id
field into m2m employee_ids field.
task - 2797331
closesodoo/odoo#88119
Related: odoo/enterprise#26264
Related: odoo/upgrade#3439
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
When creating a user and employee from the wizard, the employee was
taking the default name from the context instead of the one chosen
in the wizard.
closesodoo/odoo#88368
Taskid: 2819821
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
Departure reasons could be used on business code (eg: payroll).
Currently the mapping is made based on the xmlid, but it could
happen for some customers to create several departure reasons
of the same kind. (ex: "Resigned - Salary" or even
"Resigned - Personal Reasons").
This commit uses the departure reason on _get_default_departure_reasons
to allow considering them together.
closesodoo/odoo#87662
Taskid: 2811192
X-original-commit: c7f46a4760fa2beb7d50b4b95f10e14a1a326423
Related: odoo/enterprise#25771
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Having both an activity type "Request Signature" and "Signature
Request" on the plan were confusing and misleading for the users.
Related odoo/enterprise#25511
Related odoo/upgrade#3398closesodoo/odoo#87082
Taskid: 2796407
Signed-off-by: Kevin Baptiste <kba@odoo.com>
* Redesign views
* New layout for the job kanban card + redesigned menu
* Create new reports
* Candidate Sources: get a better view on where applicants are
coming from;
* Time in Stage: shows how long an applicant is in the current
stage.
* Archiving a job archives applicants as well
odoo/enterprise#24816odoo/upgrade#3395closesodoo/odoo#85479
Taskid: 2738082
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The group_public_id and group_id and subscription_department_ids
should only be used when the channel_type is 'channel'.
task-2766712
closesodoo/odoo#84813
Related: odoo/upgrade#3266
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Make sure related values are correctly propagated to the
resource.resource creation, and discard the inverse update post record
creation when it doesn't change anything
closesodoo/odoo#85601
Related: odoo/enterprise#25664
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* post onboarding notes in batch
* subscribe users in batch
* Only fetch the menu_hr_root data once, instead of once for each record
created.
Part-of: odoo/odoo#85601
After installing l10n_be_hr_payroll, the address, email, phone and bank account number take half of the dedicated space.
This commit makes the fields take the dedicated space
task-2790206
closesodoo/odoo#86098
Related: odoo/enterprise#25126
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The goal is to make it easier to link employees to users.
We can now directly create an employee from the 'invite' user form view
As well as create a new user from a form view using an action.
TaskId-2762247
closesodoo/odoo#85428
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Expected Behaviour
When a user goes to his own profile, he has two ways to change his password :
1. through the 'Account security' tab
2. through the 'Actions' > 'Change password' menu in list/form view
Both option should let the user change its password, or one of the two should
not be present
Observed behaviour
While the first one works as expected, the second option gives an error as
the user doesn't have the admin rights
Reproducibility
This bug can be reproduced following these steps:
0. Make sure to have the "Employees" app installed
1. Connect as an employee (e.g. demo/demo on runbot)
2. Click on your name at the top right, go to 'My Profile'
3. Click 'Action' then 'Change password'
Problem Root Cause
There is an override of field_view_get for the res.users model in the hr
module which elevates the user with sudo so that the user may modify their
own user in some capacity. The problem is that by elevating the ACLs of the
user, fields_view_get will also return actions that are not normally
available to the user (e.g. deletion of user profile)
Related Issues/PR
- opw-2735671
closesodoo/odoo#86116
X-original-commit: 6487a9ea7d25d14a86a7476b4b512f3681da7405
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Reorder smart buttons on the hr_employee to have them in the following order:
1. Documents
2. Holiday status
3. Time Off
4. Planning
5. Timesheets
6. Equipments
7. Cars
8. Contracts
9. Appraisal
10. Work Entries
11. Payroll
12. Attendance
13. Extra Hours
- Log in the chatter the name of the plan that has been started via the button "Launch Plan"
- When on mobile, open the Time Off Calendar in month view
- When sending a sms without any message, only display Message once in the invalid fields
- Avoid the sms-help info disappearing when clicking on it and there are characters in the body of the message
- Update the tooltip of phone number in the send sms wizard
- Avoid the employee name to be displayed on two lines on mobile if the name is too long. Reduce the font size instead
task-2735679
closesodoo/odoo#83745
Related: odoo/enterprise#23886
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose
=======
for example: in Europe/Brussels timezone, the presence
hour of an employee using this timezone is up with one hour.
The issue is that we give a localized time to format_time pretending
it's not (removing the tzinfo), so it's converted twice.
Specification
=============
To solve the issue, just give the time in UTC to format_time.
opw-2741634
closesodoo/odoo#85510
X-original-commit: 8953eb2e387bd046c586e815c10c1e30b00db13d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Avoid to base64 encode, then decode to process assets and images for a ~25% speed improvement.
Change image processing tool to work on images, rather than base64 encoded strings.
Performance is ~25% faster on assets & images:
/web/assets/...frontend.min.css: 13ms to 7ms, base64 enc/dec: 2 -> 0
/web/image/XML_ID: 10ms to 8ms, base64 enc/dec: 3 -> 0
/web/image/res.users/2/avatar_128: 40ms to 20ms, base64 enc/dec: 6 -> 2
closesodoo/odoo#82851
Related: odoo/enterprise#23537
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When setting users on the appointment type as staff, we want to consider
their resource_calendar_id (work schedules) only if they correspond to the
current company and are linked to employees, not the ones linked to the users
directly. In order to display those work hours correctly, we use a new related
field on the employee_id in res_users model as it will return the employee of
the user in the current company, if any.
Therefore, we add the new field employee_resource_calendar_id directly in
hr module (in res.users model) to reduce diff and centralize the fields as
close as possible to the employee_id definition.
--- Links ---
Task-2499566
closesodoo/odoo#82234
Related: odoo/enterprise#17934
Related: odoo/upgrade#2578
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Adds a new non stored field to make it easier to query all employees
from the active user's department and it's children department(s).
The result is guaranteed to always contain the active user's employee.
task-2700231
closesodoo/odoo#81472
Related: odoo/enterprise#22724
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Current behavior:
When a user doesn't have any HR access right he cannot access his own profile
Steps to reproduce:
-Go to the demo user settings
-Remove all the right in the HR section
-Log into demo account
-Try to access My Profile
opw-2712593
closesodoo/odoo#81674
X-original-commit: ee932eab329043a3ddf82bb39dff458f4eb7f7ad
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
The tags management on an employee was limited to HR Administrator,
which didn't make sense as an HR Officer could manage the tags just not
assign them to an employee.
closesodoo/odoo#81654
Taskid: 2715498
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit users were not able to edit their settings if they
had a linked employee for a company that was not currently active for
them.
This is due to the fact that since the employee_ids field is considered
`safe` to read/write by your own user the fields were loaded in sudo and
thus bypassed the security rules that were meant to prevent that issue.
The security rule is now enforced as a domain on the `employee_ids`.
TaskId-2715341
closesodoo/odoo#81612
X-original-commit: b5b105eabd90419a5856e8279e277743c5915fc9
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, the computed field _compute_is_system make a write which
one is a bad practice and trigger a lot of others calls on res.user model.
opw-2716468
closesodoo/odoo#81555
X-original-commit: f85a67935c5dfa660e94f9bed8e8058c8df256cc
Signed-off-by: Jérémy Kersten <jke@odoo.com>
This commit adds methods to easily obtain calendar validity per resource
for a given search period and get the work intervals per resource,
taking into account the validity of their calendars.
In hr, the create and departure date of an employee are taken into
account to compute the calendars validity.
In hr_contract, it looks for every contract of human resources with
employee of type student or employee existing in the search period and
consider the specific calendar of the contract as valid during the
contract-lifetime.
PR: #77362
task-2646630
William Braeckman