Tag Archives: trac

Posted on
by

Just a quick note here primarily for my own reference, but also hopefully to save anyone else the faff of getting this set up.

In the arms race between Eclipse and Netbeans, it is Netbeans which seems to have jumped ahead in terms of usability and stability. Unfortunately it does not have Trac integration, forcing you to use the web interface (and as I’ve previously remarked, pretty much all bug trackers are only worth using if you use an API interface).

Cubeon provides Trac support, however it has a real problem with self signed certificates when using SSL. Using their faq over here provides only part of the solution if you happen to be using multiple virtual hosts over SSL.

The gotcha is that only one SSL certificate can be served per IP address/Port combination, and the default one generated by Debian’s setup scripts is for localhost only. In my case I had multiple subdomains of my main site and I could not bind a certificate to a specific vhost to the exclusion of all others.

My solution:

  • Generate a self signed certificate for the server and install it on your vhosts, but when you’re asked for you Common Name enter a wildcard – so instead of www.example.com enter *.example.com.
  • Download and install this certificate in your local keystore, as explained in the faq. Replace <your-server-alias-here> with the address of the Trac server under the wildcard domain e.g. trac.example.com
  • Set up a Trac repo in cubeon, be sure to disable ssl verification (which would otherwise complain about the self signed cert)

Simples, YMMV.

Posted on
by

Trac_Logo_512x512There are a number of ways that an Elgg plugin developer can manipulate views via the powerful Elgg views system.

Most Elgg programmers are by now familiar with extending or replacing existing views, or providing new views for new objects etc.

But what if you just wanted to make a simple tweak to an existing view – for example to replace all instances of rude words in a feed article, or to turn passive links into active ones?

Well, fortunately Elgg provides a post processing hook for views which can do just that.

After every view has been generated, the framework will trigger a plugin hook called “‘display’, ‘view'”. This hook is passed a parameter ‘view’ which contains the name of the view being processed (eg. object/blog).

The contents of the view are passed in the $returnvalue variable which you can perform any processing on before returning it from the hook.

I have just uploaded a Trac tags plugin to the Elgg community site which provides a good example of this.

The Trac tags plugin is a tiny plugin which uses the views post processing hook to turn Trac links (e.g. #xxxxx for tickets and [xxxxx] for changesets) into active links into your repository, and here’s how – first we register the hook:

function tractags_init()
{
....
// Register our post processing hook
register_plugin_hook('display', 'view', 'tractags_rewrite');


// define views we want to rewrite codes on (means we don't have to process *everything*)
$CONFIG->tractags_views = array(
'object/thewire',
'object/blog'
);

....
}

Then in our handler looks something like this:

function tractags_rewrite($hook, $entity_type, $returnvalue, $params)
{
global $CONFIG;

$view = $params['view'];

if (($view) && (in_array($view, $CONFIG->tractags_views)))
{
// Search and replace ticket numbers
$returnvalue = preg_replace_callback('/(#)([0-9]+)/i',
create_function(
'$matches',
'
global $CONFIG;

return "<a href=\"{$CONFIG->trac_baseurl}ticket/{$matches[2]}\">{$matches[0]}</a>";
'
), $returnvalue);

// Search and replace changesets
$returnvalue = preg_replace_callback('/(\[)([0-9]+)(\])/i',
create_function(
'$matches',
'
global $CONFIG;

return "<a href=\"{$CONFIG->trac_baseurl}changeset/{$matches[2]}\">{$matches[0]}</a>";
'
), $returnvalue);

return $returnvalue;
}
}

I’m sure you will be able to come up with some much more interesting uses!

Image from the Trac project.

Posted on
by

Over on his blog, my good friend and colleague Ben has written a good post about bugtrackers. He is essentially complaining that there are currently none available that are good for both developers and end users.

Broadly speaking I agree with him. The two main players – Bugzilla and Trac – are both lacking. Bugzilla’s interface has notable usability issues, and trac too is somewhat lacking.

In both cases however, the core functionality of what a bugtracker actually does – a prioritised and editable todo list – works perfectly.

The problem is interface.

How do we create one that is useful to both developers (who need quite detailed settings) and end users (who need a simple interface and in many cases need a certain amount of hand holding in order to fill in a report which is useful to the developer)?

Thinking back to my usage of both Bugzilla and Trac – the answer is that we don’t.

Let me explain: I have used both Bugzilla and Trac in anguish on large projects for many many years, but I have hardly ever used the default interface – currently I use the excellent Mylyn (nee Mylar) for Eclipse. For me a bugtracker is a central todo list accessible from anywhere – combined with a central svn repo it becomes possible for me to continue to do work anywhere there is a computer and internet connection… invaluable if you spend any amount of time travelling.

It seems to me that a good approach would be to have the bug tracker entirely API driven (more so than it is now – which in many cases is a later bolt on), that way it would be possible to provide a variety of expert interfaces for developers and a simplified interface for end users – rather than having one interface try and do it all.

This interface should hold peoples hand and ask specific targeted questions to encourage non-programmers to provide reports which will be useful to developers.

Tagging (and tag clustering) could be a useful technique to then group issues together – making it easy to find related issues and to spot duplicates.

Building on some social technology to establish relationships between issues, comment around them and attach files and other media could also be useful.

If the underlining engine is the same this shouldn’t involve too much in the way of work duplication, but will allow for tighter integration with the tools and workflow people actually use.