College Lab Equipment Damage Reporting Web App with Photo Proof and Repair Status

College Lab Equipment Damage Reporting Web App with Photo Proof and Repair Status is a web application that lets students report damaged college lab equipment with a photo, and lets the lab in-charge track each report through repair to closure. A student selects the lab and equipment, picks a damage type and severity, describes the fault, and attaches a photo as proof; the report then moves through three stages — Reported, Under Repair, and Repaired — noting every change.
In most colleges this happens verbally or in a paper register: a broken oscilloscope is mentioned to a technician, the note is lost, and the next batch discovers the same fault again. Without a photo, the in-charge cannot judge urgency before visiting, and without a status trail nobody knows whether a repair was assigned, awaits a part, or was finished. This project replaces that chain with one auditable record per damaged item, keeping damage, evidence, and closure visible to all.

The damage reporting web app follows one report from the bench where the damage is found to the moment the repaired item returns to service. A student files the report in the lab itself, the lab in-charge verifies the photo and assigns the repair, a technician works through the fault and records notes, and the report closes only after an after-repair photo is checked. At every stage the same record is updated, so the student, the in-charge, and the technician all read the same status instead of chasing separate messages. The steps below trace that journey step by step, from selecting the lab and equipment to the final verified closure, and show exactly where the system's guards — the one-stage-at-a-time rule and the photo-before-closure rule — actually bite at each handover.

1. The student opens the report form and selects a lab; the equipment list narrows to that lab's registered items, and the student picks the damaged item.
2. The student picks a damage type and severity, writes what happened, attaches a photo of the damage, and enters their name and roll number.
3. On submission the system generates a reference ID in DMG-YYYY-NNN form and the report appears on the dashboard with the status Reported.
4. The lab in-charge filters the dashboard by lab, status, or severity, opens the report, verifies the photo, and advances it to Under Repair with an assignment note.
5. The technician records progress notes on the same report — for example, that a display module has been ordered or a fuse is under test — while the item stays withdrawn from issue.
6. Once the repair is done, an after-repair photo is attached to the report so the fix itself is evidenced, not merely claimed.
7. The in-charge verifies the after-repair photo, advances the report to Repaired, and the full timeline remains searchable as the item's repair history.

Tech stack:

• HTML5 · CSS
• JavaScript
• PHP
• MySQL
• Apache · XAMPP local hosting
• Responsive web design

The damage reporting web app is built around three capabilities that matter most in a working lab: fast reporting with photographic evidence, a repair workflow that cannot be skipped, and a dashboard that shows the whole lab estate at a glance. Around those core capabilities, the build adds severity triage so urgent faults surface first, lab-wise filtering so an in-charge sees only their own labs, and a repair timeline that records who changed a status and why. Everything listed below is implemented in the working demo: the form submits a real report, the dashboard filters real records, and the detail view advances a report one stage at a time. Optional additions, such as email alerts or a companion mobile app, are kept out of this list and described separately as future scope.

• [Photo-proof damage report] The reporter selects a lab and equipment item, chooses a damage type and severity, describes the fault, and attaches a photo of the damage. The photo travels with the report, so the in-charge judges urgency from evidence instead of a second-hand description.
• [Strict three-stage repair workflow] Every report moves only in the order Reported, then Under Repair, then Repaired. The system refuses a jump from Reported straight to Repaired, and an after-repair photo is required before closure, so a repair cannot be marked done on words alone.
• [Lab in-charge dashboard] All reports across all labs appear in one table with live counts of reports awaiting action, under repair, and closed. The in-charge sees the full lab estate without opening each lab's register separately.
• [Severity triage] Four levels — Low, Medium, High, and Critical — let urgent faults stand out. Critical reports are highlighted and appear first, so a broken safety-critical item is never buried under routine reports.
• [Damage-type taxonomy] Six fixed damage types — physical damage, malfunction, missing part, calibration drift, display or control fault, and other — replace free-text guesswork, so reports can be grouped and compared across labs.
• [Lab and equipment register] Five labs and eight equipment items are registered in the demo, and the equipment list narrows automatically when a lab is chosen. Adding a lab or an item is a register entry, not a code change, in the delivered build.
• [Repair timeline and in-charge notes] Every status change is logged with a note, from verification to part ordering to closure. The timeline stays attached to the report after closure, giving the lab a permanent audit trail for each item.
• [Searchable report history] Each report receives a reference ID in DMG-YYYY-NNN form, and the dashboard searches by ID, equipment, or reporter name. A student can quote one ID and everyone involved opens the same record.

• Complete web application source code (report form, dashboard, detail view, status workflow)
• MySQL database schema with sample labs, equipment, and reports
• Working single-file demo app with realistic sample data
• Setup instructions for local hosting
• Project report PDF (background, workflow design, database design, testing)
• PPT presentation for final review
• Viva Q&A preparation document (CRUD operations, workflow state machines, file uploads, role-based access)
• Project abstract PDF