Contact Chase

DCOHome v3

This project was done while I was an RTA Coordinator with Student Affairs IT at the University of Montana, Missoula. This was a ground-up implementation of a very extensive intranet portal and set of web services used by SAIT. I began working on this after learning about a number of new technologies that I felt could benefit the development and maintenance of these internal products. This included the use of distributed version control systems in the form of Mercurial, the use of a model-view-controller object-oriented PHP framework in the form of CodeIgniter, and the use of a standard JavaScript toolkit to provide powerful cross-browser features including Ajax and interactive Widgets in the form of the Dojo Toolkit. This ground-up implementation was aptly timed as well given that I had learned a great deal about the limitations of the architecture used in DCOHome v2, which I had little control over, which would allow me to make much wiser decisions given much more clearly defined requirements and an unrestricted freedom to shape the underlying architecture of the intercommunicating systems. Similarly, the conditions of the SAIT student employment contracts where drastically changed and the existing software used to manage employee positions, log worked hours, and track employee's completion of their contract would no longer be suitable for dealing with the newly formed contracts. Overall, the development of DCOHome v2 (the previous major rewrite of many of these tools) served as a very good learning opportunity that allowed myself and other developers to become familiar with new languages, databases, methodologies, and paradigms as well as build a product that would elicit valuable user feedback which would be used to shape the creation of DCOHome v3. This knowledge made it possible to create DCOHome v3 in a way that was significantly more flexible, more modular, more focused on critical features, and more user friendly.

Since this is such a large project I am not able to describe every aspect of it in detail. Several of the major features are overviewed in the media gallery on this page and include some brief notes with each image and I have chosen to highlight and describe only a small subset of the features of this system below. There are also many features that, unfortunately, cannot be shown visually through the media gallery and I have tried to describe some of the most significant ones below as well.

User Authentication And Permissions

Active Directory Integration: The University of Montana uses a domain running on Microsoft's Active Directory to manage computer and user accounts for university staff and students. As SAIT was responsible for managing the user accounts for anyone within the Division of Student Affairs the integration of Active Directory authentication into the DCOHome web application was a very good fit. To begin, users would use their domain username and password to gain access to DCOHome. This made it so that users would not need to remember a separate password and if their Active Directory user account was ever disabled they would, automatically, also no longer be allowed to access DCOHome. Additionally, since users were already assigned to a variety of security groups in Active Directory based on their role, these groups proved useful in granting and limiting access to certain features. For example, when a client provided their username and password to gain access to the public support ticket interface they would automatically be shown only the support tickets relevant to the department that they work for based on their membership in security groups. This means that there is no need to setup any kind of account in the DCOHome database when a new employee joins a department, the creation of their Active Directory account and its assignment to security groups is automatically sufficient to allow them to login, view tickets, post comments, and perform other actions. This LDAP integration with Active Directory proved to be very valuable and was soon adopted to protect many other web applications managed by SAIT.

Multi-factor Authentication: To optionally allow an SAIT employee to increase the security of their DCOHome account I added the ability for SAIT employees to associate a Yubikey with their account. Yubikeys are USB hardware tokens that emulate a keyboard and are responsible for generating time-based one-time-passwords. By doing this it required users to know both their username and password when logging in as well as have physical access to their assigned Yubikey. Using this method it would be impossible for another user to gain access to an account without the associated Yubikey even if they had discovered the account's username and password.

Sidebar Widgets

WebDAV Integration With Microsoft Exchange: SAIT used a number of shared calendar on the university's Exchange servers to track what employees were expected to be staffing the DirectConnect Office, what employees were making their weekly rounds to Student Affairs departments, and similar scheduling of our staff. Knowing that this information was important to be able to access quickly I built several sidebar widgets which used WebDAV to authenticate and connect with the Microsoft Exchange server and retrieve this scheduling information in real time. An accurate representation of who was currently scheduled in each location was available to anyone logged into DCOHome and this information was automatically kept up to date via JavaScript and Ajax refreshes. This WebDAV access, along with the use of Active Directory user accounts to authenticate with DCOHome, allowed me to also retrieve personalized email and calendar information for the currently logged in user used for alerting and display within DCOHome.

Associated Services

