Flatiron Mod 2 Project — Student Management System
Our mod 2 project was a student management service but of course with a lot less features than a real world version of it should have.
Overview:
First of all there is no sign up page. Because people can’t manually register for the school. They have to go through the lengthy procedure of application, placement testing, and etc. We assumed that this step was done already and student accounts are on the database with their default usernames and passwords.
There’s two types of users: Students and professors.
Student abilities:
- Look at all the courses offered by school and be able to register for the course on the same page.
- Look at the courses required for their major in particular and be able to register for the course on the same page.
- Look at the courses they’ve taken before and see their grades and professors.
- Look at the courses they’re currently taking and be able to drop them.
- see their progress toward graduation and how many courses left to fulfill the major.
Professor abilities:
- See the courses they’re teaching this semester.
- See all the students registered for the course and be able to grade them
Models:

Course,Professor,StudentandMajorcan exist by themselves and don’t depend on other models for creation.CourseandMajorhavetitleanddescriptionattributes.ProfessorandStudenthave attributes describing the person such asfirst_name,last_name, anddoband etc; Plususernameandpassword.- To create a class, we need the professor and the courses. So that’ll be an instance of
ProfessorCourse. ProfessorCoursesrepresents a class so it haslocation,start_dateandend_dateattributes. (e.g.,Room 103, 9/1 – 12/25)Sectionis another model that hasday,start_time, andend-timeattributes. (e.g.,Monday, 5:00 – 7:00)ProfessorCoursehas manySections. (usually two)Professorhas manyStudents. How?Professorhas manyProfessorCourses.ProfessorCoursehas manyStudents, throughStudentProfessorCourses.- Therefore,
Professorhas manyStudentsand vice versa. - Each student can have only one major. Which means that students have the foreign-key of
major_id. Therefore, the rails association would beStudentbelongs toMajor. Majorhas manyCourses throughRequirements and vice versa.
Security:
We designed the app such that professors (once logged in) cannot navigate to the students page and vice versa. We implemented this feature by adding two key-value pairs to our sessions upon login.
class SessionsController < ApplicationController def create ### Find the user using the username @current = (Student.all + Professor.all).find{ |inst| inst.username == params[:username] } #### If the username is found, authenticate using the entered password redirect to the correct page. if @current && @current.authenticate(params[:password]) #### If authentication is successful we add the following keys to ours sessions. session[:user_id] = @current.id.to_s session[:position] = @current.class.to_s.downcase redirect_to @current else flash[:errors] = ["Please enter a username and a password."] redirect_to login_path end
end def delete session.delete(:user_id) session.delete(:position) redirect_to login_path endend
In our StudentsController and ProfessorsController we have the authorized method and we run that before doing any of the actions. This method blocks the user from accessing unauthorized pages by redirecting them to their homepage. It does so by checking the sessions[:user_id] and sessions[:position].
class StudentsController < ApplicationController before_action :authorized ..............
..............
.............. def authorized if session[:user_id] if session[:position] == "professor" redirect_to professor_path(session[:user_id]) elsif session[:user_id] != params[:id] redirect_to student_path(session[:user_id]) end else redirect_to login_path end end
end
And we have the same authorized method for our professors controller.
There’s another validation that we run upon creation of Professor and Student So we would never have the same usernames. If we had a single user table that stored all the usernames and passwords, we could have done this validation as easy as this: validates :username, uniqueness: true. But since there are two tables, we implemented it as follows:
class Student < ApplicationRecord has_many :student_professor_courses has_many :professor_courses, through: :student_professor_courses has_many :professors, through: :professor_courses has_many :courses, through: :professor_courses belongs_to :major has_secure_password validate :cross_table_uniqueness ...........................
...........................
........................... def cross_table_uniqueness condition1 = Student.find_by(username: username) condition2 = Professor.find_by(username: username) errors.add(:username, 'Username already exists') if condition1 || condition2 end
end