// Request Tracker (RT) - Rich Text Custom Fields

For those that haven't had the privilege to work with Request Tracker, it's a ticket registration system which can be used in various situations. One of the more popular usages would be incident management but it can also be used for bug tracking, project managent, CRM like functionality, etc.. If you haven't already, go check it out: http://bestpractical.com/rt/

By default Request Tracker comes with certain custom field types, one of which is the Wiki Text Custom Field. This would allow you to use wiki markup, similar to MediaWiki, which will format your text. Formatted text is something our users specifically want for the Articles feature (knowledgebase) so you'd say they would be happy with this feature. However, the problem with this Custom Field is that you need to learn the wiki syntax by heart which isn't something every end-user want's to do (let's face it, users are spoiled ^_~).

To fix this I've applied the following patch/changes to my RT installation, which has been succesfully tested with versions 4.2.3, 4.2.4 and indirectly also on 4.2.5. For the 4.2.4 release you'd have to manually commit these two patches though, this will fix an issue I've come across for this spicific patch:

Now the actual change itself, this is how it's now installed on my 4.2.3 version (thus, without the above commits).

Convert Wiki Text CF into a Rich Text CF

This modification is inspirerd by the following wiki:

First we need to copy the core Wiki Text CF file to a local directory for editing:

cp /opt/rt4/share/html/Elements/EditCustomFieldWikitext /opt/rt4/local/html/Elements/EditCustomFieldWikitext

Then we need to edit this file:

nano -w /opt/rt4/local/html/Elements/EditCustomFieldWikitext

Add the following code:

%# --- Wiki Text Area ==> Rich Text Area ---

<script type="text/javascript">CKEDITOR.replace( '<%$name%>',{ width: '100%', height: RT.Config.MessageBoxRichTextHeight });</script>

%# --- Add just bove <%INIT> ---

This basically already converts the Wiki Text area into a Rich Text area. However, technically, if you enter wiki markup into the field it would now still format that markup. Something I find unnecesery since you now have a WYSYWIG editor at your finger tips.

So we now make sure that the Wiki Text custom field is used as if it's a normal text custom field, the following does this by creating a symbolic link in the local directory:

ln -s /opt/rt4/share/html/Elements/ShowCustomFieldText /opt/rt4/local/html/Elements/ShowCustomFieldWikitext

You can now restart RT, make sure to empty the mason_data/obj directory:

service apache2 stop && rm -rf /opt/rt4/var/mason_data/obj/* && service apache2 start

And voula, you now have a rich text custom field which you can use wherever you feel the need.

Adjust the theme to fix line breaks

Even though all of this works, I've noticed that RT shows allot of empty space for line breaks. To fix this you can edit your current theme with the theme editor, add the following lines:

/* CF Value styling */
.value br { display: block; margin: 5px 0 0 0; line-height: 5px; content: " ";}

Customize the appearance of your Rich Text editor

RT uses CKEditor, by default it comes with a certain configuration which might not be what you prefer in your installment.

Creating the following file with allows you to change this default/behaviour:

nano -w /opt/rt4/local/static/RichText/config.js

This is the configuration that I'm currently using:

 * @license Copyright (c) 2003-2013, CKSource - Frederico Knabben. All rights reserved.
 * For licensing, see LICENSE.html or http://ckeditor.com/license

