Contact Chase

Project Details

Project Tags

The following tags have been assigned:

Media Gallery

Login Page - Access to the private components of DCOHome system was restricted to authorized employees of SAIT.Dashboard - The welcome page greeting user that just logged into the system.User Profile - A listing of editable details for a specific user and an overview of the recent Kudios they had received from other employees.User Profile - A settings page allowing users to customize their experience including which sidebar widgets would be visible and if audio notifications would be incorporated into the chat component.User Profile - A form allowing users to change their passwords.
User Profile - A listing of all users of the system available to administrators.Programmer Documentation - A documentation wiki was built into the system allowing common elements to be documented by programmers for future programmers to use as reference material.Database Management - An integrated form for allowing select authorized users to execute and display results of SQL queries without needing a dedicated client. Useful for quick troubleshooting and maintenance.Timecard - A listing of hours from a previous pay period which have been applied to an award (blue) or paid (green).Timecard - A visual display of an employee's previous and current contract awards and their state of completion.
Talos - A listing of switch interfaces wired to rooms in Turner Hall. The user can lock, unlock, enable, disable, or refresh the status of each interface as well as add notes describing special interfaces.Talos - An output of the response from two switches after issuing a command to perform a batch refresh on a number of interfaces.Talos - An overview of the active (green) or inactive (red) state of each interface on each switch registered in the Talos system.Talos - An administrative tool allowing a programmer to easily refresh the state of an entire switch with the click of a single link.Remote Support - A list of employees available to provide remote support to users. Those with permissions will also be able to update the text strings displayed on the GUI of Chase's Tool.
Remote Support - Continued below the fold. Those with permissions will also be able to update the text strings displayed on the GUI of Chase's Tool.Remote Support - An example of the correlation between entries made in DCOHome and how that same information appears on the GUI of Chase's Tool.Appointments - A display of the appointments over the surrounding days ranging from three days in the past to ten days in the future based around the current day.Appointments - Master appointments allow RTAs to setup appointments at specific times on specific days of the week. These appointments will then automatically recur until canceled.Appointments - One-time appointments allow RTAs to schedule individual appointments that do not recur. These are used for schedule changes or one-off alterations that need to be made to the master appointments schedule.
Appointments - Timeless appointments allow students to add their name to a list of people requiring support without associating a specific date and time with that request. This was used at the beginning of fall semesters when RTAs were swamped with appointments.Appointments - The welcome screen of the public form used by students to register for appointments with the RTA responsible for providing technical support for their residence hall.Appointments - The contact us screen of the public form used by students to register for appointments with the RTA responsible for providing technical support for their residence hall.Appointments - The residence hall selection screen of the public form used by students to register for appointments with the RTA responsible for providing technical support for their residence hall.Appointments - The sign up entry screen of the public form used by students to register for appointments with the RTA responsible for providing technical support for their residence hall.
Tickets - A list of closed tickets. The tickets colored yellow are tickets that have been marked as being, at least partially, handled by the network/system administrators within SAIT.Tickets - A list of open tickets. The red tickets are tickets that have not yet had RTAs assigned as being responsible to resolve the ticket.Tickets - Ticket details page. Includes all information about a ticket including the information entered at ticket creation as well as who is assigned, what special instructions have been given, and what comments have been left in the comment thread associated with that ticket.Tickets - Internal page for our staff to create tickets on the behalf of departments. The first step is to select the department requesting the ticket be opened.Tickets - Internal page for our staff to create tickets on the behalf of departments. After a department is selected, the rest of the form will be automatically populated with information for that department.
Work Orders - A list of work orders that can be filtered based on a number of criteria.Work Orders - A form used for our staff to create new work orders from print outs received from the Banner ERP system.Install Logger - This tool allowed our employees to document the operating system and other specialized software installed on each computer within our office.DirectConnect Network Backend - This screen lists the different residence halls and university-owned apartments receiving the DirectConnect service and their associated DHCP pools.DirectConnect Network Backend - This shows the editable details of an individual DHCP pool from the list.
DirectConnect Network Backend - This shows the form used for adding new DHCP pools to the list.Students - A listing of students currently registered in the system. No data is shown here as a result of this screenshot being taken from a development server without student data.Students - A form used by our staff to move the student from one housing assignment to another. In this version of DCOHome this was a manual daily process for each student that moved housing assignments.DHCP Leases - A listing of all of the current DHCP leases in the dorm associated with the logged in RTA. There is no data shown since this screenshot was taken from a development server without this data.Console Registration - A tool used by our employees to enter, register, and authenticate the validity of certain Internet-enabled gaming consoles such as the XBox 360 and PlayStation 3.
Disconnects - A listing of students who have been disconnected from the DirectConnect network for various reasons including copyright violation, misuse of university resources, or malware infection.Disconnects - A tool used by our employees to document the disconnection of a student from the DirectConnect service. This tool was used for documentation and manually disabling the switch interface connecting the student to the Internet was still required.Summer - A special tool used during summer to add students or guests visiting the university so they could have access to the DirectConnect network during their stay in university housing.Summer - A special tool used during summer to modify the date a student or guest is expected to leave university housing and, therefore, the DirectConnect network.Summer - A special tool used during summer to enumerate for our staff the network interfaces on the network switches that needed to be enabled or disabled each day to grant and deny access to the DirectConnect network.
Forums - A list of test forums from a development server. This allowed our staff members to collaborate and communicate in a centralized area alongside the other tools required for their job.Forums - A form used to create a new forum thread and poll within the forum system.Forums - An example of an individual form thread with a poll incorporated into the discussion.Forums - A tool allowing the current user to upload a new avatar for their DCOHome account.Inventory - A list of all parts that have been added to the system that need to have their inventory level tracked.
Inventory - A report designed to show the specific details about an individual item which is having its inventory levels tracked by the system.Inventory - A form used for the creation of a new location within the inventory system where tracked items can be stored.Inventory - A form used for the creation of a new item that needs to have its inventory level tracked.Inventory - A form used to add a batch of an individual item to a specific location as would be the case when SAIT purchased items from a vendor.Inventory - A tool used to adjust the inventory values. This was used to modify inventory information to account for lost, stolen, or inaccurately counted materials.
Inventory - A tool used to combine several individual items into a single larger item. For example, coaxial cable sold by SAIT is created from one length of raw coaxial cable and two terminators to form a single complete and usable cable.Inventory - A tool used to move inventory from one tracked location to another within the system.Inventory - A tool used to document the sale of an item in inventory for a given price.Projects - An index of projects being tracked in the project management system.Projects - An example of the details for a specific project being tracked by the project management system.

