CSE Checklist Tool

Executive Summary

This document describes the "CSE Checklist Ttool." The concept of this tool is that staff member users create records for instances of things that require coordinated actions by multiple staffers, after which the staffers mark off each item as it is performed. The tool displays each task with its status.

In order to allow a single tool to serve multiple applications, there is a separation of code from data. There is a general purpose "engine" shared by all applications, and there is a per-application configuration file that establishes the personality of the tool for that application.

Applications

These are the applications that use the checklist tool:

visiting faculty
Blah, blah, blah. Test version.

Implementation

The tool is coded in Perl5.

The personality of this program is set via the URL, which contains the path of the configuration file, which is available to the program as the value of the PATH_INFO envar.

We store the persistant state in a Storable. The top-level data structure is an array of records. Each record is a hashref, with keys named by the values of the tag fields in @elements.

The details of the fields in the hash are controlled by the @elements data structure, which lives in the configuration file that is necessary to give this tool a personality. For the most part, each item in @elements corresponds to a field in the hash (except for 'section' and 'instr' types).

The element types, and their attributes, are:

Type Semantics Attributes
text a text input field name, tag, size, required, email, valid, ordered, indexed
date a date input field name, tag
action also a date, but implies an action name, tag, indent
caction yes/no radio buttons name, tag
section immutable text with leading HR name
instr immutable text name, collapse
synthetic text synthesized by calling the function $_->{display} display

The attributes have these meanings:

Attribute Semantics
tag single-token handle on the element
name displayed label
size for 'text' elements, the field width
required a required field
email an email address-- include mailto links
valid a regular expression that valid values must match
indexed whether this element is a column in the index
ordered whether users can sort the index on values of this field

We worry that a record could lose data if one user submits data between the time that another user loads the edit screen and saves their own data. Therefore, we store a last-modified timestamp on each "record" (that is, each element of the array in the Storable), and store the time that an edit screen was built in a hidden field in the edit screen. We won't store data for a record if it was modified more recently than the edit screen was built.

This program implements a test and a production installation, distinguished by the name of the script: it the substring "test" is found in the script name, it's running in test mode. Currently, that has no effect whatsoever other than to set the unused variable $debug, but it can come in handy for debugging. Because test mode is controlled entirely by the script name, nothing needs to be changed in this file to move to production mode (other than the filename itself).