Trac - suggested permission levels for developers & managers

Question

I'm a fan of Trac, and of course when I'm just using it for my own, lone, projects I can just give myself full admin rights.

When there are other developers involved, or a not-very-technical manager (or, for that matter someone that is a designer rather than hard-code developer), that needs to be able to keep up with what is happening - and do things like add/update tickets, but not potentially break anything, then the fine-grained nature of the permissions gets to be a little more complicated as to what is required for someone.

What permissions do you use for those groups of people (and other similar ones)?

Answer 1

I typically turn on all the VIEWs, plus WIKI_CREATE, WIKI_MODIFY, TICKET_CREATE (or TICKET_CREATE_SIMPLE if using the Simple Ticket plugin) and TICKET_APPEND.

For users I trust to have a little more power, I'll also turn on TICKET_MODIFY.

For a non-technical manager, I'll also turn on MILESTONE_ADMIN. For a technical manager, I'm likely to jump to TRAC_ADMIN -- but if that's too far, at least add REPORT_ADMIN.

Typically, I'll go ahead and give the developers TRAC_ADMIN... but if you don't trust them that far, the above permissions through the power user level plus TICKET_ADMIN are probably sufficient.

Answer 2

I generally avoid giving the *_ADMIN perms to users if I can avoid it. Trac 0.11 makes that a little easier by adding TICKET_EDIT_DESCRIPTION.

Depending on the setup and the culture, I'll grant the *_VIEW permissions to authenticated (everyone who has logged in) or in lax setups, anonymous (everyone, even not logged in).

I will generally create a developer group, grant the various permissions to that group. Then you just add people to the group (or add the group as a permission to the user, same thing). Do the same for designer, manager, tester, etc.

A manager would want the various ROADMAP_* and MILESTONE_* permissions. I'd be cautious about REPORT_ADMIN unless the manager actually knows SQL. My boss is generally happy to give me an example spreadsheet of the report he wants and I'll whip up a report for him. Be sure to point out to them that if they setup a custom query that does what they want, they can bookmark it -- everything is in the URL -- so they can go back to exactly that same query with current data using that bookmark.

You'd probably want to let authenticated file and append to tickets--doesn't usually who notices a bug, you still want to know about it. If you lock down the workflow permissions enough, you may be able to give out TICKET_MODIFY to more people as well, though that route will be a bit more work.

Those you have some trust in can probably be granted TICKET_EDIT_DESCRIPTION so they can fix up their bug report formatting when they forgot to to start with.

If you have a lead developer, that individual user should probably have TICKET_ADMIN to deal with adding versions and such.