Related Projects

The following projects are related:

DCOHome v2

This project was done while I was a Resident Technology Assistant (RTA) with Student Affairs IT at the University of Montana, Missoula. DCOHome v2, the second major iteration of the home-grown intranet portal used internally by SAIT, was created mostly due to a need to transition the front-end of the DCOHome system from using ColdFusion to PHP. This decision was made due to the unnecessarily expensive cost of renewing our ColdFusion licenses to keep the existing ColdFusion instance of DCOHome running. Therefore, we began porting each individual module and feature from ColdFusion to PHP while keeping the same backend Microsoft SQL database as a shared data source between the two front-ends during the migration period. This meant that feature additions and significant architecture changes were not generally made because the existing ColdFusion front-end needed to remain fully functional until it was retired.

This particular project was incredibly valuable to me as a learning experience. The individual projects making up DCOHome v2 served as "real-world firsts" in many categories for me including working on a large-scale project with a team of very capable programmers, working with several new programming languages, working with a version control system used by more than just myself, and efficiently making use of large relational databases.

Each of the major modules will be described briefly below. I have attempted to organize them from most significant (top) to least significant (bottom) based on my personal involvement in the development of that module and the importance of that module to the system's everyday use. The media gallery on this page follows the same general ordering. Each module below has also been tagged as being a migration of an existing module from the existing ColdFusion application or as an entirely new module that had not previously existed.

Note: The media gallery on this page contains screen shots taken from a development server using a test database several years after development on this project had already stopped. As a result of this, some pages don't contain real-world data representative of the system's actual use and some pages are missing data entirely. Nevertheless, I think you should be able to get a general sense for the functionality of the systems involved by observing these images in additions to the descriptions of each module below.

[Migration] [New]

For this new application a small new PHP framework was created that would make the development of the system as a whole easier for future modules. This included features such as user authentication, basic access control on an "admin" or "not admin" basis, individualized user settings, a built-in wiki-like system that allowed programmers to document for other programmers the features and elements of shared libraries they had developed or implemented, a built-in tool allowing authenticated users to leave notes on any page within the system, and a universal templating system allowing pages to incorporate common elements and widgets as well as be themed individually for each user.

After the initial build of the critical modules was complete I was also responsible for enhancing the user permission options to be more granular, making it possible to grant permissions to a user for specific actions rather than simply making the user a full system-wide administrator.


