Attendance Reopen Request Storage

Summary

A reopen request stores a proposed correction to an employee/date Attendance outcome and its terminal review decision.

Audience

• Backend developers, QA engineers, managers, and support engineers

Reference Content

Persisted lifecycle

The object contains tenant, employee, date, optional Attendance identifier, current and requested status/hours, reason, request status, requester, optional manager, reviewer, decision time, rejection reason, and created/updated times. Pending can become approved or rejected.

The composite index supports employee/date/status lookup but is not unique. The workflow checks for an existing pending request before insertion, so one pending request is an application-only rule and remains race-sensitive without a database unique constraint. Future-date rejection and payroll-lock checks are also application/service boundaries, not schema constraints. The optional Attendance identifier has no modeled foreign key or cascade action.

Source References

• microservices/src/attendance-service/Domain/Attendance/AttendanceReopenRequest.cs
• microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
• microservices/src/attendance-service/Infrastructure/Persistence.cs
• microservices/src/attendance-service/Application/Services/ReopenRequestWorkflow.cs

Related Articles

• Attendance database
• Attendance technical documentation
• Attendance API documentation

See Also

• Attendance business documentation
• Attendance overview

Keywords

• Attendance persistence
• EF Core
• PostgreSQL

Revision Information

• Status: Draft
• Last reviewed: 2026-07-15
• Review cycle: Quarterly