SLMT Technology  ·  LMS Platform Portal Demo

Academic Setup

The complete backbone of the ERP. Every feature — attendance, assignments, feedback, exams — requires the Academic Setup chain to be configured correctly first. This page covers all 8 pages across admin/ that define your department's academic structure.

graph LR
    A[academic-years.php
Create Year] --> B[classes.php
Create Classes]
    B --> C[subjects.php
Add Subjects]
    C --> C2[bulk-subjects.php
Bulk Add Subjects]
    C --> D[allocations.php
Allocate Teachers]
    D --> D2[bulk-allocation.php
Bulk Allocate]
    B --> E[divisions.php
Manage Year Codes]
    B --> F[course-names.php
Manage Course Names]
    D --> G[All Modules Unlocked
Attendance · Feedback · Marks]

Page 1: Academic Year Management (`admin/academic-years.php`)

The very first step before anything else in the system can be used. The Academic Year (e.g., 2024-25) acts as a universal label that organises all data — classes, timetables, reports, and records — into isolated annual blocks.

  • Single Active Year — Automatic Deactivation:
    Only one year can be designated as "Current" at any time. When an administrator marks a new year as current, the system automatically removes the current label from all previous years before applying it to the new one. There is no risk of two years being active simultaneously.
    Core Benefit: Transitioning from one academic year to the next is a one-click, zero-downtime operation. Every dashboard, report, and data view across the portal automatically reflects the new year immediately.
  • Deletion Safety Guard:
    Before a year can be removed, the system automatically counts how many classes are already registered under it. If any exist, deletion is blocked entirely and the administrator is shown exactly how many classes would have been affected — e.g., "Cannot delete. Used by 12 class(es)."
    Core Benefit: Prevents irreversible data loss. Years with active academic data can never be accidentally deleted, regardless of the user's permission level.
  • Duplicate Year Code Prevention:
    Each academic year has a unique code (e.g., 2024-25). Before any year is saved, the system checks whether that exact code already exists. On edits, it correctly ignores the current record itself during the check — so re-saving an existing year never produces a false duplicate warning.
  • Optional Date Range:
    Each year can optionally store a formal start date and end date. This enables the portal to display date ranges on official reports, certificates, and university-submission documents, making them compliant with institutional formatting requirements.
  • Form Security on Every Action:
    All Add, Edit, and Delete operations require a unique, one-time security token that is verified server-side before any change is made. Delete actions trigger a JavaScript confirmation step as an additional safeguard, preventing accidental or malicious removal triggered by a simple link click.

Page 2: Class Management (`admin/classes.php`)

The foundational hierarchy of the entire department. Every student enrollment, timetable slot, attendance session, and teacher allocation is permanently linked to a Class. A class is uniquely identified by the combination of: Course Name + Year Level + Division + Academic Year.

  • Four-Point Duplicate Prevention:
    Before a new class is created, the system checks across all four defining fields simultaneously. If a class with the exact same course, year level, division, and academic year already exists, the creation is blocked. This makes it impossible to accidentally have two "TY-BCA Div A 2024-25" entries in the system.
  • Auto-Generated Short Name:
    The system automatically builds a standardized display label (e.g., "BCA - TY (A)") from the individual fields the HOD types in. This label is stored alongside the class and used consistently across every dropdown, report, and export in the portal — no manual reformatting required anywhere.
    Core Benefit: Every dropdown across the entire portal — Allocations, Attendance, Reports, Timetable — automatically shows the correct, consistent class name without any additional configuration.
  • Strict HOD Data Isolation:
    Each HOD can only view, edit, or delete the classes they personally created. Even if someone tries to manipulate a web form to access another HOD's class data, the system verifies department ownership on every write operation and silently rejects any unauthorized change.
  • Collapsible Folder Hierarchy (UI):
    Instead of displaying all classes in a flat list, the interface groups them into an expandable tree: Course → Year Level → Division. Clicking on a course name expands only that course's year levels; clicking a year level expands only its divisions. No page refresh is needed at any step.
    Core Benefit: A department managing 24 divisions across 8 courses becomes instantly navigable. The HOD can focus on just "TY-BCA" and see its 3 divisions, without scrolling through an overwhelming flat list.
  • Live Student & Teacher Headcounts:
    Each class card automatically shows the current number of actively enrolled students and the number of distinct teachers assigned to that class. If a newly created class shows "0 Students", the HOD immediately knows that student enrollment is still pending — without running any separate report.

Page 3: Subject Syllabus Management (`admin/subjects.php`)

