Training Registration System
Durham Tech typically has a number of faculty and staff training workshops each semester, covering topics from utilization of Sakai, the current learning management system, to use of various online systems such as Colleague and SoftDocs, and even offerings for common software such as Microsoft's Office suite. These workshops are listed on a website built on ColdFusion technology, which enables faculty and staff to register for courses, receive reminders when a course is upcoming, and allows managers to track both registration and attendance.
Though the system is still functional, it is aging, and was designed without authentication. As part of the effort to upgrade the technology infrastructure at Durham Tech, a new site based on the Drupal content management system will incorporate additional features as well as tighter integration with the rest of the network.
The data model for the system is quite simple, and includes three basic data types -- workshops, meetings, and registrations.
The first of these is the workshop, which represents a particular training topic. Each workshop consists of a title, description and a section category. A given workshop, once created, can be linked to any number of meetings and reused from semester to semester.
The second data type is the meeting. Meetings represent actual training sessions, and include location, instructor, and beginning and end times. Meetings are also the basis for registration, and so contain information on registration settings. These include registration capacity, dates when registrations are opened and closed, wait lists and wait list limits, and reminders. Any number of registrations can be linked to a given meeting.
The third data type is the registration, which consists simply of a registration state, and are the only data type that can be created by non-administrative users. They are linked to a user and a meeting, and usually created by a user. If creating a registration would exceed the capacity set in the meeting's registration settings, the registration state is set to "Wait list". Otherwise, a new registration is set to "Registered." Upon completion of a training session, the registration state can be changed to "Attended" or "Completed," and the state can also be set to "Dropped," at which point the registration will no longer count towards the meeting capacity.
There are workflows for creating, editing an deleting each of the above data types, each linked to a menu item in the left sidebar menus except for the trainee registration workflow, which is started from the far right "Register" link for any views that list meetings.
The workflow for creating a new workshop is simple, starting with the "Add new workshop" link that opens a form allowing entry of the workshop title, description, and a drop-down list to select the workshop section. Once created, the workshop is immediately available for scheduling meetings. Editing or deleting workshops can be done from the "Manage workshops" menu item with the "edit" and "delete" links in the resulting view.
Creating a new meeting begins at the "Add new meeting" link, which opens the form for adding meeting details, including fields to choose the start and end dates, locations (a drop-down list) and the workshop (also a drop-down list). The instructor is the only text-entry field. Once this information is entered, the form for registration settings opens, allowing the user to set the capacity for the meeting, and optionally add a reminder email that will be sent on a selected date. The user can also impose limits on when registration opens and closes, or change the wait list options, which are enabled by default. Editing or deleting meetings can be done from the "Manage meetings" menu item, which opens a view with "edit" and "delete" links. In addition, there is a "manage" link for each meeting that allows the user to alter the registration settings.
The creation of a new registrations is the simplest of the three. If a user clicks on a "Register" link, they see a form that allows them to confirm their choice, and if the meeting is at capacity, they will receive a message that they've been placed on the wait list. An administrator that clicks on the same link will also see a drop-down that will allow them to choose a to register another user. There is no simple way to delete registrations, and editing them is limited to changing their state, which is done from via the "Roster" menu item. The resulting view shows a list of all registrations, filtered by registration state. The user can select a check box next to each registration that they would like to alter, and then choose a new state for the selected registrations on the next page. This would primarily be used for marking attendance and completion for workshop sessions.
The contents of the old registration system have been included in the current system for archival purposes. Though the old data are organized in a completely different manner, a custom view has been implemented to show a list of all previous registrations, grouped by the email address of the registrant. This list can be filtered by email address or last name, allowing any former trainee to view a rough transcript of their workshops.
Another feature of the registration system is the ability to send a bulk email to all registrants of a particular meeting. This can be accessed by going to the registration settings (via the Manage meetings page) and choosing the "Email registrants" button. This will open a form that will for sending an email to all registrants.
While the foregoing design is relatively simple, the underlying structures are a bit more complex. Drupal is generally known as a content management system, but it might be more accurate to describe it as a framework. Much of Drupal's functionality is achieved via extensions known as modules, but with the advent of Drupal 7, the basis of the design has shifted to configurable data objects that are known as entities. Understanding modules and entities is the key to understanding modern Drupal design.
Drupal content types and entities
In previous versions of Drupal, the basic content type was known as a node, which was a content object with certain attributes such as title, body, and publication status. As of Drupal 7, nodes have simply become another type of entity, which is simply a data object with configurable bundles of fields. Entities can be created programatically or via modules such as the Entity Construction Kit, and can contain any combination of field bundles. In the data model above, each of the data objects listed is in fact a Drupal entity. The workshop and meeting entities are nodes with customized fields, and the registration entity is a entity created by the Entity Registration module, and linked to the meeting entity. The meeting entity is then linked to a workshop entity using another module, the Entity Reference module. Th registration states are also entities that are attached to each registration, but as they are not customized in any way, they can be treated as simple field values.
The other aspect of Drupal that is important is the module structure. Even for a site as simple as this, there are a number of modules necessary for the existing functionality.
There are a several modules used for the basic functioning of the site, such as the CKEditor and IMCE modules that provide a WYSIWYG interface for text entry, and the Administration menu module, which provides an interactive menu at the top of the page for administrators.
One of the central modules to this and many other Drupal sites is the Views module. As the name implies the Views module allows the user to create custom views of almost any data in the Drupal database. The Views UI module provides a convenient interface that is easy for any database designer to understand. All of the list pages in the site use Views to represent data in a tabular format. The user first selects a base content type and display format for the view. The fields are then selected from the Views UI, as are filter and sort values. If data is combined from multiple content types, then the relationship must be specified in the Advanced section of the Views UI. Once specified, the user can then add fields from the linked entitiy to the view. For example, the main page of the site, which lists all upcoming workshops, is a view built on the meeting content type. The view is shown as a table, and the date, location, and time are all taken from the meeting node. Then, a relationship is added using the value of the Workshop field, which is an Entity Reference filed pointing to the parent workshop. With that relationship, the workshop title and section are also included, and can be used to group and sort the table results. Another relationship to registration settings is also added, and that allows the display of the capacity and current number of registrants. Finally, the Entity registration module allows the creation of a "Register" link that will create a new registration when clicked.
In addition to the Views module, the site also uses the Panels module to customize the layouts of various pages, and the Rules module to customize workflows. These are used primarily in the creation of new content. The Panels module gives the user the ability to override the default content creation forms, which include a number of fields that are unnecessary, and are always laid out vertically. The Panels module allows the user to select only those fields that are needed, and to place them on the page in any format desired. The Rules module allows the user to redirect workflows, so that instead of seeing the newly-created content after saving it (the default Drupal behavior) the user is redriected to one of the custom views. In addition, the Rules module is used to redirect the user to registration settings after creating a new meeting, so that the user can immediate set capacity and add a reminder, if desired.
The final element of the site is the Data module, which allows mapping imported data into Drupal. This is what is used to display the contents of the old registration system, with the displayed fields being mapped as text fields, and joins being specified in the Data UI.