Purpose of this commit is to clean notification process: calls, methods
API, method name, variable propagation.
Contains notably
* simplify API of methods used to group recipients when sending notification
emails;
* improve and rename methods used in email notification process;
* move some methods on model itself as non mail thread records could be
mass-mailed and _notify_email_headers could be called on other records;
Related to task 1943901
Linked to PR #32404
- Activate multi-company
- Create a company B
- Switch to company B
- Create an allocation request
An access error is raised.
Commit 7f775f0677 added a `sudo` call in order to prevent an access
error. However, it implies that the fallback value `self.env.user`
refers to the SUPERUSER, not the current user anymore. If the current
user is not in the same company than the SUPERUSER, the multi-company
record rules will be triggered.
The fallback is changed to an empty recordset, and selecting the current
user is done out of the method called with `sudo`.
opw-2003137
closesodoo/odoo#33804
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Purpose
=======
Having a clean policy in leave access right. If there
are some internal need or bugs, read this before decided
if it is an expected brhavior or not. It is what we want
in a standrard point of vew.
Specification
=============
Access rights Policy
--------------------
Remove Time Off - Team Leader access right
Leave_manager_id is now requried, by default it
is = parent_id for admin it is admin by default (data
employee_admin)
3 access rights:
- Internal User
- Time Off - All Approver
- Time Off - Administrator
3 fields for "manager"
- parent_id
- leave_manager_id
- manager_id on department
Department
Is just there for information. So never use it in
default filters
Rules Policy
------------
Don't forget to take the leave type configuration into
account
* no validation means automatic
* officer validation means you need to be at least
holidays_user to approve
* manager validation means anyone who is at least
leave_manager_id can approve
Internal User
-------------
In double validation mode he:
- can only do the first approval
- can see the everyone's leaves with a anonymisation of
the leave description
- can create a leave (even if leave type is directly approved)
- can refuse its own leaves (till not reported in payslip)
- can reset to draft his own leaves and reconfirm them
- can delete a leave in draft state
- can cancel a leave if the date_start is in the future
- cannot validate its own leaves
If leave type is configured in manager mode, he:
- can approve or refuse the leaves if he is leave_manager_id
If leave type is configured in both mode, he:
- can only do the first approval or refuse for the leave
if he is leave_manager_id
Time Off - All Approver
-----------------------
In double validation mode he:
- can only do the second approval
- can see, write, read all leaves and perform the second
approval.
- Can set a leaves as reported in payslip.
- Cannot validate its own leaves
- cannot configure leave type
- cannot create leaves in batch
Time Off - Administrator
------------------------
In double validation mode he:
- can do all the approvals
- can bypass all leaves (approve or refuse).
- can configure Time Off Types
- can create batch leaves
- can validate its own leaves
Menu
----
- My Time Off (access rights: internal user)
- Dashboard
- Time Off Requests
- Allocation Requests
- My Team (rename into "Everyone", access rights: internal
user. default filters on current year and group by
employee; default view: gantt can switch to list and form)
- Managers
- To Approve (internal user who are leave_manager_id
see and can approve. See only leave he has to approve
(domain))
- Time Off
- Allocation
- All
- Time Off
- Allocation
- Payroll
- Time Off to report.
- Reporting (access right: time off administrator)
- Time Off Analysis
- Report by Department
- Configuration (access right: time off administrator)
Usability
---------
- In all list of "manager menus", add actions to change
status in mass
- In leave type data:
- move Home Working from data to demo data
- There are 2 Paid time off, get rid of the company on
it and share it on all companies (keep only the one
in data)
- Leave type like this:
- Overtime Compensation/compensatory days (keep only
one of both, to avoid having 2 same leaves in
demo data). Validation by: team leader and hr
officer, no validity date
- Paid Time Off 2019. Validation by Team Leader
and Payroll Officer. Remove validity, remove 2019.
- Unpaid. Can be taken in hours. Approved by Payroll
officer and team leader. No allocation needed.
- New leave request: order of leave type in the m2o:
1. leaves where allocation are fixed by rh and remaining
> 0 and allocated > 0
2. leaves where free allocation. Where reaming is > 0
and allocated >0
3. One already taken
4. All other leaves.
- Remove the sequence widget in leave type
- The employee should get a notification when his leave is
refused "Your "leave_type_name_" planned on "start_date"
has been refused"
- from the dashboard calendar, the reset to draft should lead
to edit (avoid user has to click on edit)
- An employee should be notified when a leave is approved
"Your [leave_type_name] on [start date] has been approved"
Leave Dashboard V2
------------------
https://drive.google.com/file/d/1pMCqDlecqM7ngvmhJJdWtkG2_GiXHyIX/view?usp=sharing
Testing
-------
Everything concerning the leave requests has to be tested.
All the access rights have been reviewed and need testing.
Migration
---------
Don't forget to keep the filters in the calendar view (otherwise RIP perfomances and usability)
TaskID: 1950998
closesodoo/odoo#33813
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>
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
=======
There are currently multiple ways to determine if an employee is presence
or absent:
- login state (user status on chat)
- checkin/checkout from the Attendance app
- leave
- hr_presence (email, ip)
Those states are displayed in several different places and can be inconsitent.
e.g. Logged in -> green in the chat
Not checked in -> red on the employee kanban view.
The multiple ways to determine employee presence described above
should be aggregated together to have a better consistency.
Specification
=============
There are 3 presence states (previously defined in module `hr_presence`),
namely `present`, `absent`, `to_define`. They are now defined as soon as
`hr` module is installed.
The state computation can have several behaviors according to which apps
are installed:
1. `hr` is installed
Check employee presence based on login by default (only for employees with
a user).
Kanban state (private and public): should be green when logged in, red when logged out and
orange when the user is away.
Private employee form: Display a stat button "Connected" on the form view
when the user is logged in or "Last Activity xx/xx/xxx" otherwise.
2. `hr_attendance` is installed:
when the user is logged out, the state
is determined from the checked in/out state. But when the user is logged in,
consider the user as present (even if he checked out).
Kanban state: green for checked in, red for checked out
Private form view: attendance stat button.
3. `hr_holidays` is installed:
Has the highest priority if the employee is on leave.
Kanban state: red if employee is on leave.
Private form view: stat button "Absent Until xx/xx/xxxx" if employee
is on leave.
4. `hr_presence` is installed:
Two additionnal presence checking option: emails sent and IP address connected.
Once a user sent an email or the IP address was connected, he is considered
present for the entire day.
There should be at most one stat button on the employee form view, with the
relevent information.
Task id: 2024482
closesodoo/odoo#34933
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Parentheses in the label of units of measure sometimes make
reading needlessly uncomfortable.
Specification
=============
Remove parentheses in the name of every standard uom.uom and hardcoded
occurence on views/field names.
TaskID: 2030444
closesodoo/odoo#34492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When a new request of leave is created, some fields are computed to
calculate if it's possible or not, to take the leave
(virtual_remaining_leaves, leaves_taken, remaining_leaves and
max_leaves).
These fields are computed using the fields :
allocation : hr_leave_allocation.number_of_days.
and request : hr_leave.number_of_days.
When a leave type is in hours, both of these fields are calculated
differently:
allocation: The allocation field is calculated dividing the number of
hours registered by the user per the average hour per working day.
(https://github.com/odoo/odoo/blob/d809b476819968837b61bdd78fbf101caac73adc/addons/hr_holidays/models/hr_leave_allocation.py#L236)
request : The request field is calculated by finding the real number of
requested days.
(https://github.com/odoo/odoo/blob/d809b476819968837b61bdd78fbf101caac73adc/addons/hr_holidays/models/hr_leave.py#L360)
If in the company each day have different working hour, then the number
of days calculated with the average hours didn't represent the real
number of days that the employee can take. This issue can avoid the
employee to take a leave even if he has the correct number of hours to
take it.
Now, the fields (virtual_remaining_leaves, leaves_taken,
remaining_leaves and max_leaves) are calculated using either the days
fields or the hours fields depending on the leave type.
opw-1972133
closesodoo/odoo#33244
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a leave type is in hours, before this commit, in the allocation
list the allocation is shown in days. The problem is that the number of
days its calculated with the average hour per day. If in the company
each day have different working hour, then the number of days calculated
with the average didn't represent the actual number of days that the
employee can take.
Now, in the allocation list, the allocation is shown either with days or
hours depending on the leave type.
opw-1972133
Purpose
=======
In Belgium, we need to support some partial time on 2 weeks.
For instance, a mid time, means you could work on monday, tuesday
and wednesday on week1 and monday and tuesday on week 2. Others payroll
softwares manage this.
Specification
=============
Add a checkbox on resource calendar to manage 2 weeks. --> Consider even/odd weeks.
Add sections on calendars (Like sales orders)
Modify methods in resources to apply this behavor generically.
Check that attendances aren't overlapped
Write an integration test for holidays - benefits - payslip
to check all this, + "credit temps" and wage modification.
Note
====
For the sake of simplicity, we only manage calendars over 2 weeks
to consider the odd/even weeks and keep an easy implementation.
For more complicated calendars (eg: over a months with specific targetted days),
it's better to create specific allocation requests and apply specific leaves
for those days, as it would be the case for parental leaves.
closesodoo/odoo#31674
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The number of hours in time off were computed based on a mean of
number of hours in a week. It can engendre problem if an employee
doesn't work with the same number of hours every day.
Now the number of hours are computed based on employee's calendar
and so the real number of hours are used.
closesodoo/odoo#33137
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- If the current user doesn't have write access to `hr.leave` or
`hr.leave.allocation` and tries to modify the manager (`parent_id`) of
a `hr.employee` record, an access right issue is raised.
This commit fixes the issue.
OPW-2000569
closesodoo/odoo#33542
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
When an allocation have as leave type hours, and have the mode different
from 'By Employee', the stored duration (in days) is calculated dividing
the filed number of hours by 8 (number of hours per days).
During the validation, an allocation is created for each employee that
match the mode chosen.
In these allocations, before this commit, the number of hours displayed
is calculated by multiplying the stored duration (in days) with the
average number of hours of the employee.
The problem is that in may cases the average number of hours of the
employee is different from 8, and the display number of hours is not
correct.
Now, the number of hours is calculated with 8 when the allocation is
created from another allocation.
opw-1972133
closesodoo/odoo#33675
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
In order to force the user to select a new leave_type when requesting a
leave for someone else. We reset its value in the `_onchange_employee_id`
Task : 1984487
Closes#32697Fixes#29806
Courtesy of @sswapnesh
closesodoo/odoo#33178
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
The goal of commit 2dbce5e was to handle the company
holiday type in onchange which was probably forgotten
when the company type was introduced.
However because the last `elif` was changed to `else`,
the `else` clause is executed in some situations where
it shouldn't.
e.g. If holiday type is `employee` and an employee is set,
the `else` clause is (obviously wrongly) executed.
This is particularly a problem if the employee is not
HR user nor manager. In that case, the field employee_id
is invisible and its value has been deleted by the onchange.
The allocation cannot be saved because it violates the
sql constraint (employee is null).
Also, the `mode_company_id` and `category_id` should be set
to `False` when the holiday type is not company/category.
1. Open form view to create a leave
2. Change the leave type to 'By department'
3. Choose the department of the current user
4. Save the leave
5. Approve the leave
=> ValidationError, cannot have two leaves at the same time.
In `@api.onchange('holiday_type')`, when choosing by department
it sets `employee_id`, `mode_company_id` and `category_id`
to `False` ONLY if the department is not already set.
But by default, the employee is set to the user's employee
and the department is set to the employee's department.
Therefore the employee is never set to `False` and the
department leave is linked to this employee.
When validating the 'department' leave, an 'employee'
leave is created for each employee in the department.
For the current user, it crashes because the deparment leave overlaps with
the 'employee' leave since the department leave is linked to
the employee.
- When changing the `holiday_type` of a leave allocation while having an
employee set and if this `holiday_type` has as its value `employee`
the field `employee_id` is set to False.
This is not the intended behavior. We want the field `employee_id`
to be filled if the `holiday_type` is set to `employee`.
closesodoo/odoo#32886
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
When a leave type is in hours, before this commit:
- in the leaves request list the request duration is shown in days.
- the name of the leave shown duration in days.
- the rounding after the conversion from hours to days, generates some
misunderstandings. If you have a day of 7.5 hours, and you take a leave
of 2 hours, it would be round it to 0.25 days, and not to 0.27 days as
it should be. This occurs because we round to the 1/16 of the day.
Now:
- in the leave request list, the request is shown either with days or
hours depending on the leave type.
- the name of the leave shown duration either with days or hours
depending on the leave type.
- the leaves are shown in the correct unit, there is not more
misunderstandings occurring because of the rounding.
related to commit : 5c33ebef5f and 2c366acbf0
opw-1974691
closes#29804closes#33290closesodoo/odoo#33369
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When approving a leave, to make an informed decision, it might
be needed to check leaves already taken by the employee or leaves
of its collaborators. This commit adds a widget displaying some stats
in a leave form view. Stats displayed are:
- the number of days taken
by the employee this year, grouped by leave type
- Leaves taken by employees in the same department in the month
of the leave.
This widget is only displayed in the context of the action leading
to leaves to approve.
This commit improves screens usability in the Time Off app.
The following points have been changed:
1. For leaves and allocations, add buttons on the kanban
card to directly approve or refuse if it's not already
validated.
2. On the leave kanban card, only display the dates,
not the full datetime.
3. Add a description to the activity created when a
leave/allocation needs to be approved by someone.
4. Allocation are now sorted in the list view, more recent firsts.
5. In the allocation form view, add a stat button to know
how many leaves has been allocated and how many has been taken
for the allocation leave type. The button redirects to the employee's
leaves of the leave type. Only shown for holiday type 'emloyee'.
6. In the leave form view, there are currently two duration fields
for managers. The readonly duration is an informative field for regular
employees and the editable duration is meant for managers, it's used if
the number of days needs to be manually set for some reason.
Make sure the manager only sees the editable duration fields.
7. From "My Dashboard", the creation form view should not be the
manager form view (default view) which has additional unecessary fields
when requesting a leave for yourself (`employee_id`, `holiday_type`, ect).
It's now showing the form view for regular employees.
Task 1961713
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- The creation of leaves using "no validation" are not possible
if the `SUPERUSER` is not in the "Holidays / Team Leader" because
the validation is made using `sudo`.
OPW-1951316
closesodoo/odoo#31952
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
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>
RomainLibert