Skip to content

Latest commit

 

History

History
206 lines (172 loc) · 6.99 KB

README.md

File metadata and controls

206 lines (172 loc) · 6.99 KB

Role Based Notice System

A PHP-based web application for managing notices with a multi-role approval workflow.

Features

  • Multi-Role System: Super Admin, Admin, Principal, HOD, Teacher, Student.
  • Notice Workflow: Role-based creation, approval, rejection, and publishing pipelines.
  • Leave Management System: Faculty can apply for OD (On Duty) leaves, routed through HOD and Principal for multi-level approval.
  • Salary Certificate Request: Teachers can request salary certificates digitally; Principals examine and sign them resulting in an official printable document.
  • User Profile Management: Built-in credential management allowing all roles to update personal details (Name, Email, Department) and securely change passwords.
  • Modern UI Redesign: Engineered with a responsive dark-charcoal sliding sidebar, dropdown groups, smooth transitions, and a minimalistic grid-card layout using TailwindCSS.
  • Notifications & Dashboards: Dashboard aggregators containing pending requests, badge counts, and notifications.

Setup

  1. Import setup.sql into your MySQL database.
  2. Configure database credentials in config/db.php.
  3. Serve the application via XAMPP/Apache.

Default Credentials

All users have the password: password123

  • Super Admin: superadmin
  • Admin: admin
  • Teacher: teacher
  • Student: student

System Documentation

1. System Overview

The Role Based Notice System is a web application designed to manage the lifecycle of notices within an educational institution. It features a multi-tiered approval workflow involving Super Admins, Admins, Teachers, and Students.

2. User Roles & Responsibilities

Role Access Level Responsibilities
Admin Highest - Manage system users, supervise global notices.
- Register new accounts and handle legacy system mappings.
Principal High - Final approval authority for Salary Certificates and Faculty Leaves.
- Oversight of all departmental activities.
HOD Medium-High - First-level approval for Departmental Leaves.
- View Teacher and Student directories for their specific department.
Teacher Medium - Apply for OD Leaves and Salary Certificates.
- Review/Publish notices to Students.
- View assigned Student directories.
Student Low - View published notices.
- Mark notices as read (automatically tracked).

3. Authentication Flow

The system uses session-based authentication with role verification.

sequenceDiagram
    participant U as User
    participant L as Login Page
    participant C as AuthController
    participant D as Database
    participant S as Session

    U->>L: Enter Username, Password, Select Role
    L->>C: POST /login (username, password, role)
    C->>D: Query User by Username
    D-->>C: Return User Data (Hash, Role)
    C->>C: Verify Password Hash
    alt Password Valid
        C->>C: Verify Selected Role matches DB Role
        alt Role Match
            C->>S: Store User ID, Role in Session
            C-->>U: Redirect to Role Dashboard
        else Role Mismatch
            C-->>L: Show Error "Role Mismatch"
        end
    else Invalid Password
        C-->>L: Show Error "Invalid Credentials"
    end
Loading

4. Notice Workflow (State Machine)

Notices go through a strict approval pipeline.

stateDiagram-v2
    [*] --> PendingAdmin: Super Admin Creates Notice
    
    state PendingAdmin {
        [*] --> AwaitingAdminApproval
        AwaitingAdminApproval --> AdminApproved: Admin Approves
        AwaitingAdminApproval --> AdminRejected: Admin Rejects
    }

    state AdminApproved {
        [*] --> AwaitingTeacherAction
        AwaitingTeacherAction --> TeacherPublished: Teacher Publishes
        AwaitingTeacherAction --> TeacherRejected: Teacher Rejects
    }

    state Rejected {
        AdminRejected --> PendingAdmin: Super Admin Edits & Resubmits
        TeacherRejected --> AdminApproved: (Hypothetical Re-review)
        TeacherRejected --> PendingAdmin: Recovers to Draft/Edit
    }

    TeacherPublished --> [*]: Visible to Students

    note right of PendingAdmin
        Visible to: Super Admin, Admin
    end note

    note right of AdminApproved
        Visible to: Admin, Teacher
    end note

    note right of TeacherPublished
        Visible to: Everyone (Final State)
    end note
Loading

Detailed Workflow Steps:

  1. Draft/Creation: Super Admin creates a notice. Status is set to pending_admin.
  2. Admin Review:
    • If Approved: Status becomes admin_approved. Notified: Teacher.
    • If Rejected: Status becomes admin_rejected. Notified: Super Admin (with reason).
  3. Teacher Review:
    • If Published: Status becomes teacher_published. Notified: Students.
    • If Rejected: Status becomes teacher_rejected. Notified: Admin.
  4. Resubmission: Super Admin can edit admin_rejected notices, resetting status to pending_admin.

5. Database Schema

The system maps users, notices, logs, and interaction data.

erDiagram
    USERS ||--o{ NOTICES : "creates"
    USERS ||--o{ LEAVES : "applies"
    USERS ||--o{ SALARY_CERTIFICATES : "requests"
    DEPARTMENTS ||--o{ USERS : "contains"
    
    USERS {
        int id PK
        string username
        string full_name
        string email
        string password
        enum role
        int department_id FK
    }
    
    NOTICES ||--o{ NOTICE_LOGS : "has history"
    NOTICES ||--o{ READ_RECEIPTS : "viewed by"
    NOTICES {
        int id PK
        string title
        text content
        enum status
        int created_by FK
        text rejection_reason
    }

    LEAVES {
        int id PK
        int user_id FK
        date leave_date
        enum status
    }

    SALARY_CERTIFICATES {
        int id PK
        int teacher_id FK
        date from_date
        date to_date
        enum status
    }

    NOTICE_LOGS {
        int id PK
        int notice_id FK
        int performed_by FK
        string action
        string old_status
        string new_status
    }

    NOTIFICATIONS {
        int id PK
        int user_id FK
        string message
        boolean is_read
    }

    READ_RECEIPTS {
        int id PK
        int notice_id FK
        int student_id FK
        timestamp viewed_at
    }
Loading

6. Directory Structure

The application follows a simple MVC (Model-View-Controller) pattern:

  • config/: Database configuration (db.php).
  • public/: Public entry point (index.php) and assets.
  • src/: Application source code.
    • Controllers/: Logic for handling requests (AuthController, NoticeController, DashboardController).
    • Models/: Database interactions (User, Notice, Notification, Log).
    • Views/: HTML templates.
      • auth/: Login pages.
      • dashboard/: Role-specific dashboards.
      • layouts/: Shared header/footer.
      • notices/: Forms for creating/editing notices.
  • setup.sql: Database initialization script.