This commit adds a new model `hr.attendance.overtime`.
When an employee checks out, an overtime entry will be created when:
- the option is enabled on the company;
- the employee worked more or less than the number of hours they
were supposed to work that day.
TaskID: 1904850
Users with the rights 'Manual Attendance' get (read-only) access to their
own attendances.
closesodoo/odoo#66934
Taskid: 2438863
Related: odoo/upgrade#2216
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps:
- As admin, go to Settings > Users & Companies > Users
- Edit Mark Demo (demo)
- In Human Resources > Attendances, select Manual Attendance or blank
- As demo, go to My Profile
- Click the smart button showing the hours worked for the last month
- Remove all filters
Bug:
The demo user, who hasn't the rights to see the other employees
attendances, can see them.
Explanation:
Every user must have the right to read attendances in order to see their
own attendances. Not giving the users the read rights in the security
record rule prevents the record rule from being applied when reading
attendances. This makes the read access rights the only rule and allows
everyone to see the attendances of the others.
This commit also fixes the default selected employee when going to the
attendances tree view on these paths:
- User
- Employee
- User > Employee
In fact, sometime, `active_id` is the ÌD of the user and not of the
employee. This leads to incorrect results since another employee's
attendances are shown.
Finally, this commit prevents users from creating attendances from other
apps since only attendance officers and above can have access to the
creation form within the Attendances app.
opw:2440117
closesodoo/odoo#65334
X-original-commit: b3247c81200200590d669b76a58d06e6adf66d69
Signed-off-by: backspac <backspac@users.noreply.github.com>
Before this commit, a user with attendance administrator rights can see
the attendances of all users of all companies and not only the companies
he is allowed.
Now, the administrator will only see the attendances of the users of the
companies he is allowed.
opw-2263577
closesodoo/odoo#52355
X-original-commit: 0e8f86795db74fe21daa8776243415291371fdf6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
It's the unique group needed for a kiosk attendance. Avoid to give
to much rigths.
id=2088561
closesodoo/odoo#38954
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
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.
- Migration to new API
- MODEL : hr.attendance now has check_in and check_out datetimes plus a computed field worked_hours, no more action (in/out) and no more reason.
hr.employee has extra fields: pin and barcode and can print a badge containing that barcode.
- the module contains : -> a menu "My Attendances" to check yourself in or out manually.
-> a menu "Manage Attendances" with 3 submenus:
- "Attendances" where you can edit attendances
- "Employees" where you have a kanban view of the employees (to see who's checked in or print badges)
- "Kiosk Mode": fullscreen, made to be at the entrance of companies to allow
all employees to check in and out, either with a barcode scanner to scan your badge
or by selecting them in a kanban view and checking in or out manually with or without
entering their PIN. (enable/disable in Configuration)
-> a menu "Configuration" where you can change enable/disable PIN use.
- GROUPS : -> HR manager (base.group_hr_manager): full access to the attendance module.
-> HR officer (base.group_hr_user): full access except the "Configuration" menu.
-> Manual Attendances (base.group_hr_attendance): only access to the attendance menu "My Attendance" to check in and out manually in the back-end
-> Employee (base.group_user): has no access to the attendance module. (should only check in and out through the "Kiosk Mode" put at his disposal)
- Views adaptation to the new fields, addition of a presence indicator (green/red dot) to employee kanban and form views.
- sales_team: demo data enable sales team features to users
- hr_attendance: admin can enable attendance features from hr settings
- multi_company: if admin enable these features, she gets the
multi-company usability settings
- account: enabling multi-currency functionalities enable pricelist
functionalities
ir.rule records are in noupdate data blocks to let the admin
alter them without fear of them being reset at next update.
Other records such as groups are in normal mode, so they
can be updated whenever necessary
bzr revid: odo@openerp.com-20121218232001-t425t4hi7qbmsip2
Kevin Baptiste