The timecard application is probably one of the most important components of the DCOHome system for a number of reasons. Student Affairs IT is responsible for providing technical support and related services to dozens of different departments, organizations, and individuals including all students of the University of Montana as well as all staff members within all of the individual departments within the university's Division of Student Affairs. Because of this need to serve so many disparate entities and justify the funding of the SAIT annual budget from each of these entities it is necessary to very accurately record how SAIT employees spend their time and allocate it among these entities. Additionally, since most SAIT employees are hourly employees on a contract stipulating a required minimum number of hours to be worked, it is necessary for documentation to exist to ensure that contract requirements are successfully fulfilled by each employee.

The timecard system allows each individual employee to document each block of time that they work. Information is recorded about the date and time of the work, the department who is benefiting from the work being done, and a description of the work that was done. This information can then be used in a number of ways. First, reports can be generated to use to justify the need for each individual department to fund the SAIT annual budget based on their previous usage of SAIT's services. Additionally, these records can be reviewed by the employee's supervisor to track the employee's progress toward the completion of their contracted requirements in addition to allowing the supervisors to review what an employee was working on during a specific time and hold them accountable for how they spent their time. This system was used constantly on a daily basis throughout the life of DCOHome v2 by every employee of SAIT during this time.

Talos (Network Switch Management Tool)

The Talos module, which I named after the giant man of bronze from Greek mythology responsible for protecting the ports of Crete from pirates and invades, was responsible for allowing the SAIT staff to manage the state of the interfaces on the Cisco network switches making up the university's DirectConnect network. This was a new project - not the migration of an existing module - I completed independently with the goal of automating routine time consuming tasks performed by RTAs. In this case, at the point in time when I developed this system, SAIT partially controlled access to the DirectConnect network by disabling switch interfaces that led to network jacks that students had not paid to have activated. This was a routine task assigned to RTAs. They would be asked to review the roster for them assigned residence hall, compile a list of students that had paid to have their network jacks activated, enable these interfaces, and disable the interfaces of all other students through an entirely separate system that, due to its design, made this process tedious, slow, and unreliable if more than one person was trying to use it at the same time. Since we were already tracking the residency status of students within the DCOHome database I decided to integrate the control and documentation of the network switches throughout the residence halls into DCOHome as well. With this integration it was then possible to easily automate and expedite this process, reducing the man hours required to repeatedly perform the task and increasing the accuracy and reliability of the process by eliminating or minimizing human error.

In particular, Talos allows - via manual or automated instruction - granular control over enabling a switch interface, disabling a switch interface, locking an interface so those without sufficient permissions cannot alter the state of that interface, checking the current state of an interface, adding and associating textual comments with each individual interface, and performing batch enables, disables, and refreshes on numerous interfaces on an individual switch simultaneously. Additionally, using these features it was possible to generate reports and visual representations from the available data. Each interface on each switch was also associated with the building, room number, and jack identifier associated with the location of the network jack to which it is wired. Since students housing records in the DCOHome database included these same details it was also possible, via these housing records, to associate a switch interface with each individual student on the DirectConnect network.