Subjects are the atomic link between a teacher's work and student records. Every assignment posted, attendance session taken, and feedback form submitted is tagged to a specific subject. Subjects must exist before teachers can be allocated.

  • Verified HOD Identity at Every Step:
    The system verifies the HOD's identity against the teacher records table on every page load. If no matching record is found (e.g., a mis-configured user account), the page stops loading immediately with a clear error message, preventing any orphaned or unowned subject records from being created.
  • Year Code Validation from Live System Config:
    When adding or editing a subject, the available "Year Level" options (FY, SY, TY, etc.) are always loaded live from the system's Divisions configuration table. This means HODs can only enter subjects for year levels that are officially activated in the system — preventing invalid data from entering the subject library.
    Core Benefit: Year-level vocabulary stays perfectly synchronized. If an institution activates a new program (e.g., a "PG" level), it immediately becomes available in Subject Management without any code change.
  • Assignment Quota & Compliance Tracker:
    Each subject can have a defined maximum number of assignments required for the semester (e.g., 5 assignments). The system compares this quota against the actual number of assignments the teacher has posted in real-time. The status indicator on each subject changes colour automatically: ● Green when on track, ● Yellow when approaching the deadline, ● Red when the quota is missed.
    Core Benefit: Automated syllabus compliance — the HOD can see at a glance whether every teacher is meeting their assignment delivery targets, without manually checking or asking.
  • Subject Type Classification (Theory vs. Practical):
    Each subject is classified as either Theory or Practical. This type is used directly by the Timetable Builder's Auto-Allocate engine, which ensures theory subjects are only scheduled into lecture periods and practical subjects are only placed into designated lab periods.
  • Safe Deactivation (No Hard Delete):
    Subjects are never permanently deleted. Instead, they can be toggled inactive. An inactive subject is immediately hidden from all assignment creation forms, attendance marking interfaces, and teacher dropdowns — but all historical records attached to it (past attendance, old assignments, feedback) remain intact and reportable.
    Core Benefit: Removing a discontinued subject from active use does not erase years of historical academic data linked to it, keeping all university audit records intact.

Page 4: Bulk Subject Manager (`admin/bulk-subjects.php`)

A high-speed subject entry tool built for the start of each new semester, when an HOD needs to add or update 8–12 subjects for a class in one session rather than one at a time.

  • Live Spreadsheet-Style Editor:
    After selecting a Course and Year Level, clicking "Load Subjects" instantly pulls all existing subjects for that class into an editable table — no page reload. New blank rows can be added at the bottom. Existing subjects appear slightly shaded to visually distinguish them from new additions.
  • Safe Overwrite Logic — No Accidental Duplicates:
    When saving, the system intelligently decides what to do with each row: if the row is an existing subject, it updates it. If the row is new but a subject with the same name already exists for that course/year, it updates that match instead of creating a second copy. Only genuinely new subjects trigger a fresh creation.
    Core Benefit: The HOD can safely click "Save" multiple times. All changes are processed as a single, all-or-nothing operation — if one row encounters an error, all changes are rolled back together, leaving data in a clean state.
  • Non-Destructive Row Removal:
    Clicking the remove button on an existing subject row only removes it from the current editing session. A clear warning dialog explicitly tells the user that the subject is not being deleted from the system — preventing accidental data loss for users who assume removing the row also deletes the record.
  • Detailed Save Report:
    After every save, the system shows a precise breakdown of what happened: "Added: 5. Updated: 3. Errors: 0." If any rows had issues, the notification bar turns yellow (warning) instead of green (success), so partial failures are immediately obvious.

Page 5: Teacher-Class Allocations (`admin/allocations.php`)

