Hi Everyone,
First, thanks Jesse for soliciting input from the user community; hopefully this input will improve the quality of the software. Second, this message is not meant to be critical, as its goal to get the user community more involved in the Request Tracker development process. As I reviewed the responses to this thread the one constant I saw and kept coming to mind was better technical documentation. A fair amount of the ideas submitted could have been easily accomplished by writing an extension to RT or a standalone script in perl. This is easier said than done. I have written several reporting scripts and added a few code modifications to Request Tracker to add functionality to the code. I will say writing the code to do this was not very easy. All I had to go on was looking at existing Request Tracker code, and through trial and error, I was able to code what I wanted to do. Sometimes the code to get certain data items amounted to less than 10 lines of code. But, to derive the 10 lines of code could take hours. I also submitted questions to this forum and there were folks who were very helpful when I truly got stuck. What is sorely needed for Request Tracker is a true and serious technical documentation manual. A manual that really explains all the functions and calls used specifically in Request Tracker (libraries, etc.), including example code. To the uninitiated looked through Request Tracker code to figure out how to read ticket information, generate reports, etc. is not a very pleasant experience. Fortunately, I was able to use code from various contributed software extensions to construct reports and Request Tracker extensions by extrapolating how something was done and applied it to what I wanted to do. I am surprised that there are not more contributions to the Request Tracker archive; considering the number of sites which use Request Tracker. Part of this reason is what is embodied in this message. A good, solid technical manual would go a long way to improve Request Tracker because more people will be able to understand how to construct viable code. In regards to handling mandatory fields, we came up with a compromise solution. We only have folks who manage tickets the capability to log into Request Tracker. We created a set of external CGI scripts which capture the ticket data needed to populate a ticket. All field checking is done within the CGI. Also, we are free to set up field widths any size we like and format the CGI form in a more user friendly manner. Once the user submits the ticket, the ticket is e-mailed directly into Request Tracker through the ExtarctCustomFieldValues template (available at the Wiki). We just make sure that the various field values are in the body of the e-mail can be detectable by the ExtarctCustomFieldValues template. Finally, we set up an unprivileged account called "guest", which allows the user to view their new ticket via e-mail and via the CGI script after they submit the ticket. We modified all the other e-mail specific templates to include the "guest" account user name and password in the URL. So far, we have had no issues with tickets not being filled in properly; which has made many folks lives easier. Finally, by using a CGI scripts and e-mail there is not direct interaction with Request Tracker and the database. As for reporting, I created several scripts which provide metrics on our queues. These scripts can produced both text based and spreadsheet (perl model request) for management and higher up review. These scripts used some of the programming ideas in RTX::Statistics and rt-remind.pl, both are available on the Wiki. Some additional programming had to come by looking at Request Tracker code itself. In regards to Asset Tracking and change control, we use Asset Tracker and have a field called "Change Comments". When a person makes a change on the asset, they put something into "Change Comments" which the value is placed in the Asset history. While this is not very elegant it gets the job done. In addition, I created a set of scripts which uses SSH tunnels to obtain configuration information from our UNIX/Linux based systems. The data is then filtered and a report is created for each host. Another script parses the reports and updates various custom fields for the appropriate asset maintained in Asset Tracker. This works 99.99% of the time; however, sometimes SSH will hang on systems which ran out of disk space. We run this script against 300 systems each night, barring SSH hangs, takes about 20 minutes to complete. With the exception of updating custom fields in Asset Tracker, virtually all the code does not require knowledge of the internals of Request Tracker or Asset Tracker. As for the custom field updates, well this required bothering the author of Asset Tracker a lot and reading through the code. Finally, the conclusion one should reach from this message that if there was a solid technical documentation manual, much of what is being requested could have been developed by the user community. What is contained herein are some of my experiences over the past 18 months; beyond that time I never heard of Request Tracker. I believe there should be means for the user community to be provided the tool, in this case technical documentation, to enhance Request Tracker beyond what is provided today. Nick PS If someone tells me how to put a tar file on the Wiki, I will be glad to provide some of the reports and code enhancements I mentioned in this message. I would include in the tar file, a copy of the reports, modifications to Request Tracker/Asset Tracker, modifications to RTx::Statistics, the Asset Tracker SSH scripts and the CGI scripts. I also have a manual I wrote for installing Request Tracker at our site including all the enhancements we made to the Request Tracker code. My Management believes in contributing back to the Open Source community so this would not be an issue. Hopefully, some of these enhancements and changes will make it into Request Tracker 4. ------------------------------------------------------------------------ --------- Nick Metrowsky Consulting System Administrator 303-684-4785 Office 303-684-4100 Fax [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> DigitalGlobe (r), An Imaging and Information Company http://www.digitalglobe.com <http://www.digitalglobe.com> ------------------------------------------------------------------------ ---------
_______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
