CODEWITHSUNDEEP
svnproject-managementtrac
torial
torial

Reputation: 13121

How can I best take advantage of Trac?

I have a Trac project installed on top of a Subversion implementation (easy to do thanks to Webfaction's control panel), but now I have configuration work to do. With that in mind, are there easy ways to do the following in Trac:

1) Ensure that customers can only see a high level progress indicator.
2) Give daily summary reports on tickets, testing, and tasks.

Also, I am interested in knowing if there are any highly recommended plugins that I would be sorry I forgot to install.

Upvotes: 16

Views: 2574

Answers (7)

Lena Schimmel
Lena Schimmel

Reputation: 7493

1) high level progress indicator:

The roadmap tab gives you kind of a high level progress indicator. It lists all milestones, and for each milestone it shows you:

  • milestone title
  • short description
  • date on which the milestone is due
  • how much time is left until then (or how long you are behind you schedule)
  • how many tickets are assigned to that milestone and how many of them have been closed, visualized as a nice green progress bar. This bar is drawn on the assumtion that each ticket has the same weight, which might be misleading

You can restrict your permissions in a way that your customer can only access this view.

Depending on the relationship between you and your customer, you might want to give him the ability to create new tickets (permission TICKET_CREATE), which should be possible without giving him read access to other tickets (TICKET_VIEW and TICKET_MODIFY). Sorry, but I can't currently test if this really works, maybe someone can comment on this.

2) daily summary reports

trac offers you RSS feeds for everything you can think of. It should be possible to generate daily reports from this, or you simply tell your RSS client to check the feed once a day.

Trac also has the abilty to inform a ticket-owner via mail if that ticket changed, but it will happen instantly, not as a daily summary. You can comment on tickets, and sometimes we use them like a discussion board or mailing list, and in this case it's good to be notified instantly.

Other configuration

In each project I do with trac, I create a custom query to list all tickets that nobody owns:

SELECT p.value AS __color__,
   owner AS __group__,
status,
   id AS ticket, summary, component, milestone, t.type AS type, time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
  WHERE status = 'new' AND (owner = '' OR owner = 'somebody'  OR owner = 'None' )
  ORDER BY owner, p.value, t.type, time

Each ticket may have an owner and several people in the cc field, but the report for my tickets only lists those where you are the owner. To overcome this, I add a query like this:

  SELECT p.value AS __color__,
   (CASE owner WHEN '$USER' THEN 
     (CASE status 
       WHEN 'assigned' 
       THEN 'Tickets that you accepted' 
       ELSE 'Tickets that were assigned to you, please accept or reassign' 
      END) 
     ELSE 'Tickets, that have your name in the cc' END) 
     AS __group__,
   id AS ticket, summary, component, version, milestone,
   t.type AS type, priority, time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t
  LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
  WHERE t.status  'closed' AND (owner = '$USER' OR cc like '%$USER%')
  ORDER BY owner, (status = 'assigned') DESC, p.value, milestone, t.type, time

(this code works in trac 0.11b)

That's my favorite ticket report. It goups tickets by three classes:

  • Tickets you own and accepted
  • Tickets that were assigned to you, but you didn't accept yet
  • Tickets that have you in the cc (that the fancy thing you don't get without that query)

The queries might look scary, but they are simple modifications of the queries that are already there. You don't have to hack the trac source code, the webinterface lets you edit queries.

Plugins

I recommend the XML RPC plugin if you work with eclipse. It enables tight integration with Mylin. (I think basic integration works even without the plugin), so your developers can do many tasks from within eclipse without switching to the trac webinterface.

(If you use eclipse, but don't know mylin, you should have a look at it. You can test it without any configuration because it comes with most eclipse distributions and can work as standalone without trac.)

Upvotes: 8

Bob Nadler
Bob Nadler

Reputation: 2765

As mentioned in one of the comments, you can't restrict ticket or comment access based on the user. Finding or creating an external reporting system is your best bet.

A couple of things based on experience with Trac:

  1. Creating a custom workflow is pretty straight froward. The use of GraphViz is a huge help for communicating states and actions. A workflow plugin (like AdvancedTicketWorkflowPlugin) that further extends the built-in functionality isn't too hard to do if you need more complex state interaction.

  2. For custom reporting, you can write SQL queries that take named parameters, then link to these from a wiki page:

For example, the query can contain a WHERE clause like this:

WHERE datetime(t.changetime, 'unixepoch') >= datetime('now','-$DAYS days')

and the wiki page can have this:

Show activity for last [http://server.com/trac/report/9?DAYS=8 8] days.

Upvotes: 3

Oliver Giesen
Oliver Giesen

Reputation: 9429

You could probably withdraw all permissions except ROADMAP_VIEW from the anonymous user but that will probably be a bit too high-level, no? Access control at the individual ticket or comment level is currently not supported AFAIK. See http://trac.edgewall.org/wiki/TracPermissions for details about trac permissions.

Upvotes: 3

Anders Eurenius
Anders Eurenius

Reputation: 4226

If it's a stock install, the database is just an SQLite3, so you can easily write scripts to fetch "safe" info, like the number of tickets, or why not one of the reports. That way, you can discuss freely as long as the ticket name is ok. Revisions, milestones, wikipages, tags (if you use that plugin) are also available.

Upvotes: 3

Jon Topper
Jon Topper

Reputation: 3097

As far as additional plugins are concerned, we install TocMacro, XmlRpcPlugin, WysiwygPlugin and TracRedirect. In particular, the WYSIWYG plugin is really good for encouraging less technical staff to maintain their own documents in the wiki - you can even C&P from MS Word whilst retaining formatting, which helps.

Take a look at the custom ticket workflow stuff that Trac gives you, if your own workflow isn't well represented by Trac's defaults. This has allowed us to add code review and integration testing steps to the workflow.

I'd recommend making your Trac server authenticate against some central authentication framework. We run an LDAP tree with auth credentials in it, and this is used by all our internal systems - including trac, svn, samba, openvpn etc.

Upvotes: 5

ceejayoz
ceejayoz

Reputation: 179994

@Dave Dunkin is right. Use Trac for your internal use, and use a system like Basecamp to give your clients a high-level overview of what's going on in the project.

Upvotes: 3

Dave Dunkin
Dave Dunkin

Reputation: 1107

I would not recommend using the same Trac project for tracking development tasks and showing the customer progress. You want to be able to be candid with your development tickets, comments, etc. Customers can focus on the wrong things and misinterpret data you put in the tickets. I would recommend providing the customer with a separate project that contains high level tasks and only shows the progress on those tasks, not the nitty gritty.

Upvotes: 17

Related Questions