Below is the diagram of the components that are there in the HCM App and attendance package, and how the interaction happens:
Add attendance package dependency in pubspec.
Create a bloc that extends the attendance listener class and creates the override methods.
Create model classes that import attendance models and add companion class.
Create repositories local and remote as per project requirements and structure.
Add typedef for repositories in untils/typedef.
Initialise repo in network manager, and create oplog.
Create SQL tables in case of offline.
Add navigation to manage the attendance page from the HCM app, and pass the required fields.
This module helps in marking the attendance of the field users (referred to as attendees), who are supposed to work on the campaign till the campaign is live.
ROLE: DISTRICT_SUPERVISOR
This module has 3 associated screens:
Manage Attendance
Date and Session Selection
Mark Attendance
Once the supervisor clicks on the “Manage Attendance” button, the supervisor is taken to the attendance registers mapped to them. The attendance registers are to be created manually, by taking a combination of the project, and the supervisor or staff member is mapped to it.
.
Field
Description
Campaign name
Name of the campaign.
Event type
Type of event where attendance is done, that is training or distribution.
Start date
Start date of the campaign.
End date
End date of the campaign.
Status
If the end date is passed, the status will be inactive, or if the register status is inactive, the status will be inactive, else, the status will be active.
Staff count
Number of attendees in the register.
Attendance completion
Shows the number of days for which attendance has been submitted submitted to the server.
Fetch all attendance logs for the register.
Based on the sessions configured for the register, check for the logs where the entry time and the exit time are equal to the start and the end time of the session.
For individuals who do not have logs that are the same as the start and the end time will be by default marked as absent if any of the individuals' logs is present for the register.
//generateDateList will return the map of completed attendance Dates.
list = generateDateList(
e.attendanceRegister.startDate!,
e.attendanceRegister.endDate!,
registerCompletedLogs ?? [],
e.attendanceRegister.additionalDetails?["sessions"] != 2,
);
var completedDaysCount =
e.attendanceRegister.additionalDetails?["sessions"] == 2
? list.length ~/ 2 //for registers with 2 sessions
: list.length; ////for registers with single session
The date selection range commences from the start date of the attendance register and extends to the end date of the register or today's date if today falls before the end date of the register.
If the attendance for a past day is already submitted, then the CTA must change to view attendance from mark attendance.
Upon selecting the attendance register, a list of completed dates is generated. We iterate over the dates from the start date to the current date, checking for any missing dates in the list to identify missed attendance dates.
The trainees or supervisors should be able to mark the attendance daily twice (one for entry and exit) against each register (default configuration for sessions).
Supervisors can mark half-day, full-day, and absent - Definitions of the statuses are as follows:
Not marked: Default status in the register. This must be the status when the user has not taken any action on the line item.
Present: Tapping once must change the "Not Marked" status to 'Present' (Not Marked —> Present).
Absent: Tapping twice must change the 'Present' status to 'Absent' (Not Marked —> Present—->Absent).
Half-day (Only if config requires attendance once a day): Tapping thrice must change the absent status to half-day (Not Marked —> Present—->Absent—-> Half Day).
Save and Mark Later: If the user marks attendance for 10 out of 50 people, and clicks on save and mark later, the supervisor should be able to reopen the given attendance register while it is active and see the status of the attendance marked as per the last time they updated the screen.
Submit: If the user marks attendance for 10 out of 50 people, and clicks on submit, an error message is shown to mark attendance for all staff. After marking attendance for all staff, and clicking on submit, the supervisor navigates to the attendance recorded acknowledgement screen.
For the registers, for which attendance is submitted, we have a flag upload_to_server for each log. If this is true, then the attendance for the register is submitted.
As we cannot send absent logs to the server, we filter the present and half-day logs, and create the oplog for those.
For each marking, two log objects are created for sending to the server: ENTRY and EXIT as shown below:
[{
"registerId": registerId,
"individualId": attendeeList.individualId,
"time": entryTime,
"type": "ENTRY",
"status": "ACTIVE",
"tenantId": tenantId,
"documentIds": []
},
{
"registerId": registerId,
"individualId": attendeeList.individualId,
"time": exitTime,
"type": "EXIT",
"status": "ACTIVE",
"tenantId": tenantId,
"documentIds": []
}]
/health-attendance/v1/_search
POST
/individual/v1/_search
POST
/health-attendance/log/v1/_search
POST
/health-attendance/log/v1/_create
POST
