| Age | Commit message (Collapse) | Author |
|---|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
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
|
|
This is a simple renaming without adaptation.
|
|
* Fix alignement/layout problems since the reintroduction of
bootstrap grid gutter.
* Fix mobile layout problems.
* Fix various Firefox problems.
* Use odoo variables and simplify LESS.
* Use input type="text" instead of input without type.
|
|
* Remove use of flex for kanban record layout (text overflow ellipsis
could not work in row wrap flex layout as flex would prefer to wrap its
elements than add an ellipsis inside its content)
* Fix xml templates (double use of o_kanban_image + non-existing class)
|
|
Mainly fixes for the follow button and move css to less
|
|
Removed fields and code related to the display of groups and employee
suggestions. This impacts notably the model of res.users in mail and
hr.
|
|
|
|
The kanban view has been split in various files, and js modules
using them need to correctly import the classes.
|
|
removed useless icon-* classes of old font-awesome
|
|
picker, add domains on reports and style improvements
|
|
This commit introduces a new view type, the timeline view. This view is
intended to display messages like the previous chatter. This is now a view
like the form or list view. Like other views it will be possible to have
custom templates for some specific needs, allowing customization.
[IMP] mail: the value tracking is modified. Previously messages were created
containing the modified values. Those values are now stored, using a new
model mail.tracking.value. The message body is dynamically build based on
the values. Tests have been updated.
This version is temporary. Indeed two main modifications will come in a short
future :
- the new design will improve the display
- the slack mode will change the way the Inbox and notifications are managed
All glory to the Hypnotoad.
Special thanks to Valerie Pirenne (vpi), Jerome Maes (jem) and Richat Mathot
(rim) that did not code but said a lot of things. Martin Trigaux (mat) did
nothing, a bit like for the slides modules, but he is busy sending emails.
|
|
|
|
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
|
|
|
|
|
|
|
|
hr add a simple kanban view that is updated by the various hr modules.
Each module adds statistics and links in the kanban vignette, either
in a to do or to approve column.
The department kanban view can be seen as a small dashboard to have
the main data about the department displayed. Links allow the HR
manager to be redirected towards the various things to do or to
approve in its department.
|
|
|
|
especially when using the group-by. Added a missing 'row', used an img-responsible
class instead of a fixed width.
|
|
|
|
|
|
|
|
|
|
unnecessary, worked by accident and broken by change to interpolation regex in 35f5fb46
|
|
|
|
|
|
|
|
|
|
bzr revid: mat@openerp.com-20130702095014-boktf79ocopibi0t
|
|
bzr revid: al@openerp.com-20130628100441-swpanf2jwcojygh4
|
|
bzr revid: mat@openerp.com-20130621075406-d9syftu04k8iytcz
|
|
Those are now 2 widgets extending web.Widget, included inside a Sidebar widget.
bzr revid: tde@openerp.com-20130515103518-2djzogjdtjh0n7rl
|
|
bzr revid: mat@openerp.com-20130403152443-3jqg0v182mcqsk0f
|
|
bzr revid: mat@openerp.com-20130403151056-4vjno2k9n77drm6y
|
|
bzr revid: mat@openerp.com-20130403143243-e0bysy0sqy90i2io
|
|
bzr revid: mat@openerp.com-20130403142716-lmsz9hwkg7tathly
|
|
bzr revid: mat@openerp.com-20130320111520-fmz14if4k400s9s4
|
|
bzr revid: mat@openerp.com-20130311164829-vd8wuwh1657s0vjt
|
|
bzr revid: fp@tinyerp.com-20121126203154-ubkwzc1cpgur4nyf
|
|
bzr revid: fp@openerp.com-20121121230513-5qtw1ci29sz07a5x
|
|
bzr revid: psa@tinyerp.com-20121023060126-k6m0o0bfk9gnqf2s
|
|
bzr revid: psa@tinyerp.com-20121010063335-n7n0j6cytjinavxs
|
|
bzr revid: fva@openerp.com-20120920154645-lctwfo0tbaxsobwg
|
|
bzr revid: al@openerp.com-20120906175616-0bpm1yhb5rrsi44u
|
|
bzr revid: al@openerp.com-20120906104624-sq3cd652vevmij6c
|
|
bzr revid: tde@openerp.com-20120730141034-nyb8qcixcd72rdja
|
|
bzr revid: mit@openerp.com-20111223152935-cta0qlc2kt7g079h
|
|
bzr revid: mit@openerp.com-20111216161433-dg1quduz0v2tgwbo
|
|
bzr revid: mit@openerp.com-20111213142329-42f4h5tto0mf6dqi
|