The routing engine of the entire ERP. This page determines which teacher has access to which class for which subject. Without an allocation, a teacher cannot mark attendance, post assignments, view feedback results, or enter marks for a class — they are completely invisible to it.

  • Collision-Safe Subject Assignment:
    Every new allocation is saved inside a protected block. Before inserting, the system checks whether the same subject is already linked to the same class for the current year — using a case-insensitive, whitespace-trimmed comparison to catch near-duplicates. If a match is found, the teacher on the existing entry is simply updated, rather than creating a conflicting second record.
    Core Benefit: Prevents "split-brain" scenarios where two teachers both believe they are the assigned teacher for a subject. The system enforces one-teacher-per-subject-per-class as an unbreakable rule.
  • Class Teacher Role:
    An allocation can be marked as a "Class Teacher" role. This allows designating a teacher as the administrative guardian of a class even if they don't teach a specific subject. If no subject is entered for a Class Teacher allocation, the system automatically assigns a generic label to prevent blank records.
  • One-Click Full Teacher Interchange:
    A dedicated tool allows the HOD to instantly swap the complete workload between two teachers for the entire academic year — every subject, every class, in one action. This is done through a carefully sequenced internal swap process that avoids any momentary data conflicts during the transition.
    Core Benefit: If a teacher resigns mid-semester, the HOD can transfer their entire workload — 12 subjects across 4 classes — to a replacement in approximately 3 seconds. All historical attendance and records remain attributed correctly to the original teacher.
  • Special Allocations — Cross-Division Elective Groups:
    A second section of the Allocations page handles elective subjects and inter-disciplinary groups. The HOD creates a named "Special Allocation" group, assigns a subject and teacher, then handpicks specific students from multiple different class divisions to form the group. These cross-division student groups are then schedulable on a separate, dedicated timetable.
    Core Benefit: Handles modern curriculum requirements — open electives, remedial batches, project groups, and interdisciplinary subjects — where students come from multiple standard class divisions.
  • Visual Allocation Matrix Overview:
    The page displays a visual card-based layout showing every class alongside its currently allocated subjects and teachers. Classes with no allocations at all are marked with a distinct orange warning badge, giving the HOD a clear, at-a-glance checklist of pending staffing tasks before the semester begins.

Page 6: Bulk Allocation Manager (`admin/bulk-allocation.php`)

A time-saving tool designed for the start of a semester when all 10–12 subjects of a single class need teacher assignments in one session.

  • Pre-Loaded Subject Grid with Current Assignments:
    After selecting a Class, Academic Year, and optionally a Semester, clicking "Load Subjects" instantly populates a full subject list. Each row shows whether a teacher is already allocated (displayed with a green "Allocated" badge) and pre-selects their name in the dropdown, so the HOD only needs to change rows that need updating.
  • Built-In Duplicate Guard:
    On save, the system internally tracks which subjects it has already processed in that session. If the same subject name appears more than once (e.g., from a data inconsistency in the form), only the first occurrence is saved and the rest are silently skipped — preventing database errors or duplicate entries.
    Core Benefit: A full semester's staffing plan — 10 subjects each assigned to their respective teacher — can be completed and saved in a single form submission rather than 10 separate trips to the allocation page.
  • Idempotent Saving:
    Running the bulk save multiple times with identical data produces exactly the same result every time — no new records, no duplicates. Existing allocations are updated; new ones are inserted. This makes it safe to use as a "review and confirm" tool at any point during the semester.

Page 7: Division (Year Level) Configuration (`admin/divisions.php`)

The system-level configuration page that defines the official list of valid year-level codes used across the entire portal.

  • Single Source of Truth for Year Labels:
    Year level labels like FY, SY, and TY are defined once here and automatically appear in every form across the portal — Class creation, Subject management, and Allocations. Adding a new year level here instantly makes it available everywhere, with no code changes required.
    Core Benefit: Expanding the institution's program structure (e.g., adding a "PG" or "4Y" level) requires a single record entry on this page. The entire portal adapts instantly.
  • Safe Deactivation (Preserves History):
    Year levels are never hard-deleted. Deactivating a code removes it from all active dropdowns while preserving the integrity of any historical classes, subjects, and records that were created using that code.

Page 8: Course Name Management (`admin/course-names.php`)

Defines the official list of programme names (BCA, BBA, B.Com, etc.) that appear in the class creation dropdown.

  • Enforced Naming Consistency:
    Because all class names are selected from this controlled list rather than typed freely, the system guarantees naming consistency across every module. Subject filters, allocations, reports, and timetable views all reference the exact same programme name — eliminating silent mismatches caused by variation in typing (e.g., "BCA" vs. "B.C.A." vs. "b.c.a.").
    Core Benefit: One correct entry here means every report, export, and official document generated by the portal always shows the exact, institutionally approved programme name.

Security: Protected Writes Across All 8 Pages

All Add, Edit, and Delete operations across all 8 Academic Setup pages share the same layered security protocol, ensuring no unauthorized or accidental changes can be made.

  • One-Time Request Token: Every form is paired with a unique, server-generated security token that is validated before any action is taken. The token expires after a single use, preventing replay attacks.
  • Server-Side Verification First: The very first thing the system does upon receiving any form submission is verify this token. If the token is missing, expired, or invalid, the entire action is silently discarded — no data is read, written, or deleted.
  • Ownership Checks on All Edits & Deletes: Every update and delete operation additionally verifies that the record being modified belongs to the requesting HOD's department. A valid session is not sufficient alone — departmental ownership must also be confirmed on every write.
  • Confirmation Step for Destructive Actions: Delete operations require the user to confirm intent through a JavaScript dialog before the request is even submitted to the server, providing a final human checkpoint against accidental data removal.