Some fixes coming from V9 revision 2be1dfc1ed7c9814cd3dbf4eb4cc95f842f738c2. The
purpose is to avoid to send emails in batch and to limitate automatic
subscription.
- add a context key to use the email queue for notifications linked
to allocations created in batch. This way emails will be send asynchronously
and will not create a deadlock when having a lot of allocations to process.
- also fixed a missing context in a browse
The stat button 'Leaves' on the employee's form view displays the total number
of leaves (including holidays allocations and leave requests). When the button
is clicked, only leave requests are show, which makes inconsistent the number
displayed with the list of results. This fixes this behavior.
opw-640349
The validation of leaves was broken because it relies on a check on the
remaining days. The problem is that the latter uses an old-api function field
that is not recomputed yet at the time of the validation. The fix consists in
using a non-computed field instead.
Indeed using fromkeys with a list / dict as argument leads to the creation
of shared list / dict. This could create some ugly side effects when
used in loops. This commit fixes or cleans this kind of statement to avoid
unwanted side effects.
Nor modify once approved
It wasn't possible for employees to approve their holidays themself, thanks to the GUI, but this was possible through xmlrpc calls, or when altering the html directly in the browser.
Besides, this was also possible to edit the holiday through the same trick once the holiday validated
In the Employee form, a remaining legal leaves field is available, which shows remaining validated leaves from allocation requests
As this is not allowed to delete a validated allocation requets, it shouldn't be possible to reduce the validated remaining leaves of an employee.
To reduce the remaining leaves of an employee, the user should cancel and remove the allocation request
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
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
This instance was not actually exploitable for
SQL injection as it is not callable directly
via RPC and guarded by other queries when indirectly
called. Still plain awful.
The number of leave requests left is based on the employee_id key in the context, when displaying the status of an hr.holidays we don't have the information in the name_get of the hr.holidays.status.
The fallback on the number of employees is done with the uid but we can not rely on it as well as the name_get on m2o field is done with superuser_id.
bzr revid: mat@openerp.com-20140508124946-ttyr84iajg9q6l0y
- Access Right too restrictif for user
- Bug UI between Firefox and Chrome
- Bug UI many2many_tag cursor on bullet
- Temp Fix on email_template to manage partner_to
- Manage attendee from hr_holidays
- Manage avatar_model in sidebar_items for filter (res.partner was hard coded)
- Remove quick add from HR-holiday, because some field (as day) is calculated on event "onchange"
bzr revid: jke@openerp.com-20131220141855-mbhxtr07fn0sroe0
Otherwise, the user who creates the allocation request by employee tag will benefit of the leaves he just entered, twice if he has the employee tag, once if has not the employee tag(and in this last case, he should not have this leave allocation, as he do not have the tag
bzr revid: dle@openerp.com-20131211180025-pg8kf13bt6d1vk9l
The check_holidays() validation was not working correctly
because it was called both before and after inserting new
leave requests, with inconsistent results.
Using it as a fixed constraint is simpler.
bzr revid: odo@openerp.com-20131015165416-in0rfd7rrjmekv0g
- 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
starts in confirm
from confirm, possible to get back to draft with reset signal, calling old set_to_draft, now
renamed holidays_reset, in the same workflow
from draft, possible to go to confirm
bzr revid: tde@openerp.com-20130805113023-1cs1s18dd5m4mi20