|
|
|
The New Request page contains many panels, these panels will be used to hide and show sections based on the user preferences. The required fields are:
Based on the user's person information, the following fields will be automatically populated:
These populated fields can still be changed by the user creating the request.
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 Optional Panel allows a user to enter further information that will help locate future requests. Most of the drop down lists will be filled by the system based on the user login information. The requestor, department, division, and location should be extrapolated from the user login. The client can be selected if the user knows which client is directly affected by the request. The Requested Completion date should be a date combo or calendar control that allows the user to select a date they would like the request to be completed by. This date is only stored for estimation purposes only. The Priority drop down list will contain a specific list of priorities that the user may select from. The Rank is related to the priority, but will be used by workers to determine which requests should take priority for a specific user. A user may rank one request over another, but only over ones they have made. The Machine Panel allows a user to adjust which machine they may be using or one they need a worker to look at. The machine button will allow the user to hide the machine combo if no machine is necessary to view when printing a report of a request entered. The machine combo will be filled by the system based on the users login information, but may be changed by a user. This version will not lock down machines, but future versions may be set to only allow a user to select machines located in his or her department and location. The Attachment Panel allows a user to enter further supporting documents or files that will help workers perform the tasks to complete the request. For reporting purposes, the attachment panel has a button which would allow the user to hide or show the attachment grid. The grid will provide a way for the user to pick files to be uploaded. These files will be listed in the attachment grid. Not displayed on the diagram of the new request page is a file upload control. The file upload control will probably be visible next to the Show Attachment button, the user can enter a local file, and it will be uploaded, and added to the attachment grid. The grid should contain the filename and the location the system choose to store the file. The files will be stored in a specific request attachment location accessible by the web server, so they may be presented for download. The Submit and Cancel buttons allow a user to save the request into the Work Request system, or to clear the request if they decide that it has been created in error. Pressing the Submit button will actually check that the Request is ready to be saved and perform any necessary page level validation. Pressing the Cancel button will actually check to make sure that any sub items added during the request entry are removed properly. It will make a call to the Clear fields method to clear all drop down lists, grids and text boxes properly.
|
|
Copyright 2002 - 2003 XOCOMP, llc All materials and notes are the intellectual property of XOCOMP with expressed permission for use by PROTOCOL. |
