views:

1605

answers:

7

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.

+16  A: 

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.

Dave Dunkin
So there isn't a way to restrict the view that the client has to achieve this?
torial
I don't think you can restrict a user to only view some tickets and not others, or some comments of tickets.
Dave Dunkin
Seems to violate DRY (Don't Repeat Yourself). Maintaining data in two places is a recipe for inconsistency and lost items.
Mystere Man
Trac is open source and this seems like restricting which tickets to view would be a pretty easy feature to add.
Eli
@Eli - Yes, you could add it, but I don't think it would be easy. You would have to make sure you cover all the different ways to view tickets (reports, macros, etc.) and the usability would be tough to get right.
Dave Dunkin
@Mystere Man - I don't think it's a violation of DRY because the info in my tickets is very different from the info I want to communicate to my customer. What I want the customer to see is more along the lines of the roadmap, but even that can be misleading. It all depends on the customer.
Dave Dunkin
+3  A: 

@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.

ceejayoz
any free alternatives to Basecamp?
torial
Basecamp is free for small projects. There's an anti-37signals site that has a list of Basecamp alternatives - http://www.whybasecampsux.org/#alternatives (site's a fun read, heh)
ceejayoz
You can also have two instances of Trac, one public facing, the other internal. Worked fine here.
agnul
Thanks for the additional link, I'll take a look!
torial
+5  A: 

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.

Jon Topper
+3  A: 

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.

Anders Eurenius
+3  A: 

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.

Oliver Giesen
+3  A: 

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.
Bob Nadler
I'm new to trac, but I discovered you can use Custom ticket queries trac.edgewall.org/wiki/TracQuery along with Authz based wiki control trac-hacks.org/wiki/WikiRbacPatch to restrict ticket view based on the user. Am I right?
Amit Kumar
I've never used WikiRbacPatch, but based on the documentation the added access control would only apply to wiki pages. I do not believe this patch would affect the results of a custom query.
Bob Nadler
+7  A: 

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.)

Brian Schimmel