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
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
As Marc Demo, at the begining of the month, through
the client action, you can checkin but not checkout.
There is one limitation in the way the attendance state is computed:
It uses the attendance with the most recent checkin date.
Therefore, if an attendance is created in the future, it's the later
attendance which is taken into account, not the current attendance.
Steps to reproduce the problem:
1. Create an attendance in the future with both start and end
date set.
2. Through the client action: checkin
=> the client action stays on the checkin screen because you are
considered as checkout. Hence you cannot checkout.
It's difficult to change the way the state is computed, especially
having the right triggers.
Adding a constraint to avoid attendance in the future is probably a
bad idea. It could unintentionaly fail if the user's time is off by
a few minutes on his computer.
On the other hand, this situation should rarely happen (only when manually
creating an attendance, which has little functional sense).
Solution: Fix demo data to avoid attendances in the future.
Tests needed to be adapted because they used demo data. They no longer
use demo data.
- 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.
Kevin Baptiste