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.
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:
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:
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.)
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.
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:
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:
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.)
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.
@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.
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.
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.
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:
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.
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.
© 2022 - 2024 — McMap. All rights reserved.