Flatiron Mod 2 Project — Student Management System

Amirata Khodaparast
Sep 6, 2018 · 3 min read

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:

  1. Look at all the courses offered by school and be able to register for the course on the same page.
  2. Look at the courses required for their major in particular and be able to register for the course on the same page.
  3. Look at the courses they’ve taken before and see their grades and professors.
  4. Look at the courses they’re currently taking and be able to drop them.
  5. see their progress toward graduation and how many courses left to fulfill the major.

Professor abilities:

  1. See the courses they’re teaching this semester.
  2. See all the students registered for the course and be able to grade them

Models:

  1. Course , Professor , Student and Major can exist by themselves and don’t depend on other models for creation.
  2. Course and Major have title and description attributes.
  3. Professor and Student have attributes describing the person such as first_name , last_name , and dob and etc; Plus username and password .
  4. To create a class, we need the professor and the courses. So that’ll be an instance of ProfessorCourse .
  5. ProfessorCourses represents a class so it has location , start_date and end_date attributes. (e.g., Room 103, 9/1 – 12/25)
  6. Section is another model that has day , start_time , and end-time attributes. (e.g., Monday, 5:00 – 7:00)
  7. ProfessorCourse has many Section s. (usually two)
  8. Professor has many Student s. How?
  9. Professor has many ProfessorCourse s.
  10. ProfessorCourse has many Student s, through StudentProfessorCourses.
  11. Therefore, Professor has many Students and vice versa.
  12. Each student can have only one major. Which means that students have the foreign-key of major_id. Therefore, the rails association would be Student belongs to Major.
  13. Major has many Courses through Requirements 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

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade