Results matching “2006/08/22/using_drupal_to_build_a_knowledge_base_with_rt” from Contentment

I previously published an article here about using Drupal and RT together to create a knowledge base system. I've continued to improve the system and wanted to give an update on how it's working.

Of the pieces I mentioned in my previous article, I have implemented Organic Groups in the system. I have not (yet) implemented any of the other ideas I had at the time. In addition, I have used the Front-Page module, added use of the Content Construction Kit (CCK), and started adding some tweaks to RT.

Organic Groups

I have added Organic Groups to the site to operate the same kind of functionality as is provided by a SharePoint sub-site or a Trac project. Each Organic Group is a smaller segment of the whole knowledge base dedicated to a specific project or knowledge area. Organic Groups allows each user of the site to be a member of just the groups that are of use to him. It keeps membership lists for each group and also provides (some) notification regarding new content (it would be nice if content updates could be included as well, but does not at this time). Content may also be associated with no group or can be associated with a group while also being public as well.

All in all, this has been very helpful to segmenting the site.

Front-Page

I've used the front page module to setup a simple comment that goes to all anonymous users. The knowledge base is available from the Internet, but is only intended for internal use at this time. However, it is possible that someone might stumble upon it (most reading this could probably guess it's location in less than three tries and probably a majority only in one...). I wanted a special page facing out for anonymous visitors so that it would tell them to bugger off (though, in much nicer terms than that). It would also help our staff find the pages they are looking for more easily.

The front page module allows me to setup a front-page that's special to any anonymous visitor as well as having a page that's special to those who have already logged in. After you login to the site, the new front-page is a basic table of contents and list of policy documents that affect all of the group sites.

Content Construction Kit

The CCK is the future of all content on Drupal sites, as far as I can tell. Soon, the "story" and "page" and "blog" content types will just be custom content types created by the CCK. This is a good move. Custom content types has been a weakness of Drupal for sometime and flexinode wasn't quite there—in fact, it was one of those demo-turned-indispensible modules that every programmer dreads creating or maintaining.

In this case, I've used a combination of the CCK, the Category module, and the Event module to create a special content type, the "sub-project". These are a combination of "component" and "milestone," which seems to fit our web development project. Some of the features on the site can be grouped into convenient sets that all can be accomplished together. Each of these tasks are related and often feed each other, but aren't really the same task, thus are handled in separate tickets. This has been very helpful.

Each sub-project has a title, a description, and a due date (the need for the event module). These are plottable on a calendar via the event module. These are also "categories" via the Category module, i.e., nodes that act like taxonomy terms. This allows knowledge base content to be classified into these special categories. This is very cool. I have also pulled these into RT, which I will cover in the next section.

In addition to the above, I plan on creating some other custom content types for various bits. For example, I would like to build a "computer" content type to describe individual machines on our network and a "software package" content type to describe computers. These can then be used in the IT group to associated particular articles with particular computers and software packages. Thus, the CCK content types begin to take up the role provided by custom lists in SharePoint. These can also figure into the RT modifications I'm about to describe.

Auto-Complete in RT

I need to formalize this a bit better, but I have added customizations to the custom field rendering component in RT so that I can make custom fields autocomplete in the same way as they do in Drupal. I have added a "Sub-project" custom field to the Web Development queue. Then, I tweaked the component so that those custom field editors pull the available values from the available milestones in Drupal. This is the first real communication I've added from one system to the other and, so far, to work it requires you to be fully logged in to both systems (no single sign-on yet).