Wendigo DHCP Server: The core leasing logic, logging, and persistent data storage for the Wendigo DHCP server was implemented completely within DCOHome. Wendigo, SAITs home-grown Java DHCP server, made use of private APIs exposed by DCOHome to make on-the-fly network address leasing decisions for every device on the DirectConnect Network. This technology formed the core of the DirectConnect Network Access Control system I helped develop.

Interactive Voice Response: While never fully deployed to the production server, I created an interactive voice response system that allowed users to interact with the DCOHome service through the use of telephone calls with touch-tone DTMF input, SMS messages, or a combination of both. This was designed to be particularly useful when RTAs were assisting students while not in from of their own computer. For example, RTAs often helped students connect their game consoles to the DirectConnect network while in the students room during a scheduled appointment. Using this system the RTA would be able to use their cell phone to send an SMS message to query the personal information of a student. DCOHome would reply with an SMS message containing the student's relevant personal information. A subsequent SMS from the RTA could be used to associate the MAC address of the student's game console with the student's account and queue it for unrestricted access to the DirectConnect network. Once a reply SMS was sent to indicate success the RTA could test the connection and leave knowing the game console had been successfully setup. Many such use cases were implemented that would make "in the field" access to DCOHome's data and services much easier to access.


Utility Threads: The forums system in this version of DCOHome was designed to be incredibly flexible. In particular, it was designed to allow nested comment threads to be easily, automatically, and conveniently associated with any other objects within the DCOHome system and a universal view allows these forum threads to be embedded in any page within the system with a single line of code. For example, when a client user enters a support ticket a new forum thread is automatically attached to that ticket and user comments are automatically posted to that thread. This thread can then be easily displayed on that ticket's details page, or any other page, using a single line of code.

Polymorphic Architecture: A very powerful addition to this version of DCOHome was the architecture of the forums being designed to allow a wide variety of parties to interact with a forum. In previous version only users with accounts in the DCOHome system could interact in forum conversations. In DCOHome v3 the forums were designed to efficiently make use of polymorphism to allow many types of entities to interact with a forum conversation. For example, when dealing with client support tickets, both SAIT employees with DCOHome user accounts and client users within the department with an Active Directory account but without DCOHome accounts can both interact and communicate in a single forum thread. Similarly, when students check in their computers for long-term support services, both the employee with a DCOHome account and the student without any account at all can communicate on a forum thread associated with the transaction.

Student Computer Check-In And Product Sales Transactions

Paper Process Goes Digital: SAIT had been using generic paper forms to record information about students checking in computers for long-term support and troubleshooting. These forms, created in bulk many years in advance, quickly became out of date and led to many issues that a digital system was able to resolve. First, prices listed in a digital system could be changed as our prices change whereas prices on the thousands of carbon-copy paper forms had to be scratched out and a new price written in by hand which appears terribly unprofessional. Second, the back of these forms was used by our staff to record notes about the work that was done on the checked-in computer. Unfortunately, since it was a limited amount of space our staff often didn't leave verbose enough notes or did not write legibly so that others could read it. Both of these problems were resolved by making use of forum utility threads associated with the digital transaction. Third, using a paper process there is no easy way to keep the owner of the computer in the loop as to the progress of the work being done. With the digital process emails can be sent as work progresses and the transaction moves between different stages of completion. Forth, when situations change and we need a student to authorize new charges to be billed against their account the paper format requires we have them physically come back to our office to sign paperwork. In the digital system the student can receive an email requesting approval for new charges and authorize those charges from any computer with Internet access. Finally, this digital system streamlined the storage and retrieval of these records as well as helped to streamline the actual billing process done by RTA Coordinators. This same system was also used to track sales of products from our office and the reporting features built into the system allowed us to run reports on inventory levels and sales numbers over given timeframes.

Talos Network Switch Management

Using Ajax, JavaScript, and Widgets: The Talos system allows SAIT to manage the Cisco network switches used throughout the University of Montana's DirectConnect network. This system was a sophisticated module that makes extensive use of JavaScript, Ajax, and many of the widgets included in the Dijit library from the Dojo Toolkit. For example, users can interact with visual representations of switches by hovering over an interface for specific details about that interface, use right-click context menus to perform actions on individual interfaces, receive real-time updates and visual feedback as changes are applied to the switch, and perform and queue batch updates on multiple interfaces or switches. Given the slight delays required to communicate with and alter the state of the remote network switches, the JavaScript and Ajax technologies used make for a much better user experience than reloading and re-rendering the page after each individual action is performed.