> For the complete documentation index, see [llms.txt](https://docs.digit.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digit.org/health/ph-v1.7/deploy/configuration/ui-configuration/attendance-management.md). # Attendance Management ## **Overview** 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** ### **User actions** This module has 3 associated screens: 1. Manage Attendance 2. Date and Session Selection 3. Mark Attendance ## **1. Manage 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. . #### Data Field to Manage Attendance Screen: | **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. | #### Attendance Completion Days Logic: 1. Fetch all attendance logs for the register. 2. 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. 3. 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` ## 2. Date and Session Selection 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. #### Missed Attendance Logic: 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. ## 3. Mark Attendance 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). 1. 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). 2. 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. 3. 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.
#### **Marking attendance and sending to oplog logic implementation:** 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": []` `}]` ## API Details
End PointRequest MethodRequest Info
/health-attendance/v1/_searchPOST
curl --location --globoff '{{base_url}}/attendance/v1/_search?tenantId=mz&staffId={{individualId}}&referenceId={{projectId}}' \
--header 'Content-Type: application/json' \
--data '{
        "RequestInfo": {
        "apiId": "mukta-services",
        "action": "",
        "did": 1,
        "key": "",
        "msgId": "20170310130900|en_IN",
        "requesterId": "",
        "ts": 1513579888683,
        "ver": ".01",
        "authToken": "{{token}}"
    }
}
'
/individual/v1/_searchPOST
curl --location 'https://unified-dev.digit.org/individual/v1/_search?limit=1000&offset=0&tenantId=mz&includeDeleted=false' \
--header 'Content-Type: application/json' \
--data '{
    "RequestInfo": {
        "authToken": "fc30d219-1075-4ee0-93af-8dc987f18b1c"
    },
    "Individual": {

```
    "id":[{{listOfIndividualIds}}],
    "tenantId":{{tenanatId}}
}
```

}'
/health-attendance/log/v1/\_searchPOST
curl --location '' \
\--header 'Content-Type: application/json' \
\--data '{
"RequestInfo": {
"apiId": "mukta-services",
"action": "",
"did": 1,
"key": "",
"msgId": "20170310130900|en\_IN",
"requesterId": "",
"ts": 1513579888683,
"ver": ".01",
"authToken": "{{token}}",
"userInfo": {
"id": 324783744763,
"uuid": "01b5b303-9e80-49d7-9d65-396675f0591e"
}
}
}'
/health-attendance/log/v1/\_createPOST
curl --location '' \
\--header 'Content-Type: application/json' \
\--data '{
"RequestInfo": {
"apiId": "mukta-services",
"action": "",
"did": 1,
"key": "",
"msgId": "20170310130900|en\_IN",
"requesterId": "",
"ts": 1513579888683,
"ver": ".01",
"authToken":"{{token}}"
},
"attendance": \[
{
"registerId": {{registerId}},
"individualId": {{individualId}},
"time": ,
"type": "ENTRY",
"status": "ACTIVE",
"tenantId": {{tenantId}},
"documentIds":\[]
},
{
"registerId": {{registerId}},
"individualId": {{individualId}},
"time": ,
"type": "EXIT",
"status": "ACTIVE",
"tenantId": {{tenantId}},
"documentIds":\[]
}
]
}
'
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.digit.org/health/ph-v1.7/deploy/configuration/ui-configuration/attendance-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.