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>
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>
Step to reproduce:
- Go to 'My Preference' or User profile as admin
- Click on the world icon to add a language
Old Behaviour:
- Open the technical view of languages
New Behaviour:
- Open a wizard to add a a language
taskid-2774319
closesodoo/odoo#92855
Signed-off-by: Arnaud Joset <arj@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>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
* restore position relative:
> Columns no longer have position: relative applied, so you may have to
> add .position-relative to some elements to restore that behavior.
https://getbootstrap.com/docs/5.1/migration/#grid-updates
Example:
Favorite widget isn't shown on the right location due to change
in Boostrap 5, so we restore the old positioning of the `.col`
PS: another fix is to simply remove the position absolute of
`.o_favorite` but its break the favorite in kanban project.
* remove usage of `width` in kanban image when `col` is also used:
The class `o_kanban_image` is
```css
.o_kanban_image {
width: 64px;
}
```
In BS4 the col rules are:
```css
.col-4 {
flex: 0 0 33.33333333%;
max-width: 33.33333333%;
}
```
and in BS5:
```css
.col-4 {
-webkit-box-flex: 0;
-webkit-flex: 0 0 auto;
flex: 0 0 auto;
width: 33.33333333%;
}
```
So `width` overrides the `col` rules.
To summarize:
In BS4
```css
{
max-width: 33.33333333%;
width: 64px;
}
```
In BS5
```css
{
width: 33.33333333%;
width: 64px;
}
```
e.g. where there is the case:
Helpdesk > Reporting > Customer Ratings (Kanban card)
Task ID: 2766483
Part-of: odoo/odoo#95450
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
Backport of odoo/odoo#81474
Before odoo/odoo#86889 a regular user with employees in multiple
companies was not able to change his own language due to a chain of
event calling onchange on all the employee_ids and employee_ids on
res.users being read as sudo.
The fix does work but was wrong because it gave access to the user's
public employee regardless of the active company_id
A domain was added to employee_ids to make force the security rules even
in sudo.
closesodoo/odoo#94618
X-original-commit: 90cec4073e065c142043fcea1d68a10c7cb72e73
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The field pos_employee_ids (pos_hr) links hr employees records to
settings records
but this model isn't readable for Pos Administrators by default.
This commit gives read rights on hr.employee model to settings users,
reusing a confusing existing ACL whose name targeted system users,
whereas the group effectively targeted was the internal users.
Since this rule didn't give any rights, we might as well correctly
replace
it so that the name can match its purpose.
Part-of: odoo/odoo#91909
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
* hr, im_livechat, mail, sms, snailmail, test_mail_full, website_livechat,
website_slides
PURPOSE:
Creating a record with no values has no sense but is sometimes useful during
tests.
The support should be dropped for `default` parameter in `create`.
SPECIFICATION:
All the occurrences of `create()` have been replaced by `create({})`.
Task-2869394
closesodoo/odoo#93917
Related: odoo/enterprise#28538
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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>
Kevin Baptiste