Impacted modules:
hr, hr_contract, hr_recruitment, hr_payroll, fleet, hr_skills, hr_appraisal, ....
Several onchanges have been converted to computed fields in the following modules :
Community :
- hr
- hr_contract
- hr_recruitment
- hr_work_entry
- hr_maintenance
- hr_expense
- hr_expense_check
- hr_holidays
- sale_expense
- account_analytic_default_hr_expense
Enterprise:
- hr_contract_salary
- hr_referral
- hr_payroll
- hr_payroll_expense
- test_l10n_be_hr_payroll_account
There are still 2 onchanges with complex behavior that couldn't be converted easily:
- an onchange that updates "tz" (timezone) that is defined as a related field
to "resource_id.tz". Apparently it is useless except to initialize the default
value of "tz".
- an onchange that updates "name" that is defined as a related field to
"resource_id.name".
the applicant.
closesodoo/odoo#45414
Taskid: 2169099
Related: odoo/enterprise#8572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* converts dynamic domain from onchange_department_or_employee_id to a
static domain on the field
* remove the department_id field (and all uses of it), it looks to
never be set and not really be settable: the field is hidden in the
form, doesn't have a default value, does not have anything to
compute it, ...
* remove the onchange itself as it has very little value: it
auto-selects an equipment if there exists a single equipment
assigned to the selected employee or to no employee
Even if we removed the "equipment not assigned to any user"
bit (under the assumption that people would mostly request
maintenance for their own equipment, and that this would usefully
trigger more often) it's unlikely for dedicated users of
hr_maintenance to assign only one equipment per employee. So the
onchange would rarely do any useful work, and what work it saves is
trivial: if there's only one equipment the employee could ask about
for maintenance it's really trivial to do that.
Task 2115472
closesodoo/odoo#40963
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In the employee form view and in the employee profile, the stat button
displaying the equipment count is wrong.
It counts the equipment owned by the user, not equipments assigned to the
employee.
closesodoo/odoo#38889
X-original-commit: 07bd725c97519a82cc76f3069614ac70b49495a3
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
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 is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
- rename models from hr.equipment.something to maintenance.something
- add concept of maintenance team and dashboard
- remove generic alias for maintenance
maintenance is not dependant on hr anymore. A new module hr_maintenance is
added that adds hr-related fields (employee owner, ...). This way maintenance
is a stand alone application.
