Our helpdesk system sucks.  It’s a half-cocked .NET (v1.0) app that was basically conceived as a proof of concept and left alone.  In my opinion, it hardly even meets our most basic need: search.  The importance of documentation in the area of IT support is paramount! 

Currently, the simple app performs and searches.  That’s it.  And that’s being generous with the “searching” description.  It doesn’t support tags or boolean searches.  You have to basically guess right to return any results.  We’ve grown accustomed to this searching method so much that we can cheat it to serve our needs.  This has to change!I’ve spent hours upon hours looking at other helpdesk-y applications and nothing impresses me.  I need a system that can perform the following operations:

1. SEARCH
   • Tagging
   • Boolean
2. FLEXIBILITY (mostly DB-related tasks requiring unique tables)
   • Must include the ability to attach multiple IT workers to a ticket
   • Must automatically update time fields (ticket created, assigned, updated, etc.)
3. EXTENSIBILITY
   • We must be able to extend the usage of this tool to provide a framework for future webapps

The last requirement is the most important.  We need a framework that can be used for multiple helpdesk-type apps.  We have several pieces of software that beg to be converted to web applications.  There’s a prevailing hypothesis that webapps, when used on the intranet, offer enhanced security over desktop apps.I’ve spent several days just searching for a framework that will allow me to create a helpdesk application as outlined above and I’ve come up completely empty. My searches began with AJAX so as to steer away from M$-based .NET apps for a more open solution.  

Unfortunately, even through searching O’Reilly’s Safari Books Online, I haven’t gleaned any useful information to aide me in this quest.  After reading a recent article in Wired Magazine about Ruby on Rails, I’ve started to explore the possibilities of using RoR.  What’s most confusing about web development is how all of the pieces fit together.  RoR, AJAX, DHTML, HTML, etc, are all very confusing when it’s unclear how they fit together to deliver the application. The most frustrating aspect of this entire project is that the datagrid, the most fundamental component of any web application, seems to be the most elusive of all components.  I’ve found just a few examples (in various languages) but none of them appear to use SQL data and most are pricey or included in a pricey development environment.  I’ll continue the search…

I finally narrowed down the tags necessary to reasonably import all of our MediaWiki pages.  There are only two problems that we’ve decided to deal with:

1. Each imported article is tagged with the fulltext of the article
2. The nice bit of javascript code: if (window.showTocToggle) { var tocShowText = “show”; var tocHideText = “hide&quote;; showTocToggle();} }

And then one that’s annoying just me, the only Apple user in the department.  This occurs when I try to access a wiki page using my MacBook Pro with 10.4.11 and Safari 3.0.4:   

 

So far the rest of the guys in my department love the table editing and the search.  The search will get better once the articles aretagged properly.  We’re removing that bit of code and the fulltext tag on each page we access as we get to them.

I’m attempting to import our small (~300 articles) wiki into Apple’s new OS X Leopard Wiki software.  I’m using MediaWiki 1.10, MySQL Essential 5.0.24, and PHP 5.2.3 on a Windows Server 2003 box.  I’ve been following a few discussion on Apple’s Support Forums (http://discussions.apple.com/thread.jspa?threadID=1262380&tstart=0) and only recently have we talked about Apple’s Wiki Importer (only available to ADC members).  Using the MediaWiki Export Document from the Disk Image, I was unable to successfully point the tool at my wiki’s index page.  By process of elimination I determined that one bit of JavaScript code rendered the page (within the tool) incorrectly:

 // if we’re on the index page, expand the “to” links

if (location.href == appleWikiImporter.indexPageURL()) {

$$(‘a’).each(function(a) {

if (a.href && a.innerText == ‘to’) {

add_index_links_from_url(a.href);

}

In other words, when I pointed the Importer at my All Pages MediaWiki page, it displayed no page links what so ever.  Removing the above code solved the issue. 

The next step is to determine which sections of MediaWiki’s CSS need to be ignored so that they aren’t imported into Apple’s Wiki.   I should also mention that I chose to use the default MediaWiki skin (and therefore the default CSS), which is located at %mediawikidir%\skins\common\wikistandard.css.  I iterate through a couple of times to try and figure out the correct syntax for the sections to ignore and determined that Apple’s tool identifies the sections in my CSS by using dot notation.  In other words, by specifying “.footer” as a CSS Content Exception, the Importer ignored the “#footer” tag in the CSS and therefore any “footer” tag in a wiki article. Currently I’m having problems with the “Edit” field that MediaWiki puts next to any heading/sub-heading.  Also, the Importer tool is taking the fulltext of a MediaWiki article and setting that as a tag for the resulting Apple Wiki article.  More to come as I figure this stuff out.