Mechanical Engineering Machine Scheduler 2.0
|Mechanical Engineering Machine Scheduler|
|Sponsors||University of Idaho|
|Duration||Fall 2020 - Spring 2021|
|Faculty Adviser||Bruce Bolden|
The goal of the project is to improve, complete, and implement the Mechanical Engineering Machine Scheduler that was worked on during the 2019-2020 academic year.
- 1 Problem Definition
- 2 Design Considerations
- 3 Project Learning
- 4 Final Design
- 5 Validation
- 6 Team Members
- 7 Additional Documentation
During the 2019/2020 academic year, team MErge developed a beta implementation of the Mechanical Engineering Machine Scheduler. The key features had been developed; however, further testing for security needed to take place, as well as the implementation of more features. Current unsatisfactory features as well as bugs encountered also needed to be fixed.
- An unlogged-in view of the landing page with current machine availability
- A login and authentication page that allows users to login with school credentials
- The ability for admin to add and delete machine units from the machine list
- A database with to hold data that are associated with the calendar
- Interaction between the database and the web application to retain the most recent data regarding the scheduling system
- The ability to check billing codes against valid ones in the database
- The ability to create profile roles for admin, graduate students and undergraduate students
- The ability to correctly validate user login credentials
- Automatically disable equipment when scheduled time is over (administrator-defined time blocks)
- Sustainable – not easily broken by software updates
- Calendar view, showing equipment reservations and person reserving.
- Summary reports of usage and billing information
Our team was able to accomplish all the deliverables except for implementing a system to automatically disable (power off) equipment when scheduled time is over.
Our website maintains the systems implemented by Team MErge. Multiple systems communicate with the user and the database. Below is a basic outline of how these systems communicate with each other.
Auth0 (Chosen Authentication Service)
Auth0 is an easy to implement, adaptable authentication and authorization platform.
Pros: + Easy user management for assigning roles and blocking users + Universal login page provided + Login credentials validated and scored securely + Ability to add social connections to authentication process (Google, Microsoft Account, etc.) + Can be for native or web apps (for later down the road)
Cons - Not integrated with the current University active directory. Users are currently required to register an account using their existing uidaho email.
Our website uses the free service provided by Auth0. If the number of users for the website exceeds expectations, an upgrade to a paid plan may be necessary - however, our team would recommend a migration of the website to University systems in this case instead.
Our team decided Auth0 was the best possible solution as an authentication service, given that we were not permitted to use the University of Idaho systems. Auth0 provides a very user friendly solution to authenticating and managing users, which eases the transition when this project is handed off.
Microsoft Azure is the current system the University of Idaho uses for authentication of users.
Pros + Users can use their existing credentials used for other University of Idaho services + Integration with Outlook Calendar + Long term support
Cons - Functions such as assigning roles and blocking users may have to be done manually for each existing user
This solution would utilize existing University of Idaho systems, so no cost would be incurred.
Using Microsoft Azure would be the ideal solution, as users would be able to use the credentials they already have. Unfortunately the University has a thorough vetting process for all applications hosted and utilizing their authentication system, so future teams will have to work with ITS closely on this. One downside is that depending on the information stored by the University for each user, it may require more checking to determine who should have access to our website. For example, should a student from the Art program be able to access and use this website?
Website Design: ( React Web Framework )
Use Case: - The React framework makes web development easier by initializing a starter app that comes with a built-in npm/yarn scripts, testing folders, and a base starter page to work from. This allows for a more organized approach to starting the web page. - The component-based architecture allows for easy re-usability of code. - The large open-source community and libraries means that there will be more off the shelf technology available for use.
Setup: The repository was initialized with the create-react-app started application for React. This app is aimed towards beginners and single page applications but allows for scaling for more complicated websites later.
Our final product is a functional hosted website, in which its main features allow users to schedule times for equipment [See Figure 1.1], save scheduled information to our database, authenticate scheduled times with billing codes, and allows administrators to manage and add machines to this scheduler.
Our final product features many of the same functionalities implemented by Team MErge - however, we have made many improvements such as a working authentication system, more admin functionality, and email notifications. More testing and user feedback needs to take place for this website for a final release, but the current website can be accessed at https://csmetest.herokuapp.com/ (may take up to 30 seconds on first load).
Each user will have the ability to see upcoming and past reservations for machines [See Figure 1.2]. These are all stored on a database, and will keep records of this, which can be exported to CSV or PDF files for easier formatting outside of the website. As well as keep a personal backlog on your own machine.
There are multiple roles for users, which give each role a different set of features they can use on the website. These roles consist of undergraduate, graduate, and administrator roles. The final design gives each role the following features.
The undergraduate student role consists of:
- Making reservations for various machines - Checking upcoming and previous reservations from their account window
[See figure 2.1]
For an undergraduate to make a reservation, most machines will require the assistance of a graduate student. This is for safety reasons, and before requesting a graduate student the undergraduate student is expected to talk with them prior to this reservation online.
Most reservations for machines will also require a billing code entered. This is for wear and tear of machines, and will be used to help maintain the machines.
Students will receive a confirmation email after they have made a reservation, or if they cancel a reservation. They will also receive an email if an Admin has cancelled one of their reservations.
The graduate student role consists of
- Making reservations for various machines - Checking upcoming and previous reservations from their account window - Future Implementation (View and cancel upcoming reservations accompanying undergraduate students)
[See figure 2.2]
Graduate students have all the same features as undergraduate students, except they do not require another graduate student assisting them. Graduate students would only require a billing code in order to reserve a time slot for a machine (if the machine requires one to be provided).
Graduate students will receive a confirmation email after they have made a reservation, or if they cancel a reservation. They will also receive an email if an Admin has cancelled one of their reservations.
The administrator role consists of
- Making reservations for various machines - Checking upcoming and previous reservations from their account window - Future Implementation (Cancel upcoming reservations accompanying undergraduate students) - Manage all machines (add, delete, edit) - Manage all billing codes (add, delete, edit) - Manage all reservations (add, delete, edit) - Manage all users (delete, block, change role through Auth0)
[See figure 2.3]
Administrators have the same abilities as graduate students, and undergraduate students with various other features. The main purpose of administrators is to manage all the information graduate and undergraduate students will be able to see.
Administrators are able to manage the machine list. They are able to add new machines, delete machines, and edit information of each machine. Such as machine name, ID number, and whether they require a billing code and/or graduate student accompanying undergraduate usage.
Administrators will also be able to add, delete, and edit billing codes. When a student is reserving time with a machine most of them will require a billing code for use. As a reservation is made the students inputted billing code will verify it is indeed a real billing code with our database. All of these real billing codes will be manually added into the database by administrators.
Administrators will also be able to manage all reservations. They will be able to create new reservations, delete any reservation, or edit any reservation. This feature is here if for some reason a reservation must be deleted for reasons such as a student lost access to the machine shop, a reservation had to be moved ahead a few hours because of scheduling, etc. Administrators can also add notes to past reservations for their reference.
Administrators can also edit user roles and delete users. Users with a @vandals.uidaho.edu email are able to access the website with undergraduate functionality by default, and users with the @uidaho.edu email are given the "Graduate" role by default. Through the Auth0 account and interface we have set up, the Administrator may assign the "Admin" role to users they would like to have the Administrator functionality within the website.
Administrators will receive a confirmation email after they have made a reservation, or if they cancel a reservation. If they cancel a reservation made by another user, an email will be sent to that user automatically notifying them that the reservation was cancelled.
Suggestions To Future Teams
Although our team was able to make many improvements from the website provided by Team MErge, we were unable to perform extensive testing and obtain user feedback from Mechanical Engineering students and faculty.
Focus groups is the next phase of testing that needs to be accomplished. We would like to determine if the website is accessible enough for all students and faculty, as well as if there are any unintended interactions existing on the website.
The largest future feature that we agree needs to be the main priority is migrating this project to the University of Idaho network. The University was strict regarding allowing integration with their authentication service, and unfortunately we were not able to make our case during our time on the project this year. Azure will ensure that this website will be more secure, will last longer, and will easily facilitate the University of Idaho login credentials. This will allow for features such as hooking up our website with students outlook calendars and easily allow students to be able to log into the Machine Scheduler website without having to register every single user with our database.
Migration to Azure: - Better security / authentication - Long term support - Facilitates University of Idaho's login credentials
Our team used the following validation plan:
Validation Approach: - Only users with UIdaho emails should be able to create accounts - Multiple users should be able to use the website concurrently - Users should be able to view their schedule - Admins should have control of billing codes and admin tasks - User login credentials should be stored securely - Website should function indefinitely without updates
Our team was able to validate all these features, although more extensive testing and research needs to be done regarding multiple users using the website concurrently and the lifetime of the website.
Our team also utilized the focus group data made available to us by Team MErge:
Focus Group (Faculty and Administrators): - Condense reservation process to one page - Some machines will have billing codes and some will not - Add a new role of blocked or view-only for students who abuse the system - Admins can add notes to past reservations - Some machines will have to have a graduate students while some do not
We were able to implement all the feedback points provided by this focus group.
Focus Group (Graduate and Undergraduate): - Undergraduates must validate with graduate students for requested time - Undergraduates and graduate students receive an email on the day of - Graduate students can delete reservations, which will send a notification to undergrads. There will also be a reason given to undergrads for the reason it was canceled. Such as "Have a meeting at that time, schedule for two hours later." etc.
Our team was not able to implement a system for graduate students to view or cancel reservations where they are accompanying an undergraduate student due to time constraints.
Major: Computer Science
Major: Computer Science
Major: Computer Science