Placement Management System with MySQL
A training and placement cell portal where eligibility is decided by the server, not by hiding a button.
One-time purchase — source code, database, the written report and everything below, all in a single ZIP.
No account needed — pay & download instantly
Look inside the report
Showing the first 12 pages of 98. Tap any page to read it full size — this is the actual Word file you get, not a mock-up.
Screenshots
Tap any screenshot to open it full size. These are from the project actually running — not mockups.
About this project
A complete training and placement cell portal built the way a college actually runs one, with three separate roles. Students fill in an academic profile and upload a resume. Companies register and post drives with their own eligibility rules. The placement officer approves companies, verifies student records, and pulls out the branch-wise placement report the college is asked for every year.
The part that lifts this above a normal CRUD project is the eligibility engine. A drive carries its own conditions - branches, minimum CGPA, active backlogs, class 10 and 12 percentage, passing batch and last date - and every one of them is checked on the server when the student presses Apply. Hiding the button is not the protection here; sending the form by hand is refused just the same, and there is an automated test that proves it by calling the apply function directly with an ineligible student.
A student who is blocked is told exactly why, every reason at once, rather than a flat 'not eligible'. That single decision is what makes the portal usable, and it is the thing examiners ask about most.
The college's one-offer policy is in here too: once a student is placed, the remaining drives close for them unless the new package is at least twice their current offer - the dream company rule. It lives in two lines of config.py, not buried inside a route, because every college sets it differently.
Applications move one step at a time - applied, shortlisted, interview, selected - and every move is written to an audit table with who did it and when. A rejected candidate cannot quietly be selected later, and a drive with three openings cannot select a fourth. Resumes are stored outside the web root and served through a route that first works out whether you are the student, the placement officer, or a company that student actually applied to.
MySQL is used properly. Every table is InnoDB with real foreign keys and ON DELETE CASCADE, allowed branches sit in their own table instead of a comma-separated column, and a UNIQUE key on (drive_id, student_id) makes a double application impossible even if two tabs are submitted at the same moment.
Features
- ✓Three roles in one portal - student, recruiter and placement officer
- ✓Eligibility engine: branch, CGPA, backlogs, class 10 and 12, batch and deadline
- ✓Every rule is re-checked on the server, so sending the form by hand changes nothing
- ✓A blocked student is told every reason at once, not just the first one
- ✓One-offer placement policy with the dream company exception, set in config.py
- ✓Applications move one stage at a time - a rejected candidate cannot be selected later
- ✓A drive with N openings cannot select the N+1th student
- ✓Every status change is written to an audit table with who did it and when
- ✓Resumes stored outside the web root, served only to the student, the TPO and that company
- ✓Real PDFs only - the file's first bytes are checked, not just the .pdf extension
- ✓Changing your CGPA or branch sends the profile back for verification automatically
- ✓Companies stay invisible to students until the placement cell approves them
- ✓Branch-wise placement report with rate, highest package and CSV export
- ✓Application funnel, top recruiters and package spread on the officer's dashboard
- ✓Applicant list per drive with filters and CSV export for the recruiter
- ✓MySQL with InnoDB, real foreign keys and ON DELETE CASCADE throughout
- ✓Allowed branches in their own table, not a comma-separated column
- ✓UNIQUE (drive_id, student_id) makes a double application impossible
- ✓Database and tables are created automatically - no .sql file to import
- ✓PBKDF2-SHA256 password hashing with a per-user salt
- ✓Every query parameterised; a SQL injection attempt is part of the test suite
- ✓check_setup.py tells you exactly what is wrong if MySQL is not connecting
- ✓36 automated self-tests you can run in front of the examiner
- ✓No CDN anywhere - the whole UI works with the internet switched off
Modules
Tools
- • Python 3.8+
- • Flask (web framework)
- • MySQL / MariaDB (XAMPP works out of the box)
- • PyMySQL (database driver)
- • VS Code (or any editor)
- • Any web browser
Requirements
Python 3.8 or newer, and MySQL. XAMPP is the easiest way to get MySQL - install it, open the Control Panel and press Start next to MySQL. Then one command installs the libraries: pip install -r requirements.txt (Flask and PyMySQL, about 5 MB). The database and all its tables are created automatically on first run - there is no .sql file to import. Works on Windows, Linux and Mac.
How to run
1. Extract the ZIP.
2. Start MySQL - open the XAMPP Control Panel and press Start next to MySQL.
3. Open CMD and go to the folder: cd path\to\placement-portal
4. Install the libraries: pip install -r requirements.txt
5. Check everything is ready: python check_setup.py
6. Load the demo data: python demo.py
7. Start the app: python app.py
8. Open http://127.0.0.1:5000 in your browser.
9. Login: tpo / tpo123 (placement officer) | student / student123 | company / company123
If MySQL uses a password on your machine, set it once before step 5:
set PP_DB_PASSWORD=yourpassword
Before a viva, also run 'python selftest.py' - 36 checks pass in front of the examiner.The same steps are in README.md inside the ZIP, along with a troubleshooting table.
What you get in the ZIP
- 📁 Full source code — commented throughout, so you can explain it in the viva
- 🗄️ Database — the schema builds itself on first run, with sample data
- 📖 README.md — step-by-step run instructions, database design and troubleshooting
- 📄 Full project report (Word) — Written out and formatted for AKTU — not an outline you have to fill in
- 📊 Presentation (PPT) — Ready for the final viva presentation
- 📝 Synopsis (Word) — The short write-up your guide asks for before approval
- ❓ Viva questions with answers — The questions examiners actually ask about this project
- 📐 8 ready-made diagrams — DFD, ER, use case, sequence and architecture, as images you can paste straight into the report