The New Request page contains many panels, these panels will be used to hide and show sections based on the user preferences.

The Request Number Panel should not really appear and the user therefore does not not need the ability to hide it.  The Request Number Panel has three main pieces.  The Request Number, Request ID, and Current Status.

The Number field is used to provide a human readable number for users to keep track of so that they may reference the request when performing searches, generating future reports, or simply revisiting the request.  The Number will be system generated, and will probably be based on location code and a sequence number.  A numeric date representation could be thrown in as well.  This again is a convenience field provided strictly for users.  It could be argued that it doesn't even have to be stored, but could be dynamically calculated at runtime.

The ID field will only be visible to IS personnel specifically for troubleshooting and maintenance.  The ID field should be auto-generated and it will probably be an auto-increment as well.  The ID will be used to tie every bit of the program together including all relationships.  The ID will however only be unique across a database.  If multiple databases will be required then this ID can be changed to a GUID.

The Status field will only display the current status of the Request.  On the New Request page it will simply always display the word NEW.  It isn't actually a textbox field but a label to further indicate that status must be changed elsewhere.  A New status will be added to the associated tracked status file with the date of the status based on the system date.

The following items must also always be displayed.  The Subject, Request's Initial Comment, the Category, and suggested Action.

The Subject line is a short version of the comment used for ease of recognition by a user when they are searching for a request and perhaps have misplaced their request number.  The Subject should contain keywords that are not found in other places in the system.

The 1st Comment is the main location where a user can further define their request.  Such comments will also be indexed in future versions to allow for broader searches.  This 1st comment must be entered by the requester so that workers can more easily accomplish their task.

The Category is a drop down list that will display a predetermined set of items to group specific actions for a request.  A Category may contain such groupings as Software, Programming, Hardware or the like.  The Category should not contain location info, department info, or other info that is in the optional section.

The Action is also a drop down list that will display a calculated list of items that can be performed for a specific category.  This version will not contain a filtered list, but future versions may determine based on the category item selected which Action options are available.

The Status section shows the current status, some buttons to change statuses, and a grid that contains the current requests historical status details as the status has been changed over the course of the Request.

The current status is displayed to the left of the Status History button.  The Status History grid should probably be hidden until the user selects status history.  

The Status should be sorted in date order with the newest date appearing at the top of the grid.  The grid should contain the status name, the person's name who set the status and the date the request received this status.  A comment field is displayed for the specific comment related to the status change if any.

Four buttons appear to the right of the Status History button.  The buttons are listed as:

• Approve
  • this button should only appear for Approvers (supervisors of the current requests department)
  • Approvers can read over a request and hit approve when they are sure that the request will be routed to the proper department based on the category
• Assign
  • this button should only appear for Assigners  (supervisors of the department for which the request is intended)
  • Assigners will be sent to a new Assignment page and upon completion, the request will be given the Assigned status
• Cancel
  • this button should appear for Assigners or Approvers (supervisors) 
  • Approvers can Cancel a request before it leaves their department
  • Assigners can Cancel a request they find frivolous or for whatever reason may arise
• Complete
  • this button should only appear for Assigners (supervisors of the current requests department
  • Assigners get the last word on whether they believe a Request has been completed

The buttons should not be enabled 

• if a user is not authorized to perform the action.  
  • Some examples might be that the users isn't in the required role
• if the action has already been performed and the status is not cyclical
  • A request should only be approved once
  • A request should not be able to be completed after it is cancelled

Copyright 2002 - 2003 XOCOMP, llc
Contact: md3@protocolla.com or md3@xocomp.net after March 2003

All materials and notes are the intellectual property of XOCOMP with expressed permission for use by PROTOCOL.