I'm still pretty happy about this and it certainly beats the pants of Microsoft SharePoint. I hope to have further updates as well. Currently, I'm thinking of more CCK types (as mentioned), pulling tickets into Drupal from RT so that categories list the tickets that belong to them (possibly using RT's RSS features and the Aggregator module or Aggregator2 module or some other variant), and getting single sign-on working so that we don't have to login twice anymore.

I'm also still considering some of the things I mentioned previously, though they aren't quite as high on my radar right now.

Cheers.

Phew! This is getting nuts. I am more busy on web development at home than I am at work. Frankly, with this flurry of stuff going on at home, I'm starting to get a bit bored with work. Well, I do want to talk about something I did at work yesterday because it was pretty cool. I've put together a knowledge base and issue tracking system using Drupal and RT. It was pretty easy and I think others might benefit from at least some aspect of the solution.

We've been using Trac to keep track of our knowledge base, issues, milestones, and source browser surrounding the web development project. For the internal IT stuff, we've been using Microsoft SharePoint. Both have had limited success. Trac worked perfect until we needed a way for web site visitors to send in support requests via email. Trac's support for this is total crud. It's still being worked upon, but after having used RT in CIS, I'm pretty hard to please when it comes to support tracker email integration. Sharepoint has worked about as well as it ever does: good enough, but it's a bit tiresome to use. If we were using the beta of the new version, it would probably be fine, but that's not trivial upgrade to perform without causing massive alterations to lots of other services we run.

Okay, so I've started to put together something that could potentially replace both of these with flying colors. It's still a work in progress, but I think I've already got something better after only a couple days of working on the problem.

First, I installed RT 3.4. After installing it and getting Sendmail configured on our hosted server, I got RT configured. I leave learning how to do this as punishment for the reader.

Then, I went in and installed Drupal 4.7 and started configuring it. First thing to do is to install all the modules. I've installed the following:

• Category. This is one of my new favorites. It is a drop in replacement for the Taxonomy module that makes every vocabulary and every term into a node. You can even use arbitrary content types as vocabularies and terms and can have vocabularies within vocabularies. It's very nice. Oh, and you can set the default item depth of a category so that it automatically aggregates children to a certain depth. Also very nice.
• Interwiki. This is kind of the best available for the functionality I'm looking for, but it needs a bit of work to get it right. Basically, you can register prefixes with it that will then be translated into URLs using a wiki-like syntax. For example, it comes configured with the prefix "w" automatically linking to Wikipedia articles. Thus, you can insert Nichols Hall and it would link off to Nichols Hall at Wikipedia. You can add other prefixes to other sites or use no prefix, i.e., foo or //drupal.org/project/pathauto">Pathauto. This ought to be a standard Drupal module. It generates paths for a node according to settings you set. I use it heavily on this site now and it's what allows us to have nice wiki-like articles on the new knowledge base.
• TinyMCE. This is a must have if you have non-technical or semi-technical staff helping you write articles. We have a content editor, Doug who understands but doesn't really converse in HTML on a regular basis. There's no need to make him when TinyMCE exists and is so easy to install and use.

That's it. I installed all of those and then went through the tedious process of setting up access controls, updating settings, etc. Now, I can create a page on the site titled "You are a foo foo" and then create another article and link to it by adding the text [:You are a foo foo
. I can use TinyMCE to format the text without worrying about learning the Wiki-syntax-flavor-of-the-month and so I won't be too afraid to show someone completely non-technical how to enter knowledge base information later on.

I added new custom interwiki prefixes for getting at RT and Trac tickets and the old Trac knowledge base articles as well for the transition period. Now, I can link to our old standards document via BoomerStandards
or to a ticket in the old system via 435
or to a ticket in the new system via 219
. I added a number of other shortcuts as well and this is really the only wiki-syntax anyone needs to know about and this is a pretty easy one to remember.

The knowledge base is now in place. Let's go back to RT. To RT, I've now added a callback to the system for the ShowMessageStanza ticket element in the RT system. That is, I created a file named "Callbacks/boomer/Ticket/Elements/ShowMessageStanza/Default" in the local hacks directory for RT. You may wish to see CustomizingWithCallbacks for more information on creating customizations using the RT callback system. Anyway, the contents of this callback is as follows:

<%perl>
$$content =~ s{(?<!&)\#(\d+)}
{<a href="${RT::WebURL}Ticket/Display.html?id=$1">#$1</a>}gx;

my %config = (

        tracwiki => 'http://trac.example.com/trac/foo/wiki/$1',

        trac => 'http://trac.example.com/trac/foo/ticket/$1',

        rt => $RT::WebURL.'Ticket/Display.html?id=$1',

        http => 'http:$1',

        https => 'https:$1',

        '' => 'http://supportkb.example.com/$1',

);

$$content =~

        s{

                (!|\\)?         # stop now if there's a ! in front

                (

                \\

\|]*):    # match a prefix like abc:, remember the prefix

                (([^\

]+))? # match a pretty name like "Blah Blah is cool."

                \]              # match closing ]

                )

        }{

                my ($escape, $match, $prefix, $link, $title)

                        = ($1, $2, $3, $4, $5);

                if (defined $escape) {

                        qq($match);

                }

                elsif (defined $config{$prefix}) {

                        my $url = $config{$prefix};

                        my $term1 = $link;

                        $term1 =~ s/\ /_/gx;

                        my $term2 = $link;

                        $term2 =~ s/\ /\+/gx;

                        my $term3 = $link;

                        $term3 =~ s/\ /%20/gx;

                        my $term4 = $link;

                        $term4 =~ s/\ /-/gx;

                        $url =~ s/\$1/$term1/gx;

                        $url =~ s/\$2/$term2/gx;

                        $url =~ s/\$3/$term3/gx;

                        $url =~ s/\$4/$term4/gx;

                        $title = defined $title     ? $title

                               : $link =~ /^                      "$prefix:$link";


                        qq(<a href="$url">$title</a>);

                }

                else {

                        qq($match);

                }

        }gex;



</%perl>

<%args>

$content

</%args>

If you're unfamiliar with Perl and Mason, you may have a migraine by now. You might have one anyway, unless you're a JAPH like me.

Anyway, this replicates part of the functionality of interwiki within RT messages by converting the [rt:123
sequences into links. This also features the ability to create links between tickets using a #123 syntax as well, which I'd like to add to the knowledge base eventually as well because I find the Trac-style linking of #123 (tickets), @123 and r123 (revisions), and [123] (changesets) to be very easy to remember and very handy.

That gets me much of the way to an integrated Drupal/RT knoweldge base/issue tracker system. I still need more though, but I haven't gotten there yet. Stuff I'd like to add in:

• Organic Groups. This would allow us to have a subsite for each knowledge base: one for internal IT, one for web development. Later, we could add one for sales information, one for content style guides, or whatever.
• Fix/replace interwiki. The interwiki module is nice, but isn't quite nice enough. It would be nice to have additional formats available. With very little effort, I should be able to create a custom filter to either extend this functionality or outright replace it just for our needs.
• Single Sign-on. I have some experience with this lately. If I can get it so that I only sign in once to Drupal and or RT and then I'm in both, that would be great. If I could implement it using an independent LDAP server, all the better.
• Configuring RT. Configuring the interwiki-ish filter for RT is done in code. This isn't ideal. With whatever solution I work on for Drupal, it would be nice if the RT filter could load it's configuration from the same place, or at least get it from a config file and not in the code itself.

Will I get all this done? Probably not, but I'll get some of it done and if I think it's interesting, I'll try to share it with you.

Cheers.