It was possible to assign a user that was not part of the same company
as the employee's for an activity which is misleading.
Make hr.plan and hr.plan.activity.type company dependent.
closesodoo/odoo#77524
Related: odoo/upgrade#2879
Taskid: 2658773
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Improve the departure wizard form view aswell as the flow when using it.
Removes the confirmation dialog when archiving an employee to directly
display the departure wizard.
Also changes departure reason to an html field instead of pure text.
Task ID: 2575279
closesodoo/odoo#72367
Related: odoo/enterprise#19116
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Automate activites linked to plan on certain triggers.
To automate onboarding and offboarding processes, we can now define
plans that will activate upon triggers, such as employee creation,
departure (archive), contract start or contract end.
Manual plans are still possible.
Upon activation of a plan, a message will be added to the employee's
chatter with the name of the plan.
More options have been added related to when to schedule the plan's
activities.
The blocking mechanism has been removed (the plan would not launch if an
activity could not be started, due to lack of information), failed
activities will now be logged into the employee's chatter.
The list and kanban employee views have also been updated to include
info such as first contract date and activity information.
Task ID: 2489095
closesodoo/odoo#68451
Related: odoo/enterprise#17343
Related: odoo/upgrade#2314
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The "Departure Reasons" where hardcoded and couldn't reflect all the
valid departure reasons (like "End Of Fixed-Term Contract").
This commit introduces a new model `hr.departure.reason`.
closesodoo/odoo#66905
Taskid: 2447056
Related: odoo/enterprise#16709
Related: odoo/upgrade#2211
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Leave the generic management of fields default to the orm as much as
possible.
* Default method is not called unless necessary.
* Default values are correctly post-processed by the orm when necessary.
revert of 0f4ec36 and bf8a9af
- Employees > Configuration > Planning Types and ensure the activity
type "To Do" is set to scheduled date several days after previous
activity (default should be 5 days);
- Check that onboarding Plan has at least 2 activities with activity
type "To Do";
- Click launch plan.
The activity type configuration is ignored and all activities are due
tomorrow. The previous commit uses the function
_onchange_activity_type_id to fix this issue.
The problem with this commit, is that the _onchange_activity_type_id
function will also change the responsible, the notes and the summary to
set them to their default value.
Now, the activities are due taking into account the activity type
configuration without modifying the already set responsible, notes and
summary.
opw-2265631
X-original-commit: 81e4745a31567af7b58064bd8b4e9bae0756354f
fine-tuning of bf8a9af1ac549be830bec28c88eb1c565b591941
- Employees > Configuration > Activity Planning > Plans and ensure the
activities have different responsible;
- Create a new Employee, assign a Manager (a different user then the one
connected, you can assign Marc Demo for example);
- Click launch plan.
Before this commit, the activity type responsible is ignored and the
responsible for all activities is the connected user.
Now, the responsible for the activities are assigned taking into account
the activity type configuration.
opw-2265631
closesodoo/odoo#54054
X-original-commit: 0f4ec369dccdf25aed259ae97b5cc8973a1a8c5a
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
- Employees > Configuration > Planning Types and ensure the activity
type "To Do" is set to scheduled date several days after previous
activity (default should be 5 days);
- Check that onboarding Plan has at least 2 activities with activity
type "To Do";
- Click launch plan.
Before this commit, the activity type configuration is ignored and all
activities are due tomorrow.
Now, the activities are due taking into account the activity type
configuration.
opw-2255586
closesodoo/odoo#51423
X-original-commit: c159479d7f714f2ec871cc4b965de3f961160789
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
PURPOSE
=======
When you close a payroll (employees), there are often a lot of document
linked. Archiving an employee should archive the contract, cancel future
leaves, archive the private address
Specification
=============
Add departure date (hr):
- Add a Date field to both hr.departure.wizard and hr.employee. In
the wizard, the field is required.
- In toggle_active() method in hr.employee, set departure_date to
false when unarchive the employee.
- If user has a current running contract, a user error will raise if
user enter a departure date earlier than the start date of the
contract.
Add checkbox to set a closing date on hr.contract (hr.contract):
- In the hr.departure.wizard, set the departure date to be the end
date of runing contract. Set the states of all draft contracts to
"cancel".
Add checkbox to free car (hr.fleet):
- In the hr.departure.wizard, set end_date to
fleet.vehicle.assignation.log, if there is no end_date or end_date >
departure_date
- Go through fleet.vehicle, find records with dirver_id to be the
employee, set it to False.
Add checkbox to archive private address (hr):
- when the private address not link to a internel user, set
employee.address_home_id.active to Flase
- unarchive it after the employee unarchived
Add checkbox to cancel future appraisals (hr.appraisal)
- find all appraisals link to the employee and state in
['new', 'pending'], set their state to 'cancel'.
Add checkbox to cancel future leaves (hr.holidays):
- only consider leaves are not in state ['refuse', 'cancel'],
find leaves with to_date > departure_date, set their state to
'cancel'.
PR #42526
Task 2153106
Related: odoo/enterprise#7471
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Current activity types master data cannot be unlinked through a quite harsh
override of unlink using xml id existence, introduced at 2602642a78.
Some of them are real master data, other could be unlinked if users want it.
Finally custom activity types may cause errors when removed if used in some
side models like server actions or automated actions.
To allow more flexibility we remove the removal constraint and implement
a fallback mechanism. It is implemented in mail.activity.mixin when calling
activity_schedule(xmlid, ...). If the given xmlid is not found
_default_activity_type() specifies the default activity to use. It can
be overridden in modules if some specific behavior is wanted.
e.g.
def _default_activity_type(self):
"""Define a default fallback activity type when xml id not found
only used in in activity_schedule() for now.
"""
try:
return self.env.ref('mail.mail_activity_data_todo')
except Exception:
return False
In this commit we also
* restrict deletion of activity type (hr.plan and ir.actions.server);
* fallback on default activity type if xmlid ref not found in
activity_schedule;
* correct calls to activity_schedule and replace some manual creation calls
by activity_schedule;
Task ID 1961156
PR #39013
Related: odoo/enterprise#6238
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Since the introduction of the public/private employee model, having an
acitivity defined on hr.employee (the private one) for an employee that
has no rights to read it is useless.
Task id 2072987
closesodoo/odoo#37021
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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'`
Purpose
=======
If the fired employee has no access to the hr.employee model,
the departure wizard will lead to a traceback, as we try to
create an activity on a model for which the user won't be able
to resolve it.
Create an activity on the related partner instead.
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose of this merge is to avoid having to define custom activity types for
each step of HR onboarding plan. This is done by adding a summary field
on hr activities, allowing to use default Todo activity type and customize
directly the summary itself.
Using custom activity types is still possible. Here we allow to avoid noise
and having too much activity types defined as most of those activities can
be simulated using the default Todo.
People can still define and use their own activity types if necessary and
required in their daily workflow.
Commit linked to task ID 1923387 and PR #30235.
Recent merge d5fd84b89a added onboarding plans to employees with some
new models. However conventions for naming files and views are not done.
This commit fixes that to ensure code readability.
Commit linked to task ID 1923387 and PR #30235.
Purpose
=======
Give the possibility to elaborate plans through Odoo. For instance, in HR,
you could create an onboarding plan when a employee is created. Someone manages
laptop and other equipment, someone check hr stuff, ... This feature is generic
but in a first time we will apply it only on the hr module.
Ease HR process in a company by creating plans: a plan is an assembly of Next
Activities that will be launched together whenever you need it.
Example of plan for an employee onboarding:
Activity: Prepare materials
Responsible: Alain
Deadline: At the contract signature
Activity: Manage Cars
Responsible: Cécile
Deadline: at the contract signature (both signature)
Activity: Plan Training
Responsible: Caroline
Deadline: After signature
Activity: Training
Responsible: Employee
Deadline: 1 week after the employement date
Specifications
==============
On HR Configuration: Add a menu "Activity Plans"
Activity plan object:
- Name
- Model (debug mode) (hr by default)
- Activity Template o2m
- Activity Type (only the one related to hr)
- Deadline (come from Activity Type)
- Responsible \/
0 Coach
0 Manager
0 Other
[Responsible_name] \/ (coach, manager or manually set if other)
Add datas, 2 plans:
Onboarding
- Name: Onboarding
- Plan lines:
Activity: Setup IT Materials
Responsible: [a user] (manager)
Deadline: At the contract signature
Activity: Plan Training
Responsible: [manager]
Deadline: After signature
Activity: Training
Responsible: [Employee]
Deadline: 1 week after the employement date
Offboarding
- Name: Onboarding
- Plan lines:
Activity: Compute Out Delais
Responsible: [a user] (manager)
Deadline: today
Activity: Take Back HR Materials
Responsible: [manager]
Deadline: today
Activity: Manage Car
Responsible: [manager]
Deadline: today
When to trigger it ?
HR specific use case:
1/ On employee, from the employee chatter:
when you create an employee, Odoobot will log a note with the following message:
"Congratulations ! May i recommand you to setup an onboarding plan?", with a link
create a plan from it.
2/ Add a button 'launch plan' to open a wizard to select the plan
3/ When archive an employee
Open a wizard with:
- Reason (selection)
- Action plan (m2o not required)
Error if employee not linked to a user.
Task : 1912681
closesodoo/odoo#29151
Pulled back the weekly attendance report from the 4.2 branch
Removed theorical workhours and holiday workhours from the reports to make sure they can be printed even if only "hr" and "hr_attendance" are installed
bzr revid: ls@numerigraphe.fr-20090202182543-km4x5yp27d74ksk8
Kevin Baptiste