SupportActionTracking

From PikaDocs

(This article is by Scott Trudeau, Michigan Poverty Law Program)

The Problem and the Plan

The requirements for the module aren't complex. We need to track who we have provided support (by legal services program) and what kind of support we provided, (type of service, service level, request type, etc.). Attorneys also like to keep brief notes about each action, as well as keep handy contact information.

With this in mind, combined with a dearth of time to build something from scratch, I decided Pika's "activity" model would work well to re-implement the existing system and fit well logically. Also, by tracking support actions as activities, I could take advantage of the Pika calendar interface to allow attorneys to manage existing support actions.

Doing It

Adding a new activity type to Pika is harder than it looks, but is still pretty easy. I added the new code and label to the act_type menu ("S | Support Action") and created a new subtemplate name activityS.html (I copied an existing activity template to start with, and modified it to meet our requirements.) Since we have to track data beyond what was already available in the activities table, I added some fields to the it (request_type, service_level, program, sa_name, sa_address, sa_phone, and sa_fax) and added supporting menus for drop-down field types (menu_service_level, menu_request_type and menu_programs). My initial template was pretty straightforward Pika template design: text fields and drop-down menus. If you’ve modified Pika templates before, this is old hat.

Since the attorneys like to track contact information for each action, and since most of the supported parties work for one of the state legal services offices, I needed to add a way for attorneys to quickly look up the address, phone and fax information for a given office. I considered using the Pika address book to store this information, but co-mingling office contact information with case-related information seemed inelegant, and I didn’t want to modify the contacts table (since ultimately, I want to replace the database solution with an LDAP one). I instead created a separate table to store only office contact information (_offices) and a menu to store a list of programs (menu_programs). MPLP maintains a state-wide legal services directory (another custom MS-Access based app I've got my LAMP sights on), which I used to generate the _offices and menu_programs tables.

Now that I had the data in the database, I needed to extend the interface to make it quick to find office contact information. I decided that I'd ask users to first select a program, and then select an office. Upon selecting an office, the phone, fax and address fields are automatically filled. This keeps the pull-down menu length manageable, and allows users to enter alternate information for contact information if they desire. The obvious way to achieve this is using javascript. I found a free implementation of something similar on the web and (heavily) adapted it to my purposes.

Once I'd written some working javascript and some php that would pull the required information from the database and format the javascript code correctly, I needed to insert this code somewhere sensible in the Pika code base. I also needed to insert code to tell Pika what to call an activity code 'S,' (activity.php doesn't look this up in the act_type table, apparently) and pre-fill a few tags for use in my template (for the current date and user). I put as much code as possible in a separate module file (modules/activity-support.php) and modified two sections of activity.php to get the desired results. There are two switch statements in activity.php, one that is encountered when adding a new activity, and the other when editing an existing activity. Each statement has special cases for each activity type -- usually it just sets the activity type description. I simply added a new case to each section (case 'S'), and placed my special-case code there. It'd be nice to not have to edit a core system file (activity.php) to add this feature, but I couldn't find a better way. Here is the activity.php code for adding a support action:

case 'S':
    $type_desc = 'Support Action';
	$a['current_date'] = date('m/d/Y');
	$a['owner_menu'] = pl_array_menu($pk->fetchStaffArray(),
					'user_id', $a['user_id']);

 	include_once('modules/activity-support.php');

         //get a list of programs from db
	$programs = sa_get_programs();

         //get the dropdowns
        $a['program_dropdown'] = sa_get_program_dropdown($programs, -1);
        $a['office_dropdown'] = sa_get_office_dropdown();

 	//get the javascript necessary for autofills
        $a['sa_js'] = sa_get_javascript($programs);
    break;

The section for editing a support action is exactly the same, except for one line, which ensures the proper option is selected on the program drop-down menu:

$a['program_dropdown'] = sa_get_program_dropdown($programs, $a['program']);

See full files included below.

The only thing left to do was add a link to the subtemplates/home.html page:

<li><a class="hd" href="activity.php?screen=compose&completed=0&act_type=S">
					New Support Action</a></li>

Room for Improvement

There are a few obvious areas of improvement for this module. Right now, the database code uses php MySQL calls to communicate with the database. Pika uses the ADOdb database abstraction library, which would be more appropriate and generally applicable (anyone out there using postgreSQL or something other than MySQL?). I could probably also rewrite the functions to better match the Pika style.

Eventually, I hope to set up a Michigan legal services LDAP Directory Server to unify our growing number of web applications and to store our existing legal services contact directory. When this is up and running, I'll probably integrate the Support Action tracking module with that LDAP directory, instead of periodically generating a new _offices table based on our existing directory.

Also, I'd like to find a way to stay out of activity.php or other system files with the module -- but at the moment, I can't see a way out of it. This makes Pika version upgrades a bit trickier, but isn't overwhelmingly burdensome to maintain.

If you want to see this module in action, email me: strudeau AT umich DOT edu.