When an accrual leave is allocated to an employee,
it starts from the employee creation date.
However, companies want to create employees before they start working.
Therefore, they want to be able to change the accrual leave allocation start
to when the employee starts working.
For instance, when hr_contract is installed, we can change the
accrual leave allocation start to the date when the first contract starts.
We create the function _get_date_start_work(),
that can be overriden to allow those changes.
OPW-1939378
closesodoo/odoo#31930
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Currently, when creating `resource.calendar.leaves` for a
`hr.leave` it creates one in the employee's calendar and one
in the contract's calendar if it's different.
But if both calendar are the same, it does not associate
the benefit type to the resource leave.
This commit fixes the issue and add unit tests for this use
case.
closesodoo/odoo#31288
The holiday_type can be 'employee', 'company', 'department' or 'category'.
However in the onchange of holiday_type, for some reason nothing was done
in the case of the 'company' value.
As a result, the default 'employee' would set the employee_id,
but then changing the type to company would not remove the employee_id.
It follows that the lucky employee would get two allocations instead of one.
opw 1938498
closesodoo/odoo#31656
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
*: project, crm, maintenance, helpdesk,
It is useless to track fields during create since they
have no initial value and future tracking message will
show changes on tracked field.
We can log a default creation message instead
(as it is now if there is no mail_create_nolog context key)
This change will implies
- less queries when creating record
- cleaner creation messages
- less occurence of mail_create_nolog ctx key
Removing tracking at create could break the creation subtypes
mechanism (example: following task creation subtype on project)
Instead of using _track_subtype to give a subtype at create,
a new _creation_subtype method can be override. If a creation
subtype is set on a specific modlel, creation messages will be
create by message_post instead of _message_log.
We also need to adapt the message_track_post_template in order to
keep this feature whithout tracking.
Task: #1916916closesodoo/odoo#31945
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before 1ced3bfca, the get_days_all_request method was called with the
context as an argument. As a consequence, because of the api.multi, the
first arg is used as the ids of the record. As the id is not used in
this method, it was not harmful. With the above mentioned fix, there is
no more argument. This causes a traceback when clicking on menu "My Time
Off/Dashboard".
With this commit, the api.model is used instead, that way, the first arg
is not considered as ids.
closesodoo/odoo#32119
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
If validation type is set to `no_validation`, checking
if a target state is achievalbe should bypass
normal checks for the user's own leaves.
Otherwise, ir.rule raises an AccessError as the user
doesn't normally have the rights for leave in
state `validate`.
When this method is called in the context of an onchange
`self.ids` is an empty list.
This is a problem when calling `holiday.check_access_rule('write')`
because it does not find any valid holidays and thus raises an AccessError.
If there are no employee set on the allocation request and if the user
is a leave officer, don't check the access rights as it would lead to
a traceback.
Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
In some exceptional circumstances, the computation of the remaining
leaves might lead to numerical errors, e.g. a very small but non-zero
number (e.g. 10^-17)
This value will be displayed in the name of the leave type because of
the `%g` used in the string format. To avoid breaking the translation,
we round the value.
opw-1935232
closesodoo/odoo#31245
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
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
- 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
The fields `validity_start` and `validity_stop` are `Date` fields, they
should therefore be compared to `datetime.date`.
opw-1918843
closesodoo/odoo#29834
Fanny He