Grad Visit Day web application (v3)

Background

This app is to be used by the Graduate Recruitment Coordinator on grad visit day, held in February or March.

Version 3 of the application uses a simpler scheduler to automate the scheduling process. Originally designed based on CSCF ST#86639
The TWiki page for v1 of this application, also based on CSCF ST#86639, can be found here: GradVisitDay

For answers to questions not adddressed here, look at the code, or talk to Daniel Allen or Jesse Hoey.

Usage

User Intructions

The most up-to-date user instructions can be found on the homepage of the application https://cs.uwaterloo.ca/grad-visit-day-scheduler/

Developer Documentation

URLs

The web application can be found at:

Git tips: GitUWaterlooCSCF

Git Cloning

To set up a working version, you must first clone the repository to your local machine. To do so, run the following command within your web directory (/var/www):

git clone gitlab@git.uwaterloo.ca:cscf/grad-visit-day.git

Apache Permissions

Once you have cloned the repository, you will find a file named htaccessDev within the root of the newly created directory. Make a backup of the .htaccess file in the directory, then rename htaccessDev to .htaccess. This will override the original .htaccess settings allowing easier setup of the development environment.

On line 4 in htaccessDev (now just .htaccess), the path to the AuthUserFile will need to be modified to point to your own .htpasswd file. If you have not created a .htpasswd file, it is best to create one in a more secure directory:

cd /home/username
mkdir private
chmod 711 private
htpasswd -c /home/username/private/.htpasswd-inv username

Database Connection and Setup

In order for the web application to display anything, it must be able to establish a database connection. To do so, you must create a file that defines some unique parameters. Navigate to the private folder we created earlier within your user directory and create a file named db-passwords.inc or similar and add these definitions to the contents:

<?phpenter a number greater than the previous entries id.
define('GRAD_DAY_APP_PASSWORD', 'your database password');
define('GRAD_DAY_APP_DB', 'your database name');
define('GRAD_DAY_APP_HOST', 'the host location of your database');
define('GRAD_DAY_APP_USER', 'your username in the database');
?>
In place of 'your database name' write 'app_grad_day'. You will see why shortly.

Next, you must go to the web application's directory and find the file named db.php. On line 9, edit the require_once statement's path to point to your new db-passwords.inc file.

require_once('/home/username/private/db-passwords.inc');

Now that the application should be able to successfully connect to your database, we need to create and populate the database for testing purposes. Login to phpMyAdmin and create a new database named 'app_grad_day' (we used this name in our db-passwords.inc file). Once you have created the database, you can use a provided .sql file to populate the database. For example, we will use the app_grad_day_DATA_FOR_TESTING.sql file. Navigate to the root of the web application (/var/www/grad-visit-day) and execute the following command:

mysql -u <username> -p -h localhost app_grad_day <app_grad_day_DATA_FOR_TESTING.sql 
Use the username and password you used when configuring MySQL on your machine.

The final step is to maually add yourself to the user table in the app's database so that you are authorized to access it. Go to phpMyAdmin and select the database. Go to the 'users' table and insert a new row at the end of the table:

  • For the id field, leave it blank as it will automatically generate the id.
  • For the userid field, enter your WatIAM username.
  • For the name field, enter you name in First Last format.
  • For the office field, enter an office if you would like.
  • For the type field, enter in 2.
  • For the group_number field, enter 0.
Hit Go and test that you can now access the application.

Database Management

The application uses a MySQL database. The database can be modified using the GUI applicaion phpMyAdmin.

Database Design

The database contains 10 tables: meeting, student, student_user, user, user_student, lab, lab_time, student_lab, time, and user_time.

The meeting table has 6 columns:

  • id (a unique number to identify the meeting)
  • user_id (the ID of the user who set the meeting)
  • student_id (the ID of the student who the meeting will be with)
  • time (the time the meeting will occur)
  • location (the location of the meeting)
  • meeting_with (the person/group who will meet with the student)
The student table has 3 columns:
  • id (the unique number used to identify each student)
  • name (the full name of the student)
  • research_interests (the student's research interests)
The user table has 5 columns:
  • id (the unique number used to identify each user)
  • userid (the userid for the user [this should be the same as the userid used to log into CAS - if this is different from the user's CAS username, the user will not be able to access the app])
  • name (the full name of the user)
  • office (the user's office)
  • type (the level of access the user should have: disabled, faculty, or admin)
The student_user table has 2 columns:
  • student_id (this is a FK value which points to the ID of a student)
  • user_id (this is a FK value which points to the ID of a user)
This table is used to link students to users. Each student ID corresponds to the ID in the students table and each user ID corresponds to the ID in the users table. This table is used to create the links which tell the app which students are interested in seeing which professors.

The user_student table has 2 columns:
  • user_id (this is a FK value which points to the ID of a user)
  • student_id (this is a FK value which points to the ID of a student)
This table is used to link users to students. Each user ID corresponds to the ID in the users table and each student ID corresponds to the ID in the students table. This table is used to create the links which tell the app which users are interested in seeing which students. These values determine what names show up under the 'Meeting Requested By' header in the 'Schedule Meetings' or 'Attendees' table. The lab table has two columns:
  • id (unique number to identify each lab site)
  • name (full name of the lab)

The lab_time table has two columns:

  • lab_id (FK value which points to the ID of a lab)
  • time_id (FK value which points to the ID of a meeting time-period).

The student_lab table has two columns:

  • student_id (FK value which points to the ID of a student)
  • lab_id (FK value which points to the ID of a lab)

The time table has two columns:

  • id (unique number to identify each meeting time-period)
  • time (full text description of the time-periods)

The user_time table has two columns:

  • user_id (FK value which points to the ID of a user)
  • time_id (FK value which points to a time-period the user is available to meet)
Edit | Attach | Watch | Print version | History: r16 | r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r12 - 2016-01-19 - EvanSymmes
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback