How we made trac customer friendly
Tue, 25 Sep 2007 | Permalink | Tags: programming
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
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.- TracAccountManager
- TracCustomFieldAdmin
- TracWebAdmin
- TracPrivateTickets
- TracSimpleTicket
- TracPermRedirect
- TracContentFilter
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
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