PURPOSE
=======
When you start a new trial of an app without demo data, you
want to have everything perfect and ready for your own configuration
closesodoo/odoo#122308
Taskid: 3328654
Related: odoo/enterprise#41423
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The introduction of Milk has brought new app icons.
Using the svg format creates a lack of anti-aliasing on the edges of the
shapes, which makes the icons look bad.
Since the png size has been reduced, we can afford to use the png format
to have the best possible quality without having a lack of performance.
task-3326633
Part of task-3326263
X-original-commit: e07cb722f2b11407a3ad093bd688b7d37afd5a88
Part-of: odoo/odoo#121886
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>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
- Reset skill levels on skill/skill type change
- Improve form view
- Add a sequence on hr.skill
closesodoo/odoo#73305
Taskid: 2575351
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To avoid mixing both plan and planning in hr plan options it was decided
to reword menus to plan instead of planning.
TaskId-2664863
Part-of: odoo/odoo#78148
- Currently all menus are out of order in app switcher.
- For example, Sales app is 16 menu away from Accounting,
Social Marketing app is 25 menu away from Email Marketing, etc.
So, all menus should be reordered.
- This commit will reorder the menus of the app switcher in order to reduce
the distance between correlated applications,
and bring the most common apps upward.
- And in this commit we have left gap of 5 subsequent sequence for further new menus.
PR: #69984
TASK ID: 2513082
Related: odoo/enterprise#17989
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Steps to reproduce the bug:
- Let's consider a user U with employee officer access rights
- Log with U and go to Employee in debug mode
Bug:
The following menus
- Configuration/Challenges
- Configuration/Departments
- Configuration/Goals history
were not accessible
opw:2450931
closesodoo/odoo#66365
X-original-commit: 02d32aa9936cb0d9a1248bb866a31f4a40a0eac2
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The work location of an employee was previously a fields.Char. That was
changed to a Many2one field to a the new model called work.location.
That had some consequences in other modules that had to be slightly
adjusted. The modules impacted were hr, hr_appraisal, hr_payroll.
Task id: 2335646
closesodoo/odoo#63192
Related: odoo/enterprise#15235
Related: odoo/upgrade#2020
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Reason: In Employees app, it is confusing for the first time users to see
both 'Employees' and 'Employee Directory' folder. Also, first user
is not assigned to any departments.
Solution: If the user can see the folder 'Employees', don't show
the folder 'Employee Directory'. Assign the first user to the
'Administration' department.
Task - 2377506
closesodoo/odoo#63038
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=========================
The goal of this task is to set up some kind of guidelines to make
kanban views consistent.
It is fine having different kanban views, but if a UI element is shared
among several kanban views, it should behave/look the same so the user
knows what to expect.
Kanban views can be split into two types:
==> 'documents' kanbans, such as res.partner, crm.lead, etc.
- those records are created/edited often, numerous
- 'opening' the card means accessing the record
==> 'dashboard' kanbans,such as stock.picking.type,account.journal, etc.
- those records are not created/edited often, there are much less numerous
- usually presented as dashboard, where 'opening' the card means
accessing a set of related 'documents' (clicking on a account.journal
to access account.move, or stock.picking.type to access stock.picking)
- configuration of the 'card record' is done through a dropdown to
access configuration
Here are some guidelines for consistency. Bear in mind that those are
not rules, but guidelines for consistency that we'd like to keep in
mind when designing.
==> 'documents' kanbans
- the record is accessed through global click
- the user avatar is at the bottom right
- the activity widget is at the bottom left (in last position if
there are other elements)
==> 'dashboard' kanbans
- the record is accessed through a 'Configuration' option in the card dropdown
- there is no global click, and therefore no focus shadow
- the dropdown icon (o_kanban_manage_toggle_button) is always visible,
with icon fa-ellipsis-v
- the listview counterpart should be presented as a dedicated
configuration menu, and shouldn't be in the 'dashboard action'
- links in the body of the card are structured as follows: link with
<count>+label, then any additional aggregated metrics (not link) to the right
example https://drive.google.com/file/d/1ZP6HDHTtC7cQ6rDWgqLoPs6U8JCeNVkW/view?usp=sharing
==> global guidelines
- the title font color is #212529, with 500 weight
- the subtitle font color is #666666, with 400 weight
- the font size is 1.083rem
- text overflow is handled through linebreak, not ellipsis
- numerical values are aligned to the right
- the kanban state widget is at the bottom right
SPECIFICATION
=================
AS per guidelines Improved follwing kanban/dashbaord view
- hr_job
- hr_department
- hr_work_entry
- hr_appraisal
- fleet_vehicle
- product_template
- sale_subscription_template
- crm_team
- res_partner
- event
- stock_picking_type
- mrp_eco_type
- maintenance_team
- quality_alert_team
- account_journal
Added the department menu on employee with default kanban view
Added sequence in hr_work_entry list view
TaskID: 2206372
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10341Closes: #50536
Without hr_recruitment it was not possible to import/export the hr.job
as they were not visible.
closes#22069closesodoo/odoo#39948
Taskid: 2088277
X-original-commit: e4de2b2e56ba188e45c5c18e4f25cca515fcb306
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1/ web: adapt formatDate to handle NaN values
DashboardRenderer might return NaN for `Date` or `DateTime` fields if
their original value is null or incorrect.
2/ hr: add job_title in demo data
3/ hr_recruitment: link employee in the chatter for new recruits
4/ hr: remove employee documents in the model
5/ hr_attendance: improve resiliency of relative_time
6/ hr: display manager on res_users
7/ hr: change Address Book to Employee Directory
TaskID: 2009111
closesodoo/odoo#34180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The field job_id is displayed in the tree view but it was not available in the form view
like in 12.0. So it was not possible to change it.
opw:2006084
closesodoo/odoo#33933
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Purpose
=======
1/ Robustness & security: right now it is not easy to understand and do something
clean in term of security (hr people vs employees, private info vs public). A
HR officer doesn't know if he can write something on the chatter. Currently, a
note will be visible for all the employees who have access to the employee form
view for example.
2/ In term of business, it makes sense to let a hr manages payroll stuff (contract,
employees private information, ... and other employee see public information
(résumé and work information)
Specification
=============
Introduce 2 new models:
- hr.employee.base (AbstractModel): This represents the basic skeleton
model on which the shared fields and methods between the public and
the private employees models.
- hr.employee.public (_auto=False): This is a sql view based on the
employee values, readable for an internal user (i.e. an employee).
The model hr.employee is not readable anymore for an employee.
There are now 3 ways to access the employee data:
1/ From the hr.employee views. HR officer access rights are required
2/ From the public profile. The public data for an employee are accessible
but can't be modified.
3/ From the 'My Profile' menu. A classic employee can access its own
data from there, and can modify them.
The activity view has been added on multiple models (invoice, fleet
contract, vehicles, leads, employee, contract, expense, expense sheet,
leave, leave allocation, applicant, partner, product, task, purchase
order, sale order) to ease the creation and the management of
related actvities.
Task 1894990
Like other models with a chatter (sales, stock, ...) it is possible to
schedule activities on employees. Scheduling an activity add the
activity to the activity menu (top-right *clock* button) where activities
are classified as *late*, *today* or *future* and grouped by
application. Clicking any of the three class on an employee activity
shows all activities regardless of their class.
opw-1957013
closesodoo/odoo#32657
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In the user preference, change the timezone of the user to blank (False value)
Save
Before this commit, a cryptic error was raised because the field tz in
resource.resource is required
Note that when writing on res.user, we write some fields (including tz)
on hr.employee, which is a resource.mixin, and therefore uses resource.resource
After this commit, we make the field required in the view
OPW 1934462
closesodoo/odoo#31312
Compute notice duration and if the notice duration is not respected,
a report about termination fees is generated.
At the end of the notice duration, we can generate a certificate
about time off not taken and an other about time off for the next
year.
TaskID: 1914556
- hr.job receives the favorite functionnality.
- Now, a newly created hr.job is favorite by default.
- hr.job receives a new field new_application_count that computes
the number of applications which are new in the flow for that job
(1st step of the recruitment flow).
- hr.job kanban boxes now display the field described just above.
- hr.job kanban boxes are now clickable and thus open related applications in a kanban view.
- Views are modified according to the images given in the related task (see Task ID below).
These changes are details such as modifying strings that are displayed or their position
in the view, or again icons that are displayed.
-> Note : Check related task to see decisions that have been made concerning these images.
- Search on Email on hr.applicant has been separated so that it is clearer.
- Rename old view crm_case_form_view_job into hr_applicant_view_form
Task ID : 1896305
Purpose
=======
If the activities are available on a model (i.e. inherits mail.activity.mixin),
add a progress bar based on the activities if nothing is defined yet.
closesodoo/odoo#24777
[IMP] hr_*: introduce the employee profile
================================
## 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. The Profile will show the employee of the current company.
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.
## Changed modules
### hr_attendance
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 hour.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 1 hour on the kanban view
### [ADD] hr_attendance_presence
Bridge module between `hr_attendance` and `hr_presence`.
This PR 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
[ADD] hr_skills: Introduce a new module for employee resumé and skills
=======================================================
Purpose
-----------
Consultancy companies need resumé and skills of their consultants.
For big projects, they often need to send them to their customers.
These information are also useful to statistics.
Specification
-----------------
### New models
#### `hr.resume.line.type`
Types of resumé lines. e.g. *Experience*, *Education*, *Hobbies*
#### `hr.resume.line`
It is a line in the resumé of an employee.
#### `hr.skill`
Name of a skill. e.g *French*, *Python*, *Piano*
#### `hr.skill.type`
Skills can belongs to a particular type. A skill type has skill levels associated.
e.g. *Languages*, *Dev*, *Music*
#### `hr.skill.level`
Levels available for a particular skill type. Each level has a label
and a progress (between 0 and 100) associated.
e.g. *Intermediary (20%)*, *Advanced (85%)*, *Expert (100%)*
#### `hr.employee.skill`
These are skills which employees have. It links an employee with a particular skill
and level.
e.g. Mitchell has an *Intermediary* level in *Python*
### Access Rights
Only a `hr_user` can create/edit `hr.resume.line.type`, `hr.skill`, `hr.skill.level`, `hr.skill.type`.
If employees are allowed to edit their infos (setting), they can also create/edit `hr.resume.line`,
`hr.employee.skill` for themselves.
### UI
Resumé lines are displayed, grouped by type, in a new 'Resumé' tab in the employee
form. Resumé lines can be reordered (handle widget)
Emloyee skills are displayed in the Resumé tab, grouped by skill type.
[IMP] hr, hr_holidays, hr_expense: Change onchange parent_id behaviour
=========================================================
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.
Task 1913089
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#30502
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
=========
{Any employee can work on a PoS session, even if he has no user. This decreases the cost of PoS App.}
We are not competitive enough on the PoS Market because customers have to pay one user per cashier while they expect to pay one user per cash station.
===============
SPECIFICATIONS
===============
pos.config
- Add a checkbox : "Login with Employees"
- If set to TRUE, an "Allowed Employees" many2many appear
- If employees many2many is empty, all employees can log on this PoS
- If set to FALSE, can only log in with the currently logged user
hr.employee
- The barcode and pin fields were be moved to the hr.employee
- Set a barcode (not pin) by default at the creation of any employee
- No Employees module with PoS > dependency to hr
Open the PoS if "Log in with Employees" = FALSE
- Same behaviour than now, when I open the PoS, I'm logged in with the current user and can start working at once. The only difference is that it is not possible to switch users anymore.
- The button to close the session is visible
Open he PoS if "Log in with Employees" = TRUE
- When I open the PoS, the first screen I see is the login screen.
(a) I choose my employee and enter my pin code (if there is pin code on my employee, otherwise not required) (I can only see employees that have access to that PoS)
(b) I scan my barcode
(c) I scan my rfid card (future development)
- When I click on the employee name, I can log in with another employee
- If the employee is linked to a user that has the pos user/manager access right, I can see the button the close the session. Otherwise I cannot close the session (and thus cannot access backend).
- Add field employee on all records created by PoS (and replace the field user by that one) (on pos.orders)
Lock Screen
- Improve the PoS Interface
- Add a new feature to allow to "lock" the session. When a session has been locked, the user/employee has to re-log-in to access the PoS
- When I try to re-log-in, by default suggest the last employee logged in in the login screen
Migration
Plan a migration strategy > barcode and pin is now on the employee and not on the user anymore
closesodoo/odoo#28567
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
Some fields are missing to ease configuration and daily use of plan and plan
activity types.
While we are at it some xml ids are updated according to guidelines.
Commit linked to task ID 1923387 and PR #30235.
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.
hr_prensence add a menu 'reports' in employee app and
hr_contract_dashboard add a 'Reporting' menu.
Merge both together.
closesodoo/odoo#32377
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
A lot of companies don't use the module hr.attendance but are faced
to employees distraction, they forget to record leaves.
In big companies, it is not easy to controle presence and
check if everyone is present in the office.
Specification
=============
1/ Review Human Resources menuitems
- Employees
- Contract
- Department
- Reports
- Employee Presence
- Configuration
- Settings
- Employee
- Tag
- Contract
- Types
- Templates
- Challenges
- Challenges
- Badges
- Goal History
2/ Add option in hr settings to decide the company policy
[ ] Controle Presence of Employees
[ ] According the system login --> Based on the bus presence (Present if 'away' or 'online')
[ ] Following number of sent emails --> Based on the sent mail.message during the day
[ ] According to the IP address --> Based on the ip address when requesting a long polling, stored on a res.users.log
3/ Add an employee presence view
This view is only for the hr manager and the data is computed when the hr manager goes to it
Clicking on this menu item will generate all kanban of employees grouped by state (present, absent, to define)
On each employee cart, an action can be requested as:
- Send a sms to the employee
- Send an email to the employee
- Create a leave for the employee
4/ Use this email template to contact the employee
Dear %(employee_name)s,
Exception made if there was a mistake of ours, it seems that you are not at your office and there is not request of leaves from you.
Please, take appropriate measures in order to carry out this work absence.
Do not hesitate to contact your manager or the human resource department.
Best Regards,
Purpose
=======
Currently when searching on a department (on the employee view for example)
we only retrieve employees from the specific department. It should return
all the employees from the department and also from its children
departments, like for partners or companies.
Specification
=============
Adapt all the search view where a department field is used by
specifying a 'child_of' operator.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated
* employee main menu actions;
* leave and allocation request main menu actions;
* applicant main menu actions;
* expense and expense report main menu actions;
* contract main menu action;
* attendance employee main action;
Following @est-odoo advice the Next Activities menu entry in hr_recruitment
is removed as there are already a lot of ways of managing activities: using
the systray, using activity view present on most actions, ...
This commit is linked to task ID 1889413.
Yannick Tivisse