jawadzafar1045/attandance_system_based_on_qr

1. Overall shape

- This repo is split into two independently built apps: an Express/Node backend in backend/ and a React/Vite frontend in frontend/.

- The system is an employee attendance and HR workflow platform centered on role-based access and server-side attendance validation.

2. Backend is the core business/API layer

- backend/server.js is the composition root: it wires environment config, database connection, middleware, and the route modules.

- Routes are organized by domain: auth, attendance, employee, leave, document, office, onboarding, and settings.

- Controllers implement the business actions, while middleware enforces authentication and role checks.

3. Identity and authorization boundary

- backend/controllers/authController.js plus backend/models/User.js handle registration/login and JWT issuance.

- backend/middlewares/authMiddleware.js protects authenticated endpoints, and roleMiddleware.js separates admin-only flows from employee flows.

- The frontend mirrors this with AuthContext.jsx, which holds the signed-in user/session state and drives route/UI access.

4. Attendance check-in flow

- Attendance is recorded through the attendance route/controller and persisted in backend/models/Attendance.js.

- The product’s key security idea is static QR + IP validation: the QR code initiates the check-in flow, but the backend decides whether the request is valid based on the employee’s network/IP and office rules.

- This means the trust boundary is server-side; the QR scanner is just an input mechanism, not the security gate.

5. Office/network configuration

- Office-wide network rules are managed through backend/models/OfficeConfig.js and the office controller/routes.

- The README’s flow shows admins creating allowed IP ranges such as localhost or office subnets; those ranges are what attendance validation checks against.

- This is the main control point for “location” enforcement in the system.

6. Employee administration

- The employee subsystem uses backend/models/Employee.js and employeeController.js for CRUD-style management.

- The frontend exposes this as admin screens like EmployeeList, EmployeeDetail, and EmployeeForm.

- This is clearly an admin-owned lifecycle: create, view, edit, and review employee records.

7. Leave management

- Leave is modeled with a small cluster of entities: LeaveRequest, LeaveBalance, and LeaveType.

- Admin-facing pages like LeaveRequests and LeaveCalendar suggest the backend supports both approval workflows and planning/reporting views.

- The employee-facing side includes MyLeaves and ApplyLeave, indicating a self-service request flow with admin review.

8. Document vault and file handling

- Document upload/storage is split across documentController.js, Document.js, multerConfig.js, and cloudinary.js.

- The architecture here is: upload through Express/multer, then store or reference files in Cloudinary rather than keeping everything local.

- Admin and employee document views (DocumentVault, MyDocuments, ExpiringDocuments) imply document lifecycle management, not just raw uploads.

9. Onboarding and task scheduling

- Onboarding has its own domain with OnboardingTemplate and OnboardingInstance models plus matching routes/controllers.

- The frontend includes OnboardingDashboard, OnboardingDetail, and MyOnboarding, so this is a full workflow rather than a one-off form.

- Utilities like scheduleIncomplete.js, seedOnboarding.js, and emailService.js suggest background reminders and notification-driven onboarding progression.

10. Settings and operational config

- Settings.js and settingsController.js indicate system-level configuration separate from office-specific config.

- This is likely where defaults, policy values, or feature toggles live, while OfficeConfig handles network/location rules.

- The split matters architecturally: global behavior vs. office-scoped behavior.

11. Frontend structure

- The frontend is organized by audience: admin pages under src/pages/Admin and employee pages under src/pages/Employee.

- AdminLayout.jsx provides the admin shell/navigation, while Html5QrScanner.jsx supports QR capture on the client.

- App.jsx and main.jsx are the entry points that stitch routing, auth state, and page composition together.

12. Frontend-to-backend communication

- API calls are centralized in src/services/*.js files, which wrap backend domains such as employees, leave, documents, onboarding, and settings.

- This keeps pages thin: UI components call service modules, and service modules call the backend REST API.

- The result is a clean boundary between presentation logic and business/API integration.

13. Persistence and data model layer

- The backend uses a model-centric data layer under backend/models/, with separate entities for attendance, users, leave, onboarding, settings, office config, and documents.

- The README mentions Firebase, but the repository structure reads like a conventional Express app with application-owned domain models and a dedicated DB config in backend/config/db.js.

- For architecture diagrams, treat the backend as the system of record for all operational data.

14. Automation, seeding, and CI

- seed.js, fixLeaves.js, and the utilities under backend/utils/ support bootstrapping and maintenance tasks.

- GitHub Actions are split by tier with separate backend and frontend CI workflows, reinforcing the repo’s two-app structure.

- Deployment hints on the frontend side include vercel.json, suggesting the UI can be hosted independently from the API.

15. Primary end-to-end data flows

- Admin signs in → JWT issued → admin configures office IP rules, employees, leave policies, onboarding, and documents.

- Employee signs in → frontend scans static QR or submits attendance action → backend validates JWT, role, duplicate-day constraints, and IP range → attendance record is stored.

- Admin and employee dashboards then read back from the same backend models for reporting, history, and workflow progress.