How reshist/homs-app works
Purpose and Runtime
HOMS is a Flutter/Dart mobile client for hostel out-pass requests and authority review. It is intended for Android and depends on a PHP API backed by MySQL; neither backend code nor database schema is present here. The application entry point is main.dart.
Role-Based Access Boundary
Login is split by user role—student, CA, HOD, VP, and warden—indicating role-specific authentication and navigation rather than a shared generic portal. Primary screens are screens/login/student.dart, screens/login/warden.dart, and screens/login/hod.dart; equivalent CA and VP entry screens exist alongside them.
Student Request Lifecycle
Students initiate and track their own passes through the student area. screens/student/pass-apply.dart is the request-submission boundary, while screens/student/pass-history.dart presents prior request outcomes. screens/student/profile.dart represents the student account/profile surface. README notes these Android capabilities remain under development despite being functional in the referenced web application.
Authority Workflow and State Queues
Passes move through explicit status partitions: pending, approved, and declined. Each authority role has separate views in screens/pending-pass/warden.dart, screens/approved-pass/hod.dart, and screens/declined-pass/vp.dart (with parallel CA/HOD/VP/warden files). This layout makes approval/rejection a role-scoped workflow, with status changes persisted through the PHP/MySQL backend and reflected back to student history/status views.
Role Dashboards and Student Review
Authority landing areas are role-specific dashboards: screens/dashboard/ca.dart, screens/dashboard/hod.dart, and screens/dashboard/warden.dart. Detailed student inspection is likewise role-partitioned in screens/student-details/ca.dart, screens/student-details/vp.dart, and screens/student-details/warden.dart. The likely control flow is login → role dashboard → status queue → student/pass detail → approve or decline.
Warden Administration
The warden area owns management-oriented capabilities beyond reviewing requests: screens/warden/add-pass.dart, screens/warden/add-department.dart, and screens/warden/add-student.dart. Supporting listing/management screens, screens/warden/pass.dart and screens/warden/department.dart, imply warden control over pass types and department/student reference data consumed by pass application and review flows.
Integration Boundary
All mobile screens are UI-layer Dart files under screens/; no in-repository API client, state-management layer, backend implementation, or notification provider is visible in the supplied tree. The material external boundary is therefore Flutter client calls to the PHP API, which owns authentication, request status, approval decisions, and MySQL persistence. “Real-time status updates” are a product requirement, but the implementation mechanism is not evidenced here.
Main entry points: ca.dart Role dashboards · student.dart Role login screens · pass-apply.dart Pass application · pass-history.dart Pass history
Components 15
Flutter mobile client
- App entry
main.dart - Role login screens · Separate entry points exist for student, CA, HOD, VP, and warden.
screens/login/student.dart
Student flow
- Pass application
screens/student/pass-apply.dart - Pass history · Shows request outcomes and status.
screens/student/pass-history.dart - Student profile
screens/student/profile.dart
Authority workflow
- Role dashboards · Role-specific landing areas for CA, HOD, and warden.
screens/dashboard/ca.dart - Pending pass queue · Role-scoped requests awaiting review.
screens/pending-pass/warden.dart - Approved pass queue
screens/approved-pass/hod.dart - Declined pass queue
screens/declined-pass/vp.dart - Student/pass review · Role-partitioned student inspection before a decision.
screens/student-details/ca.dart - Pass type management
screens/warden/pass.dart - Department management
screens/warden/department.dart - Student administration
screens/warden/add-student.dart
External backend
- PHP API · Owns authentication, request status, and approval decisions.
- MySQL · Persists users, reference data, and pass workflow state.
Connections 19
- App entry → Role login screens: starts
- Role login screens → Pass application: student access
- Role login screens → Role dashboards: authority access
- Pass application → PHP API: submits request
- Pass history → PHP API: loads status
- Student profile → PHP API: loads account
- Role dashboards → Pending pass queue: opens queue
- Pending pass queue → Student/pass review: inspects request
- Student/pass review → PHP API: approve or decline
- PHP API → Approved pass queue: approved state
- PHP API → Declined pass queue: declined state
- PHP API → Pass history: updated outcome
- Role dashboards → Pass type management: warden management
- Role dashboards → Department management: warden management
- Role dashboards → Student administration: warden management
- Pass type management → PHP API: manages pass types
- Department management → PHP API: manages departments
- Student administration → PHP API: manages students
- PHP API → MySQL: persists state