Remote Support (A Component Of Chase's Tool)

The remote support module is a component I developed independently as part of Chase's Tool, a tool used by SAIT to provide remote VNC support to customers who were not in the same physical location as our staff members. Remote support was primarily used to supplement telephone support by allowing our staff to see and interact with a customer's computer desktop without needing to be in the same physical location. A detailed overview of how the components of Chase's Tool interact and what purpose each serves can be seen on that project's page.

[Migration] [New]

The RTA (Resident Technology Assistant) staff at SAIT is responsible for providing in-room technical support for all residents living in university housing. Each RTA is responsible for being on-call in their assigned building for a minimum number of hours each week where they will be available to either assist students who have made scheduled appointments in advanced or assist students who show up during this time without a scheduled appointment. The appointments system facilitates the tracking of this obligation and make the signup and notification process easier for all parties involved.

This first phase of this module was to migrate the features of an existing system from the ColdFusion application. The usability of this version of the system was somewhat limited due to architecture from the ColdFusion version that needed to be preserved. For example, each appointment had to be created individually each week and there were limitations on when the start time of the appointments could be.

After we completed the migration process I began to develop a brand new system with an alternate architecture that allowed for much more flexibility and integration with other systems. This new system is the one shown in the media gallery on this page. First, I created a way for RTAs to create a recurring schedule of appointments that would be used as their master appointment schedule. This made it so individual appointments didn't have to be created each week. Instead, only individual modifications from the master schedule needed to be made as necessary by canceling an individual occurrence of an appointment and created a new one-time appointment. Second, I created a new type of appointment called "timeless appointments" that allowed students to sign up for an appointment without a specifically assigned time. This worked much better during times of heavy demand because RTAs could visit each student on the list and often complete more appointments in a night than would be possible with individually scheduled half-hour appointments. Additionally, I added functionality that tied the appointments system into the timecard so work done during appointments could be automatically clocked to the RTAs timecard. Finally, I created the ability to track the status of individual appointments and, at the end of each night, generate a dynamic PDF that the RTA could print that they could use to attach individualized notes to the doors of students who had not been present for their appointment.

A private system used by the RTAs was integrated into DCOHome. A public interface was made available to students signing up for help. This multi-step process would guide the student through the process of providing the necessary personal information as well as giving them the option of the different times the RTA for their specific building would be available to assist them.

Tickets And Work Orders

The tickets and work orders modules were used by SAIT to interface with other university departments and track the progress of work being done on individual support tickets submitted by these departments. Having a dedicated centralized system to track this information made it significantly easier for our support staff to quickly get up to date with the status of a project and for the staff in the department receiving support to receive automatic notifications as progress on the ticket is made. Tools were integrated into the system to allow supervisors to assign each ticket to any number of employees, add private comments only visible to SAIT staff, and approve or deny attempt to close tickets marked as completed by employees to ensure high quality customer service was being provided and the client's problem had been successfully resolved.

Work orders contained similar functionality to support tickets but were used to track work performed on university property within the rooms of students living in university housing. For example, RTAs were responsible for repairing any physical damage to network, phone, and cable jacks available in student rooms within twenty-four hours of the problem being reported. The work orders system allowed the Residence Life staff working the front desk of each residence hall to, via a public interface, submit new work orders after damage was reported where it could be tracked to ensure it was handled in a timely manner. The work orders system was also used to indicate when students should be charged for time and materials used during the repair, such as when the damage was intentional rather than normal wear and tear.

DirectConnect Internet Modules

Several modules were included in the DCOHome v2 system in order to facilitate the DirectConnect Internet connection process. This included systems for storing and managing personal information about student living in university housing, housing assignment records for these students, and records about devices connected to the DirectConnect network and their associated DHCP leases.

These systems formed the foundation for data storage used to create the home-grown network access control system that protected the DirectConnect network. These systems included many special functionality such as allowing our employees to register devices such as game consoles as well as process disconnects for students who had violated the terms of service associated with using the DirectConnect network.

[Migration] [New]

The forums module was integrated into the DCOHome v2 system in order to allow persistent stored communications between SAIT employees which was more appropriate in many situations than email. This was used in production to arrange meetings between employees, take polls, and serve as a location for documentation about long-term problems to be placed.

After the initial migration of the forum system I added additional features to allow forums to act as polls where employees could vote on different options as well as adding tracking so that each individual forum thread was able to determine if the currently logged in user had already viewed that thread since the last change or not. This made it much easier for users to be alerted of new postings made in the forum system.

Install Logger

The install logger module was built to track details about the hardware and software of the computers used by SAIT staff. This system would allow us to track the physical location and hardware specifications of each machine. It also allows the installation and removal of software applications to be tracked in a centralized location where other staff members can check how critical the presence of each software package on each machine is and use that information to determine if it could be safely removed. It was also possible to track identifiers such as hardware service tags and software serial numbers or installation keys and associate those with specific computers.

Inventory Tracking

The inventory tracking system was created as a new module in DCOHome v2 rather than a migration of any existing features from the ColdFusion application. The purpose of the inventory tracking module was to track the inventory levels of different physical products sold by SAIT in a variety of locations. Users of the system were able to setup a number of locations where inventory could be stored, setup a number of items and item components, and track the buying, selling, and movement of these items between locations. One of the big advantages of this system was the ability to assemble sellable items from their individual components. For example, a twenty-foot coaxial cable would be composed of two coaxial terminating ends and twenty one-foot coaxial cable increments. Once these items were assembled a new sellable product would be added to the inventory and the individual components would be deducted from the inventory. Notifications were also put in place to alert the proper individuals when inventory for specific products in specific locations fell below a given threshold. This system was primarily developed by Kaiser Leib.

Project Management

The project management module was designed to track the progression of larger or longer-lasting projects within SAIT. This system incorporated several features common to many project management applications such as tracking milestones, deadlines, project tasks, and user comments within a hierarchical system allowing the nesting of projects. This system was primarily developed by Dave Short.