CKEDITOR.editorConfig = function( config ) {
	// Define changes to default configuration here. For example:
	// config.language = 'fr';
	// config.uiColor = '#AADC6E';
  config.toolbar = 'Full';

config.toolbar_Full =

config.enterMode = CKEDITOR.ENTER_BR;
config.shiftEnterMode = CKEDITOR.ENTER_P;
config.enableTabKeyTools = true;
config.htmlEncodeOutput = false;

config.disableNativeSpellChecker = false;
config.browserContextMenuOnCtrl = true;

config.toolbarCanCollapse = false;
config.toolbarStartupExpanded = true;
config.font_names =
    'Arial/Arial, Helvetica, sans-serif;' +
    'Courier New/Courier New, Courier, monospace;' +
    'Georgia/Georgia, serif;' +
    'Lucida Sans Unicode/Lucida Sans Unicode, Lucida Grande, sans-serif;' +
    'Tahoma/Tahoma, Geneva, sans-serif;' +
    'Times New Roman/Times New Roman, Times, serif;' +
    'Trebuchet MS/Trebuchet MS, Helvetica, sans-serif;' +
    'Verdana/Verdana, Geneva, sans-serif';
config.contentsCss = CKEDITOR.basePath + 'contents.css'; // won't need this after ckeditor 4.3.2

This changes the Rich Text editor into the following style (this is how I use it at the moment):

Pro's and con's

Even though this works, it does have some conditions that come with it.

  1. This isn't “core” functionality of Request Tracker so it might get broken during updates. (proper testing is a must)
  2. These custom fields are always quite “big” because of the top bar and the default styling of using 100% width. This is fine for Articles but could be annoying when using this Custom Field somewhere else.
  3. There are also a few things that aren't working as well when using this in Articles:
    1. The feature to create tables doesn't work. This is a result of the custom fields themselves being in a table and having a table within a table doesn't really work…
    2. It loses formatting when inporting the content of a Article page into a ticket. e.g. default e-mails, instructions, etc. (a shame, would be nice if it kept it's formatting). But, even without formatting the content is displayed properly (not that different from plain text).

But, on the flip side, the wiki text custom field can be used in Articles for a fully formatted knowledgebase which helps the support desk and makes documenting things allot easier for those that don't want to learn wiki markup.


// Wiki: *nix - Bonnie++

I've added a wiki page on how to use Bonnie++ with a few reference links.

Haven't heard of Bonnie++? Bonnie++ is a benchmark suite that is aimed at performing a number of simple tests of hard drive and file system performance. And the best part is that it's entirely via the commandline ^_^

Go check it out it's pretty cool!


// Wiki: Request Tracker - RT::Extension::QueueChangeOnUpdate

I've added a new section to the wiki, Request Tracker, and the first addition is a simple plugin which will add a queue change box to your update (comment/reply) page.


// Mac OS X Server - Microsoft Office & network homes issues

In an earlier post I've hinted to an issue concerning Microsoft Office when using it in a networked Mac OS X environment and that it would be solved by using NFS instead of AFP for mounting home directories.

This however was an incorrect assumption, the whole story is listed in this 5 year old post on Mac OS X Hints:

Bottom line is that when you use network homes on a Mac (ever since OS 10, or maybe even longer), then Microsoft Office will expect a “.TemporaryItems” directory in the root of the mounted volume. In most cases it would be inside the root of the “Users” folder on the server.

As I would expect for most organizations, we don't use the “Staff” group. We follow the Unix convention where your primary group has the same name and GID as the username and UID. So the default rights on the “.TemporaryItems” directory usually are wrong from the start. (root:staff)

On top of that, as would be normal a regular user can't create or modify directories in the root of the “Users” folder on the network so the problem can't be fixed automatically either + in most cases the “.TemporaryItems” directory doesn't even exist.

In order to solve this you have to create the “.TemporaryItems” folder inside the root of the “Users” folder located on the server:

$ cd /path/to/volume/or/sharepoint/Users
$ sudo mkdir .TemporaryItems
$ chmod 1777 .TemporaryItems

This is a slightly modified version of the Mac OS X Hints article. Our users don't have a group “Staff” so setting the group doesn't really solve anything. So we just want everyone to be able to write inside this group, thus setting the “Others” to read and write as well instead of no access.

The content of the “.TemporaryItems” directory is quite safe, regular users will have their own directory inside this one (numbered) which has their own UID + primary GID which in our case is user specific. So nobody can access content from another user.

We've also tried making a symbolic link from “/tmp” to “.TemporaryItems”, this however didn't seem to work regardless of the rights. So, your sadly forced to do it as stated in the Mac OS X Hints article.

This solution should work for both NFS home directories (e.g. your Mac is a client inside a regular Unix network, or you use NFS shares on your Mac OS X Server) and AFP home directories.

As some comments mentioned in the Mac OS X Hints article, this issue might date back to Microsoft Office 98 for Mac and is still persistant in Microsoft Office 2011!

Hopefully someone will find this useful, it took us quite a long time to find the problem due to the brilliantly vague errors from Microsoft Office. Though in the end they were right, users really didn't have rights to read or write. But PLEASE tell us where it's trying to write!!!!!!


// Wiki: Mac OS X - OD Scripts

These are a few scripts we use for registering and unregistering Macs to an OD server.

Quite useful for those that administer allot of Macs, they save you some manual labour.

Recent Comments
QR Code: URL of current page
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported