Blog's control panel: | Home | Tags | Index | Rss 2.0

How we made trac customer friendly

Tue, 25 Sep 2007 | Permalink | Tags:

I have some friends running a music digital promotion company and I recently got them on Trac. They simply loved it, and kept on saying for weeks they couldn't believe they worked without such tool. Face it, especially if your business is software development, living without a SCM/project management system is a suicide.

A few things to say about Trac before starting

At the time of writing the stable version of trac is 0.10.x. The development version introduces some major innovations and quite a lot of stuff in terms of plugin isn't compatible. That said there's lots of improvements in the plugin framework as well, and more and better things are now possible. 0.10 is rock solid but presents several limitations and it's quite hard to customize the interface, which as you might guess it's a crucial point for a customer facing product.
It's not non-techy friendly and plugins lack documentation, one of my friends found quite tricky dealing with a couple of them.
Also user management is quite unusual and raises a brow in anybody familiar with the classic user form registration and idea of user record. It's so unusual that it could be said of non existing.... Users are actually htpasswd like accounts which are then used by apache for the authentication; everything else revolves around session keys, which are available to anonymous users too. I dont know you, but to me session means something temporary and generally short lived, maybe a few hours, not longer, but most surely it doesnt suggest me anything permanent as a user and its metadata should be. Basically you set your email and name and get this session key which fills in those details for your when you raise tickets etc, which means you can pretend to be whoever you want, including other registered users. To be fair the user/password is there so the session can be associated to it and one could make a visual distinction between registered users and anonymous ones. Also, there are advantages for anonymous users, which is the main driver being this implementation.

Functionalities from a user perspective

One of my friends' mission is to make things for users as simple as possible and to me they've done really well on their business site, altho I'm the last person that should talk about usability, I have no ideas whatsoever of what the average user expects and most of those things look awkward to me.
The only 4 available things:
  • Login/Logout
  • View tickets
  • New ticket
  • Help
New ticket should use simple ticket (see below) to offer customer a simplified form containing only subject, description of the bug, and type, with latter being wish or bug.

The plugins

Trac alone is far from ready even for non-tech users, let alone customer. You need to install at least 7 plugins, 3 admin side and 4 users side. Admin side there isn't much to explain, those 3 first plugins are pretty much standard, last one being integrated with 0.11. TracPrivateTickets is necessary so customers wont be able to see each other's ticket, TracSimpleTicket gives them a simple newticket form where you can take out all the fields like milestone and priority which is up to the staff to decide upon; anonymous users should only be allowed to view the wiki, everything else requires a login and TracPermRedirect allows you redirect to the login form rather than displaying an error;TracContentFilter is a very simple plugin to allow some on the fly content modifications necessary to simplify bits and pieces of the interface.

Components and trac.ini

This is a list of what components you should enable/disable to get a completely locked down instance and limit the available features the the minimum customers require:
[components]
acct_mgr.admin.* = enabled
acct_mgr.api.* = enabled
acct_mgr.db.* = enabled
acct_mgr.htfile.* = enabled
acct_mgr.htfile.htdigeststore = enabled
acct_mgr.http.* = enabled
acct_mgr.http.httpauthstore = disabled
acct_mgr.pwhash.* = enabled
acct_mgr.pwhash.htdigesthashmethod = enabled
acct_mgr.web_ui.* = enabled
acct_mgr.web_ui.registrationmodule = disabled
contentfilter.filter.* = enabled
customfieldadmin.api.* = enabled
customfieldadmin.customfieldadmin.* = enabled
permredirect.filter.* = enabled
privatetickets.api.* = enabled
privatetickets.query.* = enabled
privatetickets.report.* = enabled
privatetickets.search.* = enabled
privatetickets.view.* = enabled
simpleticket.web_ui.* = enabled
trac.db.mysql_backend.mysqlconnector = disabled
trac.db.postgres_backend.postgresqlconnector = disabled
trac.mimeview.php.phprenderer = disabled
trac.search.searchmodule = disabled
trac.settings.settingsmodule = disabled
trac.ticket.report.reportmodule = enabled
trac.ticket.roadmap.milestonemodule = disabled
trac.ticket.roadmap.roadmapmodule = disabled
trac.timeline.timelinemodule = disabled
trac.versioncontrol.web_ui.browser.browsermodule = disabled
trac.versioncontrol.web_ui.changeset.changesetmodule = disabled
trac.web.auth.loginmodule = disabled
trac.wiki.macros.recentchangesmacro = disabled
trac.wiki.macros.titleindexmacro = disabled
trac.wiki.macros.tracinimacro = disabled
tracauthrequired.* = enabled
webadmin.basics.* = enabled
webadmin.logging.* = enabled
webadmin.perm.* = enabled
webadmin.plugin.* = enabled
webadmin.ticket.* = enabled
webadmin.web_ui.* = enabled

Permissions

With regard to permissions you want to have a user with TRAC_ADMIN privileges and then a group called customers or similar you then assign all your users to. The group should have the following permissions:
  • REPORT_VIEW
  • TICKET_APPEND
  • TICKET_CREATE_SIMPLE
  • TICKET_VIEW_REPORTER
TICKET_APPEND is necessary to allow file uploads via the simpleticket page. TICKET_VIEW_REPORTER is what you need to achieve tickets isolation between customers. TICKET_CREATE_SIMPLE is what gives you the simpleticket form.
To be noted that at the time of writing the simpleticket plugin doesnt play well with TICKET_VIEW_REPORTER, see this bug report

Templates

Lots of customizations need to be done in this area and overriding default templates is as easy as copying them from the site wide installation to $instance/templates/. Some of the things we've done are introducing static links in the metanav and completely removing the context navbar from everywhere.

Reports

We settled down to one single report showing the tickets opened by the customer, which means selecting reporter = $USER. Here's the sql:
SELECT id AS ticket, summary, 
   t.type AS type, time AS created, changetime as _changetime,
   description AS _description,
   reporter AS _reporter,
    (CASE t.status WHEN 'closed' THEN '' ELSE owner END) AS 'waiting for', 
   coalesce(resolution, '') AS 'resolution'
  FROM ticket t
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
  WHERE reporter = '$USER' AND NOT (status = 'closed'
    AND changetime < strftime('%s', 'now', '-14 days'))
  ORDER BY (status = 'assigned') DESC, t.status, p.value, t.type, time

Conclusions

These are the basics, then there's a lot more work involving writing help pages, further customizations of the look and feel and similar. The guys are really happy about it, it makes tracking customer's problems a lot easier and it's also very useful for feature requests polls to get feedback.




SpikeLab.org is a Filippo Spike Morelli copyright 2005-2008
This work is licensed under Creative Commons Att-SA License.