This application was developed by the team using the Ruby on Rails development framework and aimed to create a central hub in which an instructor of a college course can assign a presentation to any number or combination of students, and assign all other students a corresponding scoring and evaluation of that presentation. In using the Ruby on Rails Framework, along with the corresponding styling, embedded Ruby, etc. were inspired by the Ruby on Rails Tutorial, 7th Edition, by Michael Hartl.
The application is designed to withstand malicious user actions with authetication and additional security measures.
Beyond extensive prototype testing with the application itself, we also included tests of each of the models (validations), controllers, and integration tests (how view is rendered, etc.)
Extra functionalities include:
- Dropping students
- User Authentication
- Admin ability to make announcements
- Admin ability to manage overdue evaluations
- Automatically assigning evaluations upon presentation creation
- Preventing self-evaluations
Some UI details we included to improve experience and responsiveness are:
- Responsive scaling
- Two nav bars
- Nav path in top left of dashboards to indicate users' location in application
- Simple view to support easy-to-understand functionality
- Error/success flash messages to inform user of form use
All ruby code is formatted following the rubocop style rules. Running:
$ rubocop
will show that our code is validated.
All HTML and CSS code was validated in a CSS/HTML validator. The source code is indented and commented in code for readability.
rubocop will show some errors on these rails auto-generated files.
- bin/bundle
- db/schema.rb (generated by rails from migrations)
This is not code we wrote but is essential in the rails ecosystem.
Similarly, the importing of turbo functionality warns the HTML Validator. Once again, this is required to use the turbo gem and is not HTML that we wrote.
The HTML was designed to be fully accesible with screen readers in mind. CSS selectors were used well while taking advantage of SCSS features. MVC design followed rigidly.
Clone the repository to a local environment to begin using the application. The first thing to do once cloning the project and loading the code is to acquire and update the necessary Ruby Gems for the application to run. The following commands -
$ bundle install
and
$ bundle update
will put the proper versions of the gems on the current Ruby installation that the app requires. Next, the database for the local usage of the app needs initialized. The command
$ rails db:migrate
will create the sqlite3 files and relations specified in the app to support students, instructors, and their assignments. Then, to begin working with the preinstalled administrator, run
$ rails db:seed
to populate the application with an instructor. This initial instructor has the following account information that can be used to sign in with.
| Name | Password | |
|---|---|---|
| Charlie Giles | giles.25@osu.edu | password |
Once the database has been initialized and seeded, running the application allows for full functionality for an administrator to begin assigning presentations and evaluations to their roster of students. Running
$ rails server
or the shortcut
$ rails s
begins a web server for the application on the user's local host, likely on port 3000. Opening the corresponding link will show the following home page from which a user can begin using the app.
Without signing in using the initial administrator, you can begin by registering a new student to the class. Navigate to the signup page by clicking the Create an Account button. This should take you to the /signup page. After filling out all of the given fields, a user has been created and you can begin assigning, receiving, turning in, evaluating, and aggregating presentations.
However, signing in using the seeded administrator is the most effective way to begin using the application. Upon this login, you will be greeted by a plesant home page.
From here, you can return to your administrator dashboard where all announcements and navigational materials are listed. The above navigation bar will take you to information on the application and your user's account and current session, while the side navigation bar will move a user around the current session.
From here, you can navigate to your grade book to monitor the progress of your students.
The grade may be bleak, because there are no currently assigned presentations.
To fix this, you can navigate to the Make a New Presentation tab, and in filling out the required fields, assign selected students a presentation, while all other unselected students are assigned evaluations. It is worth noting that to select multiple students to create a team for the presentation, the user must hold control while clicking.
To view the full list of students (and possibly drop those who have not completed what is asked of them), navigate to the Roster tab.
Upon logging in as a student user, much of the site is the same with the exception of creating presentations and evaluations being replaced with tabs to complete their assignments instead.
The central model of the database for the application is that of the user. A user has many evaluations to complete, teams for presentations, and presentations through those teams. The email is saved as an all lowercase string with a validating regex expression as outlined in the Rails tutorial mentioned in the Abstract. The model validates that the email is shorter than 255 characters, is unique based on the saved lowercase values, and follows the regex. The model also uses the has_secure_password helper to validate the user's password with a confirmation on signup on top of the model validation of the length of the password being at least 6 characters. The name of the user is validated to be shorter than 50 characters. Finally, for validity, the user must have a present name, email, and password.
The model for presentations establishes a presentation has many associated evaluations, teams, and many users through the teams. Our model validates that the name of the presentation is present and shorter than 50 characters. Finally, it validates that a grade for a presentation must be between 0 and 100 if it has been graded. Upon creation, the grade is given a value of nil, but when a student submits a grade, the model requires it to be within those bounds.
Both the models of the evaluations and the teams state that each resource belongs to a user and belongs to a presentation. These are not the same resource, but they are both joined to tables in the same way.
This evaluation model is the connecting piece of the application. It connects users to presentations that they must evaluate. This means that a user who is not assigned a presentation is automatically assigned an evaluation of that presentation. The model for the evaluations joins users to the presentations they are evaluating in the site's database.
Finally, using the Cancan Ruby gem, a model for abilities is used to monitor the permissions of a user. This model establishes that if a user is an administrator, they can manage all relations and models, while a regular student user is only granted permission to manage evaluations belonging to their student id while being able to view the model attributes for all other models.
All of these validations and the required/allowed values for the database attributes are tested in the /test/models directory to assert their functionality
The views of interest are:
- announcements/index.html.erb
- displays all anouncements. Functions as dashboard for users. Look varies based on user role.
- evaluations/edit.html.erb
- provides a UI to submit an evaluation (for students only)
- evaluations/index.html.erb
- provides a UI to view all evaluations (for admin only). Includes UI to unassign evaluations
- evaluations/student.html.erb
- provides a UI to view all evaluations (for admin only). Includes UI to unassign evaluations
- evaluations/student.html.erb
- provides a UI to view all evaluations (for admin only). Includes UI to unassign evaluations
To sign up, a form is presented to the prospective user to enter their name, email, password, and confirm that password. Warnings are flashed to the user if any of the model validations are incorrect, including taken emails and non-matching password confirmations.
Refer to the Rails guide for information on what standard Rails controller methods route to.
- annoucements_controller.rb
- Responsible for actions relating to announcements. This includes ensuring authentication, making announcements, deleting them, viewing them.
- application_controller.rb - All controllers inherit this.
- evaluations_controller.rb
- Responsible for actions relating to evaluations. This includes ensuring authentication, editing evaluations, deleting them, viewing them.
- presentations_controller.rb - Responsible for actions relating to presentation
- Responsible for actions relating to presentations. This includes ensuring authentication, making presentations (with additional transactional steps for broadcasting evaluations), editing presentations, deleting them, viewing them.
- sessions_controller.rb
- Responsible for actions relating to sessions. This includes the foundation for authentication, making sessions, current sessions utility functions, deleting sessions.
- static_pages_controller.rb
- Responsible for actions relating to static pages. This includes rendering static pages
- users_pages_controller.rb - Responsible for actions relating to users
- Responsible for actions relating to users. This includes making new users, updating them, and dropping them.
Eddie focused on controller code for the user, namely deleting and creating.
Alan worked in permissions for administrators and their creation and editing of resources, including users.
Quinnan worked in editing actions for controllers, focusing on mostly password validation and secure changing.
The testing bench for this project covers all of the basic functionality and some of the higher level relations. There is tests for the model validations, controller actions, and integration for the views and some session actions.
As mentioned before, all validate: statements in the models are tested in their respective test.rb file. There are also some added tests for belongs_to and has_many statements for presentations, evaluations, teams, and announcements.
Controller tests center around permission to complete actions based on a user's authentication. The user_controller_test.rb file deals with permissions for a user to create or navigate based on if they are logged in or not. All other controller test units (those of evaluations, presentations, and announcments) deal with fixtured users and assert that they are signed in and an administrator, and if not, redirects the user to a different part of the site, usually the root page or the index for that resource.
The basic integration tests deal with GET requests to the static pages of the site that can be reached without any level of authentication. This includes the root page, the about, contact, and help pages specified for the team of developers, and and login and signup pages to access the site. Also included in the integration tests are the login and signup actions. These involve actions to activate a seeded session, log in, and log out with corresponding RESTful routes.
All embedded ruby, styling in custom stylesheets, and static pages were tested with verified style checkers like Rubocop to assert that development was done with efficiency and cleanliness in mind.