When a new allocation is requested from the leave dashboard,
the page is not reloaded. Therefore the displayed data is not
up to date with the new allocation count.
This commit makes the page reload after each new allocation.
General Purpose
===============
We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the hr module is installed
and the current user is linked to an employee.
A user should be able to see and edit his own profile.
*Problem*:
Many fields on hr.employee are protected by groups="hr.group_hr_user".
Therefore, a regular user cannot see or edit those fields.
This protection must be bypassed to allow read/write access
to the regular user's own data.
A similar mechanism already exists for res.users (for Preferences)
The better (least worst) solution found is to reuse this mechanism by adding related fields on res.users.
Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
through the Preferences menu.
E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to SELF_[READABLE | WRITABLE]_FIELDS
Note:
When the front-end loads the views it gets the list of available fields
for the user (according to its access rights). Later, when the front-end wants to
populate the view with data, it only asks to read those available fields.
However, in this case, we want the user to be able to read/write its own data,
even if they are protected by groups (groups are kept on the related fields on res.users).
The front-end need to be made aware of those fields by sending all field definitions.
hr_attendance
=============
This commit integrate attendance in the new employee profile.
It also adds a stat button to this employee profile showing
the number of hours worked last month.
Remove the boolean computed field 'manual_attendance'.
This field is just a shortcut to add/remove the employee's user
in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should
be done through the normal group management screens.
hr_presence
===========
Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present),
orange (to define) or red (absent).
Currently, the presence status is only computed when accessing
the report view. As this commits displays it on the employee kanban,
it should be updated more frequently.
The state should not be updated every time the kanban view is loaded
since the computation is a bit heavy. Instead: add a cron to update
status every 15 minutes.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 15 minutes on the kanban view
[ADD] hr_attendance_presence
============================
Bridge module between hr_attendance and hr_presence.
This commit integrates hr_presence module in the employee
profile and adds the presence status on the employee kanban view.
But hr_attendance adds at the same place a similar status icon for
checkin/checkout.
This bridge module makes the status from hr_presence invisible as
hr_attendance should be the main presence control mechanism.
Also, this commit adds the ability (through a new setting option)
for hr_presence to take into account checkin/checkout to determine
the presence status.
l10n_be_hr_payroll
==================
integration with employee profile
Purpose
=======
When the manager (parent_id) of an employee changes,
it doesn't always mean that other responsibles (Leave responsible,
expense responsible, coach) should also change.
Specification
=============
When changing the employee's manager, the leave responsible,
the expense responsible and the coach should be changed only
if the field was not set or if the responsible is the previous manager.
In that case, they should be set to the new manager.
Otherwise, it means the field was most probably set manually and
it should be left unchanged.
`channel_info` can be called on multiple channels especially during
the init_messaging. The current implementation will perform read and
other queries in the loop. This commits aims to refactor `channel_info`
in order to read all informations in database out of the loop.
Computation of members informations is now the same as for `direct_partner`
As a side effect direct partner will have an email adress and members will have
im_status and out_of_office message if the partner is in a
channel of type chat. It would be easier to compute im_status in all case but
this could create performances issues when calling channel info on channel with
hundreds of users.
channel_fetch_preview will make a query in database in any case but seems to work ok
in api multi. We can put it out of the loop.
44ac7903cc fix shouldn't be broken by this refactoring since we are no longer using the many2many to find direct_partners.
When on leave, the im_status can be either leave_online or leave_offline.
This will allow to display a specific icon and a default message when the user
is not at the office.
The leave can have an out of office message. This message will be displayed
in the chat window instead of the user ooo message, and the end date of the leave will be displayed too.
Technical details.
Right now the im_status access leaves directly to know if a user is on leave or not.
An index has been added to optimise this request (thanks to rco).
A solution to optimise this would be to compute part of the information in a cron.
Task: 1856205
When creating a leave, we usually check/create activities for the
concerned users, this is fine when creating one leave.
However it starts to become a problem when trying to create leaves in
batch using the by company or by department holiday_type as the number
of leaves created in batch can become quite big.
Now when we create leaves in batch, we do not check for the activities,
which will fasten a lot the creation.
Another problem is that when someone defined a leave on the very day you
want to create such a request, then it will crash, this can lead to
waste of time and resources.
Now we raise an error before trying to create the leaves in case of
conflict.
Task: 1934383
When using the "test import" feature to import leaves request, odoo
fails with a 500 error and no error message.
The only difference with a real import is that the test dry-runs by
rollbacking. The issue here is that mails are sent *after* a commit
is done hense crashes because they do not exist anymore.
opw-1916913
closesodoo/odoo#30523
Purpose of this merge is to update main addons and set activity types used
for automated activities as master data. This means they cannot be removed.
Indeed those activity types are used in business flow to generate activities
and removing them may break some flows.
This commit is linked to task ID 1907970 and PR #29257.
- Go to Leaves > Managers > All > Allocations
- Create an allocation for:
Leave Type: Legal Leaves
Mode: By Department
- Validate
When going to the Legal Leaves form view, the days allocated are not
shown.
This is because the domain is too restrictive. The allocation has a
`date_from` which is `False`, since it is only set for Accrual leaves.
We adapt the domain accordingly.
opw-1921338
closesodoo/odoo#30152
opw-1919744
Before this commit, the user in the leave_type had the choice between
three validations : 'hr', 'manager' and 'both'. The behaviour of the
application was exactly the same if 'hr' or 'manager' was chosen.
In this commit, a computed field was added only to hide this choice,
and restrict the user to choice between the 'double validation'
or the normal validation.
This commit must be reverted once the fonctional part is implemented.
closesodoo/odoo#29952
On installation demo data causes an error on 31 december since we test:
is 31 december at midnight < now() => so after midnight error.
Solve this by comparing today instead of datetime.
opw-29776
closes#29830
The fields `validity_start` and `validity_stop` are `Date` fields, they
should therefore be compared to `datetime.date`.
opw-1918843
closesodoo/odoo#29834
If you are holidays manager, you don't really want to see the leaves of
everybody, but are more interested in the leaves of the people you
manage and yours.
closesodoo/odoo#30066
Purpose
=======
When changing the leave type on a leave request, reset the technical
fields that only have a visual purpose to avoid mismatch on the leave
duration compute method.
closesodoo/odoo#29789
1/ self.date_from on a for loop on self won't work
2/ When calling get_work_hours_count with self.date_from=False or self.date_to=False,
this will lead to a traceback when looking the timezone on the date.
Closes#29697
Lucas Lefèvre