Purpose of this commit is to simplify fields used in leave and allocation
used to store the duration of the requests. We want notably to get rid
of "number of days temp" that, contrary to its name, is not temporary
at all as it stores the real number of days. We also want to clarify
the hours or days encoding that is different on leave and allocation models.
Specifications
* number_of_days on leave and allocation is the master field holding the
leave or allocation duration in days;
* two fields are used for interface that are suffixed by _display in order
to indicate they are UX only: number_of_hours_display and number_of_days_
display. They are interface fields used for the user and correct number
of days is computed and stored in number_of_days;
* more specifically for leave model
* display fields are readonly as it is computed based on dates given by
the user, directly (from / to) or indirectly (half-day leaves for example);
* duration field is computed through an onchange. It could be directly
set by hand by managers if some confusion in the number of days appear;
* more specifically for allocation model
* display fields trigger an inverse as they are the real duration given
by HR officers or managers;
* duration field is computed through the inverse of display fields;
Various reports, data and use of leave / allocation models are updated to
use the correct field.
This commit is linked to task ID 1876795 and PR #26571.
Purpose of this commit is to simplify the configuration of leave type and
use the job of HR officers / manager by making options clearer and easier
to use.
Specifications for leave type :
* display name as header;
* remove accrual option from leave type. It is now configured directly
on allocation requests;
* add a "X days allocated" stmart button. If you set a general allocation
of 20 days, the stat button will display 20 days. Even if you go update
the allocation by employee after that. Purpose is to have the value of
main allocation done in group, not individual cases of some employees;
* add a "Group leaves" stmart button. It leads to a new leave requests
in group mode where mode is visible;
* have a unique allocation type field replacing the setting allowing to make
leave or allocation as well as limit and negative fields;
* limit leave duration encoding to two options, either day-based (allowing to
take full days or half a day), either hours-based (allowing to take full
days, half a day or some specific hours in a given day);
More technically
* limit and negative fields are removed. It was confusing as limit set to
True means you can actually exceed the limit). It can be computed based
on allocation_type ('no' meaning you can bypass the limit);
* request_unit is simplified. Day and half are merged into day;
* accrual and balance limit are moved to allocation model;
Specifications for allocation requests
* set accrual specific on allocation itself and not coming from the leave
type configuration anymore. Indeed we now consider accrual to be done
case by case independently from the leave type;
* remove negative and balance_limit. Indeed we now consider people have to
check by hand what is done by accrual;
Leave and allocation are slightly impacted by other changes, such as domain
for default leave types. Changes have been made as small as possible. Future
commits will still improve leave and allocation models and views, going
further in the cleaning process. Some tests are udpated to match the new
configuration of leave type.
This commit is linked to task ID 1876795 and PR #26571.
Purpose is to clean a bit the code to prepare some incoming modifications.
More specifically this commit focuses on removing unused views and actions
to lessen future work in shaping them like requested.
This commit contains :
* small linting of leave fields;
* remove some unused and unnecessary views and actions;
* ensure default values for request_unit_all;
* small linting of tests;
This commit is linked to task ID 1876795 and PR #26571.
Purpose
- clean access rights;
- solve some access and security issues;
Access specifications
- an user
- can see all leaves;
- cannot see name field of leaves belonging to other user as it may contain
private information that we don't want to share to other people than
HR people;
- can modify only its own not validated leaves (except writing on state to
avoid bypassing validation);
- can discuss on its leave requests;
- an Officer
- can see all leaves;
- can validate "HR" single validation leaves from people if
- he is the employee manager;
- he is the department manager;
- he is member of the same department;
- target employee has no manager and no department manager;
- can validate "Manager" single validation leaves from people if
- he is the employee manager;
- he is the department manager;
- target employee has no manager and no department manager;
- can first validate "Both" double validation leaves from people like "HR"
single validation, moving the leaves to validate1 state;
- cannot validate its own leaves;
- a Manager
- can do everything he wants
In top of that, multi company rule are correctly added.
In reporting model using in "summary" name field should also be stripped
if you are not an HR officer and if it is not your own request.
Concerning allocation requests: implement same rules except constraint on
name field as it is less private and therefore can be seen.
This commit is linked to task ID 1876795 and PR #26656.
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
We need to support the accrual allocation for leaves.
This is a special type of allocations that adds some leaves to the
allocation every X amount of time worked.
This kind of allocations is especially used in the USA, but can also be
used in other contexts (eg: In Belgium we could allocate 20 days per
year for the legal leaves)
These allocations have support for :
* A max balance limit
* Going in negative (if set on the leave_type and the manager
approves the leaves)
* Removing the unpaid leaves from the quantity of days worked
* Setting an end date after which it does not allocate anymore leaves
Task #46114Closes#22292
As we have two parallel tasks changing the rights for the approval of
leaves, we have to make sure that it stays coherent.
Basically by default an hr_holiday manager can approve anything and the
hr_holiday officer can only approve the leaves of his department and
cannot approve his own leaves.
But you can override this behaviour by setting the Validation By to
"Manager" which will force the leave to be approved by an hr_holiday
manager.
Cache invalidation when subscribing people has been added at e6f038a821.
Indeed subscribing partners to a record may lead to an access right update
as some of them are based on followers. This is why a cache invalidation
is necessary to avoid access rights issues.
However subscribing people to a record should change their rights only on
the records involved in the subscription mechanism. We can therefore give
ids to the cache invalidation to limit to updated records.
Cache invalidation is also limited when writing on followers if writing
on model, res_id or partner_id fields. Indeed changing subtypes or
channel of a subscription should have no impact on cache and access rights.
Cache invalidation done manually in _message_subscribe is not necessary
as subscription create or update mail.followers records since f9c210923d.
Create and write of mail.followers records already ask for cache invalidation.
It is therefore not necessary to invalidate cache twice.
This commit allows to save a few queries on some tests, notably about
activities that deal with subscription and messages. As cache is now kept
it is not necessary to refetch some data, leading to a few query gain. We
gain about 1K queries on com runbot.
A side effect of limiting cache invalidation is that some unit tests require
a manual cache invalidation to have up to date results. Indeed record not
being up to date in cache was hidden by the invalidation we just removed.
We need to have a clear distinction between holidays managers and
holidays officers.
For this a number of improvements have been done in hr_holidays.
For more informations about the changes see the docstrings of hr.leave
and hr.leave.allocation.
Task #34222Closes#19270
We would like to have an overview of project forecast that include
leaves, for this we need to implement several kind of 'leaves' directly
in resource module.
These kind of 'leaves' can be defined via the hr.leave.type model (only
visible in base.group_no_one (choices currently are 'leave' and 'other')
* Add field time_type on resource.calendar.leaves
* Add a domain restriction that allows for filtering on this field
* Add tests
In order to help limit leaves recording errors. We need to add some
configuration on leave type object. For example we need to avoid people
taking legal leaves 2016 on 2017.
* Add validity dates : start and end dates on the leave type. An empty
end date means forever
* Double validation : change the checkbox into a radio button with now
three choices :
- Human Resource Responsible
- Manager
- Double Validation
* Add a sequence field, using handle widget
* Add a field, to specify if the employee can select the leave type in
his allocations, requests or in both of them
Purpose
=======
Have a clear distinction between leave and allocation requests instead of
using the same model to mix 2 different concepts.
Splitting the model will allow different business code to be run on each
model as allocations and leaves are not exactly the same thing; this
will add some code but simplify future improvements
Specification
=============
1/ Completely separate the models
Model hr.holidays has been split into leave.request and
leave.allocation.
2/ Make reporting working again by using an SQL view aggregating data
from leaves and allocations
A new report has been added in order to aggregate
datas from both allocations and requests. The views have been modified
accordingly.
PURPOSE
=======
For each and every Hr application there should be one user category (One app = one category).
SPECIFICATION
=============
HR remains as it is : Employee, Officer, Manager
Each Application should have 2 access rights: User and Manager. Example for Recruitment:
- The user has access to the recruitment process
- The manager has access to the job position configuration
Each Application should grant the employee user access right (Namely the 'HR Officer')
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.
Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.
addendum to commit da6b9d1be443999028f021ff81b4cf128a4eaaa2
- better employee name and image for default employee in data (xml-id: hr.employee_root)
- in demo data hr.employee_fp renamed to hr.employee_root to not have 2 employees linked to the root user
- renamed all occurences of employee_fp to employee_root
Since base.user_root has 2 employees (one in demo, one in data).
The method _compute_leaves will use the employee id forced in context.
The test should be improved later.
Maybe not 2 employees for same partner...
Like xmo-odoo suggests, stop add Model attribute and other
variables on `self` in test cases. It makes the code unclear
and difficult to understand the test case.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
- added a workflow transition from refuse to draft, to allow resetting
a refused request
- resetting is now based on a can_reset field, taht is based on whether
it is my own request or I am an hr manager
- added an access right on crm_meeting that was preventing hr officers
to validate some requests
- improved form view to show reset to draft button accordingly
- added tests that helped trigerred the various bugs and improvements
bzr revid: tde@openerp.com-20130809144752-o21pjbc56o0t8fym
Thibault